6 ms·

Like many mention in other comments on this post, it's possible to implement using ZKPs. There are likely other methods that would be effective without comprom

by pksebben 10mo ago

Like many mention in other comments on this post, it's possible to implement using ZKPs. There are likely other methods that would be effective without compromising privacy. None of them are part of the Age Verification discussion because kids are not the actual point of Age Verification. When I say "if we have to know you're not a kid, we have to know who you are" I'm not stating an actual truth, but the argument as it is playing out politically.

magicalhippo 10mo ago
> None of them are part of the Age Verification discussion because kids are not the actual point of Age Verification. The EU age verification solution says implementations SHOULD implement[1] their ZKP protocol[2]. Not linking it to the user is stated as an explicit goal: Unlinkability: The goal of the solution is to prevent user profiling and tracking by avoiding linkable transactions. Initially, the solution will rely on batch issuance to protect users from colluding RPs. Zero-Knowledge Proof (ZKP) mechanisms will be considered to offer protection. More details are provided in Section 7. [1]: https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/#4-age-verification-solution-high-level-requirements https://ageverification.dev/av-doc-technical-specification/d... [2]: https://ageverification.dev/av-doc-technical-specification/docs/annexes/annex-B/annex-B-zkp/ https://ageverification.dev/av-doc-technical-specification/d...
- crote 10mo ago
  If privacy is an explicit goal, why isn't it a MUST? Why even bother with the initial batch issuance phase? And what's stopping them from silently adopting a batch size of 1?
  - magicalhippo 10mo ago
    > Why even bother with the initial batch issuance phase? This is a solution that requires non-trivial interaction between many paries. It seems very reasonable to want to get the parties started on the implementation so they can iron out issues in the infrastructure they're building while they work on the details of the ZKP aspects.
- mzajc 10mo ago
  Is there a good explanation of how ZKPs prevent attestation providers (which presumably know your identity) from linking an issued proof back to you if, for example, the website elects to store it? I can wrap my head around RSA and ECC and PKI, but I haven't managed to make sense of this yet. Assuming that's even a goal, of course. The cited paragraph mentions RPs (the websites, from what I understand), but makes no mention of attestation providers.
  - MatteoFrigo 10mo ago
    This is, of course, very technical, but here is how it works at a high level. In the non-ZKP presentation, the "holder" (phone) sends the credential to the relying party (website), and the RP executes some verification algorithm. In the ZK presentation, the holder executes the verification algorithm and sends to the RP a proof that the algorithm was executed correctly. The "proof" has this magical property that it reveals nothing other than the check passed. (You will have to take on faith that such proofs exist.) In particular, if the check was the predicate "I have a signature by ISSUER on HASH, and SHA256(DOCUMENT)==HASH, and DOCUMENT["age_gt_18"]=TRUE", anybody looking at the proof cannot infer ISSUER, HASH, DOCUMENT, or HASH, or nothing else really. "Cannot infer" means that the proof is some random object and all HASH, DOCUMENT, ISSUER, etc. that satisfy the predicate are equally likely, assuming that the randomness used in the proof is private to the holder. Moreover, a generating a proof uses fresh randomness each time, so given two proofs of the same statement, you still cannot tell whether they come from the same ISSUER, HASH, DOCUMENT, ...
    - parineum 10mo ago
      If it's not linked to an identity, why can't a kid use a parent's key?
      - MatteoFrigo 10mo ago
        Excellent question. More generally, what prevents me from copying the credential and giving it to somebody else? The currently favored approach works like this. The DOCUMENT contains a device public key DPK. The corresponding secret key is stored in some secure hardware on the phone, designed so that I (or malware or whatever) cannot extract the secret key from the secure hardware. Think of it as a yubikey or something, but embedded in the phone. Every presentation flow will demand that the secure element produce a signature of a random challenge from the RP under the secret key of the secure hardware. In the ZKP presentation, the ZKP prover produces a proof that this signature verifies correctly, without disclosing the secret key of the secure hardware. In your example, the parent could give the phone to the kid. However, in current incarnations, the secure hardware refuses to generate a signature unless unlocked by some kind of biometric identification, e.g. fingerprint. The fingerprint never leaves the secure hardware. How does the issuer (e.g. the republic of France) know that DOCUMENT is bound to a given fingerprint? This is still under discussion, but as a first bid, a French citizen goes to city hall with his phone and obtains DOCUMENT after producing a fingerprint on the citizen's phone (as opposed to a device belonging to the republic of France). You can imagine other mechanisms based on physical tokens (yubikeys or embedded chips in credit cards, or whatever). Other proposals involve taking pictures compared against a picture stored in DOCUMENT. As always, one needs to be clear about the threat model. In all these proposals the biometric identification unlocks the secure hardware into signing a nonce. The biometrics themselves are not part of the proof and are not sent to the relying party or to the issuer.
- baobun 10mo ago
  One thing to keep in mind when reading about any "ZKP protocol" is that on its own the term has the same inherent vagueness as "end-to-end encrypted" - especially when like here there are more than two parties concerned to solve a single verification. What information is not disclosed to whom? In what way is it ZK? One example is Googles "zero-knowledge age verification" where AFAICT, Google still has full insight into all the sensitive data and metadata. It's not like they inherently need to be the designated middleman but that is how the scheme is designed. Therefore I find it ingeniously marketed. A bit like saying "Facebook Messenger protects all your messages with end-to-end encryption", which is arguably technically true but misleading and not an honest statement.
  - Terr_ 10mo ago
    > same inherent vagueness as "end-to-end encrypted" Recent HN discussion example: How Kohler Inc. has a toilet feces analysis camera with "end to end encrypted", except they're one of the ends so it is deceptive advertising. https://news.ycombinator.com/item?id=46129476 https://news.ycombinator.com/item?id=46129476
knallfrosch 10mo ago
> the argument as it is playing out politically. The law does not mandate identity, so your argument does not hold.
orblivion 10mo ago
Okay but then if a ZKP solution is presented, that's calling their bluff. They now have one less excuse for surveillance. EDIT: Actually do one better - tell them that for 16+ websites, you're actually protecting teenagers by keeping them anonymous.
- wcarss 10mo ago
  Yeah, getting into the car with the guy holding the gun doesn't become okay because you have a great argument you're waiting to use down the road. He's already got the gun out. We should have started arguing when he just said he had a gun, indoors, in the crowd. We shouldn't have quietly walked outside at his demand. But that all happened. Here we are now, at the car, and he's got the gun out, and he's saying "get in", and we're probably not going to win from here -- but pal, it's time to start arguing. Or better yet, fighting back hard. Because that car isn't going anywhere we want to be. We absolutely can not get in the car right now, and just plan to argue the point later. It doesn't matter how right the argument is at all.
joe_the_user 10mo ago
The thing is that as far as I can tell, a ZKP of age involves a state or similar attestor to issue an ID/waller that can be querried for age without revealing identity. But attestor has to have certainty about the age of the person it issues IDs to. That raises obvious questions. What states are going to accept private attestors? What states are going accept other states as attestors? What state won't start using its issues ID/Wallet for any purpose it sees fit? This system seems likely to devolve national Internets only populated by those IDs. That can all happen with ZKPs not being broken. That is how states work.
phyzome 10mo ago
Sure it's possible, but are there implementations in use that meet this criterion? Because if there aren't, then it matters substantially less whether they're possible.
miki123211 10mo ago
The simplest possible such method? Single-use age verification codes, generated and validated by the government, sold on physical scratch cards with in-store verification of ID, piggybacking on the infrastructure we already use for selling alcohol and cigarettes. This would be far easier to implement for websites too. You'd just have a single, unauthenticated API endpoint which, given a code, tells you if the code is valid (and marks it as used). Integrating with such an API is about 1 day of work for a competent dev. Even open, non-profit platforms like Mastodon could easily implement such a mechanism. Scratch cards wouldn't have to be the only way of getting such codes. THe vast majority of people could just generate them in their banking app or whatever (which would still be far more privacy friendly than the current ID verification mechanisms).
- deleted 10mo ago
  [deleted]
immibis 10mo ago
You may be confusing the UKOSA (which is about surveillance) with the concept of age verification more generally.

magicalhippo 10mo ago

> None of them are part of the Age Verification discussion because kids are not the actual point of Age Verification. The EU age verification solution says implementations SHOULD implement[1] their ZKP protocol[2]. Not linking it to the user is stated as an explicit goal: Unlinkability: The goal of the solution is to prevent user profiling and tracking by avoiding linkable transactions. Initially, the solution will rely on batch issuance to protect users from colluding RPs. Zero-Knowledge Proof (ZKP) mechanisms will be considered to offer protection. More details are provided in Section 7. [1]: https://ageverification.dev/av-doc-technical-specification/docs/architecture-and-technical-specifications/#4-age-verification-solution-high-level-requirements https://ageverification.dev/av-doc-technical-specification/d... [2]: https://ageverification.dev/av-doc-technical-specification/docs/annexes/annex-B/annex-B-zkp/ https://ageverification.dev/av-doc-technical-specification/d...

crote 10mo ago
If privacy is an explicit goal, why isn't it a MUST? Why even bother with the initial batch issuance phase? And what's stopping them from silently adopting a batch size of 1?
- magicalhippo 10mo ago
  > Why even bother with the initial batch issuance phase? This is a solution that requires non-trivial interaction between many paries. It seems very reasonable to want to get the parties started on the implementation so they can iron out issues in the infrastructure they're building while they work on the details of the ZKP aspects.
mzajc 10mo ago
Is there a good explanation of how ZKPs prevent attestation providers (which presumably know your identity) from linking an issued proof back to you if, for example, the website elects to store it? I can wrap my head around RSA and ECC and PKI, but I haven't managed to make sense of this yet. Assuming that's even a goal, of course. The cited paragraph mentions RPs (the websites, from what I understand), but makes no mention of attestation providers.
- MatteoFrigo 10mo ago
  This is, of course, very technical, but here is how it works at a high level. In the non-ZKP presentation, the "holder" (phone) sends the credential to the relying party (website), and the RP executes some verification algorithm. In the ZK presentation, the holder executes the verification algorithm and sends to the RP a proof that the algorithm was executed correctly. The "proof" has this magical property that it reveals nothing other than the check passed. (You will have to take on faith that such proofs exist.) In particular, if the check was the predicate "I have a signature by ISSUER on HASH, and SHA256(DOCUMENT)==HASH, and DOCUMENT["age_gt_18"]=TRUE", anybody looking at the proof cannot infer ISSUER, HASH, DOCUMENT, or HASH, or nothing else really. "Cannot infer" means that the proof is some random object and all HASH, DOCUMENT, ISSUER, etc. that satisfy the predicate are equally likely, assuming that the randomness used in the proof is private to the holder. Moreover, a generating a proof uses fresh randomness each time, so given two proofs of the same statement, you still cannot tell whether they come from the same ISSUER, HASH, DOCUMENT, ...
  - parineum 10mo ago
    If it's not linked to an identity, why can't a kid use a parent's key?
    - MatteoFrigo 10mo ago
      Excellent question. More generally, what prevents me from copying the credential and giving it to somebody else? The currently favored approach works like this. The DOCUMENT contains a device public key DPK. The corresponding secret key is stored in some secure hardware on the phone, designed so that I (or malware or whatever) cannot extract the secret key from the secure hardware. Think of it as a yubikey or something, but embedded in the phone. Every presentation flow will demand that the secure element produce a signature of a random challenge from the RP under the secret key of the secure hardware. In the ZKP presentation, the ZKP prover produces a proof that this signature verifies correctly, without disclosing the secret key of the secure hardware. In your example, the parent could give the phone to the kid. However, in current incarnations, the secure hardware refuses to generate a signature unless unlocked by some kind of biometric identification, e.g. fingerprint. The fingerprint never leaves the secure hardware. How does the issuer (e.g. the republic of France) know that DOCUMENT is bound to a given fingerprint? This is still under discussion, but as a first bid, a French citizen goes to city hall with his phone and obtains DOCUMENT after producing a fingerprint on the citizen's phone (as opposed to a device belonging to the republic of France). You can imagine other mechanisms based on physical tokens (yubikeys or embedded chips in credit cards, or whatever). Other proposals involve taking pictures compared against a picture stored in DOCUMENT. As always, one needs to be clear about the threat model. In all these proposals the biometric identification unlocks the secure hardware into signing a nonce. The biometrics themselves are not part of the proof and are not sent to the relying party or to the issuer.
baobun 10mo ago
One thing to keep in mind when reading about any "ZKP protocol" is that on its own the term has the same inherent vagueness as "end-to-end encrypted" - especially when like here there are more than two parties concerned to solve a single verification. What information is not disclosed to whom? In what way is it ZK? One example is Googles "zero-knowledge age verification" where AFAICT, Google still has full insight into all the sensitive data and metadata. It's not like they inherently need to be the designated middleman but that is how the scheme is designed. Therefore I find it ingeniously marketed. A bit like saying "Facebook Messenger protects all your messages with end-to-end encryption", which is arguably technically true but misleading and not an honest statement.
- Terr_ 10mo ago
  > same inherent vagueness as "end-to-end encrypted" Recent HN discussion example: How Kohler Inc. has a toilet feces analysis camera with "end to end encrypted", except they're one of the ends so it is deceptive advertising. https://news.ycombinator.com/item?id=46129476 https://news.ycombinator.com/item?id=46129476

knallfrosch 10mo ago

> the argument as it is playing out politically. The law does not mandate identity, so your argument does not hold.

orblivion 10mo ago

Okay but then if a ZKP solution is presented, that's calling their bluff. They now have one less excuse for surveillance. EDIT: Actually do one better - tell them that for 16+ websites, you're actually protecting teenagers by keeping them anonymous.

wcarss 10mo ago
Yeah, getting into the car with the guy holding the gun doesn't become okay because you have a great argument you're waiting to use down the road. He's already got the gun out. We should have started arguing when he just said he had a gun, indoors, in the crowd. We shouldn't have quietly walked outside at his demand. But that all happened. Here we are now, at the car, and he's got the gun out, and he's saying "get in", and we're probably not going to win from here -- but pal, it's time to start arguing. Or better yet, fighting back hard. Because that car isn't going anywhere we want to be. We absolutely can not get in the car right now, and just plan to argue the point later. It doesn't matter how right the argument is at all.

joe_the_user 10mo ago

The thing is that as far as I can tell, a ZKP of age involves a state or similar attestor to issue an ID/waller that can be querried for age without revealing identity. But attestor has to have certainty about the age of the person it issues IDs to. That raises obvious questions. What states are going to accept private attestors? What states are going accept other states as attestors? What state won't start using its issues ID/Wallet for any purpose it sees fit? This system seems likely to devolve national Internets only populated by those IDs. That can all happen with ZKPs not being broken. That is how states work.

phyzome 10mo ago

Sure it's possible, but are there implementations in use that meet this criterion? Because if there aren't, then it matters substantially less whether they're possible.

miki123211 10mo ago

The simplest possible such method? Single-use age verification codes, generated and validated by the government, sold on physical scratch cards with in-store verification of ID, piggybacking on the infrastructure we already use for selling alcohol and cigarettes. This would be far easier to implement for websites too. You'd just have a single, unauthenticated API endpoint which, given a code, tells you if the code is valid (and marks it as used). Integrating with such an API is about 1 day of work for a competent dev. Even open, non-profit platforms like Mastodon could easily implement such a mechanism. Scratch cards wouldn't have to be the only way of getting such codes. THe vast majority of people could just generate them in their banking app or whatever (which would still be far more privacy friendly than the current ID verification mechanisms).

deleted 10mo ago
[deleted]

immibis 10mo ago

You may be confusing the UKOSA (which is about surveillance) with the concept of age verification more generally.