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).
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.
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.
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.
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.
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."
Notable exception: Google's Protected Confirmation [1] – the signature format of that is not natively WebAuthN/FIDO compatible, though.
[1] https://android-developers.googleblog.com/2018/10/android-pr...
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).
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.
I don't see much reason for syncing platform authenticators to attest because the keys will ultimately wind up elsewhere beyond the attested device.
- 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.
I agree. That it's part of the spec makes me nervous about the spec.