4 ms·

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

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-attestation-dep28afbde6a/web 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.

lxgr 3y ago
https://www.slashid.dev/blog/passkeys-deepdive/ https://www.slashid.dev/blog/passkeys-deepdive/ talks about this, among others. 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.
- danShumway 3y ago
  Well heck, I'm very happy you chimed in on this, thanks. Very happy surprise.
  - lxgr 3y ago
    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.
warp 3y ago
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).
- lxgr 3y ago
  I think Apple just scrapped it entirely with iOS 16 for a more consistent user experience. Unfortunately, this also makes it a dealbreaker for me – I want some credentials to be device-bound and non-extractable.
  - danShumway 3y ago
    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."
morpheuskafka 3y ago
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.
- danShumway 3y ago
  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.
JohnFen 3y ago
> I think attestation is harmful and should never have been part of the spec. I agree. That it's part of the spec makes me nervous about the spec.

lxgr 3y ago

https://www.slashid.dev/blog/passkeys-deepdive/ https://www.slashid.dev/blog/passkeys-deepdive/ talks about this, among others. 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.

danShumway 3y ago
Well heck, I'm very happy you chimed in on this, thanks. Very happy surprise.
- lxgr 3y ago
  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.

warp 3y ago

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

lxgr 3y ago
I think Apple just scrapped it entirely with iOS 16 for a more consistent user experience. Unfortunately, this also makes it a dealbreaker for me – I want some credentials to be device-bound and non-extractable.
- danShumway 3y ago
  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."

morpheuskafka 3y ago

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.

danShumway 3y ago
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.

JohnFen 3y ago

> I think attestation is harmful and should never have been part of the spec. I agree. That it's part of the spec makes me nervous about the spec.