A persistent challenge in today’s IoT landscape is the ability for network administrators to identify a connected device and the network access required for its full functionality. While a knowledgeable admin can create specific access rules for each IoT device (or class of devices), this is almost impossible for the average home or small-business user. IoT devices can offer important benefits and capabilities to their owners, but too often come at the cost of a dangerously unsecure network for the average home user.

There’s an IETF draft document called the Manufacturer Usage Description Specification (MUD) which seeks to solve this problem. From the abstract of the draft document:

“The goal of MUD is to provide a means for end devices to signal to the network what sort of access and network functionality they require to properly function.”

Let's go over the basic MUD workflow that we might see in a home network:

1. The IoT device joins the network and emits a MUD URL.
2. The home router, acting as a MUD manager, goes to the indicated URL and gets the MUD file.
3. The MUD manager processes the MUD file and can create access rules based on what access the manufacturer recommends in the MUD file.

This is great! A device can now can tell the home router what it is and where to find information about the network access it needs. This allows the average consumer to use IoT devices while maintaining a more secure network. Even if those IoT devices are compromised by bad actors in some way, the signed MUD file maintained by the manufacturer won’t change. This prevents the exploited device from making any connections on the Internet that aren’t actually necessary, since the access rules will remain the same. While this doesn’t replace the need for manufacturers to update firmware when vulnerabilities are found, it should help to drastically mitigate any impact since the router would prevent any communication that’s not permitted in the original MUD file.

What happens if a device “lies?” Keep in mind that this whole process starts with the device emitting an accurate MUD URL. The draft document provides three ways for a MUD URL to be emitted without limiting potential MUD implementations to just those methods:

1. DHCP Option
2. X.509 Extension
3. LLDP Extension

Of the three options for emitting a MUD URL specified in the draft, the X.509 Extension is the most secure. If a device is compromised, the MUD URL emitted could potentially be changed for either the DHCP Option or the LLDP Extension. With the MUD URL pointing to a malicious MUD file, the access rules could be altered to allow malicious traffic. If the device is using the X.509 extension, the MUD URL is added to the certificate by the manufacturer when the IDevID is created or by another party in the supply chain when the LDevID is created. This means the MUD URL emitted by a device should not be changeable, even if the device is exploited. The generation of the IDevID or LDevID implies that the IoT device is making use of the IEEE 802.1AR standard.

The 802.1AR standard specifies a unique identifier which is cryptographically bound to a single device, along with the mechanism to authenticate the device’s identity. To make use of the 802.1AR standard, most devices use a Trusted Platform Module (TPM) to store cryptographic keys. In the case of a MUD URL, the X.509 extension is added to the certificate for the IDevID or LDevID, which is stored on the TPM by the device maker. This ensures that any device compromised after being added to a network can’t have the MUD URL changed (as the IDevID can’t be changed). This poses a problem for many IoT devices, as there are power, space, or cost constraints that make the addition of a TPM unfeasible.

Here is where the Device Identifier Composition Engine (DICE) architectures from the Trusted Computing Group would come into play. The DICE architecture is designed to enhance the security for devices with resource constraints; IoT devices without a TPM could securely store the cryptographic keys needed to make use of the IEEE 802.1AR standard. This would allow those devices to then use the X.509 extension in the MUD standard to emit the MUD URL.

The MUD standard could help solve many of the security concerns with the IoT ecosystem, but it will require the draft document to be finalized. Both IoT device and router manufacturers will then need to add support for the standard on their devices. Even though it won’t solve all security problems in the IoT ecosystem, MUD can help increase security for the average home by helping to create easy to use and locked down access lists on home routers.

Louis Creager is IoT Security Analyst at zvelo, a provider of cybersecurity solutions for web content, traffic and devices.

eletter-05-31-2018 eletter-06-01-2018