Internet of Things (IoT) devices are everywhere these days adding tremendous value, but unfortunately also representing unprecedented levels of risk for exploitation. Anything that is connected to the internet is potentially hackable. Securing connected devices is a challenge and is top of mind for electronics manufacturers who want to avoid the embarrassment of having their devices hacked. The subject of IoT security is complex, and this blog offers a high-level summary of some of the tried and tested security solutions that can be used to build more secure IoT devices.

Our connected devices contain a wealth of information that is of great interest to attackers. Of course, we are all familiar with the value of our personal information on devices such as emails and passwords, but there is a whole host of other information that attackers are interested in too. Attackers might want to disable access to a device’s functionality or get access to the data on the device itself to stage a ransomware attack. They might use a device as a staging point to get access to the network that the device is connected to. This staging point can then be used to attack further security-sensitive devices. Attackers can also be interested in the processor resources or the network bandwidth that a specific device represents. If they manage to control a lot of devices, these resources can then be used for a denial-of-service attack. And finally, devices that use actuators or sensors, to open doors or shut off electricity for example, can be attacked and leave key functions in the home or workplace vulnerable.

So, what exactly are some of the ways that we can protect a device by design?

One way is to implement a field proven secure boot mechanism to make sure only trusted software can run on the device. This can be achieved using a ROM-based code mechanism to authenticate the software, using key material that cannot be modified by an attacker. However, using a Root of Trust module to boot the device strengthens the boot process even further and supports secure implementation of other security sensitive functions such as firmware/software updates, secure debug access control, and boot image confidentiality. Using encryption to protect the confidentiality of the software makes it more difficult for an attacker to find potential vulnerabilities, but it does require that the key material used to decrypt the software remains confidential. In devices that (also) run a lot of complex software (vulnerable to logical attacks), an attacker could gain code execution on the device post boot, which means that the firmware decryption key must never be readable from the device and its use must be limited to device initialization only.

Secondly, good security requires good random numbers. Predictable random data immediately leads to security vulnerabilities. Generating a random number requires having access to one or more sources of “unpredictable data’” that can be collected in what is typically referred to as an entropy pool. If an attacker is unable to guess the state of the entropy pool, the random numbers generated using the data in that pool will be unpredictable. Large devices, such as a Linux-based computer, have access to many different sources of unpredictable data, such as the time interval between hits on the keyboard and many other sources. Having access to multiple sources of unpredictable data allows a device to quickly fill its entropy pool and enable the generation of good quality random data.

IoT devices, on the other hand, are small and do not have as many sources from which they can fill their entropy pool to seed random numbers. Having an “empty” pool, that gives you a predictable random number, is obviously bad for security. Waiting for the device to generate sufficient entropy without much unpredictable input may take too long for an IoT device’s use cases. To address this, you can build a dedicated random number generator in the silicon of the device that will give you the ability to fill that pool quickly. Solutions that are certified FIPS, SESIP, or Common Criteria are the best choice in this situation, as it means that you are getting your random number generator from a source where it has been tried, tested, and certified.

Thirdly, data entering and leaving the device can be encrypted and authenticated to prevent certain attacks. Communication between the cloud, the backend, and the device must be secured. The software stacks implementing these communication security protocols are the first line of defense against remote/logical attacks. Software needs to come from a trusted source to ensure that it contains no bugs or back doors. Ideally, like with random number generators, it should come from a tested and certified source.

In many cases, the functional requirements of a device require a significant amount of software to run on the host processor of the system. This software is focused on making the device do what it is supposed to do; its immediate focus is not on securing the device against logical and physical attacks, which can make it vulnerable. If an attack happens, the ability to limit what an attacker can do, and the ability to ensure the device can be safely recovered, is paramount. Again, a Root of Trust core can come into play in this situation, physically separating security critical software and data from untrusted software components. It can also protect key material from leaving the security boundary of the device, preventing an attacker from making permanent changes to the security architecture.

Rambus has a broad portfolio of hardware security IP solutions designed to support the security needs required for IoT devices from the simple to the cutting-edge. Many of these solutions are FIPS and Common Criteria certified, enabling customers to reduce overall project risk and development time with a tested and certified security IP solution.

Additional resources: