Comment by titanomachy
10 days ago
Without getting into the ideological weeds too much, is there a solid technical reason for this? Like 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? If so, is there a straightforward way to prevent this without involving Google?
> 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".
3 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?
1 reply →
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.
The tool could have a mode where it just reads the cryptographic chip in your ID card via NFC and passes on the information to the verifying party. This information is signed by your government and they could verify it with the public key
Instead, they're trying to shoehorn your device into providing the same safety level and, in doing so, making it by design impossible for you to control your own device. Obviously if the sites trust a device that you control, you can make it tell them anything. The ideological part is that it's not your device anymore then and imo we should oppose that. The technical solution is to use the hardware security chip you already have with a reading mechanism that (nearly?) every smartphone already has and even works on any OS that can run a USB NFC reader. It could be an entirely open standard
I'm pretty sure all you need is the ability to login to a website and for that site to vouch for your age based on having examined your identification documents (or something like a network of PGP web-of-trust type notaries). I have a hunch that using a hardware token and biometrics is required to prevent fraud (FIDO and passkeys etc should work). The trick is preventing simulated tokens from existing/working which is where secure boot etc enter the picture.
Can you clarify what fraud you're thinking the "secure boot" (which I take to mean: being denied the access to control your own device) would prevent? Since the identity documents you already have, have this chip that works the same as your bank card, you really don't need a relaying party (your phone, your ISP, etc.) to be trusted for the receiving website to be able to verify the cryptographic signature on the data
Fraud would be someone who is not you using your identity.
2 replies →
Yeah it’s sort of like all the apps that would refuse to run on a jailbroken iPhone.
Basically on such a system you can potentially manipulate the process. Here that would probably be to install the credentials of someone else on the device.
So they want a locked down OS environment where user does not have root privileges and software has to be verified (in this case by Google) to be installed.
You would need to release a kernel and OS that requires users who modify the attestation and hardware token components of it to provide their own signing key rather than your production EU-registered one, chained back to the HSM signature emitted by the phone’s HSM signed bootloader; and then you would simply let the app check that its secure boot attestations chain to a secure bootloader/image/OS triplet that’s on file with the EU. Mix in some tech spice for the EU to prohibit OS releases that are validly signed but whose specific instance of a signature is found to be exploitable to bypass age checks and you’re set. None of this would prevent users from modding their devices, any more than macOS prevents modifications today if you turn off the security protections; but once you turn off the security protections, it can no longer attest with Apple’s signature because your modifications don’t match the signature any longer, and so Apple Wallet is inaccessible.
None of this prohibits users from modifying their bootloader, kernel, or OS image; but any such modification would invalidate the secureboot signature and thus break attestation until the user registered their own signatures with the EU.
The EU currently only transacts with Google in this regard because, as far as I know, they are the only Android OS publisher (and perhaps the only Linux publisher?) that bothered to implement hardware-to-app attestation chaining live in production end-user devices in the decades since Secure Boot came onto the scene. All it takes to change that is an entity who has sufficient validity to convince them that outsourcing permitted-signature verification to Google is unethical, which it is.
It’s a safe bet that Steam Linux was already working on this in order to attest that the runtime environment is unmodified for VAC and other multiplayer-cheating prevention systems in games — and so once they publish all that, I expect we’ll find that they’ve petitioned their attested OS signature chain to the EU as satisfying age requirements for mature gaming.
The vendor lock-in here is that Apple and Google and, eventually, Valve, are both willing to put the weight of their business behind their claims to the EU that they do their best to protect the security of their environment from cheaters, with respect to the components required by the EU age verification app. The loophole one could drive a truck through that the EU has left open to break that lock-in in the future? Anyone can petition the EU to accept attestations from their own boot-kernel-OS chain signatures so long as they’re willing to accept the legal risks visited upon them if found to have knowingly permitted exploitation for age check bypasses, or neglected to respond in a timely and prudent manner when notified of such exploitability by researchers — and if the EU rejects their petition improperly, they’ll have to answer for that to their citizens.
All of this assumes that the device, a relaying party for your identity document, needs to be secure in the first place. We don't attest the OS of the router and your ISP before being allowed to use them to relay this information to pornhub. Why does your phone need to be under a third party's control just to relay information that the government already signed onto your NFC-enabled identity documents?
But even if you were to want user's phones to be roots of trust...
> as far as I know, they are the only Android OS publisher (and perhaps the only Linux publisher?) that bothered to implement hardware-to-app attestation chaining
GrapheneOS does that. They guarantee this more than Google because Google allows devices with known vulnerabilities: https://grapheneos.social/@GrapheneOS/114864326550572663 (rest of the thread is worth reading, too)
Using Google Play's instead of Android's attestation framework means that nobody else ever could enter this market indeed, no matter how secure the OS
> None of this prohibits users from modifying their bootloader, kernel, or OS image;
... unless they don't want to turn their device into a boat anchor that nothing else will talk to. It's not going to stop with age verification.
Counterproposal: fuck attestation, and fuck age verification. Individual users, not corporations, associations, or organizations, get to use any goddamned software they want any time they want for any purpose they want, and if you set up some system that can't deal with that, tough beans for you.
Or just rely on a separate trusted hardware device (think: USB+NFC yubikey) when the device itself can't be trusted.
9 replies →
> that bothered to implement hardware-to-app attestation chaining live in production end-user devices
This is why it's important that initiatives like Web Environment Integrity fail. Once the tools are in place, they will always be leveraged by the State.
> and so once they publish all that, I expect we’ll find that they’ve petitioned their attested OS signature chain to the EU as satisfying age requirements for mature gaming.
I hope that Valve pays no mind to this nonsense and continues to allow art to be accessible to anyone.
That ship sailed decades ago when Intel promoted Secure Boot as a defense against malicious modifications; it stops rootkits and it stops cheaters, what more could one ask for, etc. App attestation of this sort has been offered in certain enterprise/government Windows 10 SKUs since day one. Apple’s web attestation protocol has been live on all T2 devices for about as long as T2 has been out.
Governments have real and serious need for verifications that are backed by their force. They’re a government; they are wielding force upon citizens by doing this, knowingly and intentionally. That is a normal and widespread purpose of the State existing at all: to compel people to align with the goals of the State, whether members of the State like it or not, until such time as the State’s goals are changed by whatever means it permits or by its collapse.
If this pans out for them, as cryptographically it will but remains to be how vendors and implementations handle it at scale, then they can introduce voting from your phone — the previously-unattainable holy grail of modern democracy — precisely because it lets the government forcibly stop the cheating that device-to-app/web attestation solves. And they can do so without leaking your identity to election officials if they care to! Just visit a government booth once in a while to have your identity signature renewed (and any prior signatures issued to your identity revoked). That’s how digital wallet passports and ID cards work already today anyways, with their photo/video/NFC processes.
Western sfbay-style tech was founded on the libertarian principle that one should be able to tell the government to fuck off and deny taxation, representation, blah blah etc. in favor of one’s armed enclave that does what it feels like. It’s fine to desire that, but it’s proven too radical to be compatible with the needs of nation-states or the needs they enforce satisfactions for on behalf of their citizens. Attacking attestation won’t solve the problem of the “State”, and has led us to a point where Google can claim truthfully to a “State” that the Android forks ecosystem isn’t competent enough to be trusted, because they can’t be bother to do attestations.
4 replies →