by Christophe Buffard, Principal System Architect, Kudelski IoT
Security has been somewhat of an afterthought for many IoT applications but as volumes scale, the attractiveness and value to hackers will as well. Recent attacks such as the Florida water treatment facility, the Garmin attack, and the Solarwinds hack are elevating the need for standards and regulation for IoT security. In response to this the National Institute of Standards and Technology (NIST) have issued NIST.IR 8259 series to provide guidance for federal agencies and IoT device manufacturers on defining IoT cyber-security requirements. This article will give an overview of these new standards and regulations and how to ensure your IoT solutions or devices are going to meet the requirements.
NIST defines an IoT device cyber-security capability core baseline, which is a set of device capabilities generally needed to support common cyber-security controls that protect an organization’s devices as well as device data, system and ecosystems. Many IoT devices interact with the physical world in ways conventional IT devices usually do not. Many IoT devices cannot be accessed, managed, or monitored in the same ways as conventional IT. NIST.IT 8228 defines an IoT device as having at least one sensor for interacting directly with the physical world and at least one network interface or connectivity (e.g. Ethernet, Wi-Fi, LTE, LoRaWAN, Bluetooth, UWB, etc.) for interfacing with the cloud or other infrastructure. NIST IR 8259A is a starting point to use in identifying the necessary cyber-security capabilities for new IoT devices.
NIST defines 6 capabilities:
The device identity is actually a chain of identities bound at various device lifecycle stages that offers operational and functional flexibility. Depending on the IoT device's security requirements and because there is not a one-size-fits-all approach, a multi-layer identity provides the highest level of security.
The minimum requirement is an immutable identity at the device level, managed by the device maker or the module manufacturer. This layer allows customers to identify devices. This identifier should be available at the logical level, i.e., via an API, but it should be available at the physical level and printed on the device. Note the physical identifier and the logical identifier can be the same value.
The identifier helps to identify the device consistently and uniquely, and can be used to support vulnerability management, access management and incident detection. While many technologies or connectivity specifications call for unique identifiers it is common to encounter duplicate identifiers.
The device configuration facilitates access control to restricted areas of the device's software. An IoT device's software can be configured according to the needs of its deployment; the same device might report data more or less frequently, for example. This data report frequency has consequences on the bandwidth used by the device and such configuration can be modified after the IoT device has been deployed, but proper security measures and tools should be in place to restrict change to this device configuration. Only authorized entities should have the ability to modify the device configuration.
More generally, the configuration change is required for cyber-security, interoperability, privacy, and usability. Without a device configuration capability, an authorized entity cannot customize a device to meet its needs and perform new integrations. It is also important to have the capability to rotate or update keys or unique identifiers in a device by authorized entities.
The purpose of the data protection capabilities is to provide the ability to protect data being exchanged between a device and an application that consumes that data. The protection works in both directions, upstream and downstream. The data protection uses well-known and proven cryptography, which ensures secrecy, authenticity, and integrity. This capability is also used to protect the data stored in the device (data at rest). This protected data will only be accessible by the device that has generated the data, i.e. this data can't be decrypted by another device or a remote server.
Access is restricted to available interfaces and services. Access permissions can be adjusted for a given application running on the IoT device, assuming that multiple applications may be running on the device. The management of interfaces and service can be limited not only to their availability but can also be limited in the way the applications are using these interfaces and/or services, such as the number of times in a given period, the amount of data, the number of attempts to access these interfaces/services or depending on the device state. Software updates could also be controlled by enabling or disabling this capability.
A remote software update via a network download or a local software update via a removable medium is the capability to update new software on an IoT device to add functionalities, fix issues, or secure the device. This capability is not necessarily present on all IoT devices; some IoT devices might be very simple IoT devices that are economically not suited for adding such capability. The software update includes an authentication of the image or firmware so that only authorized entities can update the device.
NIST 8259A allows for rolling back updated software to a previous version, although security recommendations don't recommend such a rollback mechanism, which can be used to roll back to legitimate and authenticated older software that is compromised. The need for a rollback to a previous version in case of a major issue can be overcome by an update of a later software version that makes this software version the latest one. This software update capability can also include a notification mechanism, and it can be managed by a Device Management system.
The cyber-security state awareness capability authenticates the device hardware and software configuration to a remote system. The goal of this is to enable a remote system to challenge or to determine the level of trust in the IoT device's integrity. This can identify unauthorized changes to the device software and hardware, including tampered-with software or hardware change.
NIST.IT 8228 capabilities focus on the device, but in a complex IoT service, the IoT device sends data to a back-end. So far we have been describing what the needs are to secure a device, and the need to encrypt data sent to the back-end, but the back-end security is not tackled in the NIST document.
Some NIST capabilities require configurations, or data, sent from a back-end system to the device. The back-end should follow some important security recommendations too. Development teams focus on the functional requirements of the system they design based on what is intended to do, while the attackers, on the other hand, are more interested is what an application/service can be made to do and operates on the principle that any action not specifically denied is allowed. The back-end system should performed verification such as
To name a few, basically all data received and sent needs validation, all data received needs authentication and integrity verification. A session management mechanism to protect from things like replay attacks is also important. Access control will limit what any other actors can make the device do. Error handling is often left out of the security scope but it is important to manage error handling in a way that no useful information that could provide system details or a session identifier or any other means that will helps an attacker.
Some of these capabilities are partially brought to the device by a backend system. Some of the supporting capabilities of the backend system are described here.
The backend system sends either a new or updated configuration to the device to modify the device state. The backend system also targets the device or device group to which a newly updated configuration will be applied.
The backend system has a snapshot of the device's state, so a new configuration can be applied to devices that meet certain conditions, for example. Security health can be checked against a device's known snapshot and can determine if a device was modified (e.g. software or hardware modification).
The backend system can retrieve the IoT device state by retrieving relevant information, can update/set a value on the IoT device state by sending a new value, can create a new management object that represents a new interface or a new service in the IoT device, or can delete an interface or a service on the device.
This backend system is used to set up a software update campaign based on different criteria and offers a signing service for this software update.
This system can update a device's IoT state by reading values---a value is any data that the device management system would like to read and/or modify---of the IoT device or by receiving value from the IoT device, or by notifications sent from the device.
Finally, this backend system or one of its sub-systems is in charge of rotating the IoT device keys. The IoT device keys can be a key like a symmetric key or a certificate, which in this case is a key pair. A key rotation or a key update (same applies to certificates although the process can be more complex) can be triggered if:
What do these capabilities mean, how can they be implemented, how is compliance ensured, and what is required at the device level? Developing all of these capabilities into a device and having the associated back-end to manage the devices and capabilities with a high level of service level agreement (SLA) can be difficult for some companies to find the expertise or to justify the development time and cost. Kudelski IoT has been developing their Kudelski IoT keySTREAM system for more than two years but have decades of experience managing similar requirements in the pay TV industry. Kudelski has had to deal with security breaches, managing countermeasures against hackers, revoking/refurbishing devices, and remote feature authorization across hundreds of millions of devices for more than three decades. keySTREAM integration into the device ensures compliance with the new NIST standards and guidelines ensuring a successful device management and security lifecycle.
The keySTREAM system has been architected to ensure optimal options that consider overall device cost, security requirements, and battery lifetime. Multiple different integration options are available to trade off different device and system requirements.
Security breaches of IoT devices and solutions will make security a key differentiating feature as IoT volumes scale over the next 18 months. The NIST standards and regulations will quickly move into hard requirements for many IoT devices and solutions.
The NIST Cyber-security for IoT program focuses essentially on the device, but as shown above, the application of the cyber-security capabilities requires one or more back-end systems which manage these capabilities in a dynamic way. If the IoT devices are very limited in the functionalities that they expose or if the connection can't sustain the required protocol to manage the device, then the IoT device configuration needs to be defined and applied during the device manufacturing process. In this case, the device hardware also needs some attention. The use of obfuscation, OTP, ROM memory and a secure element to achieve the expected level of security defined in the NIST Cyber-security for IoT program becomes crucial. In particular, the immutability of the ID and the secrecy of the keys used in the IoT device are of prime importance because of the lack of ability to carry out a configuration changes down the road.
[1] To take one example, LoRaWAN specifies a unique ID namely the DevEUI that is a global end-device ID in IEEE EUI64 address space that uniquely identifies the end-device, but in practice some of the device manufacturers do not respect this which potentially leads to a collision of DevEUI IDs.
Kudelski IoT is the Internet of Things division of Kudelski Group and provides end-to-end IoT solutions, IoT product design, and full-lifecycle services to IoT device manufacturers, ecosystem creators, and end-user companies. These solutions and services leverage the group’s 30+ years of innovation in digital business model creation; hardware, software and ecosystem design and testing; state-of-the-art security lifecycle management technologies and services and managed operation of complex systems. For more information about Kudelski IOT, please visit www.kudelski-iot.com.
The Kudelski Group (SIX: KUD.S) is a world leader in digital business enablement technologies that encompass digital content security, cybersecurity, and IoT.
NAGRAVISION provides end-to-end convergent media solutions to the digital entertainment industry including services and applications requiring access control and rights management to secure the revenue in digital television, internet, mobile and interactive applications.
Kudelski Security is an innovative, independent provider of tailored cybersecurity solutions to help enterprises and public sector institutions assess risks and vulnerabilities and protect their data and systems.
Kudelski IoT provides end-to-end solutions, IoT product design, and full-lifecycle services to IoT device manufacturers, ecosystem creators and end-user companies.
The Kudelski Group is headquartered in Cheseaux-sur-Lausanne, Switzerland and Phoenix (AZ), USA with offices in 32 countries around the world. For more information, please visit www.nagra.com.
