The Internet of Things (IoT) needs to be protected against diverse forms of abuse. These include not only familiar threats like financial fraud and IP theft, but also sabotage of physical assets. Many of the billions of connected devices expected to join the IoT over the next few years will be associated with systems like traffic signals or street lighting, industrial controls, safety mechanisms for important processes like power generation, smart-grid management, home energy and security, or connected cars. Attackers can try to disable or take over such devices, potentially aiming to cause widespread disruption and inconvenience, or to attack specific individuals or organizations by causing embarrassment, reputational damage or even bodily harm. Such exploits could be launched simply for amusement, personal reasons, commercial gain, or for political purposes and/or terrorism.
Security threats to IoT devices
IoT devices are designed to operate autonomously. Many are left unattended for long periods, and sometimes for their entire operational lifetime. Network connectivity leaves the devices vulnerable to remote attacks that can be launched quickly from almost any geographical location without having to overcome physical barriers such as a fence, a locked enclosure or a security guard. An attack can be directed towards the device itself, or to use it as a means to gain access to other assets connected to the same network, such as data storage containing account-holder information or intellectual property.
On the other hand, IoT endpoints are often required to be simple, low-cost, low-power devices, designed to accomplish their intended task using minimal resources. As such, the processing power and energy needed to implement sophisticated security is not available. Unlike the case with a machine such as a desktop computer, no human is routinely present to enter credentials such as a username and password as authentication allowing the device to start up and establish connections. However, the device must be able to resist various types of attacks, and to authenticate itself and present its credentials autonomously to other devices on the network.
If the device is not able to carry out these functions, attackers may be able to erase or disable application software, alter the code, or replace the legitimate application with rogue software. Alternatively, they may attempt to eavesdrop on data exchanges. A range of security principles and technologies need to be employed to help overcome these threats, but all need to be usable in a small and resource-constrained embedded system. In addition to established security practices such as minimizing access privileges for networked devices, proper firewalling and traffic monitoring; these include digital signing of software, data encryption using secure keys, and establishing strong identities for connected devices.
Verifying software authenticity
Digital signing provides a means of authenticating software to verify its origin and prevent unauthorized alteration. A software publisher can sign software independently or with the support of a third-party Certificate Authority (CA) that provides services such as signing utilities, and certificate and key management.
To digitally sign software, the publisher creates a hash of the code using a hashing algorithm. Hashing works in one direction only, which prevents hackers from reverse-engineering the process to produce an identical hash from bogus code. The hash is then encrypted using a private key assigned to the publisher. The code, its encrypted hash, and the publisher’s signing certificate are distributed together.
The end user decrypts the hash using the publisher’s public key, which is included as part of the signing certificate, and hashes the received code using the publisher’s chosen hashing algorithm. If the two hashes match, the code can be assumed to be genuine and unaltered. Figure 1 illustrates the hashing and comparing processes used to verify code authenticity.
Figure 1: A Certificate Authority manages certificates and provides tools for signing software.
Digital signing allows an IoT device to verify the authenticity and integrity of software on power-up, thereby enabling secure booting: the device will only load genuine, unaltered software signed by the authorized publisher, thereby creating a foundation of trust. The system can also verify digitally signed software such as updates or patches received via the network.
Data encryption
Encryption using a combination of public and private keys can also prevent eavesdroppers gathering intelligence from intercepted data transmissions. The system of public and private keys provides a solution to the challenges of sending encrypted data and preventing key interception. The receiving device has its own private key, which is securely embedded at the time of manufacture. At the same time, a public key is derived from the private key using a one-way process that prevents the private key from being revealed if the public key is intercepted. When a sending device sends data to a recipient, it uses the public key for that recipient to encrypt the data. This encrypted data is safe to transmit over the network, and can only be decrypted using the private key securely stored at the receiving end. Figure 2 shows how the keys are used to keep information secure when transmitted over an open channel.
The Public Key Infrastructure (PKI) is maintained by an independent third-party organization that handles generation and distribution of keys, and binds public keys to the identities of their respective users.
Figure 2: Data encryption and decryption using public and private keys.
Maintaining strong identity
The IoT device also needs to be able to authenticate itself when connecting to the network. This is equivalent to entering a username and password to login manually to an online account.
The device needs an efficient secure processor to store its identity and handle authentication, and to store public and private encryption keys, and to store keys and run hashing algorithms for verifying software signatures to be able to verify software signatures.
Embedded security in a chip
The Trusted Platform Module (TPM) has evolved to provide a secure environment for key and data storage and executing security algorithms. These devices contain a secure processor running a secure operating system, as well as secure storage and other resources such as a random number generator and a hardware-based cryptographic engine (Figure 3). Additional security circuitry protects against physical attacks. The details of secure operating systems are deliberately kept secret to prevent would-be hackers learning information needed to launch an attack. TPMs are commonly used in commercial-grade IT equipment such as desktop PCs. On the other hand, devices such as the Atmel/Microchip AT97SC3205T are designed for embedded applications and can be used in various types of IoT equipment.
Figure 3: The Atmel AT97SC3205T embedded TPM integrates resources for secure processing and key storage.
The AT97SC3205T meets the Trusted Computing Group (TCG) TPM Version 1.2 Specification. Devices are usually delivered in Compliance mode, which enables manufacturers to immediately begin testing the TPM. As the TPM is embedded into the IoT equipment, it should be changed to Real mode to set flags permanently and allow generation of a unique private and public Endorsement Key (EK) pair for use in transactions that require signing of data used by other components. The private part of the endorsement key is kept secret inside the TPM, and the public part is used by other components to verify the authenticity of data from the TPM. Generating the EK pair can take several seconds. To simplify manufacturing and reduce the time required for device initialization, devices can be delivered in Real mode if required. In this case, the EK pair is pre-generated by Atmel.
TPM_Startup(ST_CLEAR)
Incoming Operands 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
TPM_Startup(ST_CLEAR)
Outgoing Operands 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]
Listing 1: Sample startup commands for initializing the TPM.
The TPM can be made fully operational by booting up the equipment and sending a TPM startup command (Listing 1) to prepare the device for configuration. Configuration involves setting permanent flags as appropriate for the intended application. Atmel has published a sample manufacturing sequence that sets TPM flags as shown in Listing 2.
Compliance Mode: Cleared
physicalPresenceHWEnable: False
physicalPresenceCMDEnable: True
physicalPresenceLifetimeLock: True
Endorsement Key Pair: Generated
Enable/Disable: Disabled
Activated/Deactivated: Activated until the next reset,
deactivated at the next power-up or reset is requested.
Physical Presence: Not Present
NV_Locked True
Listing 2: Sample TPM flag settings.
The physical presence settings in the sample are designed to permanently disable hardware access and prevent software from losing control of the device if the settings are inadvertently or deliberately altered. Setting NV_Locked = True prevents unauthorized access to user-accessible non-volatile memory, and should only be set after the manufacturer no longer needs to access the non-volatile memory.
Conclusion
As the Internet of Things continues to grow and it becomes more of a reality to the general public, the importance of securing the billions of remote, connected objects against cyber-attack becomes increasingly clear.
Trusted Platform Modules (TPMs) that provide secure resources needed to authenticate the system’s hardware and software are small, low-power devices that are suitable for embedded applications. In conjunction with key-management and device-signing services, they can provide an efficient hardware-based security solution.
