[dwaite]

> In that pre-announce video Apple dared to insinuate that attestation by current devices is de-anonymizing, when that isn't universally the case.

Most hardware devices use batch attestation, where some group of (say, 100 000) keys all get the same private key. This does still provide some data for correlating users based on make + model + batch of their authenticators.

ECDAA was meant to be an approach to solve this with pairing-friendly curves and crypto, but the industry stayed clear of this as an unproven algorithm.

Apple (and the rather similar SafetyNet approach by Google) use a service. The interaction between the device and this service is black-box and we do not yet know how much information is exchanged. By its nature, this service can change in the future and we will not know.

However, it _could_ be limited to an RSA or EC-based DAA attestation from the Secure Enclave, a curve point on P-256, and a SHA-256 hash value to embed. There's no reason Apple needs to know either the specific piece of hardware or the site a user is going to.

> Further, it's up to the site to decide whether to use an anonymous attestation or not. The user will not be informed either way.

Several browsers will give the user the option to not send attestation if a site asks for it, to the point where capturing attestations is a UX-impacting action. You could say the UX impact is intentional - not only do basic attestations leak some tracking information, but they limit user choice in how to authenticate.

[jiveturkey]

> There's no reason Apple needs to know either the specific piece of hardware

In order to revoke a specific device without cooperation of the device itself, which is one of their advantageous claims, they do.

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.

Honestly, Apple is derelict in not describing this in more detail. Had they not made claims, it would be ok. But they are directly claiming to be better. I think we can be 100% certain they are aware of this depth of detail internally. Apple is not amateur hour.

[dwaite]

> 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.

[dwaite]

> In order to revoke a specific device without cooperation of the device itself, which is one of their advantageous claims, they do.

My understanding is that there are methods to revoke a particular group key under DAA, which would prevent that device from being able to retrieve attestations in the future.

That said, revoking individual devices is somewhat nonsense from a security point of view. There's nothing (other than the difficulty of the hack itself) that prevents a compromise of one phone from being replicated across the entire production line, which impacts the security reputation of the entire line.

Also, it is hard to imagine the use case for identifying and revoking the attestation for a single user's devices that isn't troubling.