> Disregarding that property, Apple needs to know that the "CSR", ie attestation request, is coming from the secure enclave. That means that the "CSR" needs to be signed by some key. If the CSR signing key is unique per device, Apple receives device-specific information. This can't be an ephemeral key, as there wouldn't be a chain back to the secure element. If OTOH the CSR signing key is shared, it is probably exposed, or at least accessible for malicious signing, via the now known T2 compromise. There is much to be gained by such an exploit, so this isn't merely a thought exercise.
> This complexity is all avoided by on-device attestation. EPID or EPID-like scheme could have been used, vs batch attestation.
EPID is a DAA scheme. _If_ Apple is using a DAA scheme to their attestation service, then you would use that to protect the equivalent of a CSR (which really should only need the public point and hash of the creation request).
The intermediate service exists to hide the choice of DAA scheme (and needs to potentially require things like BN curve cryptography to handle it), and to do other value add logic. For example, the attestation format is extremely similar to DeviceCheck attestations, which assert hardware/os/application authenticity for a third-party remote service call.
> This complexity is all avoided by on-device attestation. EPID or EPID-like scheme could have been used, vs batch attestation.
EPID is a DAA scheme. _If_ Apple is using a DAA scheme to their attestation service, then you would use that to protect the equivalent of a CSR (which really should only need the public point and hash of the creation request).
The intermediate service exists to hide the choice of DAA scheme (and needs to potentially require things like BN curve cryptography to handle it), and to do other value add logic. For example, the attestation format is extremely similar to DeviceCheck attestations, which assert hardware/os/application authenticity for a third-party remote service call.