The Security of IoT Devices

The security of IoT devices is a broad domain of expertise that spans the environment that devices are running in and the hardware platforms and operating systems that form the foundations on which the actual device functionality is built. Each area requires different technologies and skill sets, but all areas must form a secure unit together. The hard truth is that neglecting a single area might have fatal consequences even if all other areas are perfect.

However, having one secure device doing its job is just a start. Securely deploying and operating not just one device but the entire fleet brings another challenge in the form of provisioning, authentication, and identity management.

In This Article

We will explore several essential areas in the domain of IoT security. IoT devices come in many forms and sizes, but the following security-related aspects are common for all of them:

• Physical security perimeter of IoT devices
• Hardware
• Operating System
• Software
• Identity & provisioning of IoT devices
• Authentication of IoT devices

Physical Security Perimeter of IoT Devices

IoT devices are typically located in unpredictable, unsteady, and insecure environments that are very different from, e.g., computer systems running in data centers.

If sufficient physical security cannot be guaranteed, preparing IoT devices to face threats from potentially malicious actors with physical access is essential. There are several measures that hardware and software designers can take to reduce such risk. These measures might include general techniques, such as encrypting data on storage devices, and some more IoT-specific techniques we will explore in the rest of the article.

Hardware

Hardware is the bedrock for the security of IoT devices. When hardware is compromised, most of the software-level protections that IoT devices might have can be circumvented by attackers.

Historically, when an attacker gained physical access to a computer system, it was basically game over from a security standpoint. Fortunately, many advances have been made in this area driven by a growing number of IoT devices and other types of mobile devices. Examples of such hardware-level protections might be:

• Trusted Execution Environments (TEE) such as Intel SGX allow encrypting specific portions (enclaves) of memory that can be decrypted only by the CPU on the fly, effectively preventing code not originating from the enclave to read and modify that (including the operating system and hypervisors, should there be any).
• Physically Unclonable Functions (PUF) can be used as unique, unforgeable, and immutable device identifiers.
• A Trusted Platform Module (TPM) is a dedicated crypto processor and secure storage for critical data such as encryption keys. It can generate cryptographically secure random numbers and perform cryptographic operations using the stored keys without exposing them outside the TPM or validating hardware configuration.

Although these techniques have been researched and implemented for many years, the PUFs have not been widely spread, and TEEs have only recently started gaining traction. On the other hand, TPMs have been considered a standard for a long time, can be found in most computers, and can significantly improve the security of IoT devices without any doubt.

We should also not forget that the deliberate compromise of an IoT device by a malicious actor is not the only threat. Many devices are placed outdoors, which makes weatherproofing their hardware a must.

Operating System

Though constrained IoT devices without an operating system (OS) are common, many devices are more complex, and an OS is needed.

The fact that OS can interfere with any computer process/program running on top of it (unless some advanced mechanism such as TEE mentioned above is used) makes it a similarly important part of the IoT device security as hardware.

First, there needs to be a way to guarantee that a maliciously unmodified version of an OS is loaded during booting. Such a guarantee can be achieved by digitally signing the OS and checking the signature during booting. There are standards for this, such as Secure Boot.

Last but not least, all operating systems contain security vulnerabilities. Apart from zero-day attacks, such vulnerabilities might be effectively resolved via timely delivery and application of software patches.

Software/Applications

The compromise of a single application might seem to have a much smaller impact than a compromise of the entire operating system or hardware. However, it can be the only thing the attacker needs to succeed. Moreover, unlike operating systems, many applications directly deal with sensitive business data and interact with users.

Similar measures for operating systems can also be applied to various software packages and applications running on top of the operating system. Verifying the integrity of executables and their timely security updates should be considered.

When writing custom applications, developers should consider that the environment their code will run in is untrusted. Examples:

• When loading sensitive data into RAM, free and zero out the allocated memory as soon as possible to reduce the risk of exposing sensitive data via forced memory dump.
• Think twice before writing sensitive data onto a disk. Even with disk encryption in place, the data will be exfiltrated. When writing sensitive data to disk is necessary, consider encrypting it with a key stored in a Trusted Platform Module (TPM) mentioned in the previous section.

Identity & Provisioning of IoT Devices

To meaningfully manage a fleet of IoT devices, each device must have its own identity, and there must be a way to securely assign an identity to new devices and change the identity of existing devices if needed. We might call this process "device provisioning". For IoT solutions, identity is essential so that, e.g., data from individual devices can be securely distinguished or compromised devices disconnected.

What exactly is the "identity" of an IoT device? It depends on the context. However, the device needs a way to prove that its identity is legitimate (authenticate). We can distinguish between physical and logical device identity.

Physical Identity

Physical identity is a hardware-level identity that should be unforgeable, unique, immutable, and untransferable for the entire device lifecycle and is typically not related to the business domain. In an ideal world, physical identity would be assigned precisely once after device manufacturing is completed. This could be achieved, e.g., by combining serial numbers of all hardware components. However, this approach is much more complicated in reality:

• Hardware components can be broken and replaced with new ones. To make it even more complicated, the component can be replaced with a repaired component from another device.
• Not all hardware components have some serial number, or the serial number cannot be read easily.
• Serial numbers are typically not cryptographically secure identifiers.

That's why physical identity is usually "approximated" by generating identifiers during manufacturing or using a serial number of some component deemed primary.

Logical Identity

Logical identity, on the other hand, is typically tightly coupled to the business domain or other non-technical aspects such as device location. Similarly to physical identity, the logical identity must be unforgeable and unique, but it can be mutable and transferable.

To demonstrate the difference between physical and logical identity, consider the following example use case: A robotic arm on a car assembly line performs a specific function. It is a stationary IoT device.

This robot's physical identity is assigned right in the factory by generating a cryptographically secure UUID (e.g., c2c38155-b0d2-48b6-82fd-22fe3b316224).

This device sends data to a cloud-based IoT solution backend and receives feedback from the same backend. There are two kinds of data that this robot sends:

• Diagnostics data about the performed functionality (e.g., how many car parts on the assembly line were processed by this robot each hour).
• Internal telemetry data (e.g., amount of torque applied by each joint).

If the robot malfunctions and must be replaced, its physical identity will change.

Let's suppose the robot does not have a logical identity. In that case, correlating existing data in the cloud to the identity of the new robot is not straightforward. It might not be a problem for the internal telemetry data because they are relevant only to the original robot. However, the diagnostics data about performed functionality might be relevant for the new robot. Also, other systems that were communicating with the original robot before malfunctioning now need to be made aware that the robot was replaced.

Let's compare this to a situation where the original robot also had a logical identity related to the organization of the car assembly line (e.g., line-03-left-welding-12). If this logical identity is used for storing the diagnostics data and for communication with other systems, replacing the robot can be much easier.

Authentication of IoT Devices

No matter which identifiers IoT devices use and how they are generated, the devices must prove that the identifiers they use are legitimate. The process of ensuring that an identifier is legitimate and is used by a correct device is called authentication.

Authentication of IoT devices is always based on symmetric or asymmetric (public) key cryptography algorithms and hashing algorithms. These algorithms always need a secret key stored somewhere in the device.

How authentication works exactly depends on the specific algorithm. However, there are always the following two assumptions:

• The identity of the device is bound with the secret key.
• The secret key is truly secret.
• For asymmetric algorithms, it is only known by the device.
• For symmetric algorithms, it is only known by the device and authenticating party (e.g., IoT solution backed).

Handling of Secret Keys

Where and how precisely secret keys are stored depends on the device's capabilities and the specific authentication algorithm. The state-of-the-art approach is to keep keys in Trusted Platform Modules (TPMs). The TPMs can execute cryptographic operations directly without exposing the secret keys, providing protection from the key exfiltration.

A good practice is to derive short-lived/session-based keys from the primary key to minimize the primary key's exposure and provide forward secrecy.

Examples

The most widely used algorithms, standards, and protocols are:

• RSA, Elliptic Curves, SHA2: Foundational asymmetric (public) key encryption and hashing algorithms.
• X.509 certificates: Standard that defines how to couple asymmetric keys with identity via objects called certificates.
• mTLS: Protocol for securing TCP connections. Unlike plain TLS, both sides of the connection are authenticated. It is built on top of the foundational encryption and hashing algorithms and X.509 certificates mentioned above.
• HMAC: Symmetric key-based algorithm that can generate a signed device identifier, which devices can use to prove their identity.

Key Takeaways

The nature of IoT security is multifaceted. Although many kinds of IoT devices exist, there are some common security aspects that any IoT solution designer should consider:

• The environment the device is running in (physical security perimeter).
• The foundations the device is built on (hardware, operating system).
• The actual code that makes the device useful (software).
• Processes required for the software to run in a secure, controllable, and scalable manner (identity, provisioning, and authentication).

On the other hand, it is not a good idea to blindly follow and implement all suggestions provided by this article. Some measures are more important than others for various IoT solutions, and some might not even be relevant or feasible in certain contexts. However, relaxing security measures should always be done consciously and after proper consideration.