IoT Device Security ChecklistAdvice
Colin Duggan tells the Device Chronicle that IoT device security is now a must for IoT projects. What must IoT leaders plan for?
Colin Duggan is the Founder and CEO at BG Networks and is working to ensure embedded devices have sufficient levels of cybersecurity. He has a background as an electrical engineer and has significant experience leading large teams in applications development, systems engineering, and embedded systems development. Colin draws on his extensive experience to provide a checklist guide on what IoT project leaders should look for when assessing IoT device security for their projects.
IoT device security by design
Colin’s first piece of advice is to consider IoT device security at the beginning of the design process and then through the product life cycle. Colin says “It is difficult to add security after the design has been completed. There are a number of reasons for this. Embedded systems have limited MHz, memory, and limitations of network interfaces on embedded processors. Security features can be added after the fact but usually will not close off all the vulnerabilities.”
Furthermore, once devices have been deployed in the field, security updates will be needed. No device is 100% secure and so a secure OTA software update manager such as Mender.io needs to be planned into the design to enable this capability. Some industries have been faster than others realising this necessity and in fact mandatory regulation enforces it on the automotive industry in Europe.
Colin says it is also important to develop a vulnerability disclosure and an incident response plan. Vulnerability disclosure plans are part of a law in the US concerning IoT devices purchased by the Federal Government, and a similar regulation is being considered in the UK for consumer devices.
Keys to IoT device security
At the end of life, keys should retire so they can’t be used by adversaries to exploit vulnerabilities. Colin shares an example from industry: SkyGo used aftermarket telematics units to set up its test bench and found active certificates in the software when performing security research on Mercedes Benz vulnerabilities.
Assess threats & risks in IoT device security
Colin believes that ideally a threat/risk analysis should be performed. In a process like this, you would start with an evaluation of the system. If the system is large, for example a car, then the assets that need to be given a particular level of protection need to be identified. When it comes to smaller systems such as remote temperature sensors, it’s far easier to identify what needs protection. IoT project leaders should, Colin recommends, follow these steps:
- Assess the risks
- Determine which risks need to addressed
- Define security goals based on the risks
- Based on these security goals define the security requirements for the IoT device
Take a look at TPM
IoT project leaders must also consider integrating the security features into the IoT hardware. They must consider processor security features and/or a Trusted Platform Module (TPM). A TPM as a stand alone device offers cryptographic functionality, secure key storage, and may include a small microcontroller core with memory. They are typically used for applications and use cases that need the highest levels of security such as ePassports, credit cards, and transportation cards. They are secure against direct physical and side channel attacks (e.g. EMI, power analysis to extract secrets).
Other hardware security
Most microcontrollers and processors also offer a wide range of security features. Colin says that ideally the decision on which processor to use would consider these security features as some processors offer more than others. The key features to look for in secured hardware include:
- Secure boot
- Crypto accelerators including symmetric and asymmetric crypto, hashing
- A dedicated processor core and memory for security operations such as the management and storage of secret keys
- Ability to lock I/O interfaces such as JTAG, UART, and SPI
- Features that can detect physical tampering
- Hardware support, such as ARM’s TrustZone, for a trusted execution environment
- Software tools and driver support take advantage of these features.
IoT device security
Then there are the security features to consider to include in an IoT device. Colin suggests that NIST provides a good reference point. Among a number of recommendations, NIST recommends that IoT devices have unique identification and configuration capabilities. You can find a full list of NIST recommendations here .
Secure boot and extension of the root of trust through the various aspects of software such as U-boot, the Linux kernel, and the rootfs where application software will be stored allows for secure device configuration. Consider secure boot automation tools which help with the implementation of secure device configuration by making it easy to develop a secure binary that will leverage secure boot features in a processor. This type of tool also generates keys and signatures needed for secure boot and the extension of the root of trust.
Protect Personally Identifiable Data
The IoT device must also support data protection. This is about encrypting sensitive data such as personally identifiable data (PII) which is protected in Europe by the GDPR regulation and controlling access to this data (e.g. passwords). There must be logical access to interfaces: This is about access management and passwords. In other words only people and other devices that are authorized can access the device. In the US, there are two states – California and Oregon with password laws. Care needs to be taken when selling an IoT device in the state of California. No matter where the company is located, that company is liable if the IoT device does not have a unique password or means of authentication that is unique to the user. .
On to OTA software updates
Software updates are essential for keeping IoT devices secure. Software such as Mender.io is required to be able to remotely update software on the IoT device. The reasons that software updates are so important is that no device is 100% secure. This is seen in SkyGo’s security research of Mercedes Benz vehicles. Mercedes has gone to great lengths to secure their automobiles but SkyGo was still able to find a number of vulnerabilities. Mercedes has a software update capability and was able to close the vulnerabilities in millions of cars within a couple days.
The update needs to be done securely and Mender.io does this where the Mender client running on the device authenticates the software artifact (the software update) before the software is downloaded to the IoT device and enabled. Also, updates should only be given to authorized IoT devices. See the Device Chronicle article on the Triangle of Trust™ . Mender.io supports multiple flows for client authentication using PKI cryptography and tokens. It is also important to encrypt updates. The channel that the software update is sent might not be secure and sensitive intellectual property in the form of IoT software could be stolen. Or the software, if downloaded in plain text, may be used to reverse engineer the IoT device by adversaries to find cyber security vulnerabilities. Multiple instances of this are seen in this DEFCON 27 presentation.
Cybersecurity state awareness
Colin also describes the importance of the ability to detect if a device has been compromised. If it has, then to be able to report this in a timely manner, and take the appropriate actions to respond and recover.
The NIST’s cybersecurity framework illustrates the key steps to take.
Detection of attacks while the device is running is done by Intrusion Detection System (IDS). It is important to have a robust IDS implemented on an IoT device as a majority of remote attacks on IoT devices are made while the device is running. These attacks typically take advantage of a software bug like a buffer overflow, many times having to do with the improper parsing of network packets. TCP IP stacks are notorious for being targets for security researchers as noted in this article in Embedded Computing.
Secure manufacturing is a critical aspect of IoT security. Colin advises that security key management and the signing of software are important considerations here. He points out that an IoT device that supports secure boot, extension of the root of trust and secure over the air updates, will have multiple secure keys or certificates. Some of these keys or certificates need to remain secret and protected either on the device or securely stored in the manufacturing environment and at the company for possible use in the future (e.g. key revocation). Furthermore, Colin recommends that a hardware security module (HSM) or secure PC be used in a manufacturing environment to load the keys to each device and to keep those keys protected. Unique keys should be provided to each IoT device as that lowers the value to an attacker of breaking into that particular device. If an attacker can extract a key from a single IoT device that allows them to break other devices then it is a high value target. There is motivation to put a significant effort into breaking into the IoT device and may use a side channel attack. We saw this as early as 2016 in the potential of malware to travel over Zigbee wireless networks to attack smart light bulbs.
In summary, take cybersecurity for IoT projects seriously, and plan security protection into the design of the IoT product so that you can anticipate vulnerabilities and seal them off from malicious actors over the lifecycle of the product.