Anatomy of a secure internet-connected thing
- Autor:Ella Cai
- Lassen Sie auf:2017-04-10
Lars Lydersen was a part of the team that broke into ‘unbreakable’ commercial quantum cryptographic systems.
Now working as director of product security at Silicon Labs, he discusses the steps required to make IoT devices properly secure.
Many of the things we use on a daily basis are becoming smart and connected to the Internet. The Internet of Things (IoT) will improve our lives by helping us reach our health and fitness goals, reduce resource consumption, increase productivity, and track and secure our assets. Many embedded developers realise the potential benefits of the IoT and are actively developing various applications, from connected home devices to wearables and home security systems. However, along with these benefits come risks. No one wants to design an application that’s prone to hacking or data theft. Undesirable events like high-profile hacks can lead to serious damage to brand images and loss of customer trust, and, in the worst cases, slow down or permanently reduce the adoption of the IoT.
In the race to accelerate time-to-market for connected device products, implementing proper security is inconvenient because it adds component cost, development effort and design complexity. At the same time, in some industries, it is not crucial to have adequate security. Rather, having adequate security is a key to not being hacked.
Major security and privacy issues and bad press after a vendor’s product has been hacked might temporarily or permanently slow down the adoption of IoT.
Many consumers are already skeptical about connecting even simple devices in our homes and daily lives, and some researchers and industry watchers believe the IoT is a security catastrophe waiting to happen. In fact, quite recently, there have been a number of highly publicised hacks that are gaining wide attention so one could argue that the catastrophe is already on its way.
Hacking of quantum cryptography
The current IoT security situation resembles that of quantum cryptography, often referred to as quantum key distribution. Unlike other key distribution schemes, quantum cryptography promises unconditional security based on the laws of physics. In comparison, most key distribution schemes rely on assumptions of the computational complexity of factoring large numbers or the discrete logarithm problem.
Although quantum cryptography was discovered in 1984, it took until the year 2000 before commercial cryptography systems were brought to market. Relying on single photons, a quantum cryptographic system is complicated to build, and yet time-to-market is of the essence.
In 2010, the first security loophole that completely broke the security of these quantum cryptography systems was published. Quantum cryptography is, theoretically, impossible to break, but, in reality, side-channels, or loopholes, were not considered during system design. Also, interestingly, no loopholes were discovered until a dedicated team was assembled to break into such systems. Up until the time this team was established, the entire industry was focused on making quantum cryptography systems robust and getting them to market.
The quantum cryptography analogy teaches us important lessons. Most notably, it shows how security is an ongoing process requiring a multidisciplinary approach to anticipate potential hacks. When striving to make something as complex as a quantum cryptographic system work, the same engineering team cannot possibly be able to understand how an attacker could break into the system. These are conflicting thought processes. Thus, a quality assurance and security team needs to be separate from the engineering team building secure systems.
Another key point is that the hacking of the quantum cryptography system surely has temporarily, if not permanently, reduced market acceptance of and belief in this technology. Thus, it would probably have been beneficial for the industry to invest more in security up-front, leading to a longer time-to-market and greater cost but also substantial gain in the end.
Anatomy of a secure IoT ‘thing’
The technology necessary to make the IoT secure already exists. But the lack of knowledge of how to implement this technology is usually the root cause of most security loopholes. A “secure” Internet-connected thing does not, however, guarantee a secure system. Nevertheless, developers should at least be aware of the following types of security.
Hardware-level security
The secure IoT-device has a number of security features. First and foremost, it uses asymmetric cryptography to perform secure boot and secure boot loading or over-the-air (OTA) firmware updates. The secure IoT-device also uses hardware cryptographic accelerators that are faster, more energy efficient and less vulnerable to side-channel analysis.
In a secure IoT device, the debug port is closed. If it is necessary at some point to reopen the debug port (in the case of a remote memory access or for other reasons), this is accomplished by an authenticated challenge response scheme using public key authentication.
While secure boot and boot loading prevent adversaries from modifying the program memory, the secure IoT device further restricts access to reading the program memory. This means devices that feature internal memory or on-board flash. In the case of external memory, it also means that the contents of the external memory are signed and encrypted.
Software security considerations
To ensure that the software running on the secure IoT device further enhances security, it must be hardened in critical sections. This means that it can resist skipping single instructions.
Examples include the secure boot signature check or a password signature check. This approach ensures that if an adversary is able to make the processor skip an instruction, it does not have security-critical consequences.
Furthermore, to avoid security issues in the code or a third-party library causing system-wide access, TrustZone for ARM v8M can be used to compartmentalise the various libraries.
Secure communications
Most integrated circuits communicate with other ICs, other IoT-devices, gateways and/or the cloud, and it is necessary to secure these communication channels. When communicating with other ICs, it means turning on encryption and authentication to ensure integrity and confidentiality. One example could be storing data on off-chip memory or the wired bus between sensors or communication ICs and the main processor.
When communicating with other IoT-devices, communication protocols such as ZigBee, Thread or Bluetooth low energy are typically used. Most of these protocols have security options, and it is important to turn on these security options.
Another important consideration is device commissioning. Once secrets have been deployed between the communicating devices, securing data traffic is straightforward. However, it is not straightforward to distribute the secrets.
For wireless devices, this typically involves the commissioning step in which the device is brought on to the wireless network, e.g., using Bluetooth to commission a connected light bulb to a ZigBee-based lighting mesh network. The options for commissioning depend on the system’s general capabilities, as well as a trade-off between ease-of-use and security. Suffice it to say that the secure IoT-device does not compromise security. In addition, the secure IoT-device uses TLS/DTLS to establish secure end-to-end connections to the cloud.
Application layer
The application layer might be on the device, in the cloud service or a combination of the two. In many applications, it is necessary to have password protection, typically in the application layer. The secure IoT-device forces the user to change the password and blacklists the most frequently used passwords. If possible, the device can even enforce two-factor authentication.
System considerations
From a system point of view, a number of seemingly harmless subsystems can add up to an insecure system as a whole. Therefore, to make a secure IoT-device, there are few assumptions for implementing security within each subsystem. Each subsystem’s security is independent or minimally dependent upon the other subsystems’ security.
It is necessary for developers, device makers and service providers involved in the IoT ecosystem to accept the costs and time-to-market delays of implementing effective security at all levels within the IoT, from device to cloud, and from the beginning of each development effort. Concerted efforts to implement security throughout the IoT will help prevent devastating security loopholes, resulting bad press, and a market that might not want to invest in IoT even when the loopholes have been closed.
Lars Lydersen, director of product security, Silicon Labs, was a part of the team that broke into ‘unbreakable’ commercial quantum cryptographic systems.
Currently, he has shifted his focus to classical embedded security systems and works at Silicon Labs in Oslo, Norway.
Lydersen holds an MsC in electronics and a PhD in quantum cryptography from the Norwegian University of Science and Technology.
Now working as director of product security at Silicon Labs, he discusses the steps required to make IoT devices properly secure.
Many of the things we use on a daily basis are becoming smart and connected to the Internet. The Internet of Things (IoT) will improve our lives by helping us reach our health and fitness goals, reduce resource consumption, increase productivity, and track and secure our assets. Many embedded developers realise the potential benefits of the IoT and are actively developing various applications, from connected home devices to wearables and home security systems. However, along with these benefits come risks. No one wants to design an application that’s prone to hacking or data theft. Undesirable events like high-profile hacks can lead to serious damage to brand images and loss of customer trust, and, in the worst cases, slow down or permanently reduce the adoption of the IoT.
The IoT is often referred to as an industrial revolution. The number of connected devices will grow rapidly in the coming years. If there is any disagreement among analysts who follow the IoT, it is in the number of billions of devices that will be connected. The economic value to society is estimated to be in the range of $4-11 trillion dollars.
In the race to accelerate time-to-market for connected device products, implementing proper security is inconvenient because it adds component cost, development effort and design complexity. At the same time, in some industries, it is not crucial to have adequate security. Rather, having adequate security is a key to not being hacked.
Major security and privacy issues and bad press after a vendor’s product has been hacked might temporarily or permanently slow down the adoption of IoT.
Many consumers are already skeptical about connecting even simple devices in our homes and daily lives, and some researchers and industry watchers believe the IoT is a security catastrophe waiting to happen. In fact, quite recently, there have been a number of highly publicised hacks that are gaining wide attention so one could argue that the catastrophe is already on its way.
Hacking of quantum cryptography
The current IoT security situation resembles that of quantum cryptography, often referred to as quantum key distribution. Unlike other key distribution schemes, quantum cryptography promises unconditional security based on the laws of physics. In comparison, most key distribution schemes rely on assumptions of the computational complexity of factoring large numbers or the discrete logarithm problem.
Although quantum cryptography was discovered in 1984, it took until the year 2000 before commercial cryptography systems were brought to market. Relying on single photons, a quantum cryptographic system is complicated to build, and yet time-to-market is of the essence.
In 2010, the first security loophole that completely broke the security of these quantum cryptography systems was published. Quantum cryptography is, theoretically, impossible to break, but, in reality, side-channels, or loopholes, were not considered during system design. Also, interestingly, no loopholes were discovered until a dedicated team was assembled to break into such systems. Up until the time this team was established, the entire industry was focused on making quantum cryptography systems robust and getting them to market.
The quantum cryptography analogy teaches us important lessons. Most notably, it shows how security is an ongoing process requiring a multidisciplinary approach to anticipate potential hacks. When striving to make something as complex as a quantum cryptographic system work, the same engineering team cannot possibly be able to understand how an attacker could break into the system. These are conflicting thought processes. Thus, a quality assurance and security team needs to be separate from the engineering team building secure systems.
Another key point is that the hacking of the quantum cryptography system surely has temporarily, if not permanently, reduced market acceptance of and belief in this technology. Thus, it would probably have been beneficial for the industry to invest more in security up-front, leading to a longer time-to-market and greater cost but also substantial gain in the end.
Anatomy of a secure IoT ‘thing’
The technology necessary to make the IoT secure already exists. But the lack of knowledge of how to implement this technology is usually the root cause of most security loopholes. A “secure” Internet-connected thing does not, however, guarantee a secure system. Nevertheless, developers should at least be aware of the following types of security.
Hardware-level security
The secure IoT-device has a number of security features. First and foremost, it uses asymmetric cryptography to perform secure boot and secure boot loading or over-the-air (OTA) firmware updates. The secure IoT-device also uses hardware cryptographic accelerators that are faster, more energy efficient and less vulnerable to side-channel analysis.
In a secure IoT device, the debug port is closed. If it is necessary at some point to reopen the debug port (in the case of a remote memory access or for other reasons), this is accomplished by an authenticated challenge response scheme using public key authentication.
While secure boot and boot loading prevent adversaries from modifying the program memory, the secure IoT device further restricts access to reading the program memory. This means devices that feature internal memory or on-board flash. In the case of external memory, it also means that the contents of the external memory are signed and encrypted.
Software security considerations
To ensure that the software running on the secure IoT device further enhances security, it must be hardened in critical sections. This means that it can resist skipping single instructions.
Examples include the secure boot signature check or a password signature check. This approach ensures that if an adversary is able to make the processor skip an instruction, it does not have security-critical consequences.
Furthermore, to avoid security issues in the code or a third-party library causing system-wide access, TrustZone for ARM v8M can be used to compartmentalise the various libraries.
Secure communications
Most integrated circuits communicate with other ICs, other IoT-devices, gateways and/or the cloud, and it is necessary to secure these communication channels. When communicating with other ICs, it means turning on encryption and authentication to ensure integrity and confidentiality. One example could be storing data on off-chip memory or the wired bus between sensors or communication ICs and the main processor.
When communicating with other IoT-devices, communication protocols such as ZigBee, Thread or Bluetooth low energy are typically used. Most of these protocols have security options, and it is important to turn on these security options.
Another important consideration is device commissioning. Once secrets have been deployed between the communicating devices, securing data traffic is straightforward. However, it is not straightforward to distribute the secrets.
For wireless devices, this typically involves the commissioning step in which the device is brought on to the wireless network, e.g., using Bluetooth to commission a connected light bulb to a ZigBee-based lighting mesh network. The options for commissioning depend on the system’s general capabilities, as well as a trade-off between ease-of-use and security. Suffice it to say that the secure IoT-device does not compromise security. In addition, the secure IoT-device uses TLS/DTLS to establish secure end-to-end connections to the cloud.
Application layer
The application layer might be on the device, in the cloud service or a combination of the two. In many applications, it is necessary to have password protection, typically in the application layer. The secure IoT-device forces the user to change the password and blacklists the most frequently used passwords. If possible, the device can even enforce two-factor authentication.
System considerations
From a system point of view, a number of seemingly harmless subsystems can add up to an insecure system as a whole. Therefore, to make a secure IoT-device, there are few assumptions for implementing security within each subsystem. Each subsystem’s security is independent or minimally dependent upon the other subsystems’ security.
It is necessary for developers, device makers and service providers involved in the IoT ecosystem to accept the costs and time-to-market delays of implementing effective security at all levels within the IoT, from device to cloud, and from the beginning of each development effort. Concerted efforts to implement security throughout the IoT will help prevent devastating security loopholes, resulting bad press, and a market that might not want to invest in IoT even when the loopholes have been closed.
Lars Lydersen, director of product security, Silicon Labs, was a part of the team that broke into ‘unbreakable’ commercial quantum cryptographic systems.
Currently, he has shifted his focus to classical embedded security systems and works at Silicon Labs in Oslo, Norway.
Lydersen holds an MsC in electronics and a PhD in quantum cryptography from the Norwegian University of Science and Technology.
