A step-by-step guide to achieving fast, secure IoT connectivity and device lifecycle management

Even the most pessimistic estimates tell us that there are now 10s of billions of IoT devices connected to cloud services today. However, growth has been lower than forecast just a few years ago, with security concerns often cited as the main bottlenecks to IoT deployment, particularly in the industrial sector.

IoT devices, or endpoints, are often described as being on the ‘edge’ of a network. In order to connect them securely to one or more applications hosted on a server, either in the cloud or on-premises, the identities of the senders and recipients of data must be established beyond doubt. So, as a starting point, every microcontroller or application-specific integrated circuit (ASIC), that drives an IoT device must have a unique, immutable, and unforgeable identity. For the sake of simplicity, we’ll just use the examples of microcontrollers (MCUs) in the article, because these are used in the vast majority of applications. After the device’s identity has been confirmed, messages must be sent in such a way that only the intended recipients can interpret them, and they must not be readable or corruptible by any device that attempts to interfere with the data in transit. This is achieved using cryptography, which involves an exchange of data in the form of cryptographic keys (keys unlock the secrets with IoT data and messages) and certificates of authentication.Few embedded design engineers are cryptographic experts and cryptography is a complex subject with a language of its own. It follows that if security is not to be a barrier to the adoption of IoT in industrial applications, there must be a straightforward way to ensure not only that IoT devices are secure but that there is a straightforward way to connect them to server-based applications securely. There’s also a need to manage security throughout the lifetime of the device.

This article describes the building blocks of a secure IoT infrastructure and the process that needs to be followed to create one. It references Crypto Quantique’s Q:Architecture – the company’s QDID hardware IP that’s integrated into MCUs and the QuarkLink cloud-based security platform – to illustrate the process. The fundamental steps are similar for other RoTs and platforms. However, few tools offer all of the functionality that is integrated into QuarkLink, so the process may be more complicated if an alternative approach is taken.

An overview of the process is shown below.

Establishing a root-of-trust (RoT) at IoT endpoints

The most common way to create RoTs for MCUs is to use a random number generator (RNG) then place the identities and keys into the devices using a process of key injection. The keys are then stored in the devices’ non-volatile memory. There are some disadvantages to this approach. The process is expensive, it means involving a third-party to do the key injection, which could compromise security, and storing the keys makes them vulnerable to theft or unintended leakage. However, many MCUs used in industrial IoT devices have RoTs created in this way.

Crypto Quantique’s silicon hardware IP, QDID, enables a different approach. The IP is embedded into semiconductor chips during manufacture, without requiring changes to the standard CMOS process flow. Firmware is then injected into each microcontroller using a standard programmer. The combination of IP and firmware enables multiple random identities and related keys to be created on-demand throughout the device lifecycle. No key injection is needed, nor do the keys need to be stored, minimising vulnerability to attack.

A root-of-trust, or RoT, consists of a device’s identity and its cryptographic keys. A unique RoT is the most fundamental building block for a secure IoT network. Identities and keys are based on random numbers. The more random the numbers, the greater the security because the harder they are for hackers to determine.

Why QDID keys and identities are highly secure

Tiny variations in the thickness of the oxide layer on a silicon wafer occur during the semiconductor manufacturing process. Crypto Quantique’s technology measures the quantum effects that can be observed across the silicon barrier. The variations in the thickness of the oxide layer are themselves random but when combined with the probabilistic nature of quantum tunnelling – a quantum mechanics phenomenon – random numbers with exceptionally high entropy, or ‘randomness’ are produced. High entropy underpins high security.

To recap, for a secure IoT network we need to establish a secure RoT. This can be done using a variety of software and hardware techniques but there is growing recognition that hardware-based RoTs are fundamentally more secure than those created in software. In addition, if identities and cryptographic keys do not need to be injected or stored but can instead be created on-demand in silicon throughout the IoT device lifecycle, this is far better for security. Let’s now take a look at the end-to-end process for creating RoTs and connecting devices to the cloud in a little more detail, including where each step takes place.

During semiconductor manufacture

The QDID IP bakes a 64 x 64-bit array into each silicon chip and the bits are used to create 8 x 128-bit random numbers or ‘seeds’, one of which is designated as the enrolment seed. The collection of bits gives the MCU its unique identity. However, it does not yet have any way of proving that identity.

At a programming house or at the end user’s facility – using a standard programmer

QDID firmware is injected into each MCU using a standard, mass programming interface such as JTAG, SWD or UART. To reiterate, we’re not injecting identities or keys here, just a firmware image. When executed, the firmware uses the semiconductor manufacturer’s peripherals within the MCU to generate a pair of asymmetric cryptographic keys – one public and one private – using one of the seeds produced by QDID. The public key is then used to create a 256-bit encrypted number called a ‘hash’. The irreversible hash then registers the MCU with the QuarkLink IoT security platform, which is hosted on a secure server.

At a programming house or at the end user’s facility – using QuarkLink

The firmware that was earlier injected into the MCU enables communications with QuarkLink. The user logs onto QuarkLink then, via a simple select and click menu interface performs the following steps to provision, onboard and manage the IoT endpoint devices into which the MCUs have been installed. The IoT devices may be HVAC units, cameras, asset tracking modules, or any types of sensor or actuator.

The first requirement is to prove the identity of the devices that need to be connected to the QuarkLink. This is a six-step process and although complicated things are happening in the background, it’s all handled via a few drop-down menus and keyboard strokes when using QuarkLink. No knowledge of cryptography is needed. Here’s what happens: A pre-defined server policy is selected in the QuarkLink dropdown menu. QuarkLink currently supports AWS, Azure and Mosquito but is essentially server-agnostic and can be easily adapted for other server platforms. The identities of the MCUs within the IoT devices are imported as a batch to check that their enrolment keys have been registered on the QuarkLink. The QuarkLink platform will only engage in further communications with the devices if registration is confirmed.

QuarkLink sets up a secure communications channel using the industry-standard Transport Layer Security (TLS) protocol. Part of this protocol requires that a shared secret key – the “session key” – is generated. (If you’re interested in learning more about how this is done, this part of the process is based on the Diffie-Hellman key exchange method, details of which have been published widely). The session key is symmetric and is used to transfer encrypted data between the IoT device and QuarkLink. Symmetric keys, which are typically 128-bit or 256-bit, are used because encryption and decryption are faster. QuarkLink then asks the devices to prove their identity through the secure TLS channel. QuarkLink verifies that the hash of the public key is the same as the one originally sent to it to register the MCU within the device, as described earlier. For each IoT device, QuarkLink generates a random number called a “challenge” and sends it to the device. The device encrypts this number and returns the encrypted information back to the QuarkLink. QuarkLink decrypts the information and if it reveals the “challenge”, the device has proven its identity.

With the IoT devices now onboarded, secure connections having been established, data from the devices can be communicated to the applications running on the server. All this has been achieved within a few minutes with just a few keystrokes guided by QuarkLink’s intuitive user interface.

QuarkLink also facilitates the management of security throughout the lifetime of IoT devices. It manages device certificates and security policies, ensuring functional integrity and helping prevent cyberattacks. It also facilitates firmware signing and encryption for secure over-the-air (OTS) updates and handles key and certificate renewal. The latter may be needed after a system fault or other interruption. If devices should be compromised, they are easily removed from the network and re-onboarding can be done if the device is transferred to a new owner.

Having described how QuarkLink works with the QDID root-of-trust, it’s important to remember that it may be used with others. For example, QuarkLink is now part of the Renesas RA Series secure microcontroller ecosystem and it supports Silex Insight’s eSecure RoT module.

To appreciate how much time and effort QuarkLink can save, you only have to reflect that the most recent guide to security in the AWS cloud ran to 27 chapters and 365 pages. Most users become competent with QuarkLink in less than an hour. This 11-minute video demonstrates its ease of use.