[ulrikrasmussen]

Even relying on Android's hardware attestation API instead of Play Integrity is an attack on digital autonomy in my opinion. Any security feature which relies on remote attestation of the users entire platform is government overreach as it ultimately gives the government the power to choose what operating systems are acceptable. It is only a matter of time before this power will be misused to put pressure on OS developers to install backdoors for the intelligence agencies. And no, asking people to own two smartphones is not a solution to this problem.

Anonymous digital age verification based on a suitable ZKP scheme and/or blind signatures does not require a general purpose operating system, it just requires a few cryptographic primitives and a set of device-bound keys. It is not too much to ask that the EU develops a specialized hardware token with these exact capabilities and offer them for free to all citizens as an alternative to the app. This also gives the citizens of EU the freedom to choose not to own a smartphone without having their access to digital services severely restricted.

[whazor]

I'm ok with enforcing hardware security. Both for banks and governments.

But it must not limit the ability of running custom software on a phone. And especially not enforcing every person to get a Google/Apple signed phone.

Like if I get GrapheneOS on my phone. Banking/gov apps should work. But I believe this could be possible with enforcing hardware security as well.

[TingPing]

The chain of trust always has a software layer. I don’t believe what you want is possible.

I find the bank talking point strange, why are they special, are they even targeted more. It just feels like a boogeyman “think of your money!”

[microtonal]

For all practical purposes it's possible to do this. The boot ROM only boots a vendor-signed bootloader, the bootloader verifies the OS kernel, etc., until you have a fully verified boot chain. A secure enclave, which is completely separated from the main CPU and OS performs the attestation using a private key in its tamper-resistant storage and embeds the results of verification by the bootloader. There may be some vulnerabilities, but most of them can be fixed in updates, with exception of the boot ROM.

The reason why the system gets broken in Android occasionally is that most Android phones have terrible security and do not use a secure enclave/processor, etc. (which the iPhone had since 5s + Google/Samsung for quite some years through Titan M/Knox Vault). Instead they use TrustZone, which set up a TEE on the same CPU/RAM as the main OS. Of course, it uses memory protection for separation, but is often vulnerable to side-channel attacks. This is also the reason many Android phones will be cracked by Cellebrite in seconds (recently such a Mediatek TEE vulnerability was made public [1]).

[1] https://www.malwarebytes.com/blog/news/2026/03/this-android-...

[summm]

Nope. It is still not possible to give someone else (the government, or the bank) control over your phone while at the same time run software that you alone control with higher privileges. Please don't mix that up with "is practically hard to implement because of sloppy code. Also your attacker model is still "occasional evil government agency or evil private corporation wants to crack and read your messages", while what is discussed here is more fundamental "evil government or abusive corporation controls your phone in the first place, and can just remote control it you can't use really secure apps"

[whazor]

I want governments and banks to allow open-source software, not control my phone.

For example, I essentially trust the ROM I download from the GrapheneOS website. What I want is for governments, banks, or some independent open foundation to be able to approve that ROM too, so attestation can work with it.

More like how CA certificates work: not perfect, but not locked to one vendor either.

[summm]

So now you have the choice between two approved ROMs. Not a lot of improvement? And as soon as GrapheneOS implements something beneficial to the users that the government does not like, the approval will be taken back. That's also why GrapheneOS will probably not even think about doing that. So you want some OS functionality neither Google nor Graphene offer, you're, again, out of luck. CA is something completely different, and much more limited in what can be centrally controlled. Everybody can go to a CA, get a certificate for their domain, and use it with any server software, even with software they compiled themselves.

[ulrikrasmussen]

The software layer in age verification is not necessary to trust though. The worst that could happen is that a compromised software layer steals your age credential, but it is by design anonymous so you don't risk getting your money or account stolen or anything. This makes it a different threat model from the banking case.

[fsflover]

Have a look at Heads. It uses TPM with a hardware key to verify the boot integrity without proprietary blobs and with full control of the user. Works for me.

[Retr0id]

You can store key material in hardware-backed enclaves without involving remote attestation. If someone has a modified device/client that stores the keys elsewhere, that's on them - they're only weakening their own security.

[Meneth]

You can't have both. "Hardware security" means the manufacturer decides which OS can run and you can't override it.

[whazor]

Practically speaking, I can set up real hardware-enforced boot integrity on my Framework laptop today, both on Arch with sbctl and on NixOS with Lanzaboote or Limine.

There are still many unsolved problems in hardware security, so this is definitely not solved today. But I don’t see why it should be impossible. The EU could push the industry toward attestation models that respect user ownership instead of locking everything behind vendor-controlled software.

[summm]

I think Meneth was basically correct but a bit imprecise: Boot integrity itself is only user respectful as long as the user can freely decide and change the integrity reference values, without consequences to the latter usefulness of their system. But attestation (based on boot integrity) as a principle directly contradicts "respect user ownership". This is not a question of technical feasibility, but of principle. Attestation is directed against users. The main purpose of attestation is to make sure that the local user can be forced to use a specific software (and not run other software at the same time that could influence this specific software) to access a certain remote service. Remote attestation means by definition "vendor lock", in that the vendor and their contractual partners lock and control the device's software. Therefore an attestation model that fully respects the user simply cannot exist.

[ralferoo]

Exactly, I'm not sure what benefits hardware attestation offers to the government. Sure, it's potentially useful for the customer that they can trust their keys are secure on their device, but it kind of misses the point.

It should really be an open-source specification that defines a standard protocol, but where the device just signs a request that it knows has come from a trusted source (so maybe signed by the government's key) with a key that the government's API knows that represents you.

So, I'd envisage something like government portal lets you add a bunch of public keys, one for each device, and shares a public key of its own that can be used to verify any requests. Something that wants to verify your identity can request your public key, and ask the government API for a challenge token which it passed back to you. You can verify the challenge token is signed by the key you trust, you can sign the challenge and return it to the app, which can pass it back to the government API which can then grant access to whatever subset of information they requested (and the challenge key can include enough information for the signing app to present a meaningful request).

Very simple in terms of protocol. Only the government needs to store any of your private data. If an application just needs to know if you are of a sufficient age or not, that's all the information it gets. If you lose your device you can easily revoke your keys and add new ones.

Sure, a specific implementation on a phone might want to use hardware attestation in order to keep its keys safe, but there's no reason that it has to be mandated. A well designed public key system should be sufficient leaving the implementation to safeguard its keys, while providing a simple way to replace keys if needed.

[ulrikrasmussen]

I think the reason these systems require device bound keys is because the government is concerned with easily mass-produced forged age certificates. With software keys you can get an age certificate which can be copied instantly to a large number of devices, with hardware keys the government knows that the certificate is tied to a single physical unit.

[KoolKat23]

Again, at this point, they're taking things too far,age gates shouldn't need to be an impenetrable fortress (notwithstanding the question of whether they should exist in the first place).

It should simply be the adult account on the device is notified if the device is rooted, effectively no longer in child mode. Go crazy with the warnings on both devices if you want as they've opted in at that point.

[tomega2134]

Is this EU protocol so weak that it cannot withstand this attack, i.e. is duplicate age certificate use not detected or prevented?

[ulrikrasmussen]

You can't really prevent that unless you design a system which is inherently designed to track people, e.g. by phoning home to the issuer on each credential verification. The system being deployed right now is based on the issuer issuing batches of single-use credential tokens to device-bound single-use keys, which on the plus side means that colluding verifiers cannot use age credentials as cookies to track people. It is still vulnerable to colluding verifiers and issuers though, because the issuer can de-anonymize the tokens (it knows them and their linking to the identity of the user). This scheme also means that if the keys that the tokens are issued to are not device bound, then it is trivial to copy the age credentials to someone else.

To my knowledge, even more sophisticated ZKP schemes still rely on device bound keys to protect against duplication.

[Borealid]

> it just requires a few cryptographic primitives and a set of device-bound keys

Question: how do you make sure the keys are device-bound if you have no attestation about the hardware or operating environment?