Comment by Aaargh20318
10 days ago
> if this verification wasn’t in place, could I just alter the source code or binary to always return “yes I’m 18” (or whatever) and completely subvert the intent of this tool?
Kinda, yes.
(slightly simplifying the mechanism here)
This seems to be based on the EU Wallet project, which is still work in progress. The EU wallet is based on OpenID (oidc4vci, oidc4vp). The wallet allows for selective disclosure of attributes. These attributes are signed by a issuing party (i.e. the government of a EU country). That way a RP (relying party) can verify that the data in the claim (e.g. this user is 18+) is valid.
However, this alone is not enough, because it could be a copy of that data. You can just query a wallet for that attribute, store it and replay it to some other website. This is obviously not wanted.
So the wallet also has a mechanism to bind the credential to a specific device. When issuing a credential the wallet provides a public key plus a proof of possession of the associated private key (e.g. a signature over an issuer-provided nonce) to the issuer. The issuer then includes that public key in the signed part of the credential. When the RP verifies the credential it also asks the wallet to sign part of the response using the private key associated with that public key. This is supposed to prove that the credential was sent by the device it was issued to.
Now this is where the draconian device requirements come in: the wallet is supposed to securely store the private key associated with the credential. For example in a Secure Enclave on the device. The big flaw here is that none of this binding stuff works if you can somehow get access to the private key, e.g. on a rooted phone if the wallet doesn't use a secure enclave or with a modified wallet app that doesn't use a secure enclave to store the private key. You could ask a friend who is 18+ to request the credential, copy it to your phone and use that to log in.
What if I refuse to buy a device with a secure enclave that I don't have access to? Am I now censored from a chunk of the internet?
Is the EU essentially foisting a someone-else-owns-your-keys regime onto their citizens?
The law designed this as a privacy-friendly and convenient alternative to traditional identity verification, and stipulates usage should be optional.
Without the wallet, you'll be forced to jump through the same hoops as you're doing right now. Depending on what EU country you live in, that can be anything between "no real difference" to "making an appointment to exchange stamps on documents".
Please point out where the age verification law says it's optional to verify someone's age
Or which hoops you mean we have to currently jump through to access 12/14/16/18+ sites
2 replies →
> What if I refuse to buy a device with a secure enclave that I don't have access to? Am I now censored from a chunk of the internet?
The idea is that once you get used to that, you will get censored from all the internet.
> Is the EU essentially foisting a someone-else-owns-your-keys regime onto their citizens?
Not quite, it's the EU essentially foisting a don't-use-free-software regime onto their citizens
> You could ask a friend who is 18+ to request the credential, copy it to your phone
Oh no! Imagine you find a willing adult who does the verification on your phone. The whole system is moot!
Don't need "copy" here for that. They can just do the verification on your device without any technical tricks
> Don't need "copy" here for that. They can just do the verification on your device without any technical tricks
Yeah. that's where this system fails. It only stores a single attribute that you wouldn't mind putting on someone else's phone. In the full EU wallet the 'over 18' attribute is part of a larger set of credentials that is basically your entire digital ID. If you were to put that on someone else's phone they would be able to identify as you to numerous government and adjacent services. You'd be a fool to share that.
This whole scheme feels a bit rushed and not thought through.
Wouldn't it make way more sense to just have the RP supply a nonce that gets signed by the IDP? Isn't this how oidc works already?
Wouldn't that potentially leak data to the IDP?
All it would leak is that an age verification request happened. The RP would request you/your browser to forward the request "hi can you pls verify if user with nonce 123456 is 18?" to your IDP of choice.
And then the IDP gives you "yes the user with nonce 123456 is 18" signed with its private key, which you forward to the RP.
The only data "leaked" would be which IDP you used to the RP, and that there was an 18+ verification request to the IDP. The IDP wouldn't need to know which RP they're signing the proof for.
This does allow proxying the requests, but honestly, how locked down does this need to be? It's far easier to just snatch your parent's drivers license or passport at that point.
Even if the private key is perfectly bound to the device and can't be copied, can't you still just ask a friend who is 18+ to scan the QR code on their device and verify age? I don't see what problem these device requirements solve exactly, unless the plan is to somehow criminalize verifying on behalf of other people
> You can just query a wallet for that attribute, store it and replay it to some other website.
Uh, replay attacks are a solved problem in pretty much any industry standard challenge-response authentication, including OpenID. Am I missing something?
Doesn't this system have more privacy constraints? E.g. the website you're visiting shouldn't be able to learn anything about your identity beyond the attribute (above 18), and the identity provider shouldn't know anything about which website you're visiting.
It does seem like people tried very hard to make it privacy preserving.
You're missing the part where I describe the mechanism used to prevent replays, I'm just describing why it is necessary.