To achieve secure IoT devices and thwart attacks, it is necessary to ensure upgradability across all IoT end nodes. The longevity of IoT devices, combined with rapid advances in knowledge and tools used by adversaries, makes it infeasible to design devices that will remain sufficiently secure at any security level for their lifetime. Therefore, for devices to remain secure, it is necessary to ensure that their security is upgradable through software updates. Let’s begin with historical insight into how security has changed over time, and then consider how secure updates affect IoT device design.
Security is commonly viewed in a binary way: either a device, a service or a system is secure, or it is insecure. But the question one should ask is, secure against what? The reality is there are different levels of security, and a device can only be considered secure in the context of an attacker, when the level of security is higher than the capabilities of the attacker.
Moreover, the capabilities of the attacker are typically non-static, and therefore, the security level will change over time. The improved capabilities of the attacker can come about in several different ways, from the discovery and/or publication of issues and vulnerabilities to broader availability of equipment and tools.
Let’s review a few examples of how security levels have evolved over time, starting with symmetric encryption algorithms. In 1977, the data encryption standard (DES) algorithm was established as a standard symmetric cipher. DES uses a 56-bit key-size, so through increases in available computational power, the standard is vulnerable to brute-force attacks. In 1997, it was shown that it took 56 hours to break the algorithm via brute-force. With DES clearly being broken, triple DES, basically running DES three times with different keys was established as a standard secure symmetric cipher. Regarding the security level of DES, there has been speculation that if governments could already break the cipher in 1977, DES could never resist nation-state attacks. However, since the early 2000s, DES could not even protect against hobbyists with personal computers due to the widespread availability of computational power.
Since 2001, the advanced encryption standard (AES) replaced DES. But even AES does not guarantee absolute security. Even when the algorithm could not be easily broken, the implementation often could be hacked. Consider, for example, differential power analysis (DPA) attacks in which the power consumption or the electromagnetic radiation of the circuit performing the cryptography is used to obtain the cryptographic keys. Specifically, DPA involves capturing a large number of power consumption traces followed by analysis to reveal the key. DPA was introduced in 1998, and since then, companies such as Cryptographic Research Inc. (now Rambus) sold tools to perform DPA attacks, although at a price that made the tools inaccessible to hobbyists and most researchers. Today, the hardware tools to perform advanced DPA attacks can be purchased for less than $300 (USD), and advanced post-processing algorithms are available online free of charge. Thus, the ability to conduct DPA attacks has migrated from nation states and wealthy adversaries to nearly any hacker.
Now let’s discuss these historic lessons in the context of the longevity of an IoT-device. A typical lifetime of an IoT device depends on the application, and 20 years is common in industrial applications – a timespan we will use for this discussion. A device that launched in 1998, for example, was once only vulnerable to nation state attacks; today it must be able to withstand DPA attacks by hobbyists with $300 for tools, some spare time and lots of coffee. Predicting the future capabilities of a class of adversaries is very difficult if not impossible, especially over a 20-year timespan.
The only reasonable way to counter future attack scenarios is for the security of the device to evolve with the capabilities of the adversary. This requires IoT security that is software upgradable. There is of course functionality that requires hardware support, which cannot be retrofitted via software updates. However, it is incredible what can be solved in software when the alternative is a truck roll.
What does this mean for your IoT product? First, the product needs to be able to receive software updates in a secure way. Let’s discuss two aspects of secure software updates: from a technical point of view, namely the requirements for the device and software, and a process point of view, specifically the authorization and control of releasing software updates.
From a technical perspective, secure updates involve authenticating, integrity checking and potentially encrypting the software for the device. The software handling such security updates is the bootloader, and with these features, it is typically referred to as a secure bootloader. The secure bootloader itself, along with its corresponding cryptographic keys, constitutes the root-of-trust in the system and is typically not upgradable. The bootloader and keys must therefore be placed in immutable memory such as one-time-programmable (OTP) memory or read-only memory (ROM). Any vulnerability in this code is equivalent to an issue in hardware and cannot be fixed in the field.
The authentication and integrity check should be implemented using asymmetric cryptography, with only public keys in the device. It is not necessary to protect the signature-checking key in the devices. Since protecting keys in deployed devices is (or at least should be) harder than protecting keys in control of the device owner, it is also acceptable to use the same bootloader keys for many devices. Finally, since the device can contain and use a public key, the system is secure against DPA attacks.
Encrypting the software running on the IoT device has two benefits. First, it protects what many vendors consider to be intellectual property (IP) from both competitors and counterfeiting. Secondly, encryption prevents adversaries from analyzing the software for vulnerabilities. Encrypting the new software for secure boot does, however, involve secret keys in the device, and protecting secret keys in a device in the field is becoming increasingly difficult. At the same time, newer devices have increased resistance to DPA attacks. Furthermore, a common countermeasure against DPA attacks is rate-limiting the number of cryptographic operations to make it infeasible to get sufficient data to leak the key. Even though protecting the key is difficult and motivated adversaries will likely extract it, it does raise the bar and make life significantly harder for the attacker. Therefore, secure boot should always involve encryption of the software.
Another consequence of secure updates is the likely future need for more memory in the IoT device. This is a complicated trade-off for several reasons. First, software tends to expand to the memory available in the device. So, a larger memory device requires discipline from the software team to leave room for future updates. The other complication is the value of free memory in the future versus the device’s initial cost. More memory tends to increase the cost of the device. This cost must be justified both from the device maker and the consumer point of view. Unfortunately, the fierce competition for market share makes many device makers myopic, and they sometimes prioritize cost over future security.
Finally, it is important to have a plan for distributing the security updates. For most devices, these updates use the device’s existing Internet connection. But in some cases, this requires adding or using physical interfaces such as USB drives (i.e., sneakernet). It is also important to consider that the devices might be behind firewalls or in some cases disconnected from the Internet.
Once secure updates are possible from a technical point of view, the question becomes who has the authority to sign and issue software updates. Increasingly common for IoT devices, the software is fully owned and managed by the device maker. This means that the device maker should have proven processes in place to internally protect the signing keys and particularly who can issue updates. This might or might not be combined with authorization from the customer or end user. For some devices, the end user must actively download an update and apply it, or at least initiate the update process. In other instances, the update is fully automatic.
The longevity of deployed IoT devices, combined with the proliferation of tools and knowledge of adversaries, makes it infeasible to create devices that will remain sufficiently secure at any security level for their lifetime. Therefore, for IoT devices to remain secure throughout their practical lifetime, it is necessary to ensure that the security of these devices is upgradable through software updates. But since an update mechanism is also an attack point, it is necessary to deploy secure bootloaders in all programmable devices in an IoT product and to properly secure the bootloader keys. IoT vendors should expect to receive secure bootloader functionality from their IC suppliers. Furthermore, IoT vendors must plan upfront for delivery mechanisms and processes to issue updates. Fortunately, secure bootloaders are readily available, and relevant devices are already connected to the Internet. Enabling secure updates requires minimal effort, and there is no excuse not to do it.
Lars Lydersen is Senior Director of Product Security, Silicon Labs
