zlacker

>>doomro+(OP)
How do you defend against someone who:

- Buys or borrows a laptop / phone / whatever from somebody with an authorized private key

- Downloads an authorized private key file from a sketchy forum (maybe hacked from an unwilling target, maybe willingly shared by a free-speech advocate)

- Uses a VPN over HTTPS to visit websites in countries where age checks aren't legally mandated (and non-compliance is implicitly or explicitly encouraged for economic or ideological reasons)

>>csense+0D
The credential ("driver's license") contains a public key whose secret key is stored securely in a hardware secure element. The standard assumption is that the SE is in the phone, but it could be a yubikey or similar device. In order to use the credential, you need the SE. So you cannot buy a phone from somebody and download a credential from somebody else. You can however buy a phone and the credential from somebody. As a mitigation, the SE only generates the signature when unlocked via a fingerprint or similar biometric input which must match the one that was provided at the time the credential was issued. Whether or not your attack works in this scenario depends on the details. For example, if you only obtain the credential in person at a local government office and provide a fingerprint at that time, it's not that easy to sell the phone and the credential afterwards.

>>Matteo+0E
> the SE is in the phone, but could be a yubikey or something else

Just like with passkeys or MFA, the "something else" could be purely software though, right? And hence automated?

For example I can run Windows 11 in a virtual machine on Linux, using softu2f to emulate TPM 2.0, and Windows does not know the difference.

>>ranger+WM
The problem that needs to be solved is, how can a government give you an identity document in a way that you cannot give the document to somebody else. Whether or not this problem needs to be solved is a political question, but it seems like the majority thinks that identity documents should be hard to forge, in the same way as dollar bills should be hard to forge. The only practical solution is to have some sort of hardware that the user cannot forge, and relying parties will insist that the document be bound to such hardware. So yes, the something else could be software, but nobody will accept signatures from an emulated TPM. I had in mind a government-issued yubikey that can be identified as such, or maybe a plastic card with embedded secure chip with the same functionality. See https://github.com/eu-digital-identity-wallet/eudi-doc-archi... for the current thinking at least in the EU.

I should also remark that the above is a western-centric perspective, whatever "West" means. For example, I heard the architect for a similar system already deployed in India remark that in his jurisdiction many households share one phone across many family members, and India chose to accept more possibility for fraud in exchange for wider usability by the population. In that context this choice looks like the correct solution.

>>Matteo+441
It’s more about the device being tamper resistant than “hard to forge”. You don’t want people playing around with the device generating signatures. Algorithmically, there is nothing done on a secure element that can’t be done with software on a general chip. The defining difference is the physical separation of data and the mechanisms put in place to brick the device on detection of physical tampering.