Lock Down the IoT Infrastructure

The disclosure of the Meltdown and Spectre vulnerabilities in recent weeks has demonstrated how fundamental to the technology sector security has become and how easily electronic designs can fall prey to novel attacks. A critical factor in both Meltdown and Spectre lies in how the desire for speed can result in security issues.

Although operating systems and processor modifications can deal with the problems raised by the creators of the Meltdown and Spectre attack vectors, the widespread nature of the vulnerabilities underlines how effective embedded systems security relies on a combination of good design and supply-chain practices. With these attacks, spyware can look at the supposedly secret processing carried on by other threads running on the same processor.

Technologies Working to Secure IoT Devices

IoT device makers also have to deal with the possibility of unauthorized users uploading data and code to their products in order to subvert them. However, architectures are available that make it possible to stop this happening and massively improve the chances of surviving attacks based on other vulnerabilities.

The key is to have a protected root of trust that is backed by a secure supply-chain process that guarantees trust from the earliest point during manufacture. By doing so, service users can be sure that they can continue to trust the data that comes from IoT devices.

X.509 Architecture

The key is a chain of trust that makes it possible for each node within the IoT understand that it is communicating with legitimate users and not fraudulent imitators. Public key infrastructure (PKI) technology provides the basis for establishing that chain of trust. PKI underpins, for example, the X.509 protocol for managing secure credentials.

The X.509 architecture makes it possible to install secure, trustworthy digital certificates on each device that forms part of the IoT system. Only if each device can authenticate itself against such a certificate is it allowed to transfer data or upload new software. If the certificate is missing or found to be invalid, the IoT node can simply refuse to respond.

X.509 provides a basis for creating a chain of certificates that lead back to the manufacturer or integrator, making it very difficult for an attacker to present themselves as legitimate communicators. However, one possibility is that an attacker finds a vulnerability that leaves the certificate in place but lets them upload new, malicious code. This is where the second key component comes in: secure boot.

Secure Boot

Secure boot, assisted by hardware authentication, ensures the validity of code. The process ensures that the device boots only using legitimate code. When the device starts up and reads the code from onboard read-only memory (ROM), it checks that each block has a valid signature from an authorized supplier. This can be achieved using the same digital certificates employed for network communication. The code signature is generally created as a one-way hash of the code itself combined with the private key. If the device encounters a block of code that is incorrectly signed, it stops loading the compromised software. At that point, it can move into a factory-programmed state and request maintenance.

A key advantage of secure boot is that it provides an infrastructure that makes firmware over-the-air (FOTA) a safe process. Using digital certificates, the device can check first that the update comes from an approved source. Once downloaded and inserted into program memory, the secure-boot process can check the code-block signatures as they load. If they have been compromised, the device can roll back to the earlier firmware if it has enough space to hold both or move into the recovery state.

An essential factor in secure boot is hardware support. Although it is possible to implement some forms of secure boot without a hardware trust module, it is hard to ensure that the boot process will halt correctly if the hacker has penetrated far enough into the firmware. However, a growing number of microcontrollers and modules have built-in support for the cryptographic functions needed to support secure boot together. Examples include Silicon Labs’ Jade and Pearl Gecko microcontrollers, as well as Digi International’s DigiConnect 6 and 6UL. The TrustFence technology used by the Digital modules provides out-of-the-box support for secure boot, in addition to encrypted local storage and certificate-management features.

A further potential issue with today’s disaggregated supply chain is that systems can be tampered with before they are installed and commissioned. A manufacturer may end up delivering the private keys that underpin X.509 certificates to subcontractors that copy and supply them to potential attackers.

The Microchip Atmel ATECC508A

One solution is to use a device that is designed to be used as part of an end-to-end certificate-management infrastructure. The Microchip Atmel ATECC508A is a crypto authentication device with key storage based on the Elliptic Curve Diffie–Hellman (ECDH) technology that employs cryptographic countermeasures to guard against physical attacks.

The Microchip Atmel ATECC508A

Microchip supports the device with a secure key-management infrastructure. Instead of being programmed at the manufacturer’s subcontractors, the application or customer certificates are created and stored on the Microchip secure manufacturing line. Once programmed, the device can be soldered onto the target PCB with no further intervention — and the private key is never revealed to anyone outside authorized users.


A further benefit is that Microchip is working with Amazon Web Services (AWS) to handle the tasks of authentication and provisioning when the device attaches to the internet after deployment. Combining these technologies and services help IoT node manufacturers ensure they do not make the same mistakes as their peers in desktop computing — and build a secure IoT.