CEO Interviews: The IoT security questions that most interest technical journalists
IoT security – answers to the most common technical questions
Over the last few weeks, Crypto Quantique’s CEO, Shahram Mossayebi, has given several media interviews. This blog post summarizes Shahram’s answers to the most common questions that journalists from technical media have asked on behalf of their readers.
Shahram, could you please kick-off with an explanation of why you set the company up, the fundamental elements of the underlying technology, and why you think it’s different?
Sure. Connectivity and the IoT are at the heart of so many things in today’s world and the number of connected devices is growing massively. There are many reports of billions of IoT devices being around already and, looking at the big picture, a central question is how you can manage all these connected devices that are integrated into our lives, and how can you reliably identify them in the field.
That brings up the question of device identities. Like humans that have different identities and personas in the digital world, the same concept is being applied to devices. For example, your mobile phone is a digital device that you can use to identify yourself, but the device also has to identify itself to various services.
So, there’s the concept of a digital identity for the device on its own. This is playing a central role in the future of IoT connectivity, and not just in consumer electronics but in industrial IoT applications too.
Our technology is built on the concept that if you want to exploit the potential of connected devices or the IoT, you need end-to-end security. You need to be able to make sure you can access devices in the field remotely while being certain that you’re talking to the right device. Then the device must identify you as the authorized entity to send those commands. Only then should it execute the commands, otherwise it must ignore them.
Unless you have a unique and unforgeable identity for each device, you cannot build the rest on top of it. So that’s essentially what we’re doing to secure the connected world. We want to provide seamless end-to-end security for all these connected devices in a way that industrial end users can easily manage hundreds, thousands, millions of connected devices in the field and get data safely and securely from them. None of this is possible if you can’t rely on one or multiple unforgeable identities that are unique to the devices that you’re talking to.
So, which components are you providing?
We’re providing the building blocks. On the hardware side, the identity of the device has to be part of the fabric of the hardware. Software can be circumvented by software, so you need something that’s hard-coded. It’s like the DNA inside the device that nobody can change. For that, we are exploiting a quantum phenomenon, quantum tunneling inside the devices that gives you a fingerprint that is unforgeable, that is unique, that is random inside the device, and that nobody can predict.
The way we provide it is such that you can use that source, that building block inside the device, to create that initial identity, or multiple identities. You can also generate cryptographic keys from that source and other secure credentials inside the device and can do this over its entire life cycle.
This is the hardware root-of-trust. In our case, it’s a quantum-driven identity created by our hardware IP. The IP is designed to work with standard CMOS processes, and we license it to semiconductor manufacturers and silicon vendors. They integrate it inside their microcontroller chips or ASICs and it gets fabricated as part of that design without any change to the semiconductor process. When an IoT device is built around that chip, you create identities initiated from the hardware inside the device.
Do you regard your root-of-trust identity as a physically unclonable function, a PUF, or equivalent to a PUF, or is it a distinct technology?
Yes, when you look at the definition of PUF – a Physical Unclonable Function – it means that if you can generate a random string through hardware variability, that’s a PUF. We have the same foundation here as well. We exploit quantum tunneling through the nano-structure variation of the CMOS technology to generate randomness. One difference is that other companies may create a PUF in SRAM to generate randomness. From a security point of view, this doesn’t work well because the PUF has not been created as a main component of the SoC or MCU. It is utilizing a component that has been designed for a purpose other than security. It’s not secure against side-channel attacks. Yes, it gives you a random string, but there are so many other issues around it from a security point of view that it doesn’t make sense. That’s the first issue with existing PUFs.
We built something different from scratch. We generate randomness and not just one string but many of them, within the main component, so it’s secure. When we designed everything from scratch, we had these things in mind. Our technology, partly because of the way quantum tunneling works, partly because of our design, is inherently secure against side-channel attacks. That’s a big advantage.
The other important point is that existing PUFs just give you one random string and that’s it. It’s usually a 256-bit random string. And yes, you can use that for one identity for instance, but then you cannot use that PUF to generate all the cryptographic keys and credentials that you need during the device lifetime. You still have to go through key injection and other complexities to provision an IoT device, which is costly. In our scenario, we address all of that. We generate multiple, uncorrelated cryptographic keys internally, inside the device. You can use some of them to generate identities. Others can be used for symmetric or asymmetric cryptography, and others for authentication. Because you have that capability internally, you don’t need to rely on other auxiliary key management solutions on the hardware side, any of which will add cost and introduce risk.
Most PUF chains use an initial PUF string to generate a core hardware ID, from which a number of other keys are derived with the help of some random source, which can be on-chip. So, when you say you can generate these extra keys, what is the extra capability there?
Yes, you’re right about existing PUFs. So essentially what happens there, you’ve got a single random string, then you can use key derivation functions, KDFs, in cryptography, and use that string as a seed for KDFs, but if you want to generate different keys, you need different non-secret parameters – salts – to be added. That adds complexity because from a hardware security point of view, how can you generate more than one set of cryptographic keys?
Another challenge is how you keep track of the different salts that you use inside the KDF plus that random seed to generate different cryptographic keys. The other issue is that the other cryptographic keys that you are generating are all being derived from that single seed, so they are somehow correlated because of that root. They have the same root.
Part of our differentiation is that we give you multiple random roots, random seeds, so you don’t have to use the same seed to derive the same keys or different keys. You have different seeds, and you can use them to derive different cryptographic keys for different applications.
That also makes it easier because, for instance, you might not need any other parameters such as the salts, et cetera, that you usually need to use. Talking to customers, we found out that those MCUs that currently use SRAM PUF, for instance, have this capability and could handle the key management but, at least as far as we have been told, nobody does it this way. Inside the device, engineers just use the random seed that is generated through the PUF as its identity and just some limited encryption keys or things like that. Any other cryptographic keys that they need are usually injected into the device. They don’t derive these from the PUF seed.
What about managing your involvement in the supply chain? One of the reasons for doing key injection is you can manage the end-to-end supply chain more reasonably if you’re doing key injection. If the device is generating keys, you’ve got to find a way of linking that to your public key certificate, which may be difficult to implement. Is that something with which you’re involved, or are you squarely focused on the hardware IP end of this?
That’s a good point. Another challenge we saw in the IoT ecosystem was a disconnect between hardware security and software security. There are various hardware security options in the market, but it’s a huge task for companies to be able to take advantage of them. Some can take a month to get up and running – it’s complicated embedded technology. We solve that with our QuarkLink platform. QuarkLink provides everything needed for the end-user to take advantage of the hardware security inside the device. It helps them with all three stages of device deployment within an IoT network – provisioning, onboarding, and lifecycle management. So once end-users have our hardware IP – QDID – inside their devices, with QuarkLink they can handle secure provisioning in a third-party programming house without the involvement of that programming house becoming any kind of security risk.
Then once the devices are provisioned, QuarkLink enables users to easily onboard them to multiple IoT platforms, handling enrollment and registration to those platforms. After that, QuarkLink helps monitor the certificates, the keys, the identities of the devices, and manages them easily if users want to renew some, revoke some, generate new ones, et cetera. So that’s the software part that we provide to marry both hardware and software. From a security point of view, QuarkLink makes it as simple as possible for the end-users. With a couple of clicks, they can achieve security without really knowing much about cryptography or PKI or the various industry standards.
There’s another point I’d like to make. I believe that control of security and privacy is of utmost importance, yet it is often ignored, especially when it comes to the IoT. You usually need to use one of the ‘big brother’ services. These provide some limited security services as part of their IoT offering, but you’re tied down to whatever they tell you or whatever they give you, and they become your ‘big brother’. They pretty much know all the secrets and you don’t have any freedom. We built QuarkLink in a way that we can run it as a platform for customers if they don’t want to deal with the complicated infrastructure management and maintenance when working with large cloud providers. QuarkLink gives full control to the customer. They can run it on any infrastructure that they have, whether it’s on-premises or on private or public clouds. They own their security, from the software point of view, including the source code. Nobody has access to their secrets that they need to manage from the OEM or the end-user perspective. And none of the secrets of the devices are known to anyone else due of the way keys are being generated inside the device. Customers have a tightly controlled, closed security system in their own hands.
In terms of the hardware IP itself, are there any restrictions on what kind of process it can be used on, or does this work on anything that can handle CMOS?
It pretty much works on anything that can handle CMOS. We’re still doing some engineering work because it’s analog IP that has to be simulated and tested at each process node, then fabricated. Once proven, we ship the IP as a product. Apart from porting it to lower nodes, there’s nothing special about it – it’s normal CMOS IP.
Do you have test silicon running?
Yes. We’ve already proven the technology in 55 and 65 nanometres with Global Foundries and because it’s an old process node, that means that it will pretty much work on any other 55 or 65 nanometers processes in other foundries. Right now, for two customers, we’re looking into porting onto the 40 and 22 nanometres TSMC processes.
Is your ultimate aim to get it on as many processes as possible or are you targeting individual processes?
Our ambition is to be inside every connected device, whether it’s industrial or personal because what we provide is required for anything that is connected and hence needs security. The way the hardware block is designed, it’s easy to integrate from the hardware security point of view as well. Essentially, we could be the go-to part of the hardware security block that people just drop into their designs, and there you go. You’ve sorted out provisioning and key management.
Today, we’re targeting industrial IoT and automotive – those kinds of industrial IoT applications or connected device applications. In those domains, the majority of the devices are fabricated around 65 to 40 nanometres, although some big players are moving to 22 nanometres. Some governments have asked us to look into lower nodes, like 12 or 10 nanometres, because they work with bigger companies such as Intel and others, that use lower node processes. Those are conversations that we haven’t concluded yet. So, for what we do right now, the short- to medium-term focus is the main processes that are being used by big semiconductor manufacturers for industrial IoT.
I’m wondering how important the quantum aspect of it is versus the physical tunneling aspect of the technology.
We are really in the realm of mesoscopic physics here. So, it’s a gray area in which classical and quantum physics overlap. We do see quantum behavior because tunneling happens. We see behavior aligned with the properties that you get through Schrodinger’s equation. For instance, quantum tunneling is not sensitive to temperature variations and it’s exponentially sensitive to an angstrom of change in the quantum tunneling barrier. But at the end of the day, because you’re working at room temperature in most electronics, you’re working with the noise. We are continuing to study that noise to find out how much more we can get out of the quantum elements of it.
For instance, we are looking into the potential for pseudo-randomness certification. This is an element of quantumness that could confirm that hardware is giving you a high level of randomness that you can trust. You can trust the hardware and the phenomena behind it. So, while we don’t have a pure quantum state because we’re working with noise and we’re working at room temperature, there are quantum elements in there that distinguish the quality of the randomness and are secure against side-channel attacks, et cetera, inside the device.
Do you see ‘quantumness’ as a distinguishing feature from existing randomness projects, which would be mostly pseudo-random, I guess, in embedded devices?
Academics argue because theoretically if you’re generating any randomness from a classical source, that is deterministic, so you’ll repeat yourself. That is not truly random. But if you’re generating randomness from a quantum source, then that is inherently non-deterministic so you will always have randomness. Now the question is when we say quantum source, do we just mean pure quantum source, such as working with a single photon for instance, and measure that, or do you also consider the noise generated by quantum tunneling as a quantum source. In academia, many papers discuss this, and they consider quantum tunneling noise as a quantum source. That is the foundation of what we do.
To find out more about silicon hardware IP, please take a look at QDID.
To find out more about Crypto Quantique’s universal IoT management platform, please see QuarkLink.
To see a QuarkLink demo of the platform being used with a Renesas RA series secure microcontroller, scroll down the video on our Resources page.
About Shahram Mossayebi
Before founding Crypto Quantique, Shahram worked as a self-employed cybersecurity consultant and as a security solutions architect at CyNation, a risk management company. Of his current role, he says, “After years working in the cybersecurity industry, I have seen how companies are continually choosing between expensive and complex security or highly scaled systems without meaningful protection. Recognising the need for a holistic solution that is easy-to-use at scale yet delivers robust and reliable security for everything from connected cars to high-end consumer goods, I founded Crypto Quantique.” Shahram, who lives in London, holds an MSc in Information Security and a PhD in Post-Quantum Cryptography, both from Royal Holloway, University of London.