Post Quantum Security: Cryptography in Decentralized Identity

I'm Sam Kern and I work for in DCO, and, and Steve works for an anatomy, Steve McCowen. And we're gonna be talking about this. It's a little intimidating to follow such a technical session. One of the caveat here that, that we're not talking about cryptography, we're talking about applied cryptography. So this is a good follow on to the last session, but there'll be a little bit less technical detail in some ways, a little more than others. Steve's gonna get us started.

Alright, thank you. I Think the click's over there on the, There we go. This is a good volume. Okay.

Alright, well let's talk about what post quantum security means to all of our standards efforts. So as Sam mentioned, we are not cryptographers, meaning we're computer scientists, not mathematicians. So we're not gonna talk about the details of the nuances of post quantum. What we're talking about is how it is applied and what that means to us in our standards efforts. So first of all, why post quantum? So RSA algorithms work by prime number factoring and it's, it was computationally intensive, so it took a long time to, to duplicate it, to crack it.

And so it was considered very secure because it was hard to do El elliptic curve. Cryptography operates a little bit differently, but it has kind of the same, it takes a long time to compute. And so it was considered secure. They both use this hidden subgroup problem and that's really neat. I've got a link that'll show up in the slides, hopefully when you get them that you can follow and read all about that. What's happened is quantum computers are really good at accelerating things, mathematical. And so with these two types of algorithms, that's, that's a problem.

Now the commercial national Security algorithm, CNSA, that doesn't stand for collaborating with the NSA, by the way, the, the two CNSA 2.0 suite was updated here just recently in April. And there's a couple of things that we should note out of this. So I've listed the various types of algorithms and, and what they do and the change from CNSA 1.0, which we're operating under right now to 2.0. And right off the bat, notice the top a ES 2 56 is still a good algorithm.

So we're, wherever you're using that, we're gonna keep using that. Shaw changed a little bit, 3 84, they're obviating that and they're going to five 12 down here in public key establishment signatures and so forth. That's where we get into the real big changes. So RSA is no longer approved under this standard and also E-C-D-S-A and for those of us in the identity community, that's a real big deal. And so they have new algorithms that have been selected and you can read all about those as well. They're exciting. Here's the gotcha.

So I was in one of our standards working groups a while back and somebody made the comment, should we be doing something with post quantum? And the response was, oh, don't worry about it because we have until 2030 something. So that stuck in my mind and I went back to say, is that true? And what the release by the standards bodies that selected this is that 2030 they want exclusive use of post quantum algorithms for software and firmware signatures, but they would prefer next year.

So, ah, okay. And so these other dates, they, they cascade, they'll, they'll take a little bit longer. So how do we get there? Not gonna talk too much about this. I wanted this slide included so that it's a good reference because if you're implementing these crypto algorithms, you'll need to go to these resources and they're all intended to simplify moving from where we are to where we need to be. Start with that executive summary up there and then here's some standards that really describe the algorithms in detail.

So yeah, if you didn't read all of that or don't want to, here's what you need to do. Step one, look for any uses of diffy home and E-C-D-H-E-C-D-H-E-C-D-S-A-M-Q-V and RSA then make a plan to replace them and then replace them. So that's all you need to do. Now here's the thing that we need to be aware of in the standard that's been published, this how you get there. From here document, it says step three is discuss, discuss quantum safe roadmaps with technology vendors. And to some degree or another, that's us.

So be ready because your customers, whatever is downline from you, is gonna come back asking these post quantum questions. Alright, so in the meantime, what do we, what do we do before 2025 when they really want this? Right? So cryptographic agility is the ability for your algorithm to basically say this was this, this packet, this block, this whatever was created with this particular algorithm. And that's a really good thing because you, you can switch back and forth with algorithms, that's a good thing to implement.

And our reality that we have to deal with is our customers will be wanting to adopt post quantum at different times. And so in the interim, what we're told is traditional algorithms are, are still good in the interim time. That's elliptic curve, a ES everything we're using.

But the, we wanna shift to the post quantum that's crystals, kyber crystals, di lithium, et cetera. But there's also this thing called hybrid combinations. And that's becoming popular. So what a hybrid approach is essentially layering a post quantum algorithm on top of already encrypting or whatever with a traditional algorithm. It seems a little odd. Why would we implement the new algorithms while we're still also using the old algorithms? And the idea is that let's not make ourselves any less secure than we are now while we get experience and start implementing the new algorithms.

So who's, who's doing that? We see that right now if you're using Apple's eye message, you're going to see this layered approach and they put out a really nice blog paper that is more like a white paper that talks about how they're layering on top of the elliptic curve. They were using signal put out their P-P-Q-X-D-H, which is kind of the same thing. They layer a little bit differently, they ratchet a little bit differently, but it's the same overall process in WhatsApp's. Key directory is using this a bit of this as well.

So profile profiles need to emerge, think, think of this a little bit like governance. And so, and the systems that you're creating specify what, what the options are and what needs to be there. Because we're in this weird kind of interim time where as standards creators, we look at these dates and we say, oh, they don't need to be in there until 2030. But the reality is standards needs to come before SDKs and SDKs need to become before applications. And applications typically need to come before hardware.

And so when the hardware vendors have a 20, 30 plus date that they must be compliant or they have to stop selling at least into government and other sources that require this. We need to do our work. Like yesterday is is the big takeaway. So we don't have until 2030, we have until yeah, this, this evening. So whatever you're doing this evening talk post quantum. So thank you. Thanks Steve. So I appreciate Steve's covering of, of all the actual details there.

And, and it leads us to a discussion about, and we talked a little bit about it, but we wanna be more specific about, so what does that mean on, on what timelines? And so we wanna talk about applications of this that relate to decentralized identity. I'm gonna cover DIDs VCs and did com. I'm not specifically gonna talk about the protocols that rely on TLS security because that's a separate conversation and, and the last speaker identified that also needs an update, but I'm not gonna speak about that specifically, although it is something to pay attention to.

So the first thing we wanna start from is, is DIDs. We, DIDs are the foundation of a lot of stuff in decentralized identity.

Are they, are they post quantum safe? So if they're not using post quantum safe keys, then the answer is they won't be. But there's some other implications that are important. So did methods allow the A method to be specified with whatever, you know, method specific id that's that's actually related and different. Did methods do that in different ways?

A a, a good quality of DID methods is to actually link the identifier that is used in the DID with the actual, at least the initial key that's used inside the DID document that is seen as a good behavior. The challenge here is that if you are currently using a non quantum safe key and you're binding the identifier to that, then the DID method itself will need an update that allows for a, for a quantum safe key to be used in its place and, and be part of that identifier.

So not all did methods will need updates, but some of them will to allow post quantum keys to be bound into the identifier themselves. There is at least one did method.

You know, people lots like to talk about how many did methods there are. There is already one that is designed from the ground up to be post quantum safe. But I'm not indicating that we go entirely to that did method, but did methods that do this will need an update to make sure they can handle a a, a post quantum key for DID methods that already allow multiple key types, which is many and they don't have this bound to the identifier then, then they'll be able to, they'll just be able to allow the existence of a new key and make that happen.

But there, there will be a number that that need an update and that's something to pay attention to. So here's the implications.

The other, the other big one here that I didn't yet talk about, but it's obvious is that if you currently have a JID that that uses a non post quantum safe key, you are going to need a new did. If you won't need a new did if, if in fact you're using one that doesn't have that binding that I talked about before. But many people will actually need new DIDs. Simply rotating keys is usually insufficient.

If you are trying to, for example, provide providence and, and, and a link in a chain and you're authorizing the use of a, of an, of a secure key with an insecure key, you're probably going to do it wrong If you are doing this because you know what you're doing good teach the rest of us.

But you need to be really, really careful about simply rotating to a new key because we, it is not clear what the horizon is for when post quantum computers are, are capable of, of, of, of cracking a private key, which means that you then run into trust issues about whether the rotation that you see to a quantum safe key is in fact authorized by the original key holder or not. And so if you don't know what you're doing, then simply introduce a new did with the post quantum safe keys involved.

And then you need to publish those often through the use of, of governance or some of the other mechanisms that we already use today in order to determine which key is actually authorized, you know, for, for an organization. So be mindful that that, that you have to pay attention to the key rotation piece and to make that happen. And so people are likely going to need new DIDs. That's weird in, in some circles because it's viewed that it did is created once that's your decentralized identifier and then you never use another one again. That's the one that you use in some circles like peer DIDs.

It's expected that you would use new DS on a regular basis or you, you can manage that did come for example, promotes the, the feature of rotating from one did to another did and, and, and making those things work. And so people are going to need new DS as part of this process. There's work in the, the credential trust establishment group at the diff that actually allows for alias Ds to be used in governance to allow you to prepare for and then execute a switch from one identifier to another one for an organization. So now that we have digs, let's talk about verifiable credentials.

And Mike Jones was here earlier, he may have written this as part of the, the VC data model two, which is, which is certainly considered post quantum crypto cryptography. The main takeaway here is that you need to use good keys and those have been discussed previously where, so we're not gonna go deeply into that, but you need to do that. It's also worth noting that you can't simply magically update the signatures in place of a credential. They need to be reissued. And so you need to be prepared as an implication of this to, to reissue.

Oh, I I I'm skipping a few steps here. So the updates are in progress, they're happening. These are likely, here's some signature options that we have. This was was discussed previously as well. There are a number of signature protocols that will need post quantum evaluation and I'll, I'll explain what I mean by that. Selective disclosure works really well if the fields are encrypted separately. SD Johnson example of this. So it uses similar stuff but individually signs the, the actual attributes. And so that will work simply with the, the, the use of a new cipher suite.

The zero knowledge proofs need to be evaluated and, and probably updated predicates is sort of a subset of zero knowledge. Proofs specifically need to be evaluated. Seal signatures is, is the most common way of doing this. And there has been research into, to a replacement for seal signatures, but nothing that is considered final at this point. So these things need to be evaluated. This is unfortunate because we don't want to give up privacy features in the name of better cryptography, but if the cryptography fails, then there's no privacy anyway. So there's a little bit of a trade off here.

There's ongoing work and, and new opportunities that we'll have to move to to new credential types that, that enable these things to happen. And so you need to be prepared for how did this slide not get updated, right?

Anyway, credentials will need to be updated or re reissued. By updated we mean reissued, you'll need to reissue those credentials to people using new credential types as your ecosystem is ready for it. It's been mentioned earlier that in, in one of the, the other presentations on the main stage that multiple credential issuance is important. And so you'll, you'll need to consider multiple credential issuance, not only because you're in issuing two of different types, but one of those types is, is has been reissued with a, with a post quantum key. And that's really important.

So you'll need to be, you'll need to be ready for this over the next couple of years. And I'll talk about when in just a second.

So, is DICOM quantum safe? Not yet. DICOM is a really quick overview as a way to pass message oriented and encrypted messages between two parties. It's really useful because of the extensibility it has, it does more than just verifiable credentials in the sense that protocols can be built on top of it. It's a little like rest APIs where you can make your own rest. API on top of it. DICOM has that ability to define message types that are then available and, and so that you can interact with, with folks in a secure way.

It derives its message properties from the encryption of the message, not from the encryption of the transport, which means that if things are known to be compromised, like, you know, like TLS connections on like hotel wi wifi or something that, that, that it's not broken because of the message properties itself. So there's two plans we have for dicom. I can say we, because Steve and I are both heavily involved in, in that we're co-chairs of the diff dcom working group. We've planned for new cipher suites.

This is something that we anticipated happening and so we, the spec allows cryptographic agility but then restricts it for the sake of, of compatibility in the spec. So adjustments will allow or will move in in, you know, in phases first adding as an alternate and then requiring as the others deprecated. We're looking at li likely kyber 10 24 for key encapsulation as a, as an approved way of doing this. The other feature that we've talked about in the past is DICOM V two. That's the, the current spec now doesn't allow for cryptographic sessions.

And the addition of them gains us a couple of, of new useful features. Key ratcheting is, is one of them that we can use and that we, we get some really cool features via some inspiration from other vendors that have done neat things. And so we're planning for, for that as well to make it happen.

The, the concept of a session is that you can have a default channel like you have today, but you can establish other session channels with different cryptographic properties, including the use of ratcheting for content that needs to be secure in there. And so there's some discovery processes and some things supported by DICOM that will be leveraged in this process including feature discovery. And that's a, that's another thing that that, that we'll be working on. So the grand question is, is when is this actually happening? When do we need to be worried about it?

And the answer depends a lot about who you are. We've already talked about the dates and about when we need to to happen. And so this says when do we need to start? Now the answer's a little bit more nuanced and I'm gonna re return to the eye chart that we had earlier with the dates. You'll notice that I've added a couple of rows before you actually get, get to the, the software.

For, for more signature part, you need to have libraries and before you have libraries you need specifications. Sometimes you do, sometimes you don't. If you specify which crypto suites to be used, those need to be updated as soon as possible. And if you're, and if you're building, if you have protocols that need to exchange information, the previous speaker mentioned that they don't all work the same way. You're gonna have to trade different information in order to make the diffy Hillman replacements actually work in, in a secure manner.

And so that's something that you need to be started on yesterday. The creation of libraries now that we're getting really darn close to having stamps where within a, you know, a month of, of having stamps on, on cryptography, those need to be starting now and continuing past the finish of specifications so that those are implemented. The reason this is useful is those libraries are then used by software that then needs to enable this stuff.

If we do our job well then we won't, we won't have too much then the software won't have to adapt too much to the new libraries, but there will be some and we need to have them ready so that people can implement those and then hit their target dates in order to make this stuff work. So you either need to start yesterday now or wait just a little while for a while for software so that the libraries are there, but make sure you look for updates that are coming from your libraries so that you can have that stuff available. And that's everything. Thank you. So a big thank you to both of you.

Really interesting to get a little glimpse of the future where we're going. I'm gonna do a quick scan of the audience. Yep. If I understand correctly, these are US inspired years timeframe. What's Europe saying about all of this?

Eh, ISSA or I don't know. Yes, they, these are US inspired timelines. Yes. And so is anything really ever strictly national anymore or do we cross, we inherited GDPR. Let me just answer with that. So it depends on who the customers are. If you're selling strictly within the European Union, the European Union will have guidelines for timelines for adoption. They may have key variations. I don't know those specifics, but if your customers do sell across the ocean, then these will likely apply to you at some level. It just depends on your unique situation. Thank you.

Any other questions from the audience? Yeah, You mentioned the key rotation problem and I was wondering when you have the data is anchored in a blockchain, wouldn't that solve the problem? Because you can see that there were multiple key rotations then if an attacker in the future changes the key, again, There are some detection methods that you can use, but it's really awkward to, to work out which ones were authorized and which ones weren't. Because key rotation for, you know, by yourself is a good thing.

And so recognizing a fraudulent key rotation, there are some techniques that have been discussed, published bloom filters of signatures, other sorts of things that can make that happen. But it's one of those things that you have to do exactly right for, for stuff that is anchored in blockchains. There's gonna need to be changes there.

You know, there's, bitcoin is the obvious ledger to look at for this. And, and they've, they've talked about updates to happen. Anytime you have a DID method that's anchored to a blockchain like that, you need to make sure that you respond in a good timely manner with any changes to the underlying blockchain itself so that you, the DID method can move with it. And so often the DID method itself won't have to solve the problem because it can lean on what the blockchain does to solve the problem.

But you, it's definitely an eyes on scenario and, and and need to, to, to update as, as rapidly in time as you can. And just to add to that, what's happening is when we're toll algorithms are insecure or potentially insecure, it creates uncertainty. And so there's no date that, you know, on March 15th, 2025, all algorithms will be insecure. And so we're in this kind of trust quandary where we just don't know when a key rotation might have happened, whether it was the legitimate dead owner or not.

And so that's the dilemma and there's, there's no correct answer to that other than there's a lack of trust because of that concern. The, the people that gain the capability, most likely state actors, but it could be anyone who gains the capability of leveraging this technology to crack keys is not going to announce that they've done it. And so it's a really fuzzy date at which where we cross that horizon to whether you actually trust that or not. And it will in some cases, depending on what, what you're doing. If it's something like banking, you need to be a little more secure.

If it's something that's, you know, secure as a person to person chat, then, then maybe it's not as urgent depending on what you're chatting about, I guess to make that happen. Thank you. And we've got a question coming in virtually here. So you mentioned we will need to do our, get new post quantum DIDs. So what are the safety implications of the old ones that are left behind? Is replication possible? What options are there?

Yeah, so you need to use the existing methods that you should be or using or need to start using in order to, to add credence to DIDs, particularly for large players in any ecosystem. So how do you recognize authorized issuers of credentials authorized verif, verifiers of credentials, et cetera. And so governance is a really big play there. If you're using governance, if you're, first of all, if you're encoding that in your software, knock it off.

If you are consuming something like a governance framework or a trust registry, then those are the methods you're going to use to, to establish credence to the new DIDs that are involved. And so in that case, in the process of announcing new DIDs that represent an organization, you can also deprecate and then remove old DIDs that, that, that recognize or, you know, represent an organization in order to sort of sunset.

You don't, you can't really rotate or you can't really expire a did in generally some methods do allow you to delete, but you can certainly, you know, unrecognized their importance in the ecosystem, which then any, you know, ecosystem participants that are following along will ignore any actions taken by that did. Anyway. Thank you very much. A big thank you to the audience. Thank you to both of you for bringing us along on this journey. I think we should have a last round of applause for you before I give the the closing message.