Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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".


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


That’s not what they said. They said that when age verification is required, it is intended to be optional to use the EU digital wallet for that, and other ways are possible.


That's a fair point.

Of course, once upon a time JavaScript was optional, and now it feels like half the web won't work without it. Cookies were optional but now many sites don't even bother with a "Reject All" choice. Google Play was optional on Android, now banking apps don't work without it.

Tried to do KYC with an institution in North America lately? They used to allow diverse options - eg. physically present yourself, get a notary to attest, upload signed documents & ID - but now app-based applets which offer little to no visibility into just what data they're hoovering up from your phone and no way to manually review what you're sending before submission (...to outsourced or even offshore processors) have displaced most of those alternatives due to their convenience (especially to those who don't care about privacy) and cost competitiveness (to the service providers). Filling out customs declarations when traveling is going the same way (with longer, more customer-hostile terms of service and privacy policies than came attached to the old paper forms).

The option that's most convenient to the masses tends to become defacto, and push out the last bastions of safe alternatives relied on by nerds like me - who pay attention to this stuff and try to advocate for user agency, data sovereignty for users, and the means to maintain a healthy privacy and security posture.

I would love to see some kind of attestable flavour of Android that I as a user control the keys to (in my own case I'd even be willing to provide assurances backed up by insurance, a bond, my reputation, repudiation to some degree of vendor liability if things go wrong, etc) with tooling to help me achieve a high level of security in a low-friction manner.


> 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.


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.


So the scenario this is needed for, is where someone does a physical and technical attack on your phone just to extract the key from this app that says you're 18+. That would be why nobody can have access to their own data anymore

I'm sorry but that cure is definitely worse than the disease. This is not an attack you see outside of spy movies


Yubikeys go on your keychain. You're as likely to not notice losing it as you are your housekeys. Anyway the point is that if you're not willing to run a trusted phone, there are other very viable options... particularly for technical folks who tamper with phone software... and those who cares about the Google panopticon... that are extremely viable and should be acceptable to satisfy the stated intent of the regulation.


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.


There’s no way to prove you aren’t MitM-proxying a reply from a device not paired to your phone in that scenario, because the kernel ‘says’ it’s USB to the app but a patched kernel can lie about that unless the kernel is attested-unmodified-secured — and anyways USB can itself be mitm’d at the phys layer without the kernel knowing at all.


You can enroll keys on trusted hardware and then use them on untrusted hardware. That's how smartcards work. Enrollment is secure (say performed by your employer) and (in theory) extracting the private key is impossible.

Smartcards also seem to have the ability to issue certificate requests. I think the keys inside the cards are signed by a manufacturer trust chain (I got a gemalto card to play with for signatures and places like IdenTrust were able to verify authentic cards, but I wasn't trying to fool anything so it may be possible... but they would only issue certain levels of keys for specific cards)

I'm not saying you are wrong (I don't know enough about the details) but it all was much more sophisticated than I had thought and the chips seem to be running some sort of attestation of the chip in the card. Basically, you can't MITM things if doing so requires getting a private key that only exists in the factory. That sort of thing.


I look forward to being wrong, certainly!


Well you should understand that trusting media is not part of how modern encryption works. Having access to USB isn't any different from having access to a network switch or the airwaves. Things like yubikeys and smartcards are designed to work when using untrusted devices.

The question is how do you convince other people to trust your phone to store their secrets--not how do you yourself come to trust your own device to store your own secrets. And if you can't convince others your device is secure (i.e. "why the hell would I trust you and your phone to store my password?"), then just use something they can trust instead. I'm not saying EU is going to allow whatever, I'm just saying it's not a huge technical or usability problem to rely on something the EU should be able to trust (like a yubikey) if the EU can't trust your phone.


All valid points — however: the EU has two requirements not listed above it needs to be difficult to steal unnoticed, and it needs to minimize attempts to steal it at all.

They’re not concerned about a person handing their phone to someone else for a moment. They’re concerned about kids stealing age verification devices from people. Someone isn’t going to notice a missing yubikey until they check age next. Someone is going to miss their phone much more rapidly, be able to track it using stolen device features, and be able to report it stolen which incidentally remote kills HSM access. They can also enforce biometric checks and require a recertification after those change, which would make it nearly impossible — relative to shoulder surfing a PIN — for kids to make use of the parental device unit.

Even a fingerprint key isn’t going to meet these terms, and it’s going to have a weaker sensor that the kid will have hours or days or weeks to try and defeat using a fingerprinted glass and some glue. Locking it to biometrics stored in the phone prior to (re)certification makes it pointless for kids to try. A few still will, but word will spread.

I still personally think this is all kind of a hot mess of deferring parental authority to technology, but I’m not an EU citizen, nor a parent, so my opinion on the policy is irrelevant. I’m just here to raise awareness of why attestation is winning: technological superiority and unmatchable market fit, and an opposition that isn’t presenting coherent and most especially government-persuasive arguments to stop its use. Yubikeys are not a viable market fit in a world where tiny amoral thieves live among us — and whatever else children are to their parents, most of them have the moral integrity of a wet paper towel. Most wouldn’t think twice about lifting a yubikey, but they’ll hesitate strongly before stealing a parent’s phone, and it won’t even pay off doing so thanks to biometrics.


My mom can also do the identification on my phone and unlock it for me. There is fundamentally no way to prevent proxy issues if you let people do verification themselves

Intercepting the USB reader traffic to feed the computer a different card is about the most roundabout way of achieving that


Unfortunately I don't think they will let you do that.


Is that a reference to HAL9000?


No


> 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.


> 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.

we've banned all graphic depictions from the internet, required a verified name attached to every blog post, and made sure to confirm everyone's digital passport before letting them resolve a DNS query, but at least now I can vote from me phone instead of having to go outside. The future is bright!


Yeah, this future sucks, and we’ve had twenty years to push back and utterly failed to do so. I’ve tried for years to interest people in learning about attestation so they can curb it before it swings hard authoritarian, but no one wanted to listen b/c Linux is about having root and anything that challenges that belief is anathema to consider. Welcome to the party, the sky is falling just as it has been for years; someone else can be the harbinger for a while, I’m tired of watching people try the same old arguments that have failed for years.


> the Android forks ecosystem isn’t competent enough to be trusted, because they can’t be bother to do attestations

GrapheneOS has optional attestation, either local (another device) or remote (their server) attestation.


Aha! Graphene, with the support of impacted EU citizens, has grounds to petition the EU for inclusion in their age verification app, then. I hope someone makes that happen! (I am not an EU citizen and so have no ability to help.)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: