Root Causes 449: What Is a Quantum-safe HSM?

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

December 18, 2024

Repeat guest Bruno Coulliard of Crypto4A joins us to define a quantum-safe (or PQC enabled) hardware security module (HSM).

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanWe have a guest. We have our many repeat guest, probably the most repeat guest at this point, I think, Bruno Couillard, Founder of Crypto4A. Bruno, welcome.

Bruno CouillardGentlemen. Thank you, Tim. Thank you, Jason, for having me again. You guys are very generous.

Tim CallanSo Bruno, we love talking to you. Obviously, you have a lot of thoughts about computers and digital processes and all of that. We range around a lot in these talks. Today, I think let's ask something that's very central to your core, the core of your experience and your knowledge, and what you guys do at Crypto4A, and this is about HSMs. So can we talk about HSMs today? And the question I want to ask you, real simple. What, by your definition, what is or what would we say, is the definition of a quantum-safe HSM?

Bruno CouillardLet me start with something that is not necessarily visible to the world. As you know, HSMs are very black box living in very secure storage space and not seen by many people. They're kind of thought as an HSM is definitely the most secure box that you have. Therefore, if it's an HSM, if it's got the label HSM, it should be fine. The reality is an HSM isn't very advanced or very specific compute platform, and such an HSM is used by external application. So the HSM provides cryptographic capabilities to external applications, such as a PKI, for example. But an HSM also uses a lot of cryptographic features and capabilities. It consumes cryptography in its internal guts and in its internal design, because when you're designing an HSM, and if I'm going to be generating keys for your PKI, those keys have to be secured. They have to be kept properly safe in some storage facility. I will eventually provide you with the ability to stake two machines and build around those machines a highly available kind of construct. So your keys is going to traverse from one HSM box to another HSM box. There will be communication between two HSMs.

Today, for example, when you think of the big concern about store now, decrypt later, but when you think of the connection between two HSM, if someone is able to store that and decrypt it later because those two HSMs use classic cryptography, you're already in trouble with your HSM.

When you think of an HSM as a box providing you, as the application user, cryptographic operation, a set of questions that's never really brought up is, what does an HSM use internal to its architecture, which is cryptographically based in nature, and that, to me, is a question that not many people have raised or highlighted, and it's a critical component of being quantum-safe HSM. You can't be a classic HSM and change yourself into a quantum-safe one unless your internal operation have been rearchitected, redesigned to now operate with all the post-quantum cryptography algorithm that we have today.

This is a fresh new design because that cryptography has only been around for a few years now.

Tim CallanThis is an important point. I just want to make sure I'm understanding you correctly. So we're saying that our existing HSM, not just the boxes we have in racks, but the actual architectures, really need to be put aside in favor of new architectures that are going to be designed with PQC in mind. Am I getting that right?

Bruno CouillardAbsolutely correct. I'll even take it a step further, which actually I would, I'd love the world to take that in and consider the importance of that next step that I'm going to make here.

We designed an HSM that has been from the very moment we started thinking had to be quantum-safe. As we approach our design, we selected cryptographic operation that were quantum-safe, and any tricks that we would use would be quantum-safe in nature, and so on and so forth. One day, we take this design and now we want to apply to be FIPS validated, because everyone knows that HSMs have to be vetted. They have to eventually make this mythical process, take this mythical journey to eventually be FIPS labeled, and I recently used for someone else an equivalence, which is think of it as in a medical drug design process. If you design a drug, you have to go through, say, an FDA approval. The drug may be fantastic, but unless it's gone through critical clinical trials and then FDA approved, you're still not being sold. HSMs don't get sold unless they've been FIPS validated. So FIPS is to the HSM world what FDA is to the drug manufacturing world.

With that said, we started down the path of our FIPS validation, and we were explaining to our labs that we were going to use quantum-safe signatures for the firmware update process.

So, in essence, a machine like an HSM does not go out in the field and does not stay stable. I mean, you never just launch a product like that without considering the fact that you will likely do firmware updates, bring new features, and especially nowadays, with crypto agility being the talk of the town, you better be able to keep updating your machines to bring about the new features that the users of the HSM will want to use. Today, we're kind of using a few PQC algorithm, but in a few years from now when NIST is done with the next batch, well chances are you might want to start exploring new cryptographic functionality of your HSMs. So firmware update is a very important part.

You need two things to do a firmware update. First, you need the ability to sign the code, and somewhere in the future, that code needs to be validated by the HSM. So the HSM that lives out there has to have a root of trust that allows it to validate your signature. But to apply a PQC signature, we had to kind of debate, I wouldn't call it fight, but we had to debate quite heavily with the lab to explain the fact that, in our opinion, it was very poor practice to only use ECDSA or only use RSA for firmware update for a brand new design, because we all know everyone has got to shift away from ECDSA and RSA. So we needed to have a PQC signature.

We finally managed to have the lab accept that an ECDSA signature, in addition to an LMS, which is one of the hash-based signatures, could be allowed and only be allowed because NIST had on their FAQ page the ability to suggest you could do hybrid signature as long as one of those two algorithm is FIPS approved and in this case, ECDSA was the approved algorithm. So we were allowed to throw in LMS not because it would make our HSM quantum-safe. We absolutely wanted it to be quantum-safe, but as far as they were concerned, it counts as a zero from a FIPS design point of view.

Where I'm going with this is, in today's world, when you're designing an HSM, if the bar that you're trying to reach is FIPS, FIPS does not give you quantum-safe HSM by design. FIPS says, as long as you've got a FIPS approved algorithm, you're fine. So redesigning the signature process, the manufacturing process of your HSMs to ensure the injection of roots of trust and the use of those root of trust when you do firmware update is not something that all HSM vendors have gone and have done. I'm not even sure how many have even attempted that. This is one of the very first step in becoming a quantum-safe HSM in our opinion. You can't be quantum-safe unless your internal design is now designed to resist attacks on quantum computer in all shapes and manner. So firmware update is definitely a pretty important one.

Tim CallanSo FIPS, part of what FIPS gives us is it gives us, let's call it a consistent objective measure of whether or not a computing device or process – in this case, an HSM - meets our standards. There's no FIPS version of that for PQC. How do we know? How do I know which PQC, which quantum-safe HSM cuts the mustard, and which one does not.

Bruno CouillardAs far as we have seen so far, there's nothing out there whatsoever to help you as a buyer of an HSM.

The only thing that might exist to help you is if we were to produce, say, an RFI, for example, request for information. You send this out to your vendors. You say, all right, I'd like you to tell me, describe to me, how do you do your firmware updates? Are they based on root of trust at our PQC? Is the signature PQC ready? When you have two HSMs connected and they need to exchange keys, is that exchange based on post-quantum cryptographic algorithm that will be secure if I do store now, decrypt later? If you store any cryptographic material in a backup file or in a file outside of the HSM and on the PC or on the server, how do you secure that? What’s the key management techniques? Is a different element from RSA? If you do, for example, attestation. So some machines, especially, more and more today, when I deploy an HSM out there in the cloud, and I don't know what's in between the cloud HSM and my server, local, if I want to generate the key and then do an attestation that that key exists in the HSM that's portraying itself as being in the cloud, I need an attestation that will be safe and secure. If you do an attestation using classic signature on a post-quantum cryptographic material, it tends to be a weird thing.

If you have all had to deal with the transition to having HSMs being used for cryptographic signature keys for all code signing going forward, I think since last June if I recall. Now in order to achieve the validation of a key that's being portrayed as coming from an HSM, attestation is one of those tricks that the HSM can provide you. Well, if you're going to attest in a few years from now, an MLDSA key, and all the HSM can do is sign with RSA or ECDSA, it's kind of a bit of a broken piece there.

So there's a whole pile of constructs and techniques and capabilities that HSMs have to use in their day to day lives in order for those machines to act and behave and give you the kind of capabilities you're looking for as a PKI vendor, for example. So these machines, even before you're connected to those machines, you don't have to do a signature with the machine, but in between those machines, how they get firmware update, how they do attestation, how they store keys outside, where are the roots of trust? Are they planted inside? All of these questions are not going to be on any spec sheets anytime soon.

Tim CallanSo part of the problem there is even if I did this RFI like you talked about and I collected this information, like, if I have real cryptographic expertise inside of my walls, let's say I'm a government or a major global financial institution or something, we probably have the chops to know what questions to ask and interpret the answers and make decisions. Your average, not even your average small business, but your average medium-sized enterprise, most likely does not, and so they can't even do that.

Bruno CouillardI think it's one other example of how the entire community have to rise up. I think as a community, there are folks and actors out there that have the wherewithal to help the small enterprise through that interpretation process. The beauty, though, honestly, the funny part, or the great thing here, is that you don't have to deal with 1000s and 1000s and 1000s of HSM vendors. There's a handful of those guys. There's a handful of those companies, and it doesn't take two years to go through all of them. The RFI process could be something publicly demonstrated that doesn't meet the bar. These are questions that are, as far as we're concerned, very critical, because when you're thinking of crypto agility, which is the big buzzword if you're going to deploy a crypto agile machine in your environment, but it is not internally designed to be quantum-safe, you're kind of missing the point. The idea is crypto agility. You should build it. You should build your crypto agility on foundation that you don't have to go and replace in two weeks from now.

So the theme here is that to be a quantum-safe HSM, you have to start with a fresh design. You can't take something that exists and hope to patch it. You can't take a classic HSM and stick QR and V-chip in it and expect that to all of a sudden, the magic has happened, and it's quantum-safe. Sometimes I see some marketing literature where they somehow make you believe as you're reading the documentation that because there's quantum random number generators somewhere in that machine, the keys are now secure against quantum attack. Well, RSA what are fed by QRNG or TRNG, is going to be broken, no matter what via quantum computers. So forget about the QRNG saving your bacon here. It’s not gonna do anything.

Tim CallanWe see that all the time. Jason and I were talking about that just a couple months ago, people get confused between quantum-safe cryptography and quantum key exchange and quantum random number generation. And they're different things. They're entirely different things. They all use quantum physics, but they do different things in our computing platform, and they get conflated all the time.

Jason SorokoBruno, I want to just make a little bit of a parallel and then ask you a question.

The parallel I'm seeing is Tim and I have talked a lot about how we've gone from the age where you could have unmanaged certificates if the scale of certificates that you're managing is low, but that day is over now with the shortening of certificate lifespans and all the other risks that you face with certificates. You're showing us that complacency with old school HSMs is going to be a big mistake. So what I would like you to describe for me then is how does that affect the upcoming the needs for post-quantum or quantum-safe HSMs at scale.

So, in other words, the panic button will get hit in the next three, four years. Is the industry ready to do this mass change of legacy, classic HSMs that served us so well for decades to something completely new? Are we ready? Just in terms of the supply chain.

Bruno CouillardI think we can get there if we start today. If we delay, if we try and play marketing tricks, if we try and, hide the reality, we're not going to get there. And the other thing that's of importance here is take iMessage when Apple decided that they would turn into a quantum-safe capability. This is a download away from being quantum-safe. They were able, almost overnight, to take a system that was classic and turn it into a quantum-safe system. Whether it's fully done and finalized or part way, it's the idea that you can actually achieve very fast turnaround if you're dealing with software. Same with Chrome and same with a few other software capabilities that have very quickly been updated to demonstrate it's doable on software-based stack systems. Hardware is hardware. You have to buy hardware. You have to order it. You have to have it delivered. You have to have it installed. You have to remove the old and there's a supply chain impact here.

Your hardware devices, especially the HSMs, you can't just wait at the last minute to order all your HSM needs, because I can tell you, if anyone recalls something called COVID, and when everybody went to order masks. Guess what happened? Those physical things that you order in massive quantity get to be very expensive, and you may not necessarily get the deliveries that you paid for.

HSM is that beast at the bottom of the stack that no one really wants to talk about and would prefer it goes away, but it's a foundational block of our established digital trust and economy and so on, and you need to make sure that those machines are carefully migrated very quickly, swiftly in an orderly fashion, so that we don't end up with all being bunched up at the end with a massive panic and it's too late and there's not enough supply to satisfy the demand. I do think it's doable, but if the world shifts to the right and keeps waiting, eventually there's going to be a very high price to pay for having not moved fast enough. That's definitely if anyone wants to take that message home, I would suggest the HSMs you have today are very likely classic HSM because - -

Jason SorokoSo Bruno, the message is start now. I'm going to add that to what are the other because of the fact that HSMs don't work in a vacuum, they typically are supplying digital identity backbone to some form of application. I would say that for any of you who are looking to have any sort of innovative system, net new, from a private Certificate Authority standpoint that might be utilizing HSM, building that system net new with legacy cryptographic algorithms, might not be your best idea. I'm thinking Bruno, tell me if you agree, but I think new systems going forward, you really should be thinking about a quantum-safe system end to end, from the HSM to the private CA.

Bruno CouillardCorrect. Recently, an organization called FS-ISAC published this really cool paper, I thought, about crypto agility, and they were basically describing the importance of going to a mindset, establishing a mindset in organization. They're typically focusing their audience in the banking and financial sector, so you have to take that in mind, but they're basically suggesting that you have to establish a mindset of crypto agility from the get go. It's really, really, really important, and in their description of it, they're basically suggesting, as a designer of crypto agile system, you need to consider all the different components, that includes the HSM, and you should be considering that the HSM should eventually be replaceable. You should be able to swap an HSM from Vendor A to a Vendor B HSM, if it's the better machine, and you should be allowed to do that so that your system continues to operate in a crypto agile fashion. One other bit there that when I read that, I went, I smiled, because today, if you have an HSM on-prem, chances are if the keys have been generated in that machine, you're not going to move your keys anytime soon, because it goes with the machine, and the machine will guard your keys, but forget about taking your keys somewhere else.

Today's HSM, the HSMs of the classic era were designed with a different mindset. They were designed almost anti agility. It was almost like a vendor lock in kind of concept, and I think we need to very quickly go away from there. As we're trying to make the world a better place and a safer place, there's a whole lot of things that need to be revisited, and I think vendors have to be stepping up to the plate, and they have to all come up with if the supply chain is going to be able to satisfy the demand here everyone has got to start working hard at getting their classic HSM completely redesigned to become quantum-safe and open and swappable, so that the world that will exist in the future will be one where crypto agility is just a part of the day to day operations. It won't be a new concept. It should be ingrained in everything we do going forward.

I'm gonna get off my soapbox here. But you guys see this on a daily basis. When you think, just in your space, the variance of x.509 certificate that could end up existing, the variance of certificate path validation chain that have multiple different algorithms at different levels, from the root to the intermediate CAs to the leaf certificate, you will also have to be super agile from a PKI design point of view, and the machine that exists below the PKI better be able to keep up with your demand, because you're going to get demanded or asked by the community that you supply certificates to to have this agility built in. So it's a very it's a full stack approach.

Agility is definitely the responsibility of the entire stack. Every component, every element, have to be consisting of agility designed by principle, everything needs to be able to adapt and there will be a lot of adaptation in the future. I don't think 30 years of RSA is going to cut it in the future. It won't likely be 30 years of MLDSA. It could, but I don't think it will. Anyways, I'll stop here. Enough pontification for today.

Jason SorokoThank you so much, Bruno. Really appreciate you joining the podcast, and we will definitely be having you back again. Take care.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!