Security Requirements for IoT Devices

Designing for secure computation and communication has become a crucial requirement across all electronic products.  It is necessary to identify potential attack surfaces and integrate design features to thwart attempts to obtain critical data and/or to access key intellectual property.  Critical data spans a wide variety of assets, including financial, governmental, and personal privacy information.

The security of intellectual property within a design is needed to prevent product reverse engineering.  For example, an attacker may seek to capture firmware running on a microcontroller in an IoT application to provide competitive manufacturers with detailed product information.

Indeed, the need for a security micro-architecture integrated in the design is not only applicable to high-end transaction processing systems, but also down to IoT devices, as well.

Vincent van der Leest, Director of Product Marketing at Intrinsic ID, recently directed me to a whitepaper entitled, “Preventing a $500 Attack Destroying Your IoT Devices”.  Sponsored by the Trusted IoT Ecosystem Security Group of the Global Semiconductor Alliance (GSA), with contributions from Intrinsic ID and other collaborators, the theme of this primer is that a security architecture is definitely a requirement for IoT devices.  The rest of this article covers some of the key observations in the paper – a link is provided at the bottom.

Types of Attacks

There are three main types of attacks that may yield information to attackers:

• side-channel attacks: non-invasive listening attacks that monitor physical signals coming from the IoT device
• fault injection attacks: attempts to disrupt the internal operation of the IoT device, such as attempting to modify program execution of an internal microcontroller to gain knowledge about internal confidential data or interrupt program flow
• invasive attacks: physical reverse engineering of the IoT circuitry, usually too expensive a process for attackers

For the first two attack types above, current IoT systems offer an increasing number of (wired and wireless) interfaces providing potential access.  Designers must be focused on security measures across all these interfaces, from memory storage access (RAM and external non-volatile flash memory) to data interface ports to test access methods (JTAG).

The paper goes into more detail on the security architecture, Cryptographic Keys and a Digital Signature, plus Key Generation.

Examples of Security Measures

The first step to prevent IoT attacks is taking certain design considerations into account. Here are some examples of design and program execution techniques to consider:

• firmware storage.

An obvious malicious attack method would be to inject invalid firmware code into the IoT platform.  A common measure is to execute a small boot loader program upon start-up from internal ROM (not externally visible), then continue to O/S boot and application firmware from flash.  As the intent of using flash memory is to enable in-field product updates and upgrades, this externally-visible attack surface requires a security measure.  For example, O/S and application code could incorporate a digital signature evaluated for authentication by the security domain.

• runtime memory security

Security measures may be taken to perform integrity checks on application memory storage during runtime operation.  These checks could be evaluated periodically, or triggered by a specific application event.  Note that these runtime checks really only apply to relatively static data – examples include:  application code, interrupt routines, interrupt address tables.

• application task programming

An early design decision involves defining which tasks within the overall application necessitate security measures, and different operating system privileges.  As a result, the application may need to be divided into small subtasks.  This will also simplify the design of the security subsystem, if the task complexity is limited.

• redundant hardware/software resources

For additional security, it may be prudent to execute critical application code twice, to detect an attack method that attempts to inject a glitch fault into the IoT system.

• attestation

An additional measure to integrate into the design is the means by which the security subsystem attests (through an external interface) to confirm the IoT product is initialized as expected.  If runtime security checks are employed, the design also needs to communicate that operational security is being maintained.

IoT Product Development and Lifecycle

The figure above provides a high-level view of the IoT product lifecycle.  During IC fabrication, initial configuration and boot firmware are typically written to the device.  Cryptographic keys would be included as part of the security subsystem.  During IoT system integration, additional security data may also be added to the SoC.

Summary

The pervasive and diverse nature of IoT applications, from industrial IoT deployments to consumer (and healthcare) products, necessitates a focus on security of critical economic and personal privacy assets.  The whitepaper quotes a survey indicating that security concerns continue to be a major inhibitor to consumer IoT device adoption.  A recommendation in the whitepaper is for the IoT product developer to pursue an independent, third-party test and certification of the security features.

Here is the whitepaper: Preventing a $500 Attack Destroying Your IoT Devices

Contributors:

Published by:

Also read:

WEBINAR: How to add a NIST-Certified Random Number Generator to any IoT device?

Enlisting Entropy to Generate Secure SoC Root Keys

Using PUFs for Random Number Generation