Welcome. So I'm Paul Bastian. I'm working as an architect for the German EUDI wallet, the government-provided wallet, and working on OpenID and ITF standardization. Hello everyone. My name is Micha Kraus. I'm a colleague of Paul and I'm also working for the innovations department of the Bundesdruckerei.
And yes, before we answer this question, I would like to really shortly introduce what the term post-quantum era stands for. And yeah, the term refers to a time where quantum computers become powerful enough to really break traditional cryptographic systems. And there are basically two quantum algorithms that can be used for such attacks. The first one is CROVER and the CROVER algorithm makes brute force attacks against symmetric encryption algorithms and hash functions more efficiently.
But we, yeah, would say relatively easy, can mitigate those attacks by just increasing the key size, mainly double it, or increase the output size of the hashes. So the real beast is the second algorithm and that's SHORE, because SHORE literally breaks asymmetric traditional cryptography as we use it today. It breaks all cryptographic primitives that are built on the prime factoring or discrete logarithm problem, which includes RSA, Diffie-Hellman and elliptic curve cryptography, which are heavily used for digital signatures and public key encryption.
So the next question is, when does this era begin? And the short answer is, we don't know. It's clear that today's quantum computers are not able to run those algorithms in a scale that really matters.
But yeah, fortunately there are agencies which monitor the development of quantum computers and they give recommendations. And the message is clear, you should be aware of the threat, you should make migration to post-quantum cryptography as a top priority, and especially you have to mitigate against or now encrypt later attacks, because this is a threat for the communication today. And they also say that this should be done latest by the end of 2030. And with that, I hand over to Paul.
Yes, so now we will look into the EODI wallet system and what's the status on post-quantum cryptography. So post-quantum cryptography itself is not mentioned in the IDAS legislation and is currently also not mentioned in the architecture reference framework. It just says very generically that cryptographic methods should reflect current best practices, current best practices evolve over time, new challenges arises like quantum computers. So we need to take them into account.
One of the catalogs that is listing the approved crypto algorithms in Europe is the SOGIS catalog, which is currently not mentioning post-quantum algorithms yet. We also have the catalog from Etsy, the so-called algo paper that's looking into what Etsy wants to use for this, and they are currently looking into this. There's different recommendations how to make the migration, for example the Etsy technical guideline here, and usually they propose a three-step approach. The first is an inventory compilation, so to look first what is within the systems that you want to protect.
The second is creating a migration plan, and then as the last step implementing this migration plan. So what we want to do today in our presentation is to start with a crypto inventory and look what do we have in the different parts of the EOD wallet ecosystem and where do we need to act. So looking into the EOD wallet ecosystem, we'll have a look into five different components. You may know the usual three suspects. We have the issuer, holder, verifier, or in IDA's terms the providers, the users, and the relying parties.
Underneath we'll have the trust framework, and then as the base layer the cryptographic building blocks. We at Buena Sucre are participating in many of these building blocks. We're hosting, for example, the PID provider for the German wallet project, the Funke, and we're also the issuer of the vehicle registration card that is currently being tested, and we're also participating in the architecture of the German EODI wallet project, and we take part in international standardization.
So we kind of have a good overview of the whole ecosystem to make this crypto inventory, and with that I'll hand back to Micha to look at the cryptographic building blocks. Thank you.
Yeah, first look at what is in our new post-quantum crypto toolbox, and the good news is there has been very good progress in the last years, and the toolbox is growing steadily. So first we look at the cams. Cams are key encapsulation mechanisms that are used or can be used by two parties to establish a shared secret, and use the shared secret to secure the communication. And cams are important because if we have post-quantum secure cams, we can mitigate the store now decrypt later attacks. In the list we see three example algorithms.
The first one is based on structured lattices and is specified by NIST, and maybe this is some good and new news to you, or most of you, it is already widely used in TLS. So if you use a chrome-based browser and surfing, it's very likely that your traffic is already post-quantum secure.
That's, I think, great news. The other two algorithms are more conservative, I would say. They have not so strong cryptographic assumptions or do not use structures which can or might be some security issues.
So yeah, to sum up, we have solutions for post-quantum cams, and you have to figure out which cam fits the best to your requirements. Another algorithms that are threatened by Shor's algorithm are digital signatures. And also for digital signatures, there are already standardized algorithms available. The first two algorithms are also standardized by NIST. The first one uses also lattice space and is very efficient. The second one uses stateless hash-based, which leads to longer signatures and I would say more poor performance.
The first two algorithms are general-purpose signature schemes, so they can be used for arbitrary messages and they are now limited. The third one is also interested and is sometimes under the radar, because it's a stateful hash-based signature scheme, which means there is a state machine behind and we have just a limited amount of of signature we can use this for. But there are, I think, use cases where this doesn't matter. For example, a root CA do not have to make thousands of signatures. And the good part is here that we have very good performance.
What is interesting about the signature schemes, there's a big debate whether to use it in hybrid mode or in standalone mode. And the reason for that is that this decision has really impact to many stakeholders and the whole ecosystem and reaches in the future. Some agencies, like the NSA, they discourage hybrid mode, because they say it leads to bad performance and has some management issues. Other more conservative agencies, like the BSI, encourage hybrid mode, because they say the robustness of the new algorithms have not the same level as the traditional ones.
So, to summarize it, we already have standardized production-ready building blocks that are post-quantum secure. There are widespread consensus. We have still some differences regarding parameters hybrid or not hybrid. There's very good library support.
So, let's try it out. We want to mention it, because we really would like to have a zero-knowledge proof-friendly signature scheme. The bad news here is that all the standardized signature schemes we mentioned here are not CKP-friendly.
So, this is, yeah, a whole other story. Okay, let's continue with the trust frameworks.
So, we assume that for the rollout of the EUDI world ecosystem, we will start with a regular X.509 PKI, because that's the most mature solution that we currently have. And this is also being reflected of what is written down in the current implementing acts.
So, there we will have the usual like a root CA, one or more intermediate CAs, and then an entity. And this will be used by different components in the ecosystem.
So, there may be PKIs for issues, there may be PKIs for relying parties, PKIs for wallet providers, PKIs for relying party registrars. So, many PKIs. The good part is, well, we're using the digital signatures and we kind of have a drop-in replacement for digital signatures. And in general, like the PKI is being used by TLS.
So, everyone that's using TLS is heavily working on this. So, we can benefit from this. The problem for trust frameworks is kind of the migration time that we need. It only makes sense to start the migration from the root up. And there we have the problem usually that the root certificates are in a very high secure environment in an HSM or some other hardware, and they are not being rolled over that often. If we compare it to the German EID card, we have a root CA roll over only every three years.
So, there's not that many opportunities to actually make the post-quantum move there. And as it's also in hardware, then you need to make sure that you have the hardware to secure the root CA. And then this adds also like, because your root CA must be as long valid, like all the entities underneath are valid.
So, they also have like longer lifetimes, not as bad as like in passports. But usually, yeah, you have to be aware there's a longer migration step here, and it makes sense to look into the root CA first, because that's the slowest part.
Next up, we have the credentials. We'll have a look at this by the example of SDJOT. And SDJOT has three parts. We have the issue assigned JOT that contains the salted hashes. We have the disclosures that contain the actual attributes of the user matching to the salted hashes. And we have a key binding JOT that is being generated by the holder to actually authorize the presentation. And we'll have a quick look into what parts are relevant there. We have the signature algorithms by the issuer.
The good part here is that the underlying methods from the JOSI or HOSI registry are already crypto agile. So, there is a registry with all algorithms. If new post-quantum algorithms that are currently in drafts are added, then you can use them right away, and you don't need to add anything in SDJOT. The same also applies for the hashing algorithms that we use for a selective disclosure. These are also crypto agile as foreseen by the SDJOT draft. And the bigger problem lies in the issuer signature. As I've said, in the trust frameworks, the issuer signature may be in an HSM.
And yeah, you need to make the migration there. HSMs usually might not be the biggest problem, because the issuer itself controls them and just can buy a new HSM from a vendor that already supports PQC, but it's still something to look out for. If we look at the disclosures, we don't see too many issues, especially because quantum attacks only have problems with collision, but not with pre-image attacks.
Still, it may make sense, and some agencies recommend to move to SHA-384. Again, for the key binding JOT, we have the crypto agility from the Jose registry, but the biggest problems in the credentials lie in the key binding key that is being done by the holder. Because if we rely on hardware, for example, for the PIT in the UDUI wall ecosystem to achieve certain security levels, then this hardware-bound key must enable post-quantum algorithms. And none of the keys out there currently do that.
Summarizing, we have crypto agility, which works quite well, and we have the challenges that are mostly coming from the device keys. If we have remote WSCDs, that may work easier. External WSCDs, we need to hand out new smart cards and tokens. And the big problem is if we use internal WSCDs, because then we need to wait for the rollover of smartphones. Just a short look at what we did. We extended our issues to support not just the baseline ECDSA signature algorithm, but also some post-quantum algorithms, also in hybrid.
The graph on the right side is a little bit small, but just two takeaway messages. It was very easy to integrate those new algorithms, but they don't come for free. So you have to pay with larger key length or signature length, or with really bad performance. For example, the SLA DSA algorithm needs for verification over one second.
So yeah, that's why we said poor performance. But if you are interested to try this out, please contact us. We are really interested in prototyping and interoperability tests. And just for the context, this was all done with software keys, not with hardware keys. So last step, we look into the protocols. We have OpenID for VCI and VP, which are built on OAuth. For the transport layer, they are built on TLS, and we're leveraging all the efforts that are being done by the TLS community already. The part on top, on the application layer, is based on JSON.
For example, the DPOP algorithms or attestation-based client authentication, and they again can leverage on the crypto agility of the JOSI registry. On top, we may also have application-level encryption with JARM or HPKE. This may be where the cams actually come into place. So there we would have a drop-in replacement for the cam, and there is already standardization in place for HPKE. The bigger problem here relies if we want to do wallet attestations, where we currently rely on platform mechanisms like PlayIntegrity, and they currently do not have any support for PQC.
So if we want to authenticate the wallet and the software underneath, there are still things to do out there from the platforms. So coming to the conclusion.
Yeah, our last slide. So to answer the question of the presentation, the UDI wallet will in 2026, when the rollout is, most likely be not post-quantum secure end-to-end. We saw that there are still some challenges, but we also saw that there are good starting conditions. So literally all protocols are ready, agile to use the new algorithms.
Yeah, we really want to motivate you to have some migration strategies. And yeah, the last point is again, we really would like to see some zero-knowledge friendly signature schemes, and we are looking forward that there is good progress in the near future in this topic. So thank you very much for listening and yeah. Just a quick reminder, if anybody has questions, please raise your hand. Okay. Thank you for a very insightful presentation. So recapping from a technical point of view, we're probably good, sort of, you know.
I'm a little bit worried about the end-user perspective to all of this, because the second that this happens, in my maybe poor wording, any and all credentials in the wallet are garbage. None of the stuff that's in there can be trusted anymore. So will we have to bootstrap the entire ecosystem from the ground up then? Send them to go to the municipality headquarters to get their pit again? And how would that work? I think that it's probably an issuer's decision mostly, and it depends on like the security level that your credential, for example, is about.
I don't think that a phishing license will be endangered if we have the first quantum computers, and probably there will not be like the first QDA and then everything falls apart. But maybe there's rumors about a post-quantum computer, and then even if we have the first one, it will probably be very expensive, and maybe only very few players in the world will have this. So I think it's not as like a strict point, and then everything falls apart. But the urgency will very increase if we get these news.
Thanks, so this is a really excellent summary, so great job on that. So we have post-quantum algorithms that have been approved by NIST and others, but do we have any CMVP modules that have been approved yet, or have you heard anything about the timing of any modules that are approved? I didn't get the name of them. What kind of modules? Hardware keys modules, or?
Well, for software modules, I guess. So the CMVP, the NIST CMVP programs that sort of validate the actual modules that are implementing these algorithms. So we have the algorithms approved, do we have the modules? Have you heard anything about the timing of the modules that are approved?
Yeah, that's a good question. I don't know. I think still probably not, but yeah, I think it will not be a matter of years.
Yeah, don't have a better answer on that. Yeah, I think they are under development, so we will see them.
Okay, well, thank you very much again.
