 Thank you everyone and I'm happy to be back at Norsak, especially on a beautiful day. Like today was awesome to go have lunch outside in super sunny old Port Montreal. It's the best time of the year to visit, as I tell all my American colleagues now. So yeah, I'm from around here, I've been studied long time ago, quantum cryptography at the University of Montreal right here, and after that I joined the industry, most of my career doing cryptographic development. I'm now at MSR working on all sorts of cool advanced crypto technologies trying to bring them to market and see what can be the future of security. A lot of it deals with privacy enhancing, identity technologies, zero knowledge proofs. A lot of the focus last year, the last few years has been in post-quantum cryptography. We're avidly waiting for the NIST decision for what's going to be the next post- quantum algorithm. If NIST makes the announcement during my talk, please just interrupt me and let me know. We've been waiting on that news. But like most of the world in the last two years, there's been some interruptions because of COVID and joined an effort to help with the smart health card framework, which I'm here to talk about. So first, what's that? What's a smart health card? So I hope the organizers did not invite me because I thought it was smart cards, especially we heard that our host here is interested in smart cards. Well, yeah, it has nothing to do with that. That's an acronym or a backronym from the medical community. It stands for I have to read it because I don't know it by heart. Substitutable medical application reusable technology. It's a set of APIs in the health care industry to avoid vendors lock-in and whatnot. So it's for health cards to be able to present a medical information in a convenient way. So what it means for the COVID, so in the U.S., nationwide, people add these little paper cards. Here in Canada, the provinces at the beginning before the QR codes came in, everybody had a different solution. Either a little sticker with information, either a PDF you would download, which would contain your name, date of birth, your vaccination history, and that's what you could use to prove to various people that you've been vaccinated. So, of course, that's very susceptible to fraud and forgery modifications. So the question becomes, how do you create a digital version that can prove authenticity and cannot be modified? And so that's what a smart health card is. So the QR code, first, it's not a URL like it typically is when you scan these with your phone. It brings you to a website. These QR codes actually contain all the information and that's all you need. You don't need to call back somewhere to verify the information. Of course, most of you here in Quebec, you might have not known that you've been using the standard. Here it's been branded as Vaxi Code by the government. So, but your Vaxi Code is actually a smart health card. So if you want to learn more about what's contained there, then I guess that's a good talk for you. Before I delve into the details of the framework, how it came to be in some of the security properties, I'm just going to give a description of how this QR code is created to just have a clear representation in your mind of what's going on. So the paper information named date of birth, vaccination history, it's transformed into what's called a fire bundle. Fire is another health care standard. It's called, I have to read it again, fast health interoperability resources. So that's how the medical EHR vendors, electronic health record vendors, they talk through the fire protocols. So it's just a JSON structure with, if you can zoom in, you see the highlighted data is what's on the paper. That gets encoded into a JSON web token payload that has some metadata about who created the smart health cards, some other metadata, the fire bundles in there. And then this is signed into a JSON web signature. But because the target is a small QR code with very limited payload size, we have to make an effort to make it small. So it's minimized, compressed, and then it's base 64 URL. Then it is signed using the JSON web signature format, standard, some header that's added, the signature is added there. And then anyone who has this data is able to verify because they can look up the public key of the issuer that's in the header and verify the signature. This is then transformed into a numeric QR encoding. If you know anything about QR code, it's very standard. If you didn't know anything about that, like I did a year ago, a year plus ago, then you go read that and it's just a normal way to do that, to transform any data into a QR code. And voila, you have your final QR image. Of course, there's a lot of details surrounding what's happening there. So that's where all this is defined and specified in the smart health card framework. So the goal of this framework, I've highlighted here, is to provide a way to provide authenticated and immutable medical facts. So it's not to act as an identity document, it's not meant to be a green check mark saying, yes, I can go into this thing. It's policies around the world, policies even across time, week to week change. So the medical community wanted to provide a way just, here's the medical facts. These facts happen and then some other part of the process needs to make decisions if that's an OK condition to do activity X or whatever. So as I said, it's not an identity document, it only has a name, date of birth, and it needs to be matched into some other form of identification to make sure it belongs to the right person. And all these, this minimal set of data has been highly debated in the framework community to see is that not enough data, too much data and the level of risk about the usage of these things and whatever level of fraud, somebody with a matching name and date of birth could use your QR codes. OK, acceptable, that's fine. All the specifications are open and the work started before the pandemic in the medical industry, but of course it got accelerated and COVID became the focus of the use case. And the success of this framework versus other approaches, there have been a lot of competing proposals in the US. There have been some other approaches selected in Europe, for example, they have the digital COVID certificate, the DCC thing, which is very similar to the smart health card, it's just different set of decisions. They came up with a slightly different format, India has their own solution, and other parts of the world as well. But this one, you can find everything you want to know about that, the smart health dot cards. My team, actually, we developed this portal, demo partals, that's smart health dot cards. It allows you if you want to go scan your own QR code and see all the details of it, as I've shown the previous slide, you can do that. And part of the success of the framework is its large implementation base. So it's been picked up by Apple and Google, so they, in your phone, they support it. Natively, there's a lot of specific apps in the US, they have different jurisdictions, like VaxiCode here, New York, they call it Excelsior Pass, and Louisiana, also at their own wallet. A lot of states in the US chose to just use the common apps without their own in province or in state app. Okay, let's leave it at that for now here. Just to give you an example, you can see it's mostly a North American or Canada and US standard with deployments, but there's some other parts of the world that have adopted it and are more and more. Okay. So now what's, all these things are issued. So first, to become a smart health card issuer, you just set up a, just create a key pair, very conventional cryptography, and, well, in Canada, it's mostly the provinces and health ministries that do that. In the US, it's a bit more complicated. There's no central health authority that oversees everything, and if they do, they don't have the mandate to issue certificate, vaccination certificates to everybody. So it's mostly industry-based. So you will have some state registries, you're going to have some big pharmacies, like Walgreens or CVS, you're going to have your hospitals, they're going to be issuers. So there's a wide variety of parties. So they can all self-host and create their own key pair. And when a user, given a specific interaction with that party, it can prove that well, they got their vaccination, then they can get this QR code. It can be held on any medium. So it could be in a specific app, it could be on the Apple wallet or the Google wallet, it could be printed on paper, makes no difference. And then later, when you go and present that to a party that has a verifier, you can, they can just download the key that's identified in the QR code and validate the information. So in fact, what that's one value of using a framework that's common and that's standard is that when I came here during the pandemic visiting, I had my Virginia QR code and at the beginning the Vaxi code would not validate it because it did not recognize external keys. But at some point it did, so I was super happy to go to restaurant, just scan my U.S. QR code and it was validated by the app just because it was based on a standard and not a one-off solution. And vice versa. So my family, when they came to visit in the U.S., also they're external because you have two versions here, the one that's made for travel is a confirmant smart health card so it can be validated anywhere in the world that supports the standard. So now, as I mentioned, anybody can just start issuing smart health cards. Very easy to self-set up. There's a lot of software for it. Of course, not everybody should be trusted to be a valid smart health card issuers. So the question becomes, okay, how do you create that list? In security and cryptography, we have this notion of PKI, right, public infrastructures. That's a very convenient, that's the most common mechanism to establish trust. There's a trusted authority and it can delegate trust in different environments, which in Canada was very simple because everything here, the health care is provided by the provinces, so here each province became the authority about issuing these credentials. In the U.S., it was a mismatch of different things, as I said before. So there was a need to create, in PKI we would call that a PKD, which is a public key directory. And this organization is the VCI, which has been kind of renamed with a broader scope to verifiable clinical information. Their goal is not only to oversee the smart health card specification, but also to decide who is a trusted issuer. So there's a set to make sure that there are verified health care organizations that are actually, and they have COVID vaccines, and then once they've been vetted and audited and verified, then they can be part of this VCI trusted directory. In fact, all the Canadian provinces are part of that directory. The directory is public. If you go to VCI.org, you can see all the information, you can verify there. In fact, we were part of our team wrote some auditing software for that directory to make sure that everyone there is online, that their key sets are cryptographically correct and that all the information is secure using the right TLS config and all these things. Okay. So that's the kind of overview of the smart health cards. I hope you have a clearer idea now what's in these QR codes. I'll now discuss a few just a few more security aspects because we're here at Nordsec. One thing that that became very apparent or soon is that there was a need for a revocation feature for the smart health cards. Normal certificates can be revoked. And in the smart health cards, there's, at the beginning of the framework, because of the rapidity at which the standard came to be and because of the nature of the information, which are just clinical facts, so they should not change or you don't lose access to these facts. So the security practitioners among this group were not able to get a revocation feature day one in the specification. But of course, as it was easy to predict, there was some reported fraud and not really on the cryptography of the system, but mostly on the human factor. Here I've seen some headlines in Quebec about either nurses or medical practitioners getting bribed to get invalid entry in their vaccination registry or you could have fake the paper trail and coming from cross jurisdiction to say that you had your vaccine, then you get issued a valid credential that can be later proven false by the police. So we had to develop this revocation mechanism that was added to the specification. It came a bit later than after the first wave of QR codes were issued. So there are two mechanisms to revoke these cards. One, that's forward looking, where these cards can now have a revocation ID built in that can be listed on a, we'll reduce the acronym CRL for card revocation list here. And there's a legacy one that derives a dynamic revocation ID based on the content of the fire payload there. So let me just do a hash of a few fields there. And these can also be time-stamped in the certificate list, the revocation list, so that if you're a naughty user who got fake your paper trail and then got convinced to go get a vaccine and therefore a valid card, then if you get your card with the same revocation ID later, then you can be revoked up to a certain point and then later your card would be valid. So that's one thing that emerged after the initial launch of the framework. The other work that we have hinted to a bit earlier was the VCI directory auditing and snapshotting. So the cryptography and all the security of the card itself is not too complicated, it's pretty standard, but the devil is in the details and the big part of the making sure that the security hygiene of the system is to making sure that these issuers are not, they are trusted. So if you start seeing weird issuers there, there's going to be a lack of trust in the system. And the VCI got a lot of proposals to be joined like, hey, I'm a clinic here and I'd like to start issuing smart health cards. So there's been a big list of proposed issuers that just been rejected because they didn't mean the minimal requirement of what's a trusted issuer. So our team, we've been involved in the creating of two things. One is the audit script that I mentioned that just make sure that once you pass the test to get into the directory, then you're still okay day after day and not just your security just goes crazy or you go offline or you disappear. Then we keep track of that. The other thing that we've enabled also is to create a snapshot of the directory, including all the keys because the flow, if you remember the diagram, is that when you verify this QR code, so if you're the Quebec app and you verify Quebec QR codes every five seconds, it's fine. You have the public key. But if you're at a Super Bowl sports stadium with visitors from all around the continent, then you might need to get different keys and there's a lot of fetching keys all over the place. So you're able to download this offline version of the directory that the VCI provides and you're able to validate the QR codes in an offline manner, which is big when there's a lot of users and you don't want to have a lot of bandwidth. It could be like a transit station, New York metro station, for example, that would be useful. Okay. I think that's all I want to say about that. Let's see how I am on time. Okay, that's good. So I wanted to present the work that's been done on SmartHealth Cards, but I wanted to reserve some time to talk about the future of digital identity. So I've been in this field for a while and we've been pushing this idea of user-centric identity documents for users to be able to prove any identity facts about themselves to whichever stakeholder, it could be online, it could be in person. And I guess now the QR code that people had to present forever in the last year, then that's kind of unlocked the imagination there and helped to explain some of these scenarios and make them very concrete. So as an immediate next step, we prototyped a system that's similar to the SmartHealth Cards, but instead of having a medical payload, you could have any claims there, so any JSON WebToken payload or data, any attributes, you can encode them in these QR codes and you're able to present them and verify them in a similar manner. So, okay, let's, but one important aspect of that is the ability to add privacy on top of the framework. For SmartHealth Cards, that's something that's been debated a lot, okay, are you disclosing too much information every time you're presenting it? So when you go and board an airplane, you disclose your name, date of birth, and along with all this information already that they already know about you and way more data that you have to present. But when you go to see a movie, you typically wouldn't want to or need to present a date of birth and name even. So for a general identity document, then you don't want to force always presenting everything about yourself. And the main identity document that people have in North America is a driver's license that what you show to present some identity attributes about yourself. So to disclaim QR framework, we've added the ability to present a subset of these things. So it's a simple mechanism versus more advanced cryptographic ones using zero-knowledge proofs that you could prove properties of yourself, like I have a date of birth and I can prove I'm over 21. But that's a bit more complicated. What's very easy is just the ability to take the equivalent of a black marker pen on your driver's license and just hide the data you don't want to and present the rest. So we call that subset claim disclosure. And the way it's achieved is that instead of the issuer encoding these claim data, these attributes directly, they're ashed and salted so that for brute force resistance. And that's what gets encoded in the QR code. And to disclose this value, you have to show to the verifier these digest along with the data that was used to generate these digest. So it's as if you're presenting this driver's license with little puzzle pieces cut off. And you can see, you're seeing, you don't know what the pieces are removed, but if I take a piece, I can put it back and you see that it matches perfectly. And that's the only value that could have been there. So just as an example, I have a little demo, but I think my slides might be more illustrative. So I'll just start with these. So imagine I have this data that I want to encode in the QR code. So I have a JSON Web token, there's an issuer, the example.org issuer, there's an expiry date. And these claims on the right are the ones that I want to be able to selectively disclose. So it's my name, my real date of birth. I'm super young. And then these are transformed by the issuer. And there's a random salt, which is just a random value. And along with the claim attributes. And then these get ash using the salt and the claim value. And they get encoded in the JSON Web Signature payload. Then using the mechanism I've explained before, these get transformed into JSON Web Signature, they get signed, and then turn into a QR code. Now that I have that, if it's on paper, oh, I forget to mention the last part on the little green part of this GWS, it's an appendix, so it's extra data, and it's actually the claimed data that would allow a verifier to understand these digests there that otherwise would be opaque. Now when I'm presenting that, if I'm presenting that on paper for legacy users, everything gets disclosed. But if I have an app, a client app that understands this, the user could decide to remove some claims, let's say removing these two pieces of data from the claimed data object and then regenerate the appendix with these two pieces removed, then regenerate the QR code and present that instead. So what will the verifier do? It's going to verify that the QR code is signed, the data that's on the bottom left side didn't change, that's the one that's signed, and I can prove that these two pieces out of four that I'm presenting corresponds to the data that was encoded in there by the issuer. So that's the mathematics of what I just said. So I'll go to my final slide instead of presenting the demo, which is something you can go and run yourself, it's an open source project, so if you want to do it, it's just a web portal that's going to allow you to try that. But I wanted instead to spend a minute to discuss what I think is the future of digital identity for a user-centric approach. So some of us cryptographers that are dealing with digital identity have been proposing some of these ideas for many years, almost 20 years ago as part of a company here in Montreal that developed the U-Proof system that's listed down the list here doing all sorts of cool zero knowledge proofs on data and being able to prove properties about yourself without disclosing these said attributes. And it takes a lot of complexity to these systems, so I'm going to explain with the selectives disclosure is kind of a let's go step by step in improving from the status quo and what's going on today. So that's why the type of projects I just presented stepping off from what people have been used to will allow us to get to these advanced features. Which, so one interesting thing development is that there's a new ISO standard that's coming out, it's called the mobile driver's license, the MDL, which supports a flavor of selective disclosure, like I have disclosed. And it's going to be for, as the name says, for driver's license. I know it's going to be adopted in some parts of the States, I'm not sure about Canada. But that will be a big stepping stone and a big milestone for the user-centric digital identity. But there are more privacy featured that will be needed also for long-term benefits. One is unlinkability. So all these tokens that you receive that are signed by an issuer, a signature ends up being a random value, unpredictable value. But once you have it and you're presenting it, you're presenting essentially a long-lived cookie to different parties. So if two parties collude or if a party goes back to the issuer, okay, I got a ticket for the claims that it's an over 21 user. I don't know which one it is. But you sign and the signature is 0, 6, 1, 7, 3, then say, oh yeah, I gave that to Christian like two months ago. So this data can be randomized using what's called blind signatures or you could prove you have a signature with zero knowledge proofs without disclosing its value itself. So there are some approaches in cryptography that will allow us to break this linkage between issuance and presentation. And derived claims, which I've briefly talked about earlier, are a good way also to add some features and give power to the user. For example, to be able to show that my date of birth is such that I'm over 21 without disclosing it, or I would say over 18, or that my name does not is not listed on this denial file list or whatever without actually disclosing my name. So there's a lot of powerful techniques that have been explored. We've prototyped some of that. I'll just cite one of the projects I've been involved with. In the past, you prove does that and there's some activity in the W3C verifiable credential standard that's upcoming and people are also working on these type of features and love it or hate it. The Web3 blockchain community have been developing some of these techniques which is going to be for some of their blockchain type use cases, but also this base cryptography can be reused and applied in a wider variety of scenarios. So I'm kind of very excited about this work and the future of the Web3 blockchain. It's a user-centric digital identity which gives a lot of power and privacy to the user. So on these words, I'll conclude and I'm looking forward to the questions in the next session. Thank you. APPLAUSE