How to develop secure IoT devices

While device-makers and developers are acutely aware of the importance of IoT security, the multiplicity of devices and use cases makes for a near-infinite number of specific risks. However, there are device development fundamentals that, when observed, can shield devices against the most significant risks.

Through our own process of testing device security, we have compiled a list of the seven essential properties of high-security devices. A device with all of these properties can be considered, from a hardware standpoint, as secure as can be.

In the list below, each property is illustrated by relevant device features, and a control question to help you assess whether a given device does have this property. For security-minded developers, these good practices can be a complement to the GSMA’s IoT Security Guidelines, which Orange actively took part in devising.

The seven properties of highly secure devices

Property 1: Hardware-based root of trust

Question to ask yourself:

Does my device have a unique, unforgeable identity that is inseparable from the hardware?

Device features related to this property:

Unforgeable cryptographic keys generated and protected by hardware.

Physical countermeasures to resist side-channel attacks.

More on hardware-based root of trust

In devices with this property, secrets are protected by hardware and the hardware contains physical countermeasures against side channel attacks.
Unlike software, hardware has two important properties that may be used to establish device security:

First, single-purpose hardware is immune to reuse by an attacker for unintended actions.

Second, hardware can detect and mitigate against physical attacks; for example, pulse testing the reset pin to prevent glitching attacks is easily implemented in hardware.

When used to protect secrets and device correctness, hardware provides a solid root of trust upon which rich software functionality can be implemented securely and safely.

Property 2: Small trusted computing base

Question to ask yourself:

Is most of the device’s software outside the device’s trusted computing base?

Device features related to this property:

Private keys stored in a hardware-protected vault, inaccessible to software.

Division of software into self-protecting layers

More on small trusted computing base

The trusted computing base (TCB) consists of all the software and hardware that are used to create a secure environment for an operation. The TCB should be kept as small as possible to minimize the surface that is exposed to attackers and to reduce the probability that a bug or feature can be used to circumvent security protections. In less secure systems, all security enforcement is implemented in a software stack that contains no protection boundaries.

Property 3: Defense in depth

Question to ask yourself:

Is my device still protected if the security of one layer of device software is breached?

Device features related to this property:

Multiple mitigations applied against each threat.

Countermeasures mitigate the consequences of a successful attack on any one vector.

More on small trusted computing base

In devices with in-depth defense, multiple mitigations are applied to each threat. In systems with only a single layer of defense, just a Devices with this property use certificates rather than passwords to prove identities for mutual authentication when communicating with other local devices and with servers in the cloud. A certificate is a statement of identity and authorization that is signed with a secret private key and validated with a known public key. Unlike passwords or other authentication mechanisms that are based on shared secrets, certificates can’t be stolen, forged, or otherwise used to authenticate an impostor.

Property 4: Compartmentalization

Question to ask yourself:

Does a failure in one component of my device require a reboot of the entire device to return to operation?

Device features related to this property:

Hardware-enforced barriers between software components prevent a breach in one from propagating to others.

More on small trusted computing base

Compartments are protected by hardware-enforced boundaries to prevent a flaw or a breach in one software compartment from propagating to other software compartments of the system. Compartmentalization introduces additional protection boundaries within the hardware and software stack to create additional layers of defense in depth.
For example, a common technique is to use operating systems processes or independent virtual machines as compartments. Many low-cost and insecure devices employ an RTOS design with no software separation.

Property 5: Certificate-based authentication

Question to ask yourself:

Does my device use certificates instead of passwords for authentication?

Device features related to this property:

Signed certificate, proven by unforgeable cryptographic key, proves the device identity and authenticity.

More on small trusted computing base

Devices with this property use certificates rather than passwords to prove identities for mutual authentication when communicating with other local devices and with servers in the cloud. A certificate is a statement of identity and authorization that is signed with a secret private key and validated with a known public key. Unlike passwords or other authentication mechanisms that are based on shared secrets, certificates can’t be stolen, forged, or otherwise used to authenticate an impostor.

Property 6: Renewable security

Question to ask yourself:

Is the device’s software updated automatically?

Device features related to this property:

Renewal brings the device forward to a secure state and revokes compromised assets for known vulnerabilities or security breaches.

More on small trusted computing base

A device with renewable security can update to a more secure state automatically even after the device has been compromised. Security threats evolve and attackers discover new attack vectors. To counter emerging threats, device security must be renewed regularly. In extreme cases, when compartments and layers of a device are compromised by zero-day exploits, lower layers must rebuild and renew the security of higher levels of the system. Remote attestation and rollback protections guarantee that once renewed, a device cannot be reverted to a known vulnerable state. A device without renewable security is a crisis waiting to happen.

Property 7: Failure reporting

Question to ask yourself:

Does my device report failures back to its manufacturer?

Device features related to this property:

A software failure, such as a buffer overrun induced by an attacker probing security, is reported to cloud-based failure analysis system.

More on small trusted computing base

When a failure occurs on these devices, a failure report is collected automatically and sent to failure analysis system in a timely manner. In the best case, a failure is triggered by imperfect programming for an extremely rare sequence of events. In the worst case, a failure is triggered by attackers probing for new attack vectors. Whatever the case, a failure analysis system correlates failure reports that have similar root causes. With a sufficiently large reporting base, even extremely rare failure events can be diagnosed and corrected, and new attack vectors can be identified and isolated before they are widely exploited. Failure reporting creates a global “immune system” for highly secure device. Without failure reporting, device manufacturers are left in the dark as to the device failures experienced by their customer and may be caught off guard by emerging attacks.