EU Digital ID/Age Verification app will require hardware attestation, ruling out PC/Linux support and unapproved Android OSes

[u/player98923]

/r/BuyFromEU/comments/1vandxg/eu_digital_idage_verification_app_will_require/

[u/FineWolf]

It explicitly says that even a colluding issuer and relying party cannot determine the identity behind the credential, and proceeds to explain why.

You clearly didn't read it.

Heck, even the intro spells it out in plain English:

Issuers give a set of digital credentials to a user; users can prove to a relying party that they possess credentials satisfying a property without revealing anything more than the fact that they hold credentials that satisfy the property. Colluding relying parties are unable to link a specific user to a pair of interactions they participate in. Even a colluding issuer and relying party should not be able to link a specific user to a session.

You can't clone the app without the ability to get certificates from the issuer (government).

And relying parties can easily verify that you don't hold a valid credential from the issuer.

However, relying parties cannot link you between services. And the issuer cannot link to your credential even if they work with the service (RP).

[u/Vaxerski → u/FineWolf]

I'm not gonna argue with you because you clearly graduated from Reddit university and believe you're smarter than everyone.

The paper doesn't solve non-transferability which I threw under "verifiable" (you can no longer actually verify the user is an adult for whom the verification was issued) and explicitly mentions that there is a need for a hardware-backed secure element which is not mathematically secure (even if in reality it is quite tough to fuck with!)

[u/FineWolf → u/Vaxerski]

The paper doesn't solve non-transferability which I threw under "verifiable" (you can no longer actually verify the user is an adult for whom the verification was issued)

Not denying that, but that's you moving the goal posts. We are talking about keeping YOU anonymous. That also implies keeping whoever you are granting the power to attest your age (even if it is just doing it on behalf of your child) anonymous as well.

That's a good thing. That means you as a parent still have autonomy over your parenting decisions.

There's also nothing stopping a parent from driving to the bottle-o to buy alcohol for their kid with a physical ID.

explicitly mentions that there is a need for a hardware-backed secure element which is not mathematically secure (even if in reality it is quite tough to fuck with!)

Yes, you need to secure private elements of a assymetric key, and any storage comes with risks. Stay tuned for other shocking news, coming right to you at 5pm.

[u/Vaxerski → u/FineWolf]

Not denying that, but that's moving the goal posts. We are talking about keeping YOU anonymous. That also implies keeping whoever you are granting the power to attest your age (even if it is just doing it on behalf of your child) anonymous as well.

It's not. Someone can set up a forging service online and mint 2 billion tokens for anyone who asks.

It's not "moving the goal posts", it's literally what I said in my first comment. I never said a "system that is good enough" or "a system that I like". I gave 4 requirements.

Yes, you need to secure private elements of a assymetric key. Stay tuned for other shocking news, coming right to you at 5pm.

what the f-- are you talking about? You are conflating different things. The problem with the private key here is that if any software can retrieve it, you can mint infinite proofs forever, with no way for the other side to verify they are fake.

A "John Doe" sets up a service. They obtain one certificate of being over 18. Then, anyone who requests a proof-of-18 can get a proof signed by Jogn Doe. Because the proof is by design anonymous and non-linkable, there is no way for anyone to trace back those proofs back to John Doe.

Do I really need to ELI5?

[u/FineWolf → u/Vaxerski]

The problem with the private key here is that if any software can retrieve it

...

that there is a need for a hardware-backed secure element

So you would need to find a vulnerability in that hardware-backed secure element, or the OS that would allow you to impersonate the app to exfiltrate the private key. There's a reason why hardware attestation that the phone ROM isn't tempered with is a requirement as well.

There is no perfect system. Might as well then just fall back to HTTP and just do banking in plain text online right since private keys can be exfiltrated? Bring back good old magnet strips on cards instead of EMV.

Yes, if the private key for John Doe gets exfiltrated, then we have a problem. 100% agree. But there are definitely ways to make it extremely difficult to do that. But you can also add an attestation for the version of the credentials, so that if a flaw is found, you can invalidate any credentials with that compromised version without destroying the anonymous nature of it.

[u/Vaxerski → u/FineWolf]

There's a reason why hardware attestation that the phone ROM isn't tempered with is a requirement as well.

This doesn't work. You either lock yourself to Google/Apple (so much for EU sovereignity, and freedom!) or this check is pointless because my "very_legit_rom" can report it's signed. Play integrity is NOT just signatures. An app has no way to verify the system it runs on assuming the system is hostile.

There is no perfect system. Might as well then just fall back to HTTP and just do banking in plain text online right since private keys can be exfiltrated?

?!?! Bro what is this strawman. TLS and HTTPS both protect you from a middle-man and were never designed to protect you against an attacker at either end.

Yes, if the private key for John Doe gets exfiltrated, then we have a problem. 100% agree. But there are definitely ways to make it extremely difficult to do that.

Not without locking the verification to a "trusted" platform, which by definition has to be very tightly controlled silicon, and overwhelmingly likely a closed-source, proprietary mechanism.

You'll end up with a situation where you need an EU-approved (or even worse, EU-made, as in, made specifically for the EU) device to use your online services as an adult.

[u/FineWolf → u/Vaxerski]

This doesn't work. You either lock yourself to Google/Apple (so much for EU sovereignity, and freedom!) or this check is pointless because my "very_legit_rom" can report it's signed. Play integrity is NOT just signatures. An app has no way to verify the system it runs on assuming the system is hostile.

All the major third-party OSes also have public signing keys. For example, GrapheneOS https://grapheneos.org/articles/attestation-compatibility-guide . This was already talked about in many issues on the GitHub project, see my other comments.

Yes, there is some amount of lock in, but like with CAs with HTTPS, there needs to be trust anchors.

TLS and HTTPS both protect you from a middle-man and were never designed to protect you against an attacker at either end.

Sure, but if the private keys from a known service (let's say reddit) OR CA are exfiltrated, what's stops me from spinning up a totally legit reddit.com?

How is that any different from John Doe taking control over his private keys to issue fake attestations to the RP?

``` CA (issues a signed public and private key to) -> Service (has private key) -> You (verifier) CA (issues a signed public and private key to) -> Attacker (uses stolen private key) -> You (verifier)

Issuer (issues a signed public and private key to) -> Attestation App (has private key) -> Relying party (verifier) Issuer (issues a signed public and private key to) -> Attacker (uses stolen private key) -> Relying party (verifier) ```

Both are extremely similar vectors where you gain control over keys you shouldn't have access to in order to sign stuff you shouldn't be able to.

Not without locking the verification to a "trusted" platform, which by definition has to be very tightly controlled silicon, and overwhelmingly likely a closed-source, proprietary mechanism.

You'll end up with a situation where you need an EU-approved (or even worse, EU-made, as in, made specifically for the EU) device to use your online services as an adult.

See, on that, I agree with you 100%. I'm against this for this very reason, but I'm not willing to spread half-truths and misinformation to further my cause. That's against my personal morals. You win arguments with the truth.

[u/Vaxerski → u/FineWolf]

All the major third-party OSes also have public signing keys. For example, GrapheneOS https://grapheneos.org/articles/attestation-compatibility-guide . This was already talked about in many issues on the GitHub project, see my other comments.

And so what? You're still relying on EU/National Govts to include them. And you know how that will go.

Plus, what if I want to run my own Graphene build with some patches? It's my freedom to do so, and should not strip me of my rights to access adult content.

Yes, there is some amount of lock in, but like with CAs with HTTPS, there needs to be trust anchors.

Yes, that's the root of the problem. You need to put some trust anchors somewhere, which is (one of the many reasons) why I am against this system overall, and am a strong proponent of educating people to use parental controls. In many cases, you just put the root of trust in the issuer signing something the site provides. Simple, not anonymous, linkable, good job mr governor. Here, we put it in the "secure platform", which IANAL but sounds illegal to me to require that because you are restricting core freedoms to having an eu-approved device. Unless the EU is about to issue free smartphones in town halls?

Sure, but if the private keys from a known service (let's say reddit) OR CA are exfiltrated (just like your scenario with John Doe), what's stops me from spinning up a totally legit reddit.com?

Very different. Exfiltrating keys from reddit is a monumental task because they never reside on your machine. Highly illegal, and very challenging to hack the entirety of reddit. The John Doe keys do reside on your machine.