Assuring the security of any hardware device is a hard problem. The complexity of current systems and the interconnected nature of most devices create a broad attack surface in which bad actors can exploit a device for different purposes, including to obtain confidential information, for direct financial gain, to deny the correct operation of a system, or to gain an advantage against an adversary. Depending on the device, not being able to secure it properly can have catastrophic consequences.

In particular, Internet-of-Things (IoT) devices have increasingly been the target of malicious attacks. In May 2019, a variant of the Mirai botnet was found using different exploits to target IoT devices, including routers. In August 2019, Microsoft warned that hackers working for the Russian government have been using printers, video decoders, and other so-called IoT devices as a beachhead to penetrate targeted computer networks. Moreover, in December 2021, more than 300,000 MikroTik routers were still unpatched after years of exploits that are used to turn them into parts of botnets.

At the same time, IoT devices are becoming more capable and pervasive. First responders, military personnel, medics, and others in the field are increasingly using IoT devices to execute missions, especially in support of operations at the edge. In these types of environments applications, data, and computing power are pushed to the edge of the Internet, in close proximity to mobile devices, sensors, and end users. Being relatively cheap, small, and easy to deploy, IoT devices provide many useful capabilities at the edge, including environment monitoring, surveillance, data streaming, and acting as intermediaries to enable direct communication between parties. In this blog post, we discuss challenges for using IoT devices at the edge, as well as several approaches to IoT security at the edge.

IoT Security Challenges at the Edge

There are many security challenges related to IoT devices that are not as frequent in other types of devices. Some of these challenges are due to the low-cost and high-volume nature of these devices, and some due to the processes and quickly changing technologies that are used to build them. Key challenges include

• Not all device manufacturers follow secure development practices.
• Not all devices allow installation of software updates, which results in obsolete software running on them.
• The dynamic and rapid nature of the market results in inconsistent installation of security patches, especially for retired or older versions of products.
• There are few IoT security standards that are tailored to and implemented by IoT devices.

Moreover, IoT devices at the edge face other challenges that apply only to these environments. Network connectivity at the edge is limited and sporadic, which makes it particularly hard to keep these devices up to date. At the humanitarian edge in which first responders and other emergency personnel operate, IoT devices may need to be deployed with little planning and in unsecured areas, which makes it easy for bad actors to interfere with their operation. At the tactical edge where military personnel execute missions, there will likely be malicious parties trying to gain access to these devices, which may be deployed over a large physical area with no direct supervision. The challenges inherent to IoT devices make these situations even more susceptible to attacks.

There are various ways to try to address these challenges. One option is to create or extend standards to improve security of IoT devices, especially at the edge. This option would require IoT devices to implement these standards. Another option is to assume that off-the-shelf IoT devices may be vulnerable or untrusted, and to perform runtime monitoring and enforcement of security policies for access to these devices. We will discuss our work on both approaches in the following sections.

AAIoT: An Example of a Standards-Based IoT Security Approach

There are currently no widely accepted standards for authentication and authorization for IoT devices. A current standards proposal is Authentication and Authorization for Constrained Environments (ACE), which is a protocol being developed by a working group in the Internet Engineering Task Force (IETF). This group is adapting the existing OAuth 2.0 protocol, which is widely used by industry, to work with constrained devices with limited resources such as memory and processing power, as is the case with IoT devices.

However, ACE does not take into consideration the challenges of humanitarian and tactical edge scenarios. Our SEI project, which we call “Authentication and Authorization for IoT Devices in Disadvantaged Environments” (AAIoT) focuses on addressing two gaps of the ACE protocol: (1) bootstrapping client and device credentials and (2) authorization revocation for compromised devices. We extended the ACE protocol to address these gaps:

• Bootstrapping of Credentials: By definition, bootstrapping of credentials is out of scope for ACE because of the heterogeneity of IoT devices. However, in disadvantaged environments, not including bootstrapping—exchanging credentials used to set up secure channels to communicate between devices—as an integral part of the process is risky because client and device capture and impersonation are likely and of high impact. In our solution, we defined a process where a QR code physically associated to a device contains a pre-shared key (PSK) that would be scanned during the pairing procedure between a client and a device, to securely generate and exchange keys. This process allows for pairing in the field but requires the IoT device to have the capability of receiving and storing new credentials.
• Authorization Revocation: The ACE protocol assumes a stable connection between an IoT device and an authorization server, which authorizes third parties to access the IoT device by providing them with an access token that expires after a set time. In disadvantaged environments devices may be disconnected from an authorization server for longer periods of time. As a result, expiration times would need to be longer than usual to guarantee continued access. If an IoT device is compromised, however, it is critical to let all parties know that they should no longer have access to resources on that IoT device. We therefore extended ACE by defining a process for token revocation (which is not currently supported by ACE) in which the different parties can contact the authorization server to check if a token is still valid. This work has led to a new proposed extension to the ACE standard for token revocation.

In addition to validating the ACE protocol extensions, we developed the prototype shown in Figure 1 below.

One disadvantage of this approach is that an IoT device must implement the ACE protocol, and the extensions we defined, to take advantage of the solutions described. ACE is not yet an approved protocol, and even when it is, it could take a while for it to be widely adopted. Thus, other types of solutions that can work with commodity devices should also be considered. In the next section, we will look into this.

KalKi: An Example of a Runtime Enforcement IoT Security Approach

When integrating commodity IoT devices into existing networks, there is a high likelihood that some of these devices may not implement any security protocols or may have unpatched vulnerabilities. It is even possible for one of these devices to be compromised at manufacturing time, and thus already have malicious code on it (i.e., a supply-chain risk). However, being able to use commodity IoT devices is an advantage at both the humanitarian and tactical edge for quick response to changing missions and environments. To protect the devices from external attacks and the networks from potential attacks from these commodity devices, a solution is needed that does not require changing the software on the device itself. The KalKi platform is one such solution.

KalKi is a software-defined IoT security platform that moves security enforcement to the network, thereby enabling the integration of commodity IoT devices, even if they are not fully trusted or configurable. KalKi leverages software-defined networking (SDN) concepts to act as a flexible intermediary between these devices and the network they are connecting to, ensuring that both are protected. This protection is done through the definition of a policy model for each device type, which can ensure that protections are customized to cover each device’s specific vulnerabilities and shortcomings. The KalKi system also allows the user to easily change these policies if new vulnerabilities are found in a device model, or if the environment they must connect to requires specific policies.

KalKi uses information from the network traffic to and from a device, as well as from sensor data collected by a device, to detect both cyber and physical threats. This approach allows the system to detect potential tampering with an IoT device, as well as network-based attacks to or from a device. The security policies for a device can be combined to monitor for different types of attacks or unexpected states and react to stop an attacker.

The network monitoring and security measures of the KalKi platform are handled by µmboxes (pronounced “micro-m-boxes”), which are small software modules that implement network function virtualization (NFV) functionality. NFV allows software implementation of functions traditionally performed by dedicated hardware, such as a firewall or an intrusion-detection system (IDS). Moreover, NFV allows easy isolation and modularization of different types of network monitoring and reactions, which we encapsulate in µmboxes.

In the KalKi platform, µmboxes are implemented as containers that can be easily chained together to monitor for different threats in different ways or to protect a device or a network from different types of attacks. All traffic to and from a device goes through a set of µmboxes deployed on a KalKi node called the data node. This set of µmboxes can be different for each device, depending on its specifications.

Besides having different µmboxes and general policies for each device, a KalKi node called the control node also maintains a security state for each device. By default, this state can be normal, suspicious, or under attack. Security policies can be associated to each security state for each device, so that a different set of µmboxes is deployed for each security state. The control node collects all information from µmboxes and sensor data and can trigger changes in the security state based on the configured policies. The control node sends commands to the data node to set up the proper µmboxes and sets of network rules based on the new security state.

After performing field tests based on realistic scenarios, we realized that the KalKi platform also had to be flexible in its deployment structure. We made changes so that KalKi can be set up in multiple ways, combining the control and data nodes if required, or installed on constrained hardware, such as on a Raspberry Pi.

We conducted experiments to test the system that showed that Kalki was able to properly handle the network threats that it was configured to detect. Additional tests showed that the container-based nature of µmboxes made it easy to scale up to several dozen devices being protected by the same KalKi nodes without a decrease in reaction times.

The Future of IoT Security at the Edge

Even though the approaches described above present two useful ways to secure IoT devices at the edge, much work remains, especially as IoT devices and attackers become more sophisticated. Some areas of continued interest to us include

• There are components of a security platform that if compromised would invalidate all protections, such as the set of policies in Kalki or credential storage in any security solution. The SEI is working on modular trusted frameworks, such as überSpark, that can implement low-level constructs to isolate and secure these critical parts of a system. These constructs prevent tampering even if an attacker has physical access to a node.
• Artificial intelligence and machine learning techniques can be used to automatically detect malicious IoT behavior. These techniques could be used to identify combinations of network traffic and sensor data that seem suspicious, and thus create policies to keep the network safe without the need of manual analysis of all possible attack vectors.
• Updating the firmware of an IoT device securely is a complex challenge, and IoT devices at the edge face all the challenges of a disadvantaged environment, as well. We are interested in developing a secure peer-to-peer protocol to distribute firmware updates on a network of constrained IoT devices that is reliable, efficient, and secure by using standard firmware image formats, such as the one defined by Software Updates for Internet of Things (SUIT) and extending existing distribution protocols.

If you are facing some of the challenges discussed in this blog post or are interested in working on some of the future challenges, contact us at info@sei.cmu.edu.