[Aurornis]

Thanks for posting this.

The inherent problem with all zero knowledge identity solutions is that they also prevent any of the safeguards that governments want for ID checking.

A true zero knowledge ID check with blind signatures wouldn't work because it would only take a single leaked ID for everyone to authenticate their accounts with the same leaked ID. So the providers start putting in restrictions and logging and other features that defeat the zero knowledge part that everyone thought they were getting.

[hiciu]

> A true zero knowledge ID check with blind signatures

That is not true and "true zero knowledge ID check" + "age verification" with blind signatures is what's being implemented by the EU ID project.

So someone's id leaks. It happens. In EUDI there are things called "cryptographic accumulators of non-revocation proofs". If your ID leaks it goes into the accumulator. Similar to the certificate revocation lists. During check, you include claims "im over 18" and "my id is not in the accumulator".

This is included in the standard.

This is also (I can only assume) one of the reasons why EUDI wallets require play integrity / attestation / secure element on the device. So your private key won't be easily leaked and no one can steal your ID.

[Aurornis]

You're assuming the leak was accidental, the person knows about it, and they didn't intend for others to use it.

What happens when someone sets up a marketplace where people can sell those blind signatures using their ID for $2 each? And then kids just pay $2 to have someone else blindly use their ID to validate the account, because supposedly the system is structured so that nobody can tell which ID was used or tie it back to the account?

[namibj]

E.g. the German ID card can all on it's own, just using a server certificate configured/parametrized for this and signed by the government, do a simultaneous pseudonym passkey mint and age gate check. That way you could easily block ID reuse; note that the passkey is locked to the card not the person as it's cryptographically derived from the pair of the card's private internal key, and the server's private key that goes to the certificate.

Access to this part of the card is secured by PAKE between the transport layer (TLS) encrypting and user interface providing NFC reader (for example phone with the app, or dedicated hardware) using a PIN.

[hiciu]

That's where the google play integrity / attestation comes into the effect.

In theory you cannot export your private key from the device (from the secure element), so for each $2 someone would have to quickly unlock their phone, scan code via the app and so on.

[coppsilgold]

Private keys from secure elements leak all the time. There will be a flawed implementation that someone exploits, an insider will smuggle a key out etc.

This is why true zero-knowledge systems for this sort of thing aren't practical and will never be. Because a SINGLE leak will break it and there will be no way to even detect it.

The attestation systems you reference don't even allow true zero knowledge attestation, they involve a trusted intermediary to convert your burned-in private key to a temporary key which you use for attestation with a third party.

And the temporary key isn't even a product of a blind signature. And it's rate limited. So if a service selling these temporary keys shows up they will be able to easily trace it to the burned-in key responsible - then revoke it and if possible initiate legal action.

This also means that whenever you register to a service using one of these schemes you are registering with your real identity, it's only a question of how hard and how many parties need to collude to extract it.

And in the event that they really do blindly sign tokens generated on your device, then their scheme will not survive adoption. As it gets adopted, the value of these blind signatures will rise and services that sell them will pop up. There will be no way of tracing the sold blind signature to the compromised/colluding device and rate limiting will merely necessitate a farm of such devices as opposed to a single leaked key.

*Note that Blind Signatures are Zero Knowledge.

[blackqueeriroh]

Can you tell me when a private key has leaked from the Secure Enclave on a iPhone?

[Confiks]

> That is not true and "true zero knowledge ID check" + "age verification" with blind signatures is what's being implemented by the EU ID project.

You are mistaken. In the EUDI wallet project, unlinkable signature schemes are currently being discussed among cryptographers and a month ago Longfellow very basic support for Longfellow has been merged into the reference wallet.

You're making it seem that unlinkable signatures are very established and the default, while they are not. They're not yet properly defined, experimental and mostly unimplemented by member states. Linkable ECDSA signature are currently the default in the EUDI wallet project.

[jajuuka]

I mean that's kind of a problem with ANY solution. There will be workarounds and ways to break it. There is no perfect solution outside someone standing over you while on the internet. We need to look at this more like age checks on porn sites and gaming platforms where you just put in a birthdate. Obviously someone can lie, but that point isn't to be a perfect wall but a hurdle to clear to make sure users are aware of the content and that any sort of nanny software to block if set up.

[Aurornis]

> I mean that's kind of a problem with ANY solution. There will be workarounds and ways to break it.

That's unnecessarily reductive.

Yes, every solution will have problems, but not all solutions have similar problems.

If a solution has problems such that it can be immediately reduced to security theater and bypassed by any teenager who cares, it's just extra hassle and privacy degradation for the rest of us.

These details matter. If a weak solution is regulated into law and the government discovers kids are easily bypassing it, they will immediately pivot into requiring more restrictions on it.

[jajuuka]

Extra hassle is manageable. Sites or programs that want you to put in a birthday are extra hassle but objectively better than something like submitting an ID. Privacy degradation is also manageable as well. It just depends on the solution.

We've had decades of age gating being "are you 18+ or not" yet it is only now that talks of something more enforceable are coming up. This discussion is largely about how one can create a sense of safety and protection. For the more extreme end it's face scans and submitting ID. Even though these are bypassed by any teenager who cares they are still being pushed seriously because it instills that sense of safety and protection for children. Security theater is just a part of managing the internet and not going away unfortunately.

[EmbarrassedHelp]

> age checks on porn sites and gaming platforms where you just put in a birthdate

That's the only solution that truly protects user privacy and security. Video games and especially mature content should not require age verification. People's lives can be permanently destroyed over perfectly legal sexual fantasies, and thus anything that increases the risk of the information being tracked is unacceptable.

[dogcomplex]

This specific problem is solved by requiring that any anonymous ZK ID once used for an account be marked on an immutable ledger preventing multiple uses of the same ID. Sharing it would be pointless as multiple attempts to use it get burned. Yet none of those sites know who you are, only that you have a unique valid ID pass. They just have to check any login attempts against that ledger - easy enough.

[donmcronald]

> They just have to check any login attempts against that ledger - easy enough.

So like CT logs, but several orders of magnitude bigger? I thought centralized TLS revocation lists failed due to scale. How will this differ?

[namibj]

Just crypto tie them to the server/site and let them do it, CRLs were an issue due to distribution to every device, not because of a hastable like sparse set structure being too much. Also this isn't every connection, but only every time you (attempt to) verify your age.