IoT Security – Physical and hardware security

Editor's Note: Securing the Internet of Things is critical not only for the integrity of data streams and software within each IoT application, but also for the integrity of the enterprise resources tied into those applications. IoT security is a complex problem, requiring a systematic approach for understanding possible threats and corresponding mitigation methods.

Adapted from Internet of Things for Architects, by Perry Lea.


Chapter 12. IoT Security (Continued)
By Perry Lea

Physical and hardware security

Many IoT deployments will be in remote and isolated areas leaving sensors and edge routers vulnerable to physical attack. Additionally, the hardware itself needs modern protection mechanisms common in processors and the circuitry of mobile devices and personal electronics.

Root of Trust

The first layer of hardware security is the establishment of a Root of Trust. The Root of Trust (RoT ) is a hardware-validated boot process that ensures the first executable opcode starts from an immutable source. This is the anchor of the boot process that subsequently plays a role in bootstrapping the rest of the system from BIOS to the operating system to the application. A RoT is a baseline defense against a rootkit.

Each phase validates the next phase in the boot process and builds a Chain of Trust. An RoT can have different starting methods such as:

  • Boot from ROM or a non-writable memory to store the image and root key

  • One-time programmable memory using fuse bits for root key storage

  • Boot from a protected memory region that loads code into a protected memory store

An RoT also needs to validate each new phase of boot. Each phase of boot maintains a set of cryptographically signed keys that are used to verify the next phase of boot:

click for larger image

Establishing a Root of Trust. Here is a five-phase boot building up a Chain of Trust and starting with a Boot Loader in immutable read-only memory. Each phase maintains a public key that is used to verify the authenticity of the next component loaded.

Processors that support an RoT are architecturally unique. Intel and ARM support the following:

  • ARM TrustZone : ARM sells a security silicon IP block for SOC manufacturers that provides a hardware Root of Trust as well as other security services. TrustZone divides hardware into secure and non-secure “worlds”. TrustZone is a separated microprocessor from the non-secure core. IT runs a Trusted OS specially designed for security that has a well-defined interface to the non-secure world. Protected assets and functions reside in the trusted core and should be lightweight by design. The switching between worlds is done through hardware context switching, eliminating the need for secure monitor software. Other uses for TrustZone are to manage system keys, credit card transactions, and Digital Rights Management. TrustZone is available for A “application” and M “microcontroller” CPUs. This form of secure CPU, Trusted OS, and RoT is called a Trusted Execution Environment (TEE ).

  • Intel Boot Guard : This is a hardware-based mechanism that provides a verified boot which cryptographically verifies the initial boot block or uses a measuring process for validation. Boot Guard requires a manufacture to generate a 2048-bit key for verifying the initial block. The key is split into a private and public portion. The public key is imprinted by programmatically “blowing” fuse-bits during manufacturing. These are one-time fuses and immutable. The private portion generates the signature of the subsequently verified portion of the boot phase.

Key management and trusted platform modules

Public and private keys are critical to ensuring a secure system. The keys themselves need proper management to ensure their safety. There are hardware standards for key security and one particularly popular mechanism is the Trusted Platform Module (TPM ). The specification for TPM was written by the Trusted Computing Group and is an ISO and IEC standard. The current specification is TPM 2.0 released in September of 2016. Computer assets sold to the DoD require TPM 1.2.

A TPM is a discrete hardware component with a secret RSA key burned into the device at manufacturing.

Generally, a TPM is used to hold, secure, and manage other keys for services such as disk encryption, Root of Trust booting, verifying the authenticity of hardware (as well as software), and password management. A TPM can create a hash of the litany of software and hardware in a “known good” configuration that can be used to verify tampering at runtime. Additional services include assisting in SHA-1 and SHA-256 hashing, AES encryption blocks, asymmetric encryption, and random number generation. Several vendors produce TPM devices such as Broadcom, Nation Semiconductor, and Texas Instruments.

Processor and memory space

We have already discussed various exploits and processor technologies that act as countermeasures. Two predominant technologies to look for in CPU and OS facilities include non-execution memory and address space layout randomization. Both types of technologies are meant to burden or prevent buffer-overflow and stack-overrun types of malware injection:

  • Non-execution or executable space protection : This is a facility enabled by the hardware used by the operating system to mark areas of memory as non- executable. The intent is to map only areas where verified and legitimate code resides to be the only regions of addressable memory that can execute an operation. If an attempt is made to implant malware through a stack-overflow type of attack, the stack will be marked as non-executing and an attempt to force the instruction pointer to execute there would result in a machine exception. Non-executable memory uses an NX bit as a means to map the region as non- executable (through the translation lookaside buffer). Intel uses the XD bit (execute Disable) and ARM uses an XN bit (eXecute Never). Most operating systems such as Linux, Windows, and several RTOSs support such features.

  • Address space layout randomization : While more of an operating system treatment of virtual memory space than a hardware feature, it is important to consider ASLR. This type of countermeasure targets buffer-overflow as well as return-to-libc attacks. These attacks are based on an attacker understanding the layout of memory and forcing calls to certain benign code and libraries. Calling these libraries becomes particularly laborious if the memory space is randomized on each boot. Linux provides the ASLR ability using the PAX and Exec Shield patches. Microsoft provides protection for heap, stack, and process blocks as well.

Storage security

Often, IoT devices will have persistent storage at the edge node or on a router/gateway. Intelligent fog nodes will require persistent storage of some kind as well. The security of data on the device is imperative to prevent malicious malware from being deployed and to protect the data in the event the IoT device is stolen. Most mass storage devices such as flash modules and rotating disks have models with encryption and security technology.

The FIPS 140-2 (Federal Information Processing Standard) is a government regulation detailing encryption and security requirements for IT devices that manage or store sensitive data. It specifies not only technical requirements but also defines policies and procedures. FIPS 140-2 has several levels of compliance:

Level 1: Software-only encryption. Limited security.

Level 2: Role-based authentication is necessary. Requires the ability to detect physical tampering using tamper-evident seals.

Level 3: Includes physical tamper resistance. If the device is tampered with, it will erase critical security parameters. Includes cryptographic protection and key management. Includes identity-based authentication.

Level 4: Advanced tamper protection for products designed to work in physically unprotected environments.

In addition to encryption, it is also necessary to consider the security of media when it's decommissioned or disposed of. It is fairly easy to retrieve contents from old storage systems. There are additional standards on how to wipe and erase content securely from media (whether it's a magnetically based disk or a phase-change flash component). NIST also publishes documents on securely erasing and wiping content such as the NIST Special Publication 800-88 for Secure Erase.

Physical security

Tamper resistance and physical security are particularly important for IoT devices. In many scenarios, an IoT device will be remote and without the safeguards of on-premises devices. This is analogous to the Enigma machine of World War Two. Retrieving a working machine from the German submarine U-110 helped break the cipher. An attacker with access to the IoT device can use whatever tools are at their leisure to crack the system, as we saw with the Chain Reaction exploit.

Side channel attacks, as shown, deal with power analysis; other forms are timing attacks, cache attacks, electromagnetic field emissions, and scan chain attacks. The common theme of a side-channel attack is the compromised unit is essentially a device under test (DUT ). This means the device will be observed and measured in a controlled environment.

Additionally, techniques like DPA use statistical analysis approaches to look for the correlations of random input to output. The statistical analysis only works if the system behaves identically from run to run with the same input:

Methodology
Timing Attacks Attempts to exploit small differences in the timing of algorithms. For example, measuring the timing of a password decoding algorithm and observing early exits from the routine. Attackers also can observe cache utilization to witness the characteristics of the algorithm.
Simple Power Analysis (SPA) Similar to a timing attack but measures large changes in dynamic power or current due to the behavior of an algorithm and opcodes. Public keys are particularly susceptible. The analysis needs few traces to work but the traces need a high degree of precision. As most cryptographic algorithms are mathematically intensive, different opcodes will show up as different power signatures in a trace.
Differential Power Analysis (DPA) DPA measures dynamic power but can observe changes that are too small to be observed directly as in SPA. By injecting random input (such as different random keys) into a system, the attacker can perform thousands of traces to build a data-dependent set. Attacking an AES algorithm, for example, simply means building two sets of traces depending on the value of the bit (0 or 1) being cracked. The sets are averaged and the difference between the 0 and 1 set is plotted to show the effect of the random input to the output.

Methods of prevention are well known and several can be licensed and used in a variety of hardware. Countermeasures for these types of attacks include:

  • Modify the encryption function to minimize the use of the key. Use a short-lived session key based on a hash of the actual key.

  • For timing attacks, randomly insert functions that will not perturb the original algorithm. Use different random opcodes to create a large work function for the attacks.

  • Remove conditional branches that depend on the key.

  • For power attacks, decrease leakage at every opportunity and limit the number of operations per key. This reduces the attacker working set.

  • Induce noise into power lines. Use variable timing operations or skew clocks.

  • Change the order of independent operations. This reduces correlation factors around the S-Box calculation.

Other hardware considerations include:

Preventing access to debug ports and channels. Often these are exposed on the PCA as serial ports and JTAG ports. Headers should be removed and fuse bits blown to prevent debug access in the most hardened cases.

ASICs typically use ball grid array (BGA) pads to attach to a PCA. High-performance adhesives and thermally-resistant glue should be used to surround the package and may cause irreparable damage if tampered with.

The next article in this series will focus on cryptographic methods.

Reprinted with permission from Packt Publishing. Copyright © 2018 Packt Publishing


Perry Lea is a 27-year veteran in the technology industry and sees himself as a technologist, strategist, business developer, entrepreneur, researcher and inventor. Besides writing the book, Internet of Things for Architects, he holds more than 50 patents. He served as Chief Architect at Hewlett Packard, where he architected and steered the design of more than 60 product lines. He holds three engineering degrees and a post graduate degree from Columbia University.

1 thought on “IoT Security – Physical and hardware security

  1. “Security should always be our topmost priority regardless in whichever platform that we are working on. It should not be a concern revolving around a simple process alone but it should generally cover the whole infrastructure as well. This means that, wit

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.