In October’s ZK call, we had a presentation that provided an overview of an interesting and exciting new development for age authenication using zk. Google has recently partner with Self to offer some verification. The presentation and discussion can be viewed on Youtube. A more in depth technical talk of Self by Abhi Shelat.
Why zk verification?
In an ideal world of ‘old internet,’ it would be sufficient to enter your claimed age to watch a game trailer or click a toggle switch when signing up for a new e-mail account. This approach offers users a maximum amount of privacy by allowing users to lie.
Unfortunately, powers that be want assurances that users cannot lie. As a result, the worse possible approach has been implemented requiring users to provide copies of their licenses to prove their identities.
Assuming that the user trusts the company they share their license with, this approach has two obvious downsides:
users have to share more information than necessary.
Another option is to use zero-knowledge proofs to attest to aspects of the user’s information. Specifically, the user can selectively disclose information.
Over 18 does not require date of birth.
Nationality does not require name, driver’s license number, height, weight or date of birth.
etc.
How does Self propose to handle this?
Self proposes using passports. Passports contain a NFC chips that contain the owner’s data and a signature from the issuing country. This allows Self to design an arithmetic circuit to support age disclosure based on the passport’s issuing country.
General concerns?
Post-quantum resistance. Self originally proposed using Groth16 for generating the proof. However, due to post-quantum concerns, it appears that Self has changes to using a combination of GKR and Ligero.
Proof generation can be computationally intensive.
In the original design of Self, they proposed using a TEE server. Users would upload their encrypted passport to the TEE server where the passport would be decrypted for proof generation. The TEE hardware ensures that the passport data is deleted even if a malicious party has access to the machine. It is unclear to me whether TEE is still used (since the change from Groth16 to Ligero/GKR).
Groth16 is a zk-SNARK that emits a small proof of 3 group element. Additionally, Groth16 is efficient to verify. However, in this particular application: users generate proofs and computational powerful entities verify. A zkNARK is sufficient. This makes Self’s selection of GKR reasonable.
So I implemented a prototype of this (putting the digitally signed passport data into the witness and proving that you are above 18 at a given data).
Groth16 (or any circuit-based SNARK) is really bad for this:
you have to parse ASN.1 encoded stuff (certificates, signatures, etc) inside the proof, and unfortunately that encoding doesn’t really have a fully fixed structure
the certificate chain has 2 steps, usually with different hash/signature algorithms
there are a huge number of possible combinations of signature and hash algorithms; even if the ASN.1 encoding was fixed (it isn’t), you would need a very large number of different circuits to handle all those combinations
basically all passports are somewhat unique (so much for “standards”), even those issued by the same country!
So the right approach is a zkVM with well optimized “gadgets” for signature verification (which is hard because they all use different elliptic curves) and hashing. You can still do a final recursive proof compression wrapper with Groth16 or Plonk.
I used Risc0 for simplicity (it was only a proof-of-concept prototype); the hashing was fine but their elliptic curves implementations are either very shitty or non-existing (depending on the curve choice).
There are some obvious problems with the whole approach:
revocation is hard to handle
as what’s in the passport’s digital chip is simply digital data, which you can (indeed you need) to copy to your computer / phone, it’s then simply a file which can be freely copied, so anyone can “prove” their age with the same passport
This could be improved by:
including a random challenge in the proof
having a phone certified realtime selfie compared to the passport photo (which is also there in digital form) by a locally-run small neural network inside the proof. This looks borderline possible with zkML, but more like something feasible in 5-10 years; and requires small neural network accepted by all players. And I guess that can be probably hacked easily too (eg. by using a printout or digital rendering for the selfie)
the passport’s chip doing some challenge-response protocol, which can be then proved inside ZK. This requires changing the passport’s software, so unlikely to happen in the near future
If such a change in passport designs could be made, maybe the passports could have the same format as you mentioned earlier!
I knew from ‘region’ to region the passports were different. But I didn’t realize there were differences from the same issuing country. Thanks for the insights.
Unlikely to happen, based on my experiences with these international “non-standards”…
yes it’s way worse. Btw at least in the EU, national ID cards also have passport-compatible digital sections (with even more variations lol…). I tried like 1 passport and 3 or 4 ID cards (not so easy have a lot of those to debug things!) and they were all different… Subtle encoding differences + different hash/signature algos. One was so different that I couldn’t even set up the NFC communication layer (which is another huge can of worms btw…) and didn’t have time to debug it (as it was not my ID card…)
No (well, not in a public repo :). It was done for a company, and it’s also very very hackish (partly because the whole “standard” is very hackish…)
The insight is quite interesting nevertheless. Thanks for sharing! I’m glad you clarified that this was through a company project, otherwise I’d have a lot of questions about where you acquired additional ID cards.
Your point from earlier that an age proof based on a passport only demonstrates that you have/had access to a passport of the appropriate age, but does not tie it to you is very valid. In fact, I would say this issue seems to exist in a lot of the current non-privacy verification schemes. I feel like ‘politically’ this issue would be a criticism of zk approach but not mentioned for the ‘traditional’ approaches.
oh I can answer that: I simply asked friends and coworkers to loan me their IDs
(i don’t think you can just approach any government and ask for sample ID cards and passports for all the 100s of different versions lol)
I mean, having a challenge-response included in the physical chip would at least enforce that you hold your passport/ID in your hands, which I think is good enough for practical purposes (well depends on the context, it’s good enough for using a forum, a porn site or an online booze shop; not good enough for opening a bank account)
In fact I think there is some kind of challenge-response thingy, mainly for establishing secure communication between the NFC chip in the passport and the NFC reader, but I’m not sure that’s provable then in ZK… Would need to refresh how that works (I only put in enough effort to be able read the data from the chip, which was painful enough! and took more than a month to achieve)
I also have a funny story. So first I experimented with my own passport. Now establishing that secure communication with the chip (without which it doesn’t even talk to you) is highly nontrivial, and not exactly well-specified either. So I spent countless time with trial-and-error until it worked. But after a while I noticed that communication became significantly slower! It turns out that the chip counts the number of unsuccessful attempts, and intentionally adds delays so that you cannot brute-force. I was very afraid that I ruined my digital passport lol, but then when I finally succeeded fortunately the counter was reset…
Thanks for sharing! I’m glad you clarified that this was through a company project, otherwise I’d have a lot of questions about where you acquired additional ID cards. 