Comment by lxgr
8 days ago
> Again, X.com could ask you to re-enroll your passkey next time you sign in, but this time requiring attestation.
How? Almost none of their users own an authenticator capable of attestation (i.e., a Yubikey or similar).
> They can. Why don’t they?
They can't, because open/neutral access secure elements do not exist yet, and nobody really wants to carry an external one.
Every iPhone, every supported macOS device, all Windows machines capable of running Windows 11 and all mainstream Android devices capable of running Netflix have a Secure Enclave of some sort capable of doing remote attestation, and for virtually all of them, Secure Boot providing the foundation for it is enabled and enforced.
It just took a decade worth of waiting after the first failed attempt by MS to push TPM support.
The only device categories where Secure Boot and Remote Attestation are either disabled, unsupported or not usable for the purpose of trusted attestation are many Linux systems and Android devices not sanctioned by Google.
No, Apple used to support passkey attestation on iOS, but has since removed that feature. The same is true for macOS. Android still supports it, but not for synchronized passkeys as far as I know.
Not sure how DRM factors in here; it's a completely different problem space. Or is your stance something like "anything even theoretically capable of performing trusted computing is evil"?
Okay, so it’s possible, but Google is not doing it correctly yet, so they won’t be doing it ever despite the fact they have all the incentives to do so?
2 replies →
If they had it and then removed it, what's stopping them from adding it again?
> How? Almost none of their users own an authenticator capable of attestation (i.e., a Yubikey or similar).
I haven’t checked, but I suppose both Google and Apple have passkeys implementations capable of attestation? (If not, it should be fairly easy to add, and considering Google has been pushing for various “integrity” bullshit, this would be a no-brainer for them.)
> They can't, because open/neutral access secure elements do not exist yet, and nobody really wants to carry an external one.
I’m not 100% sure if this would work: https://developer.android.com/privacy-and-security/security-...
Presumably, banks trust Google, so if Android doesn’t erase attestation information from the HSM when unlocking the bootloader, they could use this process to verify that the key they’ve generated is stored there, regardless of whatever other software the user is running. (If Android does erase attestation info then eh, it’s just as bad as relying on Play Integrity APIs.)
Apple used to support attestation but removed it. That alone makes it non-viable for sites to enforce attestation.
> I’m not 100% sure if this would work: [...]
I believe it might, but like you I'm not sure if they really don't measure some secure boot properties into that keystore these days.
It's also usually implemented in TEEs and attested by the device manufacturer, which means there's a high chance of getting either insecure implementations in the mix or ending up with a heterogeneous mess of supported and non-supported manufacturers varying from bank to bank.
FIDO at least has their manufacturer directory; not sure if Google has something similar for Android (and if it does, whether non Google certified Android OEMs may apply).
Okay, I’ve thought about it a bit, and I’d be okay with attestation in WebAuthn if it required that the keys are transferable between providers, and that if you require attestation you don’t require any specific provider. I.e. ban vendor lock-in: if I have a key, I should be able to use it, and move my passkey to another one if I need to.
> Apple used to support attestation but removed it. That alone makes it non-viable for sites to enforce attestation.
Again, for now. Apple might have less incentives to bring it back than Google, sure, but their products are not really known for being open platforms either.
7 replies →