Engineers working on embedded systems or Internet of Things (IoT) projects must contend with the trade-offs between performance and cost that affect every aspect of that design. Security is as much a part of that equation as processing speed and memory capacity.
When it comes to enforcing security in any cost-constrained application, a balance needs to be struck between the protections that the application needs and the capabilities of a device that meets the cost profile of the target market. It is easy to assume that a microcontroller that incorporates some security mechanisms will deliver the protections needed.
But there are many ways in which the hardware, firmware and system environment interact that can lead to unforeseen vulnerabilities. Developers need to be aware of the distinctions between different forms of hardware support for embedded-systems security.
Ideally, a hardware platform will contain several elements designed to protect firmware, data and communications that act together to provide a root of trust.
Figure 1 A hardware root of trust is the foundation of a IoT device and network security. Source: PSA Certified
Manufacturers will often incorporate those functions into a module integrated into the main processor or system-on-chip (SoC) in the IoT device. Alternatively, a secure element connected to a serial port of the main processor provides the required functionality.
Hardware suppliers must make choices that balance cost and functionality, which will affect development and could compromise security more than expected if the developer does not consider details of the implementation. Even within the same product family, the support for hardware security can vary widely.
For example, the Espressif ESP32 SoC is used in many IoT platforms. Some will be accompanied by a separate secure element, such as the Microchip’s ATECC608. Some versions of the ESP32 include an on-chip controller that manages the device’s security infrastructure. This on-chip controller often includes features like a digital signing peripheral with eFuse support, which enhances the security capabilities of the device.
The electrical fuse (eFuse) technology facilitates permanent storage of security-critical data, such as encryption keys or device-specific information, making it harder for attackers to compromise the system. However, some platforms include neither the on-chip controller nor a separate secure element, which means more of the security apparatus needs to be implemented in software.
Basic protections
Microcontrollers for many years have offered a basic level of memory protection, such as protecting firmware and configuration memory against illegal writes by application code. Another common protection mechanism, usually to protect intellectual property (IP), is to encrypt the firmware, which is typically stored in flash memory. This protects against basic reverse engineering techniques and provides a way to protect data, such as data-encryption keys, that should remain private.
A microcontroller will usually store the memory-decryption key in on-chip configuration memory, possibly using e-fuses to guarantee immutability and strong protection. At rest, the data encrypted using that key sits in flash memory. This protects it from being used by an attacker who tries to read the block directly.
However, once sensitive data and keys held in the encrypted flash blocks are moved into memory, they are available in plaintext form. If an attacker can probe the memory of a running device, the presence of the copies makes the keys far more vulnerable than in devices where more advanced security measures are in place.
Developer choices can affect the efficacy of security even for the basic option of flash-memory encryption. Historically, device makers have used an encryption key that is common to all members of a product family. If a key is compromised on one device, all the others in that family are equally vulnerable. Ideally, OEMs and integrators make the memory-encryption key unique for each device. They also need to follow through with individual keys for higher-level functions.
Management at the individual device level is vital for the overall security of an IoT service. When devices enrol on the network to exchange data with the cloud, operators and users need to be sure that all the connected devices are legitimate and have not been compromised.
Online services verify the identity and the legitimacy of devices using a set of digital certificates and signatures implemented using a public key infrastructure (PKI). Each device needs its own unique set of keys and certificates, ideally inserted at the point of manufacture, to show to other legitimate users that it is not a counterfeit and is running approved firmware.
Firmware checks
Valid certificates cannot on their own guarantee that an individual device has not been compromised. They do, however, support processes such as secure or measured boot. These processes provide high confidence in the authenticity of the firmware the device is running. Secure boot uses digital certificates and signatures to check the provenance of any software update the device receives. It ensures that only valid images are used to boot the device to readiness.
If an image fails any of the checks performed using a secure boot, the device will reject the firmware and will instead try to load a known good version if it is available. Unless valid firmware is available, the device cannot start up and connect to the IoT, which protects the rest of the network.
Secure boot relies on the presence of a bootloader image that a user cannot change without the required credentials. To achieve this, the hardware platform stores the bootloader together with root keys and certificates in one-time-programmable (OTP) memory to provide immutability.
For the highest level of protection against changes, manufacturers will implement this memory using e-fuses. However, some devices instead reserve an area of flash to be used in OTP mode once a protection fuse is blown.
In principle, secure boot is possible without further hardware support. However, entirely software-based boot-management processes cannot protect against runtime interference where an attacker can tamper with the SRAM or DRAM into which the bootloader code may need to be loaded before it can run.
Microcontrollers with hardware-based separation between secure and non-secure operating modes provide a higher degree of protection. An example is Arm’s TrustZone, implemented in different forms in the Cortex-A and Cortex-M series of embedded processors. TrustZone provides the ability to restrict access to peripherals and memory regions based on security attributes.
Access should be granted only if the attributes are in place for that I/O or memory access command. By default, the processor starts in its secure mode, which provides access to secure areas. When the processor completes its boot process and moves out of secure mode, it will deny a return to the secure areas unless the code passes authentication checks. In principle, systems such as TrustZone can successfully protect the boot process.
However, care needs to be taken to ensure there is no opportunity for an attacker to snoop on data in plaintext form. For example, the processor should load encrypted data into internal SoC memory before decryption takes place to avoid memory-bus snooping.
Figure 2 TrustZone architecture separates secure and non-secure operating modes in hardware. Source: Arm
A hardware secure element provides a way of providing greater security to the boot and encryption processes with or without secure execution modes. Its strongest guarantee comes from its ability to implement a root of trust that guards the keys and certificates stored in non-volatile memory. Every off-chip transaction involving a key will be encrypted.
The secure element may be implemented on the microcontroller or embedded-processor SoC, such as the digital-signature unit on an ESP32 or a full Trusted Platform Module (TPM) on multicore SoCs, or deployed in an external device, such as the ATECC608, and accessed through a direct serial port.
Even in the presence of secure elements, some attacks remain possible if not addressed directly. One is the rollback attack. This is where the attacker tries to load an old, but valid software image that contains a vulnerability that can be exploited. Anti-rollback uses a device’s secure storage to hold a counter that is allowed only to increase monotonically. Some IC vendors support this using a combination of hardware and firmware.
Solving hardware dependencies
Though hardware vendors may offer broadly similar features, there will often be significant differences in implementation and support for standards. For example, some secure elements are designed to implement RSA protocols for PKI alongside AES. Others will use elliptic-curve technologies or even newer technologies.
To access and control these features, developers will need to understand and employ different APIs, which adds to overall project time on top of the analysis needed to perform the threat modelling needed to assess the importance of each hardware and software components of the security model.
One way of addresses these complex device security issues is to deploy a common security framework that interfaces with the diverse silicon architectures. That determines which hardware features are available on a target platform, such as the presence of a trusted-execution mode or a TPM and uses those to deliver a framework that achieves the highest possible security for that combination of features.
Figure 3 Platforms like QuarkLink are multi-function tools that can be used to automate and streamline the process of implementing IoT security during and after embedded development. Source: Crypto Quantique
Though there are many choices hardware suppliers make when implementing security features on their products, each of which has a knock-on effect on firmware and lifecycle management, a comprehensive, integrated platform enables developers to work on a common programming interface and take full advantage of the hardware security features implemented in each of the devices they use.
David Haslam is head of software engineering at Crypto Quantique. He is a strong advocate for agile methodologies and DevOps practices, driving efficiency and collaboration across cross-functional teams.
Related Content
- Getting Ready for IoT Security in the AI Era
- Navigating IoT security in a connected world
- Security standard for consumer IoT emerges
- Hardware Root of Trust: The Key to IoT Security in Smart Homes
- What’s Driving the Shift from Software to Hardware in IoT Security?
googletag.cmd.push(function() { googletag.display(‘div-gpt-ad-native’); });
–>
The post Understand the hardware dependencies of IoT security appeared first on EDN.