Minting your sanitary pass for fun and privacy

Transcript

um okay so sorry i'm just turning on the clock please tell me if the sound is correct or not but if it's right i can start so thanks everybody for joining me today for this completely improvised talk um so i will be talking about what you can do with the sanitary pass when you're a blockchain guy how you can use it even if you are not a blockchain guy and one immediate application if you're a developer would be to design your own application to validate your sanitary pass if you like so if you don't like to something kovid if you want a web app to validate your sanitary pass you will be

you will be able to code that either right after or during the hackathon so uh who am i what is this so i'm a co-founder nicola beckham a co-founder at ledger i'm currently cto at ledger origin which is the iot division of ledger which is not that well known i am interested in open trusted computing so trusted computing is basically the art of running code of computers that you can trust somehow with cryptography or other means so when you run something on a trusted computing platform you can provide a proof to someone else that your code is correct and that the platform is correct more or less the idea and i like to use trusted computing to add more privacy to different protocols so

this talk is basically a weekend hack that was not supposed to be a talk at all so it turned into an emergency talk according to the discussion you see right there on last night because apparently someone canceled and so here i am so if you wanted to see another talk you are in the right room so i'm not yeah so that's the talk for today if you don't like this talk sorry that's it so what's a sanitary path so statistical path is a qr code format which is defined by european standards so i will be calling it digital green certificate as well because that's the official name so you have a link to the first specification as it's a european standard you have a lot of other specifications not necessarily linked to that one so this talk is about

is about summarizing the specification if you're a developer how to use them how to read them um so the past can be useful to get into ethereum conferences as you know our cafe in france you can have it into the tucson ecobid app and you can verify your pass with the tucson tick of it verif and you are not supposed to run it so it might be a good way to to understand what the format is because if you read the list if you read the license of tucson sikhovit verif if you are not a health professional you're not supposed to use it to scan qr codes for whatever reason so that's it so the problem with that with the sanitary pass design as a qr code is that you have several problems so the first one is of course a security issue so you

have a signed qr code for authentication that doesn't look too great because you have no mutual authentication so everybody can copy it and i have seen people i won't give names of ethereum conferences doing that for example but sometimes they are verified with the naked eyes which means that well you are basically back to the old xkcd with pgp just hear you replace pgp by qr and well signature by vaccinated because of course if my phone displays the courier saying i'm vaccinated i am vaccinated without any doubt so that's not great the bigger problem i would say are the privacy issues so first you have to trust the validation application not to keep your data when reading it of course you have absolutely no way of

checking that because usually the application is run by a terminal that you don't control so well you can't really do anything about that but which data are we talking about so the most obvious one is your name so there is your name in the certificate less obvious things there is your age type of vaccine vaccination country issuance and expiration date because so yeah your certificate is going to expire in about two years so that's good to know and well so that's what's in the certificate but what can be extrapolated from the certificate of course you can get your list of venues because if we suppose that the application is keeping list well it's going to be able to see that time of visit then you can see who is

attending together you can see who is hitting what and so on and you can well it can turn into a privacy nightmare basically if people keep um the keep the qr codes and start doing big data or even small data on it so it's not really great so what if we could provide a proof of owning the dgc so either locally if remotely or remotely which will solve the security issue then what if we could optionally link it to a name but on demand and not by default so that would solve the privacy issue and we would like to do that without involving at any point um sending the digital green certificate to a centralized third party because if you do that you basically are

completely well you drop your privacy because then everybody can see your certificate and you don't know what the remote party will be doing so we want to do that locally with trusted computing so what is going to happen with this this is what we want to achieve and we will see how to achieve it but you get the qr code you give it to a magic trusted computing box which is going to verify it then this box will issue a proof of unique validation so that you can't have multiple people on scanning the same certificate you will have the issuance and expiration date because that's still useful to know if you are fully vaccinated and if your certificate is valid you will replace the name by a hash of your name so hash that you can reveal or not if you want

a proof of trusted computing processing of course because this data would only be valid if it's run on a secure platform since you can then have a route of trust from the secure platform to the dgc and the smart contract will be able to verify this receipt and mint something out of it so i took an example of an nft because i think it's a it's a good example but it could be pretty much anything so challenges are if we want to do that so first one which is what we will tackle in the presentation can we verify the dgc on a trusted computing platform so is it complex can we do it offline um so spoilers yes we can do it offline and no it's not complex so is the trusted computing platform open enough to let us check what it is

doing i will demonstrate how to do it on ledger because that's a trusted computing platform i know the best for some reasons and can we verify the trusted computing proof in a smart contract spoilers also yes and people already did it for ledger so my job was really easier um and another spoiler there is absolutely no code so i will show you how it works so you can implement it if you want the code will be coming later let's start so we are going to read the qr code so first we scan it so you get a big blob of text you can decode with this blob of text with a with an encoding format called base 45 it's not very common but i think it was basically done for this for this specification and then it's compressed to save space

so you can decompress it with zedlib which is prettiest on that and the result is binary json called uh cbor so if you are not familiar with cyborg i won't dig into it here i mean you can do that yourself but it's basically json and everything will read like json so if you want to read it in a human readable format you can do that with a tool called seabordam for example from from tennessee from from intel but there are probably a lot of other tools to do that so let's dig into what is our qr code you'll see that you have a kind of an array over there which is well with a lot of other sibo encoded thing so we start with the first number which is a simple tag so which is going to tell okay this message is

signed that way and this format is defined by yet another specification called cause i don't exactly remember what cause means but that's in this rfc so in this message you have the name so the format of the message protected header extended header which is empty a payload and a signature so we see here that the dgc is actually a cryptographically verified item so that's good because it means that we can make a loop we can make a link with the trusted computing platforms we can link certificates together we can have a cryptographic proof that everything is correct from the beginning we start digging into the header so the first part

thing is we have only two fields are one called algorithm and one called kid so kid means we will be able to link back to our key so first to verify that's a standard pki thing so to verify what is this key we can fetch a list so those lists are not really public but apparently some people are fetching them and putting them on guitar so that's good so here you can get the public trust list for france on this url which will list the list of well all trusted authorities from the other countries so that works well and the key of this entry is a base64 and call it kids that you are reading here so matching one to the other is pretty is pretty simple just with a short break let's say you

are reading this file you have absolutely no idea what is uh what are the pkcs standard you see something called public keypad pm um you don't want to convert it to there pass it and so on you can just base 64 decode it and take the last 50 60 65 bytes and you will get the key so if you just need to get the key and you are in a hurry you don't want to spend time reading uh pam specifications and so on you can just do that and you get the key so once you get the key you can verify the signature so to verify um so the signature is cause the code signature one that i described before that just a shortcut i mean you can probably do that with a library if you

want but let's assume that you don't have a library to do that you are going to compose the sibo message yourself so the silver message is an array of four fields the first one is a string called signature one literally signature one then by string protected header by string empty by string payload you take that you hash it you very you can verify it against the signature so the signature in the um the signature in the dgc is air and s if you want to convert it to uh to a dare signature you have some work to do but well i will leave that to the reader it's not very complicated and then well so when we do that we verify the signature we know that the dgc is valid so we can proceed if it's not valid of course we will discard

everything because it means that the certificate has been tempered by by someone for example either to fake the name fix the vaccination status or whatever interesting part the payload so when we read the payload we see bottom as well we see all the data that we need here so we have the expiration date which is a standard unix time thumb issuance date vaccine information with stack v we have the current number of doses so well the dos is needed which is sd here two current number of those is dn1 so sorry for is loss for example certificate will not be valid to enter atc but that's okay we have tg which specifies which disease this vaccine is used

um against to hear it's our beloved kovid and then you get so that's very nice you get a standardized last name and a standardized first name so it's kind of international format that's written in your in your id card i guess which is great because if you have exotic characters in your language you're not going to be exotic here so it means they're going to be nicely displayed by whatever platform you have so once we have that what the trusted computing platform can do it can verify that the vaccine is our vaccination is okay so you have the right number of doses and then proceed from there because you have all necessary information you could do the same with a pcr test so pcr tests are also

encoded using this format i'm not describing this so here i'm just focusing on vaccination you could do that with pcr tests and say okay i can have a proof of a valid pcr test now moving to ledger as a trusted computing platform so it's an open development environment you can get a link here and see how you are going to write applications from ledger the attestation mechanism that we are going to use here is something that has been implemented from the beginning but not really used today so the idea is that you can provide a proof of what is running into your ledger so you will do that by signing whatever application data you want with a code hash of the application that's running so

here you have a proof that you are running the correct version of the application because you can compile it yourself verify the hash this is going to be signed by the device attestation key which is generated when you run the attestation mechanism and optionally you can sign that by ledger issuance key so you can do your own attestation scheme yourself meaning if you want to do that with your own certificate your own set of ledger of your own set of friends owning a ledger you can do it but here we are moving one step further and we are saying that ledger is going to be generating that key because then we can verify everything from an external point of view we can verify the device is genuine that's the first part and we can verify that ledger has been providing the key

so we have a complete link from the issuance from the issuer ledger to the platform to the digital green certificate so what is the application going to do it's going to read the digital green certificate an ethereum address that is going to send the certificate to so that's nice to provide it because then we can display it on the ledger or we can we can have the user verify it and we have approved that the certificate has been sent or not to someone else so i'm not in this model i'm completely debatable but i'm not preventing people from sending the digital green certificate proof to someone else which doesn't make much sense but then we can verify that

it still belongs to the original owner which makes sense because you can't transfer your vaccine so you're still able to transfer the nft but vaccine is harder you are going to provide a privacy password so privacy password i'm going to explain what it is the application will verify the ggc pass it and issue the following data which is described on the other side so you will have an nft token id which is standard for 721 the token id is going to be here um sha 256 hash of the payload of the digital green certificate which makes it super easy then to avoid duplicates because since you can't create nft with the same token id for the by design here you have an automated way

to prevent duplicated certificates from being passed into the system you are going to have the html address that you provided a sha 256 hash of your first name so standardize last name standardized and the privacy password so if you want to reveal it to someone you would have to reveal the three elements and then someone could verify your name if you want date expiration date we sign that so that's part of the so this makes the attested data we create the attestation signature and we provide then all the other elements to verify the attestation so the code hash at the station public key and signature of the attestation publicly by ledger when we have this we have the link i was talking about and we have the complete loop from ledger to the ggc

uh now what is the smart contract going to do so just high level code here no code just description um smart contract is going to verify that the receipt format is correct so they're just verifying that it looks like what it should be then it will verify cryptographically that the device attestation public key is signed by ledger then third step it will verify the receipt that is signed by the device association public key once we verify that we know that everything is genuine and we can trust what we received then we can mint we can maintain the address that we have in the receipt we can use the token id and we will store the original address so this looks i mean the only hard part in that is the verification of the attestation

and luckily for us and for shitty solidity coders like me the hard part of the job has already been done by provable so provable formerly known as oracle i'm not supposed to say that name so please don't shoot me but you have a link here that to the well to the api and it's it's well done and you can just copy and paste and that's what i am going to do to verify it in my smart contract so when i said i have no code i lied a bit i mean i have code working in hard hat but well i want to clean it up before publishing it so then what can we do with that i think the first thing which is well definitely the most useful we can provide a single tap proof that the nft has been issued for the correct address

for the correct key so we can provide a proof of the vaccination certificate which is much better than what we have today because we can prove it cryptographically and we won't reveal our name by doing so so for example we can just sign the current timestamp uh display that as a qr code then you just have to look back on the blockchain that on this address you have the nft you can verify that you own this address because you can verify the signing of the timestamp and you have a solution which is much better than the current one and not more complicated to use because i mean from a user experience point of view you just have to scan a single queuer another nice idea no sorry it was just completely stupid idea but it was fun to

write if you have a slow kit powered door because who haven't for example installed at pfizer lab you can only open it if you are vaccinated with the right vaccine so that's well it would be a good use case for slokit i guess and well if you have another id please feel free to to come to me with the id because i'm sure it will be better than the last one next things to do so we can support more trusted computing platforms uh if you are a fan of sgx please do that please use it to to support that kind of logic it would be nice to see especially since i think with the new ecdsa at the station you can verify an sgx proof on a smart contract and never leave it

but there are a lot of people on that field playing with this gx for good or bad reasons so well please try it and i would really like to see the same thing with the xero knowledge proof and pure matte uh problem is i am very bad at that so if someone has a better idea and a very big brain well please feel free to contribute contact me show me what you can do that would be really great so we're occurred soon as i said likely next week i will be thinking i will be pointing to it on twitter uh so if you want more information about that you can just well follow me on twitter and well i will have some time for questions thank you [Applause]

so just to be clear i'm not really sure to fully understand what's the benefit on on the privacy side because like the the door still needs to look on the blockchain so you still could collect what you have done before you can collect your address it can collect your ethereum address it can't collect your name so if your ethereum address is linked to your ens then yes you have an issue but if you mint it to something that's not connected to your name then you're well you're in a better state than before any question

is it possible to fake the certificate the vaccine certificate so it's not possible to fake it if you trust in cryptography uh if you don't trust in who is owning the keys and it's completely possible to fake it i mean and we have seen that for example the easiest way to fake it is just to give money to someone that will issue you a real fake certificate so certificate with fake name but signed by the right key and of course there is nothing we can do about that so well we can't solve that but at least we can know that we can map cryptographically proven certificate to something else which is more private any last question

in order to solve that trusted vactine problem could we not combine a biometric at the time of taking being given the vaccine and combine the biometric with the vaccine certificate we could we could imagine we could imagine doing that then that would solve mostly i mean verification because it would mean that we guarantee that when we verify the certificate in that case we are not sending the key used to verify the certificate to someone else so that's an additional step that prevents people from sharing the key that was used to generate to generate the dcg so that's an additional step i would say but client-side

because then we wouldn't we wouldn't use that on the blockchain but on the client side definitely that could be an improvement to avoid sharing the key yes so you then have to avoid the sharing the biometrics and the difference is that you can i mean the one thing you can do to improve that you can have different level of proofs for example in the receipt that was uh in the receipt that is generated by the trusted computing platform here you could have an additional flag that says the quality of the key for example that this key is bound to a biometric parameter and so that this key is not supposed to be traveling and according to the level of proof that you want you could say okay i'm only trusting keys that are

generated using that scheme or i am trusting all kind of keys so that that's something additional you can you could add thank you so so far we're talking in an hypothesis where whoever is doing the test is genuine you know so essentially your approach is to validate that the data initially is correct and then find ways that people can review it but i mean it's it's early but it seems at least in france that there is a significant market let's say for

healthcare professional who produce real fakes in the sense that you know they will follow all the verification procedure but they don't inject you with the vaccine or whatsoever yes do you see any solution to validate the data even against the operator so i don't think i don't think there is a solution to validate the data in that case but there would be a solution to revoke the certificate in that case which is in my opinion better because today we don't really have ways to revoke on a fine-grained basis i think because we can either revoke the whole certificate with the whole um the whole i mean root of trust which wouldn't be a good idea but if we could revoke by individual

certificate id and we have we do have individual certificate id by the way uh either in the format here i didn't talk about it but see why in that it's supposed to be a unique identifier so we could think that at some point on the on the board i mean on whoever is testing we would have a list of blacklisted certificates that would be rejected and then this list can be cryptographically signed by anybody else and we can incorporate this into the trusted computing platform so of course you have the problem of knowing if you provided the right version of the of the blacklist or previous version of the blacklist and so on but that's an additional problem to tackle but well at least we could do something i think yeah thank you

okay we have time for our last question yeah if we have the time could you clarify how the smart contract knows that it's the right code that perfectly checked the the certificate oh so that's that's that's quite easy because um the device itself is um is computing the code hash of the code which is running on the platform so you can use the code is open source you can compile it yourself you can verify the code hash is correct so you know so you can do the link between what is verified and what is running inside the device and then the smart contract will just verify the code hash here because it will be present in the receipt that is sent by the device

so you can do it i mean either hard code it or put it in a way that is going to be modifiable only by the owner or well you can do pretty much anything but it's just a comparison in the end thank you thanks for the question thank you