ALLPCB
Introduction
IoT devices must be protected from various forms of abuse. Threats include financial fraud and intellectual property theft, as well as physical damage to assets. Many of the billions of devices expected to join the IoT in coming years will be associated with critical systems such as traffic signals or street lighting, industrial control, power generation, smart grid management, home energy and security, or connected vehicles. Attackers may attempt to disable or take control of such devices, causing widespread disruption, reputational harm, or physical injury. Motivations for attacks range from mischief and personal reasons to commercial gain or political and terrorist objectives.
IoT device security threats
IoT devices are often designed to operate autonomously and may remain unattended for long periods, sometimes for their entire service life. Network connectivity exposes devices to remote attacks that can be launched from almost any location without overcoming physical barriers such as fences, locked enclosures, or guards. Attacks can target the device itself or use the device as a pivot to access other assets on the same network, such as data stores containing account holder information or intellectual property.
On the other hand, IoT endpoints typically need to be simple, low-cost, and low-power devices intended to perform their tasks with minimal resources. The processing power and energy required to implement complex security may not be available. Unlike desktop machines, there is often no human operator to enter credentials such as usernames and passwords to allow a device to boot and connect via authentication. Nevertheless, devices must resist various attack types and be able to self-attest and automatically present credentials to other devices on the network.
If a device cannot perform these functions, attackers may be able to remove or disable application software, alter code, or replace legitimate applications with rogue software. They may also attempt to eavesdrop on data exchanges. Addressing these threats requires a set of security principles and techniques adapted for small, resource-constrained embedded systems. In addition to established best practices such as minimizing network exposure, using appropriate firewalls, and monitoring traffic, this includes digitally signing software, encrypting data using secure keys, and establishing strong identities for connected devices.
Verifying software authenticity
Digital signatures provide a method to verify software origin and prevent unauthorized modification. Software publishers create a hash of the code using a hash algorithm. Hash functions are one-way, which prevents attackers from reverse-engineering the process to generate the same hash from forged code. The publisher then encrypts the hash with a private key assigned to the publisher. The code, its encrypted hash, and the publisher's signing certificate are distributed together.
The end user uses the publisher's public key, included in the signing certificate, to decrypt the hash and hashes the received code with the same algorithm the publisher used. If the two hashes match, the code can be assumed authentic and unmodified. Figure 1 illustrates the hashing and comparison process used to verify code authenticity.
Figure 1: Certificate authority manages certificates and supplies tools for signing software.
Digital signatures allow IoT devices to verify software authenticity and integrity at boot, enabling secure boot: the device loads only genuine, unmodified software signed by authorized publishers, creating a foundation of trust. The system can also verify digitally signed software received over the network, such as updates or patches.
Data encryption
Encryption using public and private keys prevents eavesdroppers from gleaning intelligence from intercepted transmissions. Public-key systems address both securely sending encrypted data and preventing key interception. The recipient device has its own private key, securely embedded during manufacturing. The public key is derivable from the private key via a one-way process, which protects the private key if the public key is intercepted. When a sender transmits data to a recipient, it uses the recipient's public key to encrypt the data. The encrypted data can be sent safely over the network and can only be decrypted with the private key securely stored at the recipient. Figure 2 shows how keys are used to secure information over an open channel.
Figure 2: Encrypting and decrypting data using public and private keys.
Public key infrastructure (PKI) is typically maintained by an independent third party that handles key generation and distribution, binding public keys to the identities of their owners.
Maintaining strong identities
IoT devices also need to authenticate when connecting to networks, analogous to entering credentials to log into an online account. Devices require an efficient secure processor to store identities and process authentication, store public and private encryption keys, and run hash algorithms to validate software signatures.
Embedded security in chips
Trusted Platform Modules (TPMs) have evolved to provide an environment for secure key and data storage and execution of cryptographic algorithms. These devices include a secure processor running a trusted operating system, secure storage, and other resources such as a random number generator and hardware-based crypto engines. Additional security circuits help resist physical attacks. Details of the secure operating system are typically confidential to avoid exposing information that could assist attackers. TPMs are commonly used in commercial IT devices such as desktop PCs. Embedded TPM devices, such as the Atmel/Microchip AT97SC3205T, are designed for embedded applications and can be used in many types of IoT devices.
Figure 3: Atmel AT97SC3205T embedded TPM integrates resources for secure processing and key storage.
The AT97SC3205T conforms to the Trusted Computing Group (TCG) TPM version 1.2 specification. Devices are typically delivered in a compliant mode so manufacturers can begin testing the TPM immediately. Because the TPM is embedded in an IoT device, it should be switched to operational mode to permanently set flags and allow generation of a unique endorsement key (EK) pair for transactions that require signed data from the TPM. The private part of the endorsement key remains confidential inside the TPM, while other components use the public part to verify TPM-originated data. Generating an EK pair can take several seconds. To simplify manufacturing and shorten device initialization, devices may be delivered in operational mode with EK pairs pre-generated.
Example TPM startup sequence
TPM_Startup(ST_CLEAR) Incoming parameters and sizes: 00 C1 00 00 00 0C 00 00 00 99 00 01 tag 2 Bytes, Offset 0: 00 C1 paramSize 4 Bytes, Offset 2: 00 00 00 0C ordinal 4 Bytes, Offset 6: 00 00 00 99 startupType 2 Bytes, Offset 10: 00 01
Listing 1: Example TPM startup command used to initialize a TPM.
TPM_Startup(ST_CLEAR) Outgoing parameters and sizes: 00 C4 00 00 00 0A 00 00 00 00 tag 2 Bytes, Offset 0: 00 C4 paramSize 4 Bytes, Offset 2: 00 00 00 0A returnCode 4 Bytes, Offset 6: 00 00 00 00 [TPM_SUCCESS]
By starting the device and sending the TPM startup command shown in Listing 1, the TPM becomes fully operational and ready for configuration. Configuration involves setting permanent flags according to the intended application. A sample manufacturing sequence for setting TPM flags might include values similar to those in Listing 2.
Compliant mode: Cleared physicalPresenceHWEnable: False physicalPresenceCMDEnable: True physicalPresenceLifetimeLock: True Endorsement key pair: Generated Enable/Disable: Disabled Activate/Deactivate: Active until next reset, disabled on next power cycle or reset. Physical presence: Not present NV_Locked: True
Listing 2: Example TPM flag settings.
The sample settings for physical presence are intended to permanently disable hardware access and prevent software from unintentionally or maliciously losing control of the device configuration. Setting NV_Locked = True prevents unauthorized access to user-accessible non-volatile memory and should only be set after the manufacturer no longer needs access.
Conclusion
As IoT continues to grow, protecting billions of remotely connected objects from network attacks becomes increasingly important. Trusted Platform Modules provide the hardware-based security resources required to attest to system hardware and software. For embedded applications, small low-power TPM devices, combined with key management and device signing services, can deliver an efficient hardware-backed security solution.
