Getting security right when building IoT solutions can prove incredibly challenging.
Arguably, securing the “cloud” side of a solution is nothing new, and there are plenty of well-established practices and supporting frameworks that can help you do the right thing. However, when it comes to the “hardware” side—embedded devices that end up connected to public networks—this is still uncharted territory for most people.
In this article, we look at a few questions that you should be asking yourself as you’re building your connected product and provide some answers to help you make your next IoT device as secure as can be.
What is my device’s identity? Is it unforgeable?*
As you authenticate as an individual against a website or any form of online service, you are often relying on multi-factor authentication (MFA) to avoid impersonation and identity theft. Multi-factor authentication makes it virtually impossible for an attacker to forge your online identity, as they probably can’t get access to all the pieces of evidence needed to authenticate said website or service. For example, they may have gained knowledge of your password, they even stole your phone, but they don’t know your 6-digit pin, nor do they have your fingerprint. In short: they won’t be able to complete the sign-in process and impersonate you.
Can a similar mechanism be implemented for preventing identity theft of physical IoT devices?
The answer revolves around the use of dedicated hardware such as Trusted Platform Modules (TPM). In a nutshell, such equipment holds cryptographic keys that are protected by hardware. The private key never leaves the module once it’s been stored in it, and the public key is then used to attest to the device’s identity. As the keys can’t be forged, impersonating the device is effectively equivalent to gaining physical access to it (this, of course, poses other security issues which we’ll talk about shortly!).
* I know, that’s two questions in one!
Where does my code run?
The term trusted computing base (TCB) refers to the set of hardware, firmware, and software components that are critical to a system’s security. There are several aspects of your IoT device that will play a role in ensuring the overall security of the system, from the TPM, mentioned earlier, to the kernel of your—potentially real-time—operating system.
As you design your IoT device, you must keep in mind that your trusted computing base should stay as small as possible. That way, you can minimize the surface of attack and reduce the risk of a bug (or feature!) in the TCB allowing an attacker to bypass security protections and deploying malicious payloads allowing them, for example, to steal valuable business data.
If you can, try to build on top of an operating system or real-time operating system that allows you to only ship and enable the features you really need. In any case, your application code should run outside of the TCB so that it can misbehave without affecting security.
Are my software components compartmentalized?
I find watchdog timers to be an exquisite concept—if a component of your embedded system stops responding, a full reset can be automatically triggered—but I also sometimes wonder if they should exist in the first place.
Historically, and often due to hardware constraints, embedded code has been designed as a rather monolithic blob, where a flaw or a breach in one component could potentially compromise the entire system, hence the need for watchdogs to mitigate the consequences of a software failure. Now, what happens if, beyond a harmless software bug causing a module (and your system) to hang, we talk about a breach in said module? Surely you don’t want an attacker to take control of your entire system due to a flaw in one of your software modules!
To mitigate this risk, a secure IoT device should allow for its various software components to be compartmentalized and should implement hardware-enforced boundaries between them. If you build on top of an RTOS that allows you to run your modules as independent tasks or processes, you’re probably in good shape!
What’s more, your device will ideally feature a security model that allows limiting what hardware resources each software module can access.
How wide is the net cast by my security mechanisms?
From distributed denial of service (DDoS) or ransomware attacks to using IoT devices as a way to get access to corporate networks, IoT devices can be a juicy target for hackers. You should assume that your devices will be hacked and that hackers will often be more creative and persistent than you might imagine.
Defense-in-depth originates in the military as a technique to delay an attacker by having resources (fortifications, military units, etc.) deployed not only at, but also well beyond, the frontline. That way, should an attacker manage to breach the frontline, they would still face several layers of defense as they penetrate deeper into the field.
Applied to IoT devices (and IT in general), defense-in-depth consists in implementing multiple layers of security controls to put several types of mitigation in front of each potential threat.
As an example, a combination of internal firewalls controlling access to the physical buses, network firewalls, and secure boot will greatly reduce the chances of your device being compromised. In the unlikely event of an attacker getting past the secure boot and being able to execute a malicious payload, the firewalls would prevent them from physically accessing the device’s peripherals or connecting to remote third-party servers.
Is authentication based on passwords or certificates?
Have you heard of shodan.io? It is a search engine that is essentially exposing IoT’s darkest secrets. And yes, ‘1234’ and ‘admin’ passwords are some of those secrets… Among other things, shodan.io allows you to find IoT and Internet devices online for which the default password may not have been changed. Ouch, right?
Beyond the obvious threat due to having publicly accessible devices rely on default credentials, password-based authentication can prove tricky to manage at scale.
For example, how do you recover from a stolen password, especially when it is used by thousands of devices deployed in the field? Certificate-based authentication, on the other hand, does not rely on shared secrets, and enables mutual authentication, limiting the risk of man-in-the-middle attacks.
Can my device be easily and automatically updated?
When it comes to IoT devices, the saying goes: “If you can’t update it, you can’t secure it.” Period.
“If you can’t update it, you can’t secure it.”
For a device to remain secure over time, it needs to allow for security updates to be rolled out as security threats evolve and attackers discover new attack vectors. Renewable device security includes, for example, the ability to roll out operating system updates (e.g., to fix zero-day vulnerabilities) or to deploy new certificates.
Ideally, you should also have hardware measures in place to prevent your device from being reverted to a known vulnerable state once it’s been updated.
Does my device report its failures?
There are many reasons why an IoT device may fail. It can, for example, be due to an attacker trying to take control of it by exploiting a vulnerability or trying to brute-force a password. It might also simply be due to the device hitting a corner case and switching to an undefined state that makes it vulnerable.
Whatever the reason, it is essential to be able to keep track of these failures across an entire fleet, so that they can not only be diagnosed and corrected but also be used to isolate and mitigate potential attack vectors before they are effectively exploited.
There are several solutions out there to help with error reporting. The Azure Security Center for IoT and its associated open-source agent are good examples of how to automatically collect and log incidents such as failed login attempts, a connection from an unusual IP address, etc.
Conclusion
This article is inspired by the paper “The Seven Properties of Highly Secure Devices” which is a must-read. You should check it out if you want to dive deeper into some of the best practices attached to each high-level security topic we listed in this article.
Finally, if you are like me, you probably like to get your hands dirty with actual devices and actual code to familiarize yourself with a new domain. If that is the case, I can only recommend an Azure Sphere development kit as a tool to grasp what it takes to build a secure IoT device.
This kit is based on an open-hardware reference design that essentially implements all the properties that are enumerated in this article and make an IoT device secure. It features a secure, connected microcontroller unit (MCU), a custom high-level Linux-based operating system, and a cloud-based security service that provides continuous, renewable security. There are many tutorials and code samples out there to help you get started with Azure Sphere and start familiarizing yourself with all the things you should have in mind as you build your next connected device.