Root Causes 387: What Is the Post-quantum Readiness of HSMs?

Tim Callan

We're lucky to be joined by our repeat guest, Bruno Couillard. Bruno is here again to talk to us. Bruno is the co-founder and CEO of Crypto4A. How're you doing today, Bruno?

Bruno Couillard

I'm doing well. Tim, thank you for having me over. And hey, Jason, how are you doing?

Jason Soroko

Superduper, Bru.

Bruno Couillard

Excellent.

Jason Soroko

You know, Bruno, I'll tell you what, I quite often get asked a question that I really wish you were in the room because you're the guy to answer the question. Let me tell you what the question is and then here's the way I'd like you to follow it up.

The question I get is, with respect to post-quantum cryptography, people who are enlightened to the fact that they know they've got to do something, they know they've got to do something and they might even know that part of what they've got to do is inventory of their cryptographic assets, which is I know something you've spoken about on our podcast before. I think that people really want to have a deep dive understanding of what's the status of HSMs right now because they know that's really the root of things, whether it's public trust, meaning, right, Sectigo is an example of a publicly trusted CA. We back our roots with HSMs and therefore, it's gonna be important with new post quantum roots to have new kinds of HSMs. And then also, of course, there's the big problem of we're going to need new private CAs that are post-quantum capable. And everybody knows that a really good private CA has an HSM behind it. And so, because I'm usually talking to people who usually are very turned on to this subject, they always want to start the subject of where is the HSM industry right now, with respect to being ready for post-quantum. And there it is for you, Bruno. And can you please add at the top of that response your background, maybe some people, I'm just gonna say some people, might not know just how deep you go in that in being able to make these statements. So introduce your, you know, your background within the world of HSM, which is just an incredible thing.

Bruno Couillard

All right. Well, thank you, Jason.

I'll start with where does that knowledge come from. I'll give you a few seconds here on this. Back in 1994, so 30 years ago, I co-founded a company called Crypto4A. Sorry, Chrysalis-ITS here in Ottawa, Canada and at Chrysalis-ITS, we started making HSMs. The first form factor was a PCMCIA card. PCMCIA if you recall, looked like a credit card, but much thicker. So we did those PCMCIA cards and created the first HSMs I guess in that form factor, built those to accompany users in their travels so that they could do cryptography. Instead of a smartcard, they’d have a much bigger and faster cryptographic engine. Then the name we gave to that PCMCIA card was the Luna HSM. And if you guys have ever been involved with PKI, there's a chance you've dealt with some descendants of the Luna PCMCIA card. So we did PCI cards and in 2001, we created a variant of the PCI card that we embedded in a server, built a shot, a chassis around it, and it became the Luna HSM, which was network attached.

So the Luna HSM family comes from this 1994 kind of starting point and along the way, I got quite involved with designing something to inject and extract keys using an Maven sharding process, or a Shamir secret sharing scheme, in essence. Again, if you've played with the Luna HSM, you probably might have used a Luna PED, which was the small handheld device that would allow you to read your keys and then people referred to those as baby keys, and so on, because they were colorful and plastic like. But in essence, we created HSMs, we built HSMs, we sold those things back in the 90s.

And then I left to go and be a consultant with our own Canadian government, in places like CSC, which is equivalent to NSA in the U.S., Tim, and DND, which is our DOD equivalent. Again, working on advanced security, key management, PKI, embedded radio systems, and so on. Ultimately, Crypto4A came out of a view that I shared with old colleagues, from the days of Chrysalis. We felt that commercial HSMs were not really getting ready fast enough for the quantum era, which we believe strongly back in 2012 timelines was going to become a very critical, foundational challenge for any HSM vendors.

If you're going to be providing an HSM to secure the roots of trust, for the digital economy of a quantum era economy, well, you better have quantum safe HSM as your roots. Otherwise, it's kind of a broken piece of your stack that's broken. So we started the Crypto4A in that premise and we were always surprised, to be honest, to not see many HSM vendors attending and paying attention to that dynamic and quantum dynamic, I would call it, until recently. And I think it all changed dramatically when in 2022, U.S. government became quite serious about the transition to a post-quantum era, the NCCOE project for quantum or post-quantum transition. All of that kind of became a force that somehow got a lot of the HSM vendors to be involved and become interested in that transition. And I'd say that right now, from where we stand, many HSM vendors are actually active and trying to get their HSMs to become quantum safe in time to have the ability to run the PQC algorithms on their HSMs.

Tim Callan

Yeah. There's so many questions I want to ask right now. I'm trying to think of which one - - can I take existing HSMs that I already own and essentially make them PQC ready? Or do I need to replace that with new hardware? Or what?

Bruno Couillard

The answer to this is, it depends on how you feel. There are two aspects to it.

If you've purchased an HSM, an existing HSM that needs to provide you a certain level of performance, I mean transactions per seconds, and that those transactions per second that you need out of your box are likely RSA or ECDSA signatures, you’re not going to find any firmware updates for these HSMs that will likely get you to the same ML-KEM or ML-DSA, which used to be called Dilithium signings per seconds because these HSMs exist that have been sold for tens of years have evolved to be highly specialized in terms of hardware to be very fast at certain types of cryptographic algorithms. They are nominally fast.

But these fast processing capability can only handle classic cryptography. So when you need to switch that machine from a classic crypto to a PQC cryptography, you're gonna find yourself falling apart in terms of performance.

Tim Callan

And this isn't something that's solved with like a firmware update? It's just much more foundational than that. Is that right?

Bruno Couillard

Yes, most HSMs that exist on the market were designed - - like HSM vendors for the past tens of years have been focusing on the transaction per second as the metric of choice. And to achieve the fastest possible signings per second, for example, you want to deploy an ASIC inside the HSM and that ASIC is going to produce phenomenal numbers of signings per second using something like RSA or ECDSA. But that same ASIC was never designed to deal with PQC algorithms, because the ASIC was designed well before PQC algorithms came out. And in that sense, when you switch, you flip the switch from classic to PQC on your existing HSM, a firmware update is not going to solve that and there will not be a quick solution for that. You need to replace - -

Tim Callan

So there might be, for like a light use case let's call it for want of a better word, I might be able to repurpose existing hardware but for real production use, I’m going to need to be getting PQC specific, bespoke hardware that's designed and built for PQC?

Bruno Couillard

Yes.

Tim Callan

Okay.

Bruno Couillard

Now, the second thing that I suggested earlier, there were two aspects you probably would need to consider. One was the performance angle, which we've talked about a second ago here.

The second aspect that you also need to ask yourself, is you've got today a classic HSM. That classic HSM has been designed and manufactured and deployed with a root of trust that allows this HSM to verify the firmware updates using a classic signature, probably RSA in many cases. Now, if you've got that classic HSM and you want to use the classic HSM to up your game and be able to offer PQC strength root of trust, there's a bit of a break in the chain of trust in the sense that the firmware you get even if it implements ML-KEM or ML-DSA, that firmware itself will be signed using RSA. I mean, there's no choices there because the classic HSM you own would not be able to verify the firmware using a ML-DSA signature. So you have to have a bit of a leap of faith where the firmware update process and ongoing firmware update process will constantly be updating your machine using classic strength to deliver to you PQC strength. Then you have to ask yourself, is that something that you feel okay with? Is that breaking the chain of trust or that potential weakness in that chain of trust something you can just move on and live with?

Tim Callan

So correct me if this is an ignorant observation, but it seems to me that that's really about timeframes, right? Like in the beginning, if we all believe that what will happen is the amount of time to break a session will go down and down and down over time and in the early days, we're worried about some very valuable secrets where someone is happy to let something sit and crunch for a while to decrypt your code, your blobs, and then it's only considerably later, like it's much later, when we're talking about something that's fast enough that something like an adversary in the middle attack really is achievable, then it seems to me like we've got a certain amount of runway before we're at the point where that scenario is legitimately worrisome. Is that right?

Bruno Couillard

I'm kinda of thinking, Tim, I'm thinking of the types of attacks that we've seen fairly recently in the world where very advanced attacks, go and modify the firmware update process. They somehow subvert the signature on those firmware updates, and they inject firmware that the device will accept as legit, but it's, in fact, rogue.

If you do a firmware update on an HSM, and the final line of defense is when the HSM verifies the signature, the signature verification process, if it uses RSA or ECDSA, you better hope that that machine is out of your labs or out of your operation before quantum computers exist to break these RSA signatures. Because where I'm going with this is, if I'm able to break your signature keys, then I can take your firmware, modify it, sign it again, because I do now have your signing keys and send it to your HSM and your HSM would not know that this firmware update actually contains rogue elements and potentially very - -

Tim Callan

So the real time signature verification is actually seeing the correct signature because I broke it at my leisure beforehand?

Bruno Couillard

That's it.

Tim Callan

Got it. Okay.

Bruno Couillard

And the same challenge exists when you're trying to provide any device, be it an HSM, or be it an IoT device, a jet engine, a pump that does something in a grid or a pipeline, any of those elements that need to be updated, when they do validate the firmware update using RSA or ECDSA, they're all at risk that one day they will validate the proper signature but the signature will actually have been applied by someone that broke the private key using a quantum computer.

And all I need to do is I need to access your public key and if I can reverse engineer the public key using quantum computers, I'm able to use the fact that I now know your signature keys and start signing all sorts of firmware out there.

Tim Callan

And this is basically a universal problem, right? I mean, this would apply to every firmware upgrade every software upgrade, and any system, OS or environment in the world. This basic risk that you're describing, is there and needs to be accounted for. Is that right?

Bruno Couillard

Yes. And it's one of the challenges that are deployment of a lot of operational technology. Basically, you can think of an HSM as an element of operational technology. It's a machine that will be deployed, it's out there, and you need to keep it fresh and always deployed with the appropriate amount of cryptography support and capabilities. But any updates, if they're using classic cryptography for the signature to impart an authenticity level of configuration on those updates, you're at the same risk, whether it's your HSM or any of the other elements of operational technology. So, our view is that new HSMs should be manufactured today with roots of trust that are post-quantum capable so that anytime you deliver firmware to these machines, you should be able to verify that the firmware got signed using a quantum-safe signature algorithm. That way, that firmware, at the very least, you know cannot have been damaged or broken or changed or modified if you're able to validate that the signature applied to it was probably done by a PQC algorithm.

Tim Callan

So then if I'm pushing a firmware update, and I'm using PQC algorithms, that means I need to also be able to support them on the sending side?

Bruno Couillard

Yes, absolutely. I mean - -

Tim Callan

Which may not be ready out of the box today.

Bruno Couillard

That's the beauty of - - there is something that to this day baffles me. NIST in 2020 came out with two cryptographic algorithms called - they're both on hash based signature. They are stateful hash based signatures. They ultimately standardize these two algorithms by a publication named SP 800-208. And those algorithms have existed now for almost - well more than four years. And you can actually implement those. You can deploy them. They come with their own level of difficulty because you need to handle the fact that they are a staple but we've been using – Crypto4A, we've been using stateful hash-based signatures for every firmware update we've ever shipped to any of our machines. And, actually, what we have done, Tim was, is, we signed using hash-based signatures, and ECDSA signatures. So that way, we have Phipps compliance, because we use ECDSA 384 and we have the PQC compliance because we use hash-based signatures. And we've been using those for many years now and it is actually quite impressive in terms of performance and size of the signatures, public keys. So there's a lot of pluses to making use of those algorithms.

Tim Callan

I get your point. And, I'm not sure exactly when and maybe this is another question - I have so many. Like this, I understand this, this idea of this architecture and how you ultimately protect yourself from this firmware upgrade attack, right? This broken RSA firmware upgrade attack. When – and I know we all don't know this - but like, if I'm the person who's in charge of the HSMs, at, you know, an organization with, you know, valuable secrets, when should I be thinking about trying to implement an architecture like this? How far away is this?

Bruno Couillard

Well, if you deploy an HSM today, depending on the HSM, depending on your internal policies, that machine could be in operation for anywhere between 8 to 10 years, maybe even more years. If it's a root HSM, you may need to keep it around for longer. And again, that depends on your internal policies, but that's just a reality. So if you think you deploy something today, and if you came back in 10 years, and have the same specific machine used for your operations, do you feel fine with the possibility that in 10 years, no one will have broken or figured out how to use quantum computers? If you feel you're not worried about that fact and that it is fine, and it will still be fine in 10 years, then I'd suggest you could definitely go and deploy classic HSMs today. But many people feel that this is probably much closer than 10 years.

Tim Callan

So let's say that I am of the risk profile where I don't feel good about that. Is all of this stuff production ready today? I mean, you say you guys are doing it, but obviously, you're not a typical user of HSM. Is this something if I am a normal level of knowledge and capabilities IT organization at a midsize enterprise and I don't have superpowers, is this available to me? Is this something I can do today?

Bruno Couillard

Yes. I'd love to sell you the product today.

But the challenge, Tim, is where are the other HSM vendors at. Because ultimately, Tim, you would want to make sure that it's not just Crypto4A that you have in your availability search. And as I said earlier, we are collaborating. NIST’s, the NCCOE mentioned earlier had a PQC project, very well organized project and we collaborate with many other HSM vendors. They're all at the moment working on implementing their own cryptography solutions. They're all working hard to becoming - making strides towards being fully quantum ready. At this stage, I would say all of them are probably still deploying firmware libraries in their classic HSMs. I don't think any of them have done a full, you know, from top to bottom sort of redesigned HSM that's built on quantum root of trust. I don't believe that exists yet. Other than ours. But everyone is working very hard at getting there as soon as possible. How much time is it going to take them is a different question. I can’t answer that one.

Tim Callan

And I get that these are hard questions. Right. I think it was Yogi Berra, who said predictions are hard, especially when they're about the future. I think that he was absolutely right. But, you know, it's good for us to try to get a sense for how these things sit. I mean, part of what it sounds to me from what you're saying is like one of the grim realities that we may be facing is that there may be a need to swap out hardware earlier than you had originally planned in many cases. That people who made a purchase a year ago, expecting to use that device for the next 10 or 12 years, may have to decide that they're not going to get the full lifespan on that device that they were projecting, and this might be one of the things that we all have to deal with, which sucks, but it may be reality.

Bruno Couillard

I would suspect that the vast majority of those in that scenario will probably wait for stronger signs from the universe before they make that call. The challenge with this one, an absolute challenge, and I think we've seen this played out in history before - I am not trying to suggest a scenario that has not already happened in the past - But the scenario has happened in the Second World War, for example. There were some cryptographic algorithms broken and it was kept quiet for over almost 30 years.

Tim Callan

Sure.

Bruno Couillard

And if you have that sort of superpower to break into someone else's communications, and go and snoop around and do whatever you need, well chances are, you're not going to necessarily bring that up in the newspaper article or try to be calling yourself quantum supremacy. You will keep that very quiet. And for as long as he can. It's just a reality. It's the world that we've been in for many, many, many tens of years and hundreds of years, probably. So it's always that difficulty with quantum. The beauty with Y2K was we knew exactly the date.

Tim Callan

True.

Bruno Couillard

With Y2Q, we have no idea what the date is, and we won’t be told someone has crossed that - -

Tim Callan

And we won't know it until it's in the past.

Bruno Couillard

That's it. Exactly.

Tim Callan

And there isn't actually a single date. The other thing about Y2K is there was a date. And that's not how it works with quantum supremacy or Q-day or Y2Q or quantum apocalypse or whichever word you want to use. At the end of the day, it's a spectrum, right? And it's where do you sit on the spectrum in terms of value, timeframe, resources you can invest and risk you can tolerate. And all of those things, you can slide them up and down and you'll wind up at a different date.

Bruno Couillard

Absolutely. So it's an interesting, very interesting challenge. And once in a while, if I have a chance with people, I also remind folks, you know, especially those that keep or that like the bring up Y2K and Y2Q in the same some kind of context, and I like the fact that Tim, you and I are on the same page. Y2Q is nothing like Y2K. But I also add this additional element. I asked people, if you were to think of what would have the day after Y2K looked like, are any human beings on the planet? It would have been a bad day had Y2K materialized to be a challenge.

But we would still have been able to buy bread, drive our cars, get gas and connect with people using fax machines and blah, blah, blah. Y2Q is a different beast altogether. A very large portion of what we use on a daily basis is - -

Tim Callan

It’s back to pen and paper. Yep.

Bruno Couillard

Oh, man. Yep. And we've lost all of those pens and paper a long time ago. You know, my - - I hate to do that to them but my kids probably wouldn't know how to drive because they don't have their GPS anymore or something like that. There would be a lot of challenges with that.

Tim Callan

Yeah. This is this is great and insightful, Bruno. I always enjoy talking to you. I know Jason does as well. And we just want to thank you for joining us today.

Bruno Couillard

It's a pleasure, guys.

Tim Callan

And thank you, listeners. Thank you, Jason.