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.
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:
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 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:
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.
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.
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 as 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:
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 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:
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, 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:
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.
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:
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.
The most widely used algorithms, standards, and protocols are:
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:
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.
