I've always wondered why Google never moved FIDO from Play services to AOSP.
FIDO requests are scoped to an origin. Play services implementation verifies that an origin authorizes each client app. This system wouldn't work for web browsers unless every site whitelisted each one.
Conversation
So then, how come the Play services FIDO implementation does work for web browsers? It doesn't work in the general case. They have a separate privileged API for web browsers and Play services has a list of approved web browser app ids and signatures. This is actually horrific.
1
8
For the time being, Vanadium needs to support this until we have our own standalone FIDO2 implementation. We plan on making one simply using the secure element in the phone since it fully supports FIDO2 including physical confirmation and even the optional attestation feature.
1
6
We have no plans to release Vanadium on the Play Store. It also currently uses the org.chromium.chrome app id since it's the direct continuation of our unbranded Chromium builds which have gradually had privacy and security improvements added and continue to be improved.
1
1
5
This is blocking Vanadium from using the Play services FIDO API provided by sandboxed Google Play for users who choose to use it. It would be a nice stopgap for those users until we provide our own implementation. It's entirely in our power to add Vanadium to their list though.
1
2
FIDO security keys have a broken security model in multiple ways. It's not really Google's fault. They're trying to mitigate one of the problems and the solution is horrific and trusts all those web browsers not to abuse the API or get compromised and have an attacker abuse it.
2
3
Replying to
broken compared to e.g. a BeyondCorp-like approach where attestation to device & *browser* integrity+identity *is* authentication?
1
Replying to
External security keys are used across different devices and sandboxed client apps on those without treating those as separate pairings which is why they made this hard-wired list of browsers to work around it.
Authorization via physical confirmation isn't specific to anything.
1
1
What is physical confirmation meant to accomplish without a secure display showing you the client (based signed data provided by OS) and the site (which could be shown as a fingerprint, a hard-wired list of known public keys for domains/organizations, or some kind of PKI system)?
1
2
Replying to
yeah, seems like there's a fundamental problem in a lot of security stuff that's, just
A wants to authenticate itself to B, but is using "user agent" C to interact w/ B
C *must* be trustworthy/authenticated to A for A to trust any requests for auth that C claims came from B
2
2
Replying to
I don't think Google should actually have that hard-wired list because people are not strictly using their FIDO2 security key with Android and therefore Android trying to impose a security model of only trusted browsers doesn't work. It also isn't a viable approach anyways.
Replying to
yeah- h/w tokens are a fundamentally pragmatic "better than not having it, i guess" approach but without an OOB, direct-to-human (but phish/relay-resistant, somehow?) channel...
there's def. better designs and it sounds like graphene is once again doing neat stuff in this space
1
shades of the dTPM/fTPM split, actually
a dTPM can in theory be "more hardened" in some very specific ways than an fTPM might (especially around stuff like anti-hammering)
but the need for *physical separation* between the Secure Hardware Root-of-Trust and the software TCB
1
Show replies