I'm curious about "Apple Anonymous Attestation". Is Apple taking on any liability by providing this service or is this all done on hardware through private APIs?
It is only for Apple Devices, and all it does is allow them to easily disable attestation and thus (is this device used for auth secure) for a singular TouchID/FaceID.
Instead of with Yubikey where if the attestation key is compromised, and it is blacklisted, they disable every single last device manufactured with said attestation key.
all future attestations. U2F/webauthn doesn't actually provide a revocation mechanism.
> Instead of with Yubikey where if the attestation key is compromised, and it is blacklisted, they disable every single last device manufactured with said attestation key.
it is important to note that there is not a "the" attestation key. there are many. "disabling" one, to the extent that is even possible, disables only the group with that key.
Attestation is just a technical term in the WebAuthn API. Different authenticators can use different attestation data formats. Apple rolled their own, hence the name.
Apple didn't just roll their own though, they improved upon it by allowing them to easily revoke attestation for a particular implementation without affecting all other devices out there.
So if an attacker tampers with the physical device, they can revoke the key for that particular device so that it is no longer trusted (the way I am reading it) vs yubikey where if an attacker has messed with one key, there is no good way to revoke attestation for that one device.
> So if an attacker tampers with the physical device, they can revoke the key for that particular device so that it is no longer trusted (the way I am reading it) vs yubikey where if an attacker has messed with one key, there is no good way to revoke attestation for that one device.
Attestation is a statement that the hardware and firmware are genuine, with the trust model being based on genuine hardware/software. You would not typically revoke anything - third party trust in that hardware/software combination would go away. That might be for example all iOS versions below 14.2, or all iPhones before the A14 chip.
If your service cares that much about key policy, you remember the attestations of each key so that you can change how they apply to security policy. That might be, for example, allowing someone to authenticate into a lower security level until they re-register the phone after upgrading their operating system.
In that sense, Yubico has a disadvantage in that their security policy does not allow firmware updates, so any firmware compromise will permanently tarnish those manufactured keys.
> allowing someone to authenticate into a lower security level until they re-register the phone after upgrading their operating system.
Instead of "This site requires IE6" we'll have "To log back into your account, please buy an iPhone 12 Pro Max and re-register".
I'm imagining an undesirable future where having access to different sites requires carrying around multiple different pieces of authentication hardware, and the user has to keep track of which device is needed for each site. Still, that might be better than a future where all sites mandate using an authenticator made by a specific monopoly company/government, assuming we can avoid that.
Firefox and Chrome both prompt before disclosing the attestation information of your key, adding a UX tax to asking for attestations.
The protocol also does not have a way to get the browser to 'filter' potential authentication methods to just say a google titan key or iPhone 12. So while sites might determine whether to show the authentication options by scraping user agents like they always have, they can't get the browser to handle the user tapping the wrong kind of key. Instead, the browser has to repeatedly inform the user of what went wrong and drive the user through registration/authentication.
So websites _can_ restrict things to a particular form of authentication, but in many cases it may lead to a sub-par user experience. They may also need to tune this repeatedly, for instance to allow other browsers once Apple makes this available to them, or say pushing the authentication experience from desktop to phone or watch.
Since Android and Windows Hello support the same API, platform restrictions in particular have been just asking for more rope to hang yourself with. Such restrictions have been required up to this point because the platform support has been spotty (with Android being the current third place)
Can this Attestation be safely issued from macOS running on Apple Silicon, conditional on whether the user has disabled various hardware/software security features on the Mac?
When this was pre-announced awhile back I highlighted the lack of anonymity, due to the Apple secure element (T2 on laptop/desktop; whatever the name is on mobile) lacking attestation capability. That comment was downvoted by folks that presumably don't understand the problem at hand.
In that pre-announce video Apple dared to insinuate that attestation by current devices is de-anonymizing, when that isn't universally the case. And that their flavor of such would be "actually" privacy preserving. At the time, I figured this (a remote service) would be how they would address it, as the secure hardware probably doesn't have the burned in capability. Largely due to Apple needing to do it their own way.
Now of course, like the "normal" U2F attestation, this is private between the client and the service. But in Apple's case, like DOH, it is not private between client and Apple. IOW, a decrease in privacy, but marketed as an increase! LOL, classic Apple!
They go even further in their blind denial by stating:
> this approach avoids the security pitfall of Basic Attestation that the compromising of a single device results in revoking certificates from all devices with the same attestation certificate.
without recognizing or acknowledging that there is still a single point of compromise, but now it's a cloud service which many engineers have access to and presumably isn't 100% impervious to outsider attack either. So yes, it may avoid the single device security pitfall (resulting in a largish group of devices requireing to be revoked), but it trades it for an even bigger pitfall of all devices everywhere needing to be revoked!
It's sad that the reality distortion field has to be extended to privacy and security. Apple could easily just present their take on it without confusing the issues for the sake of marketing.
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. With "standard" attestation, it's up to the user in their decision of what token (security key) to buy, and is always in effect. That said, a non-attested enrollment, if done correctly on the client side, doesn't give up privacy; just security.
To answer your question, it depends what you mean by "taking on". Yes, Apple is assuming some risk. They are not taking on any liability in the legal sense.
> 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.
> 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.
> 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.
> 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.
Instead of with Yubikey where if the attestation key is compromised, and it is blacklisted, they disable every single last device manufactured with said attestation key.