[ArchOversight]

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.

[dwaite]

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

[dane-pgp]

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

[dwaite]

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)

[floatingatoll]

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?