Your IoT device wants to join my network

How do I know if your device is trusted?
What do we mean by trusted?

.. and how do I provide you/your device with the network credentials to access my network in the most secure manner?

These are some very real problems the new NIST special publication on IOT networking is trying to address with (to give it its full title) Trusted IoT Device Network-Layer Onboarding and Lifecycle Management (NIST SP 1800-36)

The size and shape of the problem

IoT security is in a bad way. We know it must be bad because many countries have introduced specific legislation to address the problem. Indeed the very existence of The IoT security foundation as an organisation, it testament to the breadth and depth of the problem.

It is worth reminding ourselves just why IoT Security is so hard to solve.

  1. They are cheap – cost pressures often force the price of device down to the level that security considerations deprioritized
  2. They are always on – IoT devices share many characteristics with internet servers. They tend to be always on (running in the background), are typically easy to connect to (so they can do their job)
  3. They are easily forgotten about… once running they can often disappear. You will only notice them when you do a network scan
  4. Provisioning them is hard – because they often have no user interface of their own, the mechanism of attaching them to the network can be complex. Also in many cases, there can be many 100s or 1000s of devices, so this same provisioning problem must be scalable .

How to we fix the problem

Problems like this are hard to fix; there is no silver bullet, but there are practical things we can do, if we act collectively. This is in part the ambition of the Trusted IoT onboarding activity. Specifically the following challenges are in scope.

  1. Provision IoT devices with unique network credentials: allowing many devices to share the same network credentials is a bad idea. The network security is reduced to security of the weakest link. Where this weakest link is an IoT device, this is not very secure at all.
  2. Provision networking credentials, with minimal use interaction: we need the process to be both simple for end users and scalable for enterprise users
  3. Provision networking credentials conditionally: make sure there is a “trustworthiness” threshold in place before we add a new device to the network. Don’t just allow anyone in.
  4. Kick them out if they misbehave. You don’t just do security on the inboard. It needs to be continuously monitored and continuously enforced. This is of course one of the fundamentally tenants of zero trust.

And specifically….

This work follows the typical pattern for NIST projects. It brings together a list of collaborators who work together to produce concrete recommendations and and working systems which clearly demonstrate some movement towards the end goal.

The special publication (SP 1800-36) Trusted IoT Device Network-Layer Onboarding and Lifecycle Management has a broad set of collaborators (Aruba (HP), CableLabs, Cisco, Foundries.io, Kudelski IOT, NquiringMinds. NXP Semiconductors. Open Connectivity Foundation (OCF), Sandelman Software Works, SEALSQ, a subsidiary of WISeKey, Silicon Labs).

Each has worked on one of more “builds” where each build demonstrates critical features of the IOT onboarding and ongoing lifecycle management process.

Device specific network provisioning

The knotty problem of provisioning network credentials uniquely to each device was addressed by building out of existing work. Across the multiple demonstrators, two different board brush, approaches were used IETF BRSKI Bootstrapping Remote Secure Key Infrastructure and WIFI Easy connect. Both are mature preexisting standards, and both considerably simplify the technical challenges, in getting the network credentials to the device.

The methods employed strongly encourage the use of EAP-TLS certificates. This is a major phase shift from the common password based approaches in use today. Firstly, each device has its own credential; reducing the network’s attack surface. Secondly the handshake is certificate based, making it much easier to protect the “secret” used to onboard.

Both methods employ a handshaking that allows the candidate device to transition from an restricted onboarding state (where the device can only see what’s needed to negotiate access) to an operational state (where the device is elevated to have full access to the network.

Crudely, this mirrors the classic “captured portal” flow, you commonly experience when getting on a hotel/train/plane wifi. Initially get access, but can see anything, but the (captured) web page. The system authenticates you, by asking for your email address or credit card or worse. And when the handshake is complete you are elevated to full access. The concept is similar, but for an IoT device, with no browser involved, and a lot better!

Policy

Each of the onboarding approaches includes an enhanced method of evaluating and enforcing network policy. Different approaches are used in each instance. Indeed, different use cases require different strategies. But each is more sophisticated than the primitive policy of do you have the password? And therefore a substantial move towards better security.

Some examples of these more sophisticated networking policies that are implementable with the IoT onboarding flow are.

  1. Does the manufacturer recognise the device: by providing flows that allow the device to communicate its identity to the network owner, and allowing the network owner to validate claims of provenance with the originating manufacturer, we can remove threat posed by untrusted manufacturers and grey market goods.
  2. Does the network owner recognize the device: there are many methods by which this can be done in practice, but the ability to reconcile a networking attach-event, with a purchase-event, e.g. do you have a receipt? Is there evidence of ownership? Is an elegant but effective method to further secure the onboarding process.
  3. Does the device offer security assurances to build trust? Two very specific examples that are becoming relevant in the evolving legislative landscape a) can the device offer a test/compliance certificate – as is now being asked for by some justification or b) can the device provide an SBOM descriptor, which allows the system to do some crude vulnerability analysis before onboarding.

These examples are just illustrative. But we feel this approach is a powerful, but extensible method for deploying trustworthiness checks at the all-important onboarding step.

Continuous assurance

Building on this, trustworthiness policy evaluation the demonstrators provide clear illustration on how to implement continuous assurance at a practical level. One of the best examples we have for this is the dynamic MUD enforcement method.

MUD (Manufacture usage descriptor ) is an existing standard that allows a device manufacturer to assert what they think is the typical behaviour for their device (a security statement of least privilege). A webcam for example will typically just allow streaming to a single IP and point and may be the occasional reconfiguration through a web interface. It should not be pursuing the network, doing internal network scans or contacting bitcoin mining infrastructure.

In the IoT onboarding demonstrators, we show how this is implemented in practice and how these MUD tests can be incorporated into a broader suite of trustworthiness tests. Simply:

  1. The device declared is MUD assertion at point of onboarding
  2. The network queries the device intent and stores it for future use
  3. The network monitors the behaviour of the device in the background and reconciles it with the MUD intent
  4. If an anomaly is detected, the network revokes the device, removing it as a future threats the network

This overarching pattern can be adapted for any of the other relevant trust policy evaluations e.g. a new CVE has been identified for this class of devices, a testing certificate for this device has been revoked, or the manufacturer has gone out of business and its update servers are no longer managed.

Factory provisioning

Finally, we need to consider Device Identities. Device Identities are a crucial security foundation on which many higher order protocols must depend. If we don’t have confidence in the uniqueness and provenance of the device, what can we do with it reliably? The exchange of device identity information is a critical component of the onboarding flow for all of the builds. But an industry issue, often overlooked, is how the device identities get embedded in the device in the first place. It is a process that whilst common in industry, is often shrouded in secrecy, for reasons of supposed intellectual property, but more often because in reality obscurity is the only real security being used. The Trusted Onboarding documents shine a light on this issue. And go some way to outlining some of the options that exist in thai space, what the tradeoffs are, which hopefully leads to better working practics in the long term.

Next steps

SP 1800-36 is in final review, the external comment phase is closed and will be published imminently. An In-Person Industry Day is planned in the Jan Feb 25 time frame, at the NCCoE in Rockville MD. This will be an excellent opportunity to engage with the project collaborators and the NIST team , exploring opportunities to take this important work forward.

Trusted Networking is a foundational IoOT security technology. It addresses some very serious IoOT security weaknesses, with solid technology, much of which is already well proven, but brings it together in a way that is practical and easy to implement. For more information, or to engage with the team directly please visit  https://www.nccoe.nist.gov/projects/trusted-iot-device-network-layer-onboarding-and-lifecycle-management

.