Fuck banks with a cactus for forcing us to relinquish our freedoms as a precondition of interacting with them, which is a precondition to exist in most societies.
Arguably, even passkeys with attestation would be a step forward compared to that, as banks could require an external authenticator tap on a rooted device, or signature of some sandboxed secure element that runs independently from the application OS.
It’s dead so far. Again, X.com could ask you to re-enroll your passkey next time you sign in, but this time requiring attestation. It’ll be phrased like “we’re upgrading your account security, please click ‘Accept’ to proceed”.
> banks could require [...a] signature of some sandboxed secure element that runs independently from the application OS
They can. Why don’t they?
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.
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.
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"?
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.)
> 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).
> 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.
Unfortunately this is fundamentally at odds attestation: If you trust anybody capable of providing a syntactically valid signature, it's not attestation anymore.
You can try and set up a neutral clearinghouse vetting attestation providers, but that itself will probably become a centralizing force itself, requiring expensive audits etc. – think web PKI certificate authorities, but even more complex (as you need keys in shipped end user devices, not just somebody's data center HSMs).
I think shunning attestation is largely the right move, with a very short list of exceptions (high trust e-signatures, high value bank transactions but not daily payment confirmation etc.)
It is a problem, but isn’t FIDO acting as this body already wrt attestation in WebAuthn? I’m only building on top of this existing process.
Regardless, a sibling commenter has a good idea of how to sidestep this in corporate environment, and I think it should work for most of actually useful purposes.
> I think shunning attestation is largely the right move
I’m glad we’re on the same page :-) But as long as we have attestation for passkeys, I think we should at least make it as hard as humanly possible to (ab)use it as a general device attestation scheme.
So I set up my own self hosted provider, and transfer the keys to it, and ... how is this any different from not being attested? The entire point of attestation is to whitelist providers so a requirement for universal transfer would seem to defeat the purpose.
I appreciate an enterprise wanting attestation for certain things, but I don't think consumer oriented protocols should support it. I also think it would make more sense for protocols to support some sort of arbitrarily extensible co-signing scheme instead of device attestation. So corporate keeps a registry of secure elements they own and which users are associated with each one. So there's no way for a vendor to lock authentication (or whatever else) to a specific OEM but corporate IT (or an end user or etc) would still be capable of binding credentials to some subset of physical devices.
...get it certified, then transfer the keys to it. Or more likely you get an HSM and use its certification.
> I don't think consumer oriented protocols should support it.
Ideally yeah, that’s my point of view as well. In the corporate land however...
> binding credentials to some subset of physical devices
I don’t think that’s the goal. My guess is, they want to be able to transfer some passkeys but not allow any copies, and this only works if one device trusts another. It could work still with your scheme (store a private key on each device; when transferring a secret, make one device encrypt it to the other and immediately destroy its own copy, and make IT department sign any transfer requests so they can check whether they own both devices).
Who are we taking about here?
For regular users it's no one's business if and when I copy my keys, for backups or any other purpose. Any scheme which attempts to prevent that must inherently infringe on my freedom.
For corporate I believe the goal is to know which registered (ie explicitly approved) device a login is coming from. Co-signing would accomplish that. The user key can be reused (not that you'd want to) and any session will still be tied to a known device. Plus you could bind a given user key to a given device on the server side so mission accomplished (assuming the hardware doesn't allow export of its key but then these are specifically approved devices so of course it won't if IT cares about that).
The corporate.
> I believe the goal is to know which registered (ie explicitly approved) device a login is coming from.
They can do that with non-transferrable passkeys already (assuming they hand out the devices, and trust the manufacturer to actually prevent transferring the keys out). No cosigning required here.
There is an alternative* of which I haven't heard in a while.
If you're dealing with a legal oligopoly then it is expected that the quality won't be so great.
(The thing that banks are afraid is malware spoofing the bank app's UI and the user then approves a fraudulent transaction... not sure how to prevent that tbh)