broken compared to e.g. a BeyondCorp-like approach where attestation to device & *browser* integrity+identity *is* authentication?
Conversation
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.
1
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
you can "pair" the Secure Hardware (dongle/chip/whatever) w/ the software TCB, and at least *encrypt that link*... but you *still need to trust the software TCB*, AND now you have to trust the Secure Hardware
1
biggest advantage is you can't exfiltrate keys (in theory) out of the Secure Hardware from the software TCB- you can give the Secure Hardware "policies"/programmable bits to release/unseal secrets only if (arbitrary boolean expression evaluates to TRUE) or whatever, but-
1
outside of rate limiting/antihammering, that doesn't get you much of anything useful *unless the Secure Hardware can actually verify the software TCB*
google's Titan seems to at least have gotten this right, or at least have *reasonably defined the problem*
1
Replying to
Titan M is paired with the SoC (via TEE) and the link has authenticated encryption, and there's key attestation which is what Auditor uses for hardware-based attestation of the OS including verified boot key fingerprint, patch level and so on since it includes all of that stuff.
The main thing it's missing is a secure display and higher level concepts than simply keys with low-level purposes (sign, encrypt, etc.) and requirements for their usage like the user being authenticated, device being unlocked, physical confirmation, etc. as it's too low-level.
1
2
Bitcoin hardware wallets have a display in addition to confirmation and show transaction with the destination, amount and fee to be confirmed on the hardware wallet along with being able to display receive addresses. Much different than a typical HSM for key storage with no UI.
1
1
Show replies