Hijacking Biometric Passports with Zero-Knowledge Cryptography - Rémi

Transcript

[Music] All right. What are the biggest unsolved problems in web 3? Any ideas? Let me help you then with one that I think is big and even goes beyond the border of web 3 itself which is this one, which is kind of ironic because all of these started with Bitcoin, which allows you to burn an insane amount of energy just to prove that you're not a bots. But it seems that up to this point, we haven't made much progress.

Then there is also this one. Are you a bad actor? Cryptography is extremely powerful. Back in the days, it was even forbidden to share the first code implementation of ARSA. And we saw the exact same thing happening with ZK. The constant hacks in DeFi reminds us that this place is a dark forest. And the bad actors are there lurking in the darkness just waiting there to take their shot. So they are going to benefit from all the privacy preserving tools that we are building unless we do something and unfortunately we don't have such such solution yet. I mean at

least not at the smart contract levels. And if these two were not enough, now we also have to prove that we are real humans because with the raise of AGI, it's soon going to be impossible to differentiate human activity from bots. And the current expectations are pointing towards 90% of the online content to be written by bots within the end of the year. So the best is to get prepared for that. And if we don't fight for privacy, the fallback solution is going

to stay the well-known Kawi which is obnoxious for many reason. First, it's not private. You are going to share all your personal information to the third party verifier and this information they're going to get stored in DBs just waiting there to get hacked. Also it's not secure from the application perspective. Um using generative AI again it became childish to pass this process. You can just do a def fake or just generate mock images of ID documents. And lastly the user experience is really bad. Um I think I did it something like four or five times

in the past few months and each time that's such a pain. like you need to find your ID document, scan it, do the liveiness check and then send it and then wait for verification. If you have an app that needs to verify the identity of your users, you are going to experience a lot of drop off at this point. And if decentralized identity is needed, it still remains inaccessible. We saw many attempts in the space uh to build this decentralized identity. The first ones were the general proof of personhoods like proof of humanity or Idino. In the last one, you used to

solve captures to prove that you're not a bots. But yeah, within the next two years, we could expect AI to solve captures that human can't. Then you have the biometrics, proof of personhood. Um these one are super interesting. They're extremely private, but you need to deal with the constraint of hardware. So, it's extremely hard to scale and you need to trust the hardware at some point. So, you could put a back door inside or you could also trick the sensors. So, that's why we decided to launch self. Uh the protocol is live since if Denver and you can try it by yourself. Just look for self zk on the

app stores. It's available on both. And if I'm here today is of course to tell you that all the issues that we saw before, they are now solved because self can obviously help you to prove that um you're not a bad actor and can help you to prove that you're a real human, but it can also help you to prevent civil attacks on on your protocol. And to do so, we decided to leverage the most trusted station of who you are, aka the biometric passport. These are a really good fit for that for many reason. First, they're um they're quite

hard to obtain and people usually only own one biometric passport. Unless you have a dual citizenship in which case uh you're lucky person then people have this genuine intuition that you should take care of your passport and most of the time they they don't lose it and finally uh there are machine readable you can read the passport using OCR on the main page of the passport there are like these two lines also known as the machine readable zone and there is a check digit in styled and it's using a really specific font designed for machine readability But you can also scan it another way because do you know what's inside the biometric passport?

Yeah, exactly. There's a chip inside and this chip contains all the passport data of course but also the digital signature of the document because this document is also signed by the country or more precisely it's signed by the document signing certificates which can sign up to 100k passport which is itself signed by the country signing certificate authority which is going to depend upon the country but can rotates it's a three to three to to five years. And these root certificates, they are published in public registries maintained by the International Civil Aviation Organization. So that's why it's so easy

to verify that a passport is genuine is because anybody can have access to the public keys. So if I take my passport data and send it to you, that's the Kawisi process. You can tell me if that's a real passport or a mock one because you can just take a look at the public keys and verify the signature. But we don't want to do that. We can do better using self and using ZK. Of course, you can prove your identity without any counterparty. And to do so instead of sending your passport data to the person or to the verifier you are going to generate a zero knowledge proof in which you are going to verify the digital signature of the document but also the whole

certificate chain and the root certificates we publish them on chain on ML trees. So you just have to do a proof of inclusion of your root certificates inside this tree. But we can even do better because instead of just proving that you own a biometric passport, you can also prove whatever is related to the passport data. So maybe that you're above a certain age or that you are part of a specific country or not on the offax list and each time without revealing anything else for the offax list. Um what we do is that we we parse it into

spar sparse ML trees and then we let you do a proof of non-inclusion of let's say your passport number inside this sparse m tree. So each time you are not going to reveal anything else that what you decided to disclose. That's it. All right. So, um, remember when I said that it was super easy to to verify the signature of a passport? Well, I lied because countries had the amazing idea to uh use different signature algorithm and hash function to sign these documents. You even have extremely weird setup like uh Shiaan

with SECP2241 which is quite uncommon in the real life but um yeah we're quite happy to show you this map today you can find it on map.sell.xyz XYZ and if you're curious about which signature algorithm and hash function is using your country you can just go to this map and hover your country and you will see this information. Anyway the country in dark green are the country that are currently supported by itself. Um if your country is not in green it means that we are just working on the implementation and if it's not issuing biometric passports um that's not a big deal because let's take the example of India. India started to issue biometric passports um last

year I think and it's even not already available in all regions of India but we already started to extend the support to ADA which is a local ID solution there so I mean if your country is not issuing biometric passport there is a really high chance that it's issuing some kind of other ID documents which is signed and that we could integrate into self All right. So, what does the experience look like and what's happening exactly under the hood? Well, the first step is the registration. In this one, you are going to first scan your passport using the camera of your phone. It's not taking a

picture, it's just reading some fields because uh the chip inside the passport is protected by a password uh who's present on the main page of the passport. So this is the second step. Um in this one you scan it using the NFC reader of the phone and yeah once it's done it means that you on boarded the signature of the document and the passport data and you are ready to generate your first zero knowledge proof or should I say the two first zero knowledge proof. So there is one for the intermediary certificates and one for the biometric passport itself.

So under the hoods, this is what's happening. As we said before, in this first ZKP, you are going to verify the digital signature of the document. But you are not going to reveal anything at this point. Instead, you are going to generate two things. The first one is a nullifier, which is um a unique identifier for each attestation. So you can consider it as just a hash of the attistation and the second one is a commitment which is pretty similar but the difference is that this time you are going to bring your own entropy inside.

So um just just a secret all right so you generate the zero knowledge proof and then the identity registry is going to verify it. So first it verify the z proof then make sure that it's the first time that it sees the nullifier and finally he will add the commitments inside the commitment mark tree updating the path to the root and this means that so this is this is the registration once it's done you're registered inside the protocol and it means that in a second time you can do this disclosure proof about your identity

And in this one, you're also going to generate zero knowledge proof. But instead of verifying the digital signature of the documents, you can now just prove that your your commitment is part of the commit the commitment tree and only you can do it because only you knows the secrets and the passport data of course. So this setup is extremely similar to the one of SIM 4. if you're familiar with it or the one of the cache also and there are two main benefits.

The first one is that the this proof of inclusion they're extremely cheap to do because it's only posted on hashes which is super optimized for ZK. And the second one is that maybe you already noticed it, but um with this second ZK proof, you are also going to generate a new nifier, but this one is no longer generated deterministically on the passport data. Instead, it's based on the secrets on your secrets and the scope which is going to differ for each application. So you can see this as the contract address or the DNS like an ID for the application you are disclosing to. So it means that even if your country is holding your passport

information, he won't be able to know who you are and to link your identity with your biometric passport proof. And even better than that, these newifier are going to be different for each application I'm disclosing to. So let's say that for app A, I'm disclosing that I'm above 18 years old and for app B, I'm disclosing that I come from Canada. I don't know. then it means that nobody will be able to link these two proofs. So that's how using ZK and biometric passports we can now get keep on biometric passport data while staying fully anonymous. All right. So this is the UX

for the disclosure proof. uh most of the time you are going to scan the QR codes and then it's going to get prompted on screen which information this app wants you to disclose and you just have to acknowledge them and then you can generate the disclosure proof. Uh this one is super fast and if it's dealing with sensitive information with I don't know let's say the passport number or your name or your date of birth then as you saw on the video is going to like you will see an extra popup saying hey this is really sensitive information just make sure that you want to really share this with this third party application. All right. Uh we also have a mobile SDK. So if you want to integrate this one inside another mobile

application, you could open the self app by just clicking on a button. Cool. Um so you may wonder where exactly we are generating the ZK proofs. So we used to do client side proving before but because of the constraints of ZK we we migrated to TS which is a trusted execution environment. So a T is a black box. We can't see what's happening there and it's issuing an attistation. In this at stationation there is a hash of the codes who's running inside the ch. Um so the flow is the following. The mobile application is going to connect

to the chi verify the chest station create the secure channel with the ch and then um share the passport data with it. And the ch is only designed to do two things. one generates the zika proof and two delete the passport data and that's it and even us we don't have the hands on that um by the way everything is open source and had been audited by ZK security just before if Denver huge thanks to them by the way um but yeah of course we plan to bring back cladet proving in the future we can do it for uh the disclosure proof in the next few months for the registration one

it's slightly different because if your country is a savage and is using like a bigger algorithm such as SHA 512 with SEP P521 then the proving key which is a file that you need to generate the zero knowledge proof can be up to five to six gigabytes and that's not something unfortunately that you can ask people to download. So uh that's why that's why we decided to offload the proving inside the team. But of course I hope that um new proving schemes are going to come up and there are like some of them that are extremely that are super promising. So yeah of course we plan to to bringing back. All right. Uh few others learning

that we had by building self. So the first one as I was saying before pinking a proving scheme is actually extremely hard. Um it's all about trade-off. Do you want to do do you want to do clients at proving and then the proof are no longer 16? So you can't verify them on chain. That's the case of Spartan for example and then you need to wrap them again inside grow 16. So it it starts to be a bit complicated or the opposite is you can't do CL at proving because you have huge D keys but then you can verify directly the proform chain. So there is no godlike proving scheme. It's all about tradeoff but I hope it's going to change soon. Then iterating on

production application with ZK it's quite hard because you need to do a trusted setup ceremony each time you change the circuits. You also need to to update the prover. You need to update the verifier. There is always a bunch of Merkel trees that you need to cach. So there are like many moving pieces. And yeah, talking about trusted setup ceremony, we did what was probably one of the largest trusted setup ceremony ever with a bit more than 40 circuits that leads to to proving keys that were between two to six GBs. So we used potion and thanks for for for the to the Pion team.

Yeah, the tool broke many times. It's not perfectly ready for production yet. All right. And lastly, um, DMs, they are not good at all to write ZK circuits. They are they're hallucinating too much. So, I guess they're just lacking of context or maybe of training data. And yeah, I hope this this is going to change soon. All right, just a quick words on our SDK. So if you have an application that needs to verify the identity of your users. So maybe you want to maybe you

want to protect against civil resistance or maybe you want to make sure that they are above a certain age or that are they are not part of your fact list then you can just extremely easily do this by verifying um the zik proof using our SDK. You can do this on the back end using the TypeScript SDK or you can do it on a smart contract. On the front end sides, uh if you're a desktop based application, you can integrate our QR code SDK. And if you're another mobile application, then you can just generate a deep link which will open the self app. And by the way, if you have a wallet or an application that don't want his users like to leave the app to

go on the self app, then there is a mobile SDK that is coming soon in which you could wrap the self app and do all the verification and generate the proof and everything inside your own mobile application. So we are currently building this one. Um, if you're interested, please reach out to me because there is no such things than building the products with our customers. All right.

Um, thanks for your time. I hope you appreciated this talk as much as I did. And I think we still have five minutes for a Q&A session. So, let's let's do it. Thanks, [Applause] At some thanks for your talk. At some point you mentioned that um some proofs are um onchain friendly for verification, some are not. Are you sending the proofs that the user generates to be verified on chain or in the in the back end of someone? All

right, that's that's an amazing question. Um, so the proof that are about verifying the identity of someone, it's totally up to the application itself. Um, so in the SDK, you are going to say, hey, I want this proof to be sent to my back end. and then you put an endpoint but you can also say hey I want this proof to be directly verified on chain and then you can just put the contract address directly and it's a bit like chain link VRF you can put a call back function inside your contract that is going to be triggered by our really because at some point you mentioned the proving keys and my understanding but I'm not a cryptographer that some proving schemes like Spartan with proof kit from

worldcoin don't require proving key or I'm wrong or it doesn't require a verifier key. No, no, that's that's right. Uh they don't directly require a proving key. Um but they are not success for example the Spartan proofs. So you can't verify them on chain. Yes. So you could verify them in the back end of the of the application, right? Yeah. Yeah. Yeah. Exactly. So that's why um I think that's what they plan to do is wrap these Spartan proofs inside row 16 to make it succeed. What if you skip the the wrapping and verify the proofs of chain because they're they're not then that's that's okay. You can do it definitely.

What are the biggest services or the apps ecosystems uh that you've integrated in? Excuse me, can you repeat? What are the biggest uh products the apps ecosystems that you're integrated in? Oh, that's that's an amazing question. So um the first product so the protocol is only live since E Denver but the uh the main integration that we have now is with talent protocol which uh maybe you know maybe you know it but it's kind of going to give you a builder score and they want to make sure that you can actually hire these people and pay them. So you are going to disclose that you're above 18 and that you are not part of the facist.

We have a lots of other partnerships coming soon but I can't talk about this right now. Yeah, from talent protocol Pedro the founder he was uh got a complaining how difficult it was to verify GitHubs of developers. So maybe at some point you're going to integrate with bitbuck at GitHub or anything in this area would be helpful for the whole hiring ecosystem. Yeah. Thanks. Thanks. All right. Thank you Remy. I think that's one more.

Okay, one more. Yeah, one more. So you mentioned that you use cryptography for security. Nowadays it's quite a good solution. But uh when the humanity comes to the day when uh we will be able to use like quantum computing, what will your be what will be your uh solutions for that? All right, that's that's a really good question too. Um so we just have to migrate to a proving scheme that is uh quantum resistance. There are already some of them out there in the wild. And the proof that you already generated using self even if um quantum computing comes up tomorrow you

you can't uh break the privacy of this proof. What you could do instead would be generate mock proofs. So you can like generate a a mock passport using quantum computing and verify this proof but at any point you won't be able it just like the hashes function. So you won't be able to break the privacy of a proof and extract the passport information from it if this makes sense. All right, perfect. Thank you. [Music]