NorthSec 2025 - Christian Paquin - Enhancing Identity Credential Privacy with Zero-Knowledge Proofs

Hopefully my voice will last for the duration of the talk. It's great to be back in my native Montreal and to be invited at Nord sect again. And I'm surprised by how many people uh showed up on a post-launch Friday afternoon, sunny like in in a beautiful Montreal like this to come hear about zero knowledge technologies. It's funny because um my first job when I graduated here uh was for a company called Zero Knowledge Systems back when we used to party like in 1999. And at the time I was talking to a few people and they always you know told me things like why is this company called zero knowledge system? Like that sounds stupid sounds like you're you don't know anything. Why would we work with you? And now it feels that almost 25 years later where things as established as zero trust architectures and these type of things then people get it. It's like okay we don't have to trust you and then in this case we don't have to trust you with our data. So privacy is back a big comeback in the the the last few years. So that's been a an interest of mine for at at the early stage of my career and I'm happy to to get back to it and try to provide more privacy specifically in in the world of online identities. So yeah, I I I've been in this field a lot. uh and in in our team at Microsoft research, we do things that are 5 to 10 years ahead of of the product teams and and try to explore technologies um that could become practical and use in to solve today's problems and this is very much what we'll be discussing today. Okay. So when we say identity, that's one of the first thing that could come to mind. If you live here in Quebec, you probably have one of these in your in your wallet. This is a I got that from the SLQ website. So, it's like a it's it's it's a sample uh driver's license, and we use it, of course, to prove that we're allowed to drive, but it has a lot of other uh uses. And specifically, for it's very common to say if you want to go walk into a bar or there's some some some alcohol, they they need to ask you, okay, are you over 20 over 18? Sorry. Over 21 is my new American mentality. So, if you're over 18, and of course, we just show our driver's license to do that. Of course, I'm providing way more information than I need to do when I do that, right? Because I'm actually showing my name, my address, a lot of information that uh the person asking doesn't need to know. But because this is an ephemeral uh transaction and the barman doesn't have photographic memory and won't like record all this information in the log, it's fine for our, you know, personal day-to-day threat model. But when we're starting to migrate these identity credentials online, uh things are quite different, right? We be very kind of wary to present an electronic version of this credential to a website. And we've seen in the news, it's it's it's been discussed a lot that a lot of websites they want to know or they're forced to they're forced to to check the age of their participants, social networks as well. And not just that, but all the other information that they are on your credential, state of residence or province of residence, these type of things. Okay, so let's imagine how that would work. So, if in real life I would like to only be able to show that I'm over 21, what could I do? Well, I could take a, you know, a marker pen and just cross out all the information that I don't want to share. And that's still authentic. I the plastic of the card and the security, you know, protection is still intact. My face is still there. Let's just forget about the face identity for now. And now I just leave the date of birth. So, I was like, okay, great. Now, the person can let me in with a minimal set of information, but it's not actually quite minimal because I am disclosing more than the fact that I'm over 18. I'm showing my full date of birth. It's losing my age and I I should I could should should go a step further and just cross out the month and the uh the day of my birth and just show the year and say, "Okay, you know, now you're convinced I'm over 18." And I still need to show that this document is valid. So I can cross out the specific um day and time of the validation period. But again, that's not minimal, right? the real minimal information is a booleans like yes or no are you over 18 and that's what zero knowledge type technology is what can help us do and just have an equivalent of just having a magic marker that says yes the date that I'm not disclosing to you is such that I'm over 18 so we know how to do that cryptographically uh this problem has been a long uh it's been there for a long time and we uh we will see how we're going to apply that to this use case. But before we do that, let's get a little summary of how online identity works today. So there are two main types of identity credentials. We have X509 certificates which have been around forever and they haven't changed much uh in the last couple of decades. And these you you get them issue there's associated private key so you can lock it in in hardware in a very secure system and you present it and you can prove like okay I'm the person who I say am identity certificates that's not or attribute certificates which have not been really popular but these exist as well and the far more common uh credential types today is called a JSON web token or a jot And these are used everywhere in open open ID in in oath in all sorts of protocols and they kind of replace the SML WS trust type protocols that we had uh a couple of decade ago. And how does these things work? So an issuer certifies some claims or attributes about you and gives you this token this credential. It is signed cryptographically so you cannot modify it. It can be tied to a private key. So nobody else can present it on your behalf without access to the private key. And then when you present that to a verifier they can check if they trust the issuer. That works and so long certificates you get them in advance and then you can present but you can't modify the content. You cannot take the black marker pen and erase some attributes otherwise that would invalidate the signature. you need all the data to see it. And if you only want to show your data birth, what would you would need to do in modern like oath type accesses is that I'm going to just ask for these attributes to the issuer. on demand in real time. I need to go to the issuer get the token specifically for the access I'm trying to get and present that which is better for privacy on what about what I'm disclosing but it means that I need to ping the issuer and therefore maybe they learn where I'm going and they get a bit more information that they would need because when I show my driver's license to get into a bar the government doesn't magically get notified of that fact. So in a way we we kind of want a system that's that would take the best of both worlds to be able to cater what we're showing with the independence of not once the the credential is issued to me I I have the control and I can do what I want with it without having to contact the issuer. Okay. So there's a new generation of credentials that provide what um we call selective disclosure. So this ability to cross out some attributes. So how do do do these work? The first one is well I'll start with the second bullet point. It's the mobile drivers license uh specification. It's developed in ISO. It's been developed for for many years. And uh after that the Jot ecosystem the JSON web token kind of replicated some of these features in a new profile that's called selective disclosure uh JSON web tokens or SD jots and how it works is that instead of encoding your attributes directly in your credential you take a random salt and then you ash the data in the digest of that you um you encode in the credential. So what goes in your certified token is just gibberish. It's a bit like you know the the password file. So you put your password that's not in clear what's in on the server. It's a a a mix with some ash uh with some salt random salts to prevent brute forcing these values. And then when I want to present this token what I do is here it is. It's a certified set of gibberish by the issuer. I did not modify it. And by the way, attribute number two is my last name. And here's the pre-image um and and and the salt that was used to to create this value. So if I didn't know that, I would not be able to present it. And if that was I couldn't pro prove a wrong value because I would not be able to come up with a pre-image to that hash that would result in the same digest that's in the credential. So MDLs are being pushed a lot these days. I was trying to look at the state of deployments in Canada and AMVA is the association I forget the acronym what it stands for but you can see at this URL uh it's it it's the organization that defines mobile driver's license profiles in North America that's why you can go in the US present your driver's license they they know how to read it it's all the same schema so it's going to carry over in the electronic world and we see that in the states the purpleish states It's already have deployments. Actually, I have one from the state of Virginia where I live. Uh that's it's standard uh trial periods and trial settings. I'll try to use it at a TSA and it didn't work uh because their reader didn't work. But it's it's getting there. So, these things are are real and they're coming and they're they're coming fast. Okay. So, that sounds like a good news. There's only one little problem and is the notion of the unlinkability. So what I was saying, so when I present my driver's license to go in a bar, the government doesn't know that I went there when it's when it's paper. But electronically, this um credential has a lot of what I call correlation handles, little unique fingerprints. So it could be personally identifiable information in the credential that you're disclosing. It could be the public key that's always you cannot present the token without showing this value and that's a unique number. So is the signature. So when you're presenting this you're leaving digital fingerprints everywhere. And after that, if even if you didn't ask for token from the issuer, you could an issuer looking at these logs could find out where you went or the ads, you know, ecosystem could do that or collusions between verifiers being uh malicious or just that's their business. Let's not forget that the web 2.0 that we know today has been built on a business model of tracking users. So we'd like to avoid our digital life to become a game of where's Charlie or where's Waldo and you know so okay where did Christian go today let's look at all the logs and he's been there and there and there of course that's less than ideal again cryptography comes to the rescue with some magic technologies that can prevent this these linkages we have what's known as unlinkable signature There's two flavors. One is blind signatures and the other one is signatures with proof protocols. And essentially is that the credential you get gets randomized by the user either uh at issuance or at presentation. That's the different between these two types of protocols. And then you can also do that black marking but in a different way than just providing the hashbased mechanism that I said earlier. It's a stronger cryptographic uh mechanism that provides uh the perfect privacy we call you cannot enumerate the salt and figure it out. You cannot brute force it. It's just if you don't know you will never be able to figure out what's under that black marker pen. Okay. So that seems like a good best of both world way to deploy that to to solve that problem. And when I do that, nobody in collusion even and maliciously can try to track and trace me wherever I went online. But again, the problem is like cryptographers, we like to work in ideal systems that typically do not exist in real life. So deploying these things have been hard for the last 20 years and nobody had great success. Um and mostly because hardware uh requirements are not there like this the TPMs the secure elements on the phones they don't support these types of signatures and changing the issuance infrastructures like all the DMVs the the the let's like the SQ equivalent in the US that that would be very difficult. So now let's switch gear a little bit. I I'll talk about this new project that we've been working on to work on this assumption. So let's just assume we can't change any of these systems today. And what we're going to do is use this new types of zero knowledge proofs to work on top of these existing credentials. And in a sense, so when a user you get a a a credential of any of these types, you could create a proof that says something like, "Yeah, I'm over 18 or I reside in Virginia or I work for this company." Any type of real true statements that you can make out of the claims that are encoded in the token, you're you're you're able to do with zero knowledge. The question is, how practical is it? Is it just science fiction or can we actually deploy that in real life? And that's what our project is is hoping to demonstrate. I don't want to scare anybody, but just a few kind of behind thes scenes look of of keywords of of things that we're using. If you know what these things are, good. You might look uh and try to learn more about it. If you uh if you don't, then uh I hope you learned something. So since the 80s the zero knowledge protocols have been you know studied and they were quite efficient until this this new things called ZK snarks uh came about and really made things more practical and more efficient and really okay so this the the very long acronym of ZK snark zero knowledge means when you prove something you don't leak more information as my initial example when I showed my I'm over 18 by showing my date or my year of birth, I'm leaking information. I'm leaking my age. If I just prove a boolean, I'm not leaking any more information. So that's zero knowledge part. Suent means small. It's very compact. A few bytes, it's like 200 bytes to to be able to show very complex statements uh and very efficiently or at least the val the validation is very efficient. Non-interactive it means I don't have it's not a protocol. I can just create it and present it to a website. So it's very useful like to log in to websites these type of of scenarios. And the arguments of knowledge means that I need to know what I'm proving. I cannot uh pro prove false statements. And we're using uh this grut 16 u proof system which has been around for a long time and it's been kind of battle tested. It's used what's that was used in Zcash if you know what that is the anonymous kind of bitcoin system. And we have the innovation that we created in in crescent versus these other uh grout 16 type systems is that if you know anything about that you might have heard that it's very inefficient to create proofs. It takes a long time you know uh and it's not very practical. But a lot of this circuitry is to prove things like I have a credential and I'm uh going to prove that all the hash data I had like the shot 256 things ash the things that signed by the issuer. I'm going to prove that I have a valid signature and that the signature is correct but I'm not going to show it to you. I can prove that I own the private key associated with the public key in the token and uh I can I'm going to sign a challenge by the verifier but I'm not going to disclose the signature value but I can all prove that I did that work without disclosing it to you and you create a bunch of of constraints but these things you kind of have to do kind of once like the the issuer signature doesn't change so I don't have to prove that a lot so I can pre-process a lot of that work in a prepare phase and that's the inefficient one and we're able to keep only the live things like to answer the challenge of the verifier and this deciding what I'm disclosing uh in the second very efficient phase that we can do on you know on a phone or something like that. So that's the if you're a zero knowledge aware person uh the innovation that we have in crescent is make the showing phase very efficient and um think I'm just going to skip that uh but some you know little Peterson vector commitment there if you're crypto aware and and and you like to see some of the details but um that we're we're able to kind of split off And now I'll show the demo and explain that uh live but essentially it's a modular way to plug in different things I want to prove. So we'll do kind of disclosure one attribute and a range proof to show that the dates expiry date is smaller than than or further away than the date of today. Okay, I'm going to skip that and just show the demo directly. And I'm tempting the demo gods by doing a live demo with like three Rust servers here on my my machine. So let's see if it works. Okay, I'm going to play the role of Alice and she works for Kontoso, which is the Microsoft default sample company that we have. So that's the name. And she logs into her administrative account. And then all right, welcome. And now this is you can get your employment verification JSON web tokens. So this is a weird UI. It's just so it can show things on the on on the screen. So let's say she gets her token and it looks something like that. Threepart B 64 of of a JSON web signature. Great. So what she's going to do now is she has a wallet that we've we've built the crescent sample wallet. It's in the browser and it says, "Oh, do you want to import this JSON web token?" Like, let's do that. And you notice she already has her mobile driver's license in there that she obtained before. Perfect. So, now it's the preparing. So, now it's doing that one time long proof. It's going to take a minute or so, but once it's in your wallet, you can use it very efficiently. So, let's that work. Let's go to another thing. She decides to join this social website. It's a very cool, edgy um social network. I wouldn't know anything about it because I'm not that cool, but they do ask to verify your age. In this case, it's 18. It could be 16. Okay. Well, she can do that with her mobile driver's license. So, if she opens the Crescent um wallet here, she sees, oh, this website would like to verify your age. Do you want to disclose that you're over 18 to social? Let's do that. And that's that the whole point of demo is just to show that the presentation and the verification of these things. It's it's for the user experience is is transparent. It's it's very fast. And now she can go and and sign up. So what happened there? I took the MDL. I didn't send the MDL directly. I just create a proof saying I have a valid mobile driver's license from the state of Virginia. And um I've demonstrated the the position of the private key without showing you the equivalent public key that's in there. And I've demonstrated that the signature of the issuer is valid without showing it to you. So there's no linkage linkable elements in the proof that I presented. And the only thing that the uh verifier needs to trust is knowing about kind of the custom the crescent system parameters which would be shared by you know the full ecosystem. AMVA there would be one for North America and trusting the original issuer which is the DMV system. They have their own PKI there. So you have to trust that as always. Perfect. Now because she did a lot of social networking, Alice would like to now need some mental counseling just to counter uh the effect of all this social networking. and her employer provides a service access to a mental health uh practitioner. But of course, you know, you might want to do that and access it to talk about sensitive issues, personal issues, and you might not even want your employer to know that you did that, right? Uh depending on what the issues. So, what you can do is present your employment credential. So just my my work credential and just disclose that okay my email address that's in the token. I'm not disclosing my full email address but just the domain part and it's from a current JSON web token and I'm also going to disclose the the US location because the the website asked for it and I'm like fine. And then again I'm logged in immediately and I don't have a relationship with this service provider. The only thing they know is that oh that's a current employee. So you know we can uh as as the the contract we have with the employer but I don't know which one of their employees and even if the employer you know IT admins and and the the the verifiers admins get together inspect all the logs they would not be able to figure out that this is Alice. It's one of the many current employees of the company. So that's um that's a demo. I'll link to the slides uh on my uh on my socials afterwards. So uh if you want to get the details, but um which I'm running out of time now, so I'm just going to open the floor for questions if anything. So that's in conclusion that's coming technologies these MDLs and all these things and the interesting thing is can we built the layer to have like the privacy that we would like as you know as a society on top of that. Thank you. >> Oh that's good. Thanks. >> I'm happy to answer any questions if any comments. Yes. So there must be a an expiry time not even a day because it should be shortlived when you present is generated every time. >> So the question is is your proof valid like forever or is there expiry date uh time to um to the proof that you're creating? Yeah, it's it's configurable is however you want as a deployer. So uh yeah, right now like we have a default of like five minutes or whatever, but it's it's it's a config that you set in in your proof system. Yes. Second topus validation. >> Yes. Okay. So the question is that prepare phase how you know how long live can it be because it's uh at some point your token will be expired. You will not be able to create a valid proof. That's fine. So the the prepare phase is valid forever because you're proving you know uh the the signature of the issuer signed that that's going to be true forever and then when you try to present it you will not be able to create a valid proof that it's not expired anymore because the the today is like part of the of the second phase because that changes every time. So everything that's dynamic is part of that second phase. Everything that's static is uh in the first phase. And the the the good thing is that that's the long part. So we're we're able to premp compute a lot of that very long thing which only took a minute you know on my laptop. Um but still it's not a good experience to wait for a minute for user experience but the second phase is really instantaneous. Is there any way? >> Ken, is there a way to prevent people to what? >> To prevent like service providers to >> ask things. Ask me things. Yeah. >> Uhhuh. Right. So the question is how can we prevent relying parties or fires to ask for too many things like I mean we can't. It's just that's their policy, right? It's just you need to show us this to access and so I mean it's it's kind of a a business problem. It seems like if privacy is important for people and you know a lot of companies are marketing privacy more and more these days. So uh it's going to be kind of a choice dictated by by the ecosystem. What the system does is that the user has to explicitly kind of view what's being asked and agree to it and present these things actively. It's not behind the scenes in you know a lot like JB tokens that you don't even know what's being disclosed. So at least there's a benefit there's a user centricity to it. Question >> maybe >> when you revoke access yeah okay so the question is how do you revoke access when somebody leaves the job? So the thing is you only prove true statements about your current credential. So if the credential itself has a revocation mechanism, you would also need to kind of prove that you're not currently revoked based on that one. So in these examples, uh we don't want like the the MDL, I think their model is that they they want to avoid that and they uh they want to have like monthly your driver's license valid for 5 years, but you're going to have monthly renewal of these MDLs or things like that. So uh depending on how they revoke the the classic token is we just follow that with with these type of proofs. >> Yes. As that number likelihood of the two are separated. >> Yeah. So you're asking uh if I may paraphrase, you're asking like timing correlation between getting a token and presenting it. Yeah. So now that's getting very nitty-gritty and I love these like analysis. So this in it's the these are all kind of side channels that you can attack if you really want to track somebody or a group of people you can measure a lot of things. That's how you know the tax on tour and these type of things work like who gets in the network and who gets out you can correlate a lot of that. So with these type of longive credentials long liveish that's why you want to get it in advance and then use it as you need. So if you just request it and present it one way that that that could leak information. But yeah, so we we live in the real world and there's a lot of ways that that you can leak this type of data. At least what we're working on is that the crypto itself, the crypto wrapper of these tokens do not leak anything. That's what the best we can do in a practical manner here. And then the rest of system of course needs to be built according to whatever threat model you're trying to achieve. Any other question? Was that a question? No. Right. All right. Well, thank you every everybody for your time. Enjoy the rest of the conference.