Ramy Shelbaya, the co-founder and CEO of Quantum Dice, is interviewed by Yuval Boger. Ramy and I discuss their encryption key generation approach using quantum technology, randomness self-verification, how their technology interfaces with cybersecurity products, the potential for keys on the cloud, and much more.
Full Transcript
Yuval Boger: Hello Ramy, and thanks for joining me today.
Ramy Shelbaya: Thank you so much for having me, Yuval. It’s an honor to be on this program.
Yuval: The honor is mine. So who are you, and what do you do?
Ramy: So I am the co-founder and CEO of Quantum Dice. We are an Oxford University spin-out that is working to secure a connected future by enabling trusted encryption with some of that quantum magic that can give you an incredibly unique advantage in the way that you create your encryption keys.
Yuval: Let’s start from the beginning. Why do people need an encryption key and what’s wrong with current encryption keys?
Ramy: Okay, let’s start at that point. So basically, when we think about cybersecurity, our mind usually goes to the things that we deal with on a day-to-day basis: things like firewalls, antivirus software, maybe you’ve seen full cybersecurity system if you’re working more on the IT end of things, but in reality, those are just the top-level layers.
As much as in any field of computing, there’s a lot of underlying infrastructure, several enabling components and really the unsung hero in all of this is the encryption key. Every encryption algorithm that we have — and I’m talking about encryption algorithms ranging from the Caesar cipher that we came up with thousands of years ago, to the post-quantum encryption algorithms that people are working hard to develop today — all of these different algorithms, no matter how simple or complex, require an encryption key.
And if that encryption key is not good, no matter how good the algorithm is, your system is vulnerable. Now encryption keys need to be completely random. We kind of see this a little bit when we think about our passwords. When you create a password for a system, the harder it is for that password to be predicted, the safer your system is. And it is similar for encryption keys. The difference is that our computers and our networks need to generate billions of those a second, and they need them to be as random as possible. The problem is it’s actually very hard to make something that is random. It’s very hard to generate it and it’s very hard to verify it and for that reason, there have been many failures in the generation of randomness that have caused vulnerabilities in cybersecurity systems.
Most recently Cisco announced that one of their firewall systems had a vulnerability caused by insufficient randomness. And this firewall appliance, by the way, is one of the most commonly used firewall systems around the world. Odds are, at this moment, some of your data is being protected behind it. And to discover this vulnerability, not just once, but twice in the last five years, just shows how difficult it is, even for the big companies to get this right. It shows that randomness, even though it’s so fundamental, is very complex to get correct.
Yuval: How does one verify randomness? Is there a randomness standard? If I came up with a new system for randomness, is there a way to test and make sure that it’s good or good enough for a certain application?
Ramy: Well, if you Google ‘verification of randomness’, you’re going to come up with a number of statistical tests that you can download. They’re completely free. Some of them have been developed by one of the biggest organizations in cybersecurity in the world, the National Institute of Standards and Technology in the US. And it’s called the Standard Test Suite. And it’s basically just a bunch of statistical tests. And the problem with those is if you look into the documentation of one of those tests, especially the NIST tests, you’ll find that they tell you not to use the result of the test to verify that you can use your random number generator in a cryptographic system. And that’s because statistical tests are just not sufficient. They can be easily fooled, and they don’t really tell you anything about the unpredictability of a number.
If I tell you the sequence 83279, can you predict the next one? It sounds pretty random, but in fact, it’s not. It’s just a sequence within the number Pi. The next digit after this is completely deterministic. Not only can we predict it, we can calculate it. The number Pi can actually fool some statistical tests into telling you that this is a completely random sequence when it’s not. And the subtle difference between what can appear statistically random and what is truly, cryptographically unpredictable is not the same thing. And so just relying on these tests is not enough. And that’s why people started looking towards quantum systems.
Yuval: Okay, so if I purchase your system, and hopefully we can learn what it is in a second, how do I know that your system generates truly random numbers?
Ramy: So now the way to do that is, as opposed to other random number generators that are used in cryptographic systems, you don’t need to rely on a test for our system. You don’t need to just look at the statistics of the numbers. You can actually examine the specific components. You can do physical measurements on these systems. And we have a perfectly rigorous mathematical model of how and where that randomness is being generated, something no other classical system can do. That’s because quantum mechanics, at its core, investigates the random behavior of quantum systems. Some of the most fundamental equations of quantum mechanics tell you how the unpredictability, how the probabilities inherent to a quantum system evolve and change in time. You can use that very same maths to prove the randomness to yourself by physically measuring the actual components that show you exactly where that random number is coming from and how much randomness is being generated.
And we put our money where our mouth is. We gave a few of our devices to the National Physical Laboratory here in the UK as part of a new project that they have been leading over the past couple of years called Aqurand. They took our QRNG apart, looked at the components, measured it, looked at the physical model, and verified, as a third-party trusted source, that what we are saying is true and what we are generating makes sense.
Now, Quantum Dice also has a small twist that not only makes us different than classical systems, but makes us critically more secure than even other quantum systems out there. That twist is that we have what’s called a source device independent self-certification. That’s a very long sentence with a lot of good scientific jargon. We just like to call it DISC. Now what this means is rather than just having this a priori physical model of your system that you’re relying on behaving this way forever, we realize that physical systems are imperfect. They cannot just operate the way you designed them at the beginning forever and they will fluctuate either naturally through decay or because of certain environmental disturbances — when it gets hotter, when it gets colder, when things vibrate. We have a secondary measurement that is related to the primary one. The primary one is the measurement of quantum randomness and the secondary one is what we call the verification measurement. And this allows you to do a continuous random evaluation of the amount of quantum randomness or entropy that’s being generated. And we do this every single time you call a key from our system. So that means when you request a key, not only is it coming from a quantum source, but we verify that it contains the exact amount of randomness that you need. And this is something very few systems out there, even quantum systems can do. And no system out there can do it with the practicality that our product can provide.
Yuval: And what do I do if the test fails? So you say, well, something is off in the physical system, and now it’s not generating numbers that are as random as they did last week. Do I just need to replace the device? What do I do in that case?
Ramy: That’s a very good question actually, and a question that a lot of our customers ask us. The answer is that our system isn’t just a binary choice. It’s not either it works or it doesn’t. Like randomness, it’s more of a gradient. You will see the amount of randomness per second go down. That’s because the amount of randomness that’s available has depleted. Now there is of course a threshold below which we cannot certify any more randomness and then you have to replace your system, but it’s much better to know that a critical component isn’t working than to have it keep working and producing nonsense. Because at least in that case, you know that you shouldn’t use these keys to encrypt anything, or else you’re going to have weak encryption. So one of the things that actually interested a lot of people, especially people who care about high-level security, is that knowledge and confidence in being able to detect when things go wrong. Everything can go wrong, but our system offers an ability to detect when it does.
Yuval: You mentioned Cisco a few minutes ago, and let’s assume that Cisco said, “Oh, we got to do something about this. We’re going to turn it into quantum. and we’re going to go to Quantum Dice, how would they use your system? Where does your system fit in or near a Cisco firewall?
Ramy: Inside of those systems, inside of those firewalls, HSMs, or any kind of cybersecurity appliance, it’s made up of a lot of different subcomponents. Currently, one of those subcomponents is a sort of classical hardware source of randomness. Our system is going to come in to replace that. At the moment, we have two product form factors. We have a 1U server rack-style system that you can connect to easily via Ethernet, and we have a half-length PCIe card that you can insert inside of your servers and inside of your large appliances. Now, as you can tell, both of these systems are relatively bulky, they’re not chips, but they can still address the need for certain low-volume, high-value applications where size isn’t really a problem. However, we’re also working on miniaturized versions of our systems because we have projects addressing satellite communications, as well as projects addressing more integrated development. And the idea here is that we’re always a component piece. We’re always having to hook up with the rest of the cybersecurity infrastructure that you’re using. And that interface can depend on what exactly it is you’re doing, but we always start at the beginning. It’s true hardware integration and it is our proprietary software which helps to manage that interface.
Yuval: You mentioned DISC, sort of the verification algorithm. Are you worried that the generation part is just going to be a commodity, that anyone and their brother can go and generate quantum numbers, random numbers using quantum systems?
Ramy: It’s actually quite hard to generate randomness from quantum systems. That’s because the word quantum system is a sort of misnomer. There is no quantum system or classical system. There are hardware systems that have certain quantum behaviors and certain classical behaviors. And the secret sauce for us is how you extract one from this mix of both. And this particular aspect of our device is a patented architecture. So it’s not just something that you can take out and slap onto any system and have it work. It’s really baked into the architecture itself. The original architecture was designed to allow you to do this. Not every architecture will allow you to do the same.
There’s also a lot of know-how in how you manage these things, how you get them working together. And at the end of the day, because it’s a component, one of the biggest things is interoperability; it’s the ability for clients to just pick it off the shelf, plug it in and have it work. And that’s not easy. All of the little bits and pieces that come into this are really what makes our product special. It’s that element of security, but also the ability to use it in a practical environment. And that’s come through hours and hours of hard work from our incredible team which is filled with all different kinds of engineers required to get something like this to meet the market needs.
Yuval: In terms of deployment, do you always see it as a local deployment next to the device that you care about? Or do you see it also as potentially a web service where I can just download a whole bunch of random numbers for use in keys?
Ramy: So that’s a very interesting question, not the least because it’s an open strategy question for us. Randomness as a service isn’t new, so entropy as a service is something that people out there have started thinking about; there are even companies doing quantum entropy as a service, but there is a fundamental catch-22 with this. The reason you want secure keys is because you want to encrypt insecure communication channels. If you’re going to rely on the internet, an insecure communication channel, to download the keys, then you have a bootstrap problem. How do you secure that initial channel in the first place? Because if that channel is broken, if somebody can see your internet traffic, they can break all of the keys that are coming through no matter how strong those keys are because they’re visible. And so there’s a little bit of a discussion in the sector about how you can deploy entropy as a service.
One of the ways we’ve done this in projects currently is as a local service rather than an internet service. So something that’s disseminated over an intranet. So if you have a very large organisation deployed over multiple different sites with a secure connection between those sites, that is not necessarily exposed to the internet, you can create a sort of service deployment in that case. And that shifts the business model a little bit and changes what the requirements look like. It’s also true of course that there are applications that are not cybersecurity-focused that random numbers can be interesting for. And that’s an area where we have a lot of active work at the moment.
Yuval: You’ve been doing this for a while, so I have two questions related to that. The first one is, “How long?” And the second is, “What have you learned over the last six months that you didn’t know before about this time?”
Ramy: We formally spun out the company in April 2020. Not exactly the best time to spin out a company. It was literally a few weeks after the first lockdown in the UK, but we really started kicking things off when we closed our first round, which was our pre-seed round. That was July 2021, and we started to grow the team and develop more technology. It’s a learning process day by day, not even over the last six months. I mean, things change so quickly that you need to keep up the pace. So to answer your question specifically about how things have changed over the last six months, we have doubled in size as a team. The company grew considerably and we onboarded a lot of different commercial projects.
And I think, I mean, it’s a cliche to say it, but it’s always true, which is that when you’re developing something in-house, it’s very different than when you’re sending it to someone and looking at what their reaction is. As opposed to software, there is no easy fix. You can’t just send a patch if something with the hardware itself is problematic. But at the same time, you want to get things out quickly, so you can’t spend too much time analyzing and debugging. I think what we learned over the past six months is that it’s really critical to think of how customers interact with the product and to think about where it’s going to sit. So similar to your question — how is this going to fit in a firewall system? — something that’s important and really, I mean, it seems obvious, but sometimes you sort of forget that every hardware piece has slightly different dimensions. Now how does something fit? And you might think that’s a little bit of a silly thing, but if it doesn’t fit, people are just not going to buy it. So there are so many little details that you need to think about from a product perspective. And I think a lot of companies focus, especially in the deep tech sector, on the exciting technology, but they sort of forget those little boring aspects of the product development that are really critical to success. Because what you don’t want to do is spend six months developing something only to have to redo everything because you figure out that your screw was misaligned. And I think that that’s something that we really took to heart as we’re bringing our products out of the lab and into the hands of the consumer.
Yuval: You mentioned commercial projects. Is there any particular project that you can tell me about? What the problem was, what the solution, what the outcome is?
Ramy: So there’s one I can speak about in more detail because it’s public, which is with a company called Iquila in the UK who are developing a novel way of doing layer-two private networks. So something similar to a VPN, but a lot more secure and a lot more efficient. And the problem there was how do you secure the connection in a way that’s better than what current systems can do and do it in a way that’s scalable because Iquila’s system can scale to thousands and thousands of users and so we have to think about how to manage that throughput, how to manage this connection between these two systems. They’re currently using one of our systems in one of the applications in the UK and we’re exploring how to deploy that application in multiple different clients. It’s a situation where something started as a simple project, went into full deployment and now we have sort of come up with a joint product.
Another application where I can’t really specify the name, but I can talk about generally, is where we’re working with a telecommunications operator. And the question here is as you were alluding to — how do you create entropy as a service for an internal organization? And so this was quite challenging because you want to be able to disseminate keys accurately, securely, and efficiently to lots and lots of users just from one device connected to a hub. This was a challenge that took some time and work between both of our companies, but it was successfully achieved. And we’ve managed to feed those keys into the cybersecurity algorithms that were being used. So this is a showcase of how something as simple as integration can really make or break a project like this. Because if we hadn’t managed to do this sort of dissemination, none of the rest would have followed.
Yuval: Out of curiosity, how many keys can you generate per second?
Ramy: So, in our fastest device, the Vertex, we can do 2.6 gigabits per second, which is the fastest system that you can commercially find available now. And we’re actually pushing the limit on speed with a new device that’s currently under development, we’re looking to go significantly faster than that.
Yuval: As we get close to the end of our conversation, I’m curious, professionally speaking, what’s keeping you up at night?
Ramy: So I think the main thing that’s constantly on my mind is how to make sure that we’re sort of responding to what the market needs and what the market is telling us, and I think that’s always a challenge, especially when a company has a lot of young engineers that come from more of a research background. There are a lot of cool ideas, there are a lot of amazing things to do, but you need to think about whether it fits because at the end of the day, we’re not a research organization, we’re a company. And so the challenge is to get all of that market feedback from very different people who all want us to do slightly different things, but we want to be a product company. We don’t want to be a project company. So to get to that point where we have something that somebody can just go in on a website, buy it, have it delivered, plug it in, and have it work, that’s a long trajectory and that’s something that we’re focusing a lot on getting right.
Yuval: Finally, a hypothetical. If you could have dinner with one of the quantum greats, dead or alive, who would that be?
Ramy: I would say Schrodinger. The reason for that is that there’s a lot of myth-making around how Schrodinger came up with his famous equation because it’s not really clear how he did it and I just want to know. I’m very curious about the origin of that. It’s something so fundamental that seemingly came out of nowhere.
Yuval: You should have been Quantum Mice and not Quantum Dice if Schrodinger is there. Anyway, Rami, thank you so much for joining me today. Thank you for being with me.