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.
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!”
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-...
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.
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.
To my knowledge, even more sophisticated ZKP schemes still rely on device bound keys to protect against duplication.
Question: how do you make sure the keys are device-bound if you have no attestation about the hardware or operating environment?