Do Passkeys even support attestation? What would they even attest to, given that the credential is effectively not bound to any secure hardware?
To my knowledge, Apple has ripped out their "anonymous attestation" service together with introducing Passkeys in iOS 16; before that, requesting attestation was an option to opt out of Passkey syncing (and create a device-bound credential).
I'd love some kind of reference for this. I'm hoping you're right.
My understanding is that iOS does still very much support attestation (https://support.apple.com/guide/deployment/managed-device-at...) but I would be very happy to be proven wrong about that. I think attestation is harmful and should never have been part of the spec.
> What would they even attest to, given that the credential is effectively not bound to any secure hardware?
Originally at least, passkeys did support attestation in the form of reporting which authenticator had issued the passkey. Again, I would love for that to change. If Apple went full-anonymous with its passkeys and did not even sign the request to verify it was coming from an Apple device, that would be a really big deal for me. It would effectively make it impossible for any serious service to block anonymous attestation.
But my guess is that they probably just eased up on the hardware part of it and that they're still allowing requests to ask if the key is coming from an Apple device. Again, if anyone has documentation proving me wrong, please share it. I would love to check off the attestation problem from my list.
In my tests Apple refuses to provide attestation. I'm using Resident Key: required, User Verification: required and Authenticator Attachment left empty. With those settings registering a credential fails if I ask for attestation: "indirect" or "direct". Only "none" works.
My theory is that setting Authenticator Attachment to "cross-platform" (yubikeys and such) or "platform" (touch/face ID) might block cloud-synced credentials, in which case perhaps attestation: "indirect" still works. But I'm just guessing, I haven't tried it.
Or perhaps Apple anonymous attestation only works when using webauthn as a second factor (i.e. without Resident Key and/or without User Verification).
> Unfortunately, this also makes it a dealbreaker for me – I want some credentials to be device-bound and non-extractable.
Why do you need attestation to have that? You can still use a Yubikey and the like, if nothing else.
Or do you mean that you want to force the users of your service to only use credentials that are device-bound and non-extractable, I suppose. But then I would ask... why?
As an RP, due to regulatory or security requirements, for example:
Knowing whether I need to worry about my users' iCloud and Google accounts having been taken over or not is important for accurately evaluating the security posture of any service built on Passkeys as an authentication factor.
And as a user, I don’t trust Apple's or Google's sync backends enough to store my most important credentials there. Especially iCloud is frighteningly easy to hijack, even with a recovery code in place (which ironically at the same time increases the chance I’ll lock myself out as the legitimate user).
> And as a user, I don’t trust Apple's or Google's sync backends enough to store my most important credentials there
I'm not sure everyone realizes that you don't get a choice whether or not Apple passkeys are synced to iCloud, you can't create a passkey from Safari unless iCloud syncing is turned on.
Regardless of whether or not there's support for exporting/importing, you should as a user have the option to not send your passkeys to iCloud. That is a completely reasonable ask. There's really no system where synchronizing to the cloud and syncing between devices/ecosystems ought to be required for the user. I want users to have that option and I have some disagreements about whether services should be able to block it, but I do want it to be an option rather than a requirement.
My guess is that Apple is worried people will turn off syncing without knowing the implications, but... it should still be the user's choice. It's completely legitimate for someone to be annoyed about forced sync.
My main issue with attestation is that it's platform controlled instead of user-controlled and that it doesn't just bind a credential to a device, it binds an authentication mechanism to a category/subset of devices.
If the attestation part was separated from the manufacturer and it couldn't be used to identify who made the device or what brand the device was or what OS it was running, and instead was just a completely randomized device key with no other information with only the restriction that it was hardware-bound, would that be enough to meet your use case or would the user being able to update the OS/firmware still be a problem for you?
My problems with attestation in order:
1. Locking down the ability of the user to change the software/firmware.
2. Allowing the website to identify the device/manufacturer (and allowing them to restrict accounts to a subset of devices).
3. Not allowing the user to replicate/change the device/move the key.
But 1 and 2 are the biggest issues I have, if they went away then 3 wouldn't be as big of a deal to me. Not that I would be super-happy about it, I still don't think it would be a good idea, but... it's comparatively less of a problem.
I could imagine a version of this where you get one private key set on firmware/OS load for your device but it's completely random, and if you update the firmware and the integrity check fails the only thing that happens is that key changes to a new one and the old key is erased. So updating the firmware would invalidate the old login keys that were relying on attestation, but it would not make it possible for a site to block an un-Googled Android from making an account or to even know that you were using an Android/iOS device in the first place.
Again, I don't think that would be a good idea, I think it would be introducing a lot of foot-guns that shouldn't be exposed to ordinary users, but I don't think it would be nearly as much of a problem as saying "we guarantee this is one of X devices in this hardware batch, and that the OS hasn't been customized."
This would be great, but as it is, platform authenticators are effectively always a combination of trusted and untrusted hardware/software, since the TEE or Secure Element usually does not have user input/output capabilities and is relying to the application processor OS's integrity to some extent.
Notable exception: Google's Protected Confirmation [1] – the signature format of that is not natively WebAuthN/FIDO compatible, though.
I think Apple mentions it in a WWDC presentation as well, but I find it quite ridiculous to bury such a significant change in a video + transcript announcement.
To be honest, I think as it is, not providing attestation was the only way to not outright be in violation of the FIDO/WebAuthN specifications (which at the moment requires specifying whether a key is "stored inside secure hardware", for which there is no good answer for synchronized credentials), but I don't think we're in the clear yet:
Nothing prevents the big platform players (who are major contributors to the WebAuthN specification) from introducing a new form of attestation that specifically allows expressing that a credential is synced. I could absolutely imagine this happening in WebAuthn Level 3, FIDO CTAP 2.2 etc.
I think the use case for attestation is for devices that were designed to prevent key export, like YubiKey, that are selected by a corporation for internal use where they want to ensure that employees self-enroll only the approved authenticators.
I don't see much reason for syncing platform authenticators to attest because the keys will ultimately wind up elsewhere beyond the attested device.
I think that's something that I'd be fine with -- you can require a YubiKey (or similar) within an org if you need on-device credentials, but general platform authenticators and syncing authenticators don't provide attestation. So in practice your choice is to either:
- require a roaming authenticator (ie, a hardware token) which can be enforced with attestation, or
- don't use attestation
I'd still like it to be reflected in the spec that platform authenticators should not support attestation, but it seems like a reasonable compromise to me. Enterprises still can do what they want and have strong security internally, but Netflix can't use attestation unless they're willing to force every one of their customers to buy a hardware token and to block web sign-in on Mac. Honestly, kind of a win-win for everyone (except for companies that wanted to abuse the spec).
I'm not against enterprise customers and orgs being able to control their own devices, I just want guarantees that the practice will stay within those companies/orgs. And restricting the capability to basically just roaming authenticators/hardware tokens seems like it would provide some guarantee.
The entire sync fabric would become the authenticator. Apple and Google could (but don't currently) issue attestation that the passkey ecosystem you're using is theirs for multi-device passkeys, and continue to use attestation for the specific hardware for DPK and single-device passkeys.
To my knowledge, Apple has ripped out their "anonymous attestation" service together with introducing Passkeys in iOS 16; before that, requesting attestation was an option to opt out of Passkey syncing (and create a device-bound credential).