Identifying the Internet of Things – one device at a time

As IoT movement pervades every facet of our lives, the pace of innovation in this field continues to grow. We are seeing novel uses of this technology that are very cool – we are also seeing a lot of implementations that are downright silly! However, most if not all, of these are very impactful. As we have seen in the past with agriculture or healthcare, IoT is moving fast and is here to stay. However, this being a classic case of trying to run before we’ve learned how to walk, IoT device developers often leave out the core component of any connected service in today’s world – security.

There are very few standards in place for IoT security – cyber or physical. Hence, a lot of IT standards are being modified or drawn upon to come up with reference architectures and security best practices for IoT security. Common among these frameworks is the need for a strong, unique and immutable identity for each IoT device. While there are various ways to establish this, industry analysts, major cloud platform providers, thought leaders and early adopters all agree that Public Key Infrastructure (PKI) is going to be the chosen mechanism for this, now and into the future. PKI itself has had to adapt and is now moving into the 21^st century with increased adoption, but also widespread application to a varied number of use-cases.

Core to a PKI-based infrastructure is a trusted third-party, a Certificate Authority (CA). CAs have existed for decades and today issue publicly (or privately) trusted credentials entities that need to prove their identity. As such, a digital certificate issued by CAs is a universally accepted identity credential on most digital platforms.

An important component or function of a CA is the act of ‘registration’ commonly performed by the Registration Authority (RA). The RA sits between the entity that is requesting an identity and the CA and essentially implements a layer of control and management over the verification of identity prior to issuance. It is responsible for checking that a particular public key belongs to the entity requesting a certificate for it.

Building a registration authority for the IoT

So how do we build a Registration Authority for the IoT?

First, we need to think of ways we can offer policy-based control to end-users who can define how exactly a device needs to behave for it to be considered an authentic device. Secondly, we need to apply this to a large common set of devices – this problem is exacerbated by the different provisioning environments that a device can be used in. We need to account for both greenfield enrollment (devices that are new or still being manufactured) as well as brownfield enrollment (devices that have already been deployed and are in use). Finally, we need to add ancillary layers like a configuration and rules engine, grouping and classification of devices, etc. This would create a Local Registration Authority or LRA and we could have deployment environment specific LRAs.

What could we use to define the authenticity of a device?

1. A pre-embedded Root of Trust (ROT)

Many IoT devices come with a pre-embedded identifier that was injected during manufacturing in a secure process. This could be a simply pre-shared secret like a key, a unique serial number, or another certificate, sometimes called a birth certificate. We could also use a hardware secure element embedded in the device – a Trusted Platform Module (TPM) or hardware based Physically Unclonable Function (PUF).

2. A device whitelist

We can upload a list of common identifiers, example a MAC address and thus create a whitelist of allowable devices which is then uploaded to the RA. The RA would then do a pre-issuance check against this whitelist.

3. Challenge-response

The RA could perform a challenge response check on the IoT device. For instance, the device would produce a public key. If this public key is on a pre-approved whitelist, the RA would then challenge the device to prove possession of the associated private key. A successful check would result in the device getting enrolled and being issued a certificate.

4. Behavioural signature

For IoT devices where we do not have a pre-embedded ROT, we could rely on less secure methods for verifying authenticity. For instance, we could use the behavioural characteristics of the device to determine and identify a specific or a class of devices. One method is to generate a hash of selected files in the files system and compare that to pre-computed hashes from a golden image – a sort of device fingerprinting.

5. Environmental checks

If we have even fewer options to rely upon for verifying authenticity, we could rely upon specific environmental characteristics within which a device is deployed. For instance, we could use a combination of the IP address to locate the geographic source of an incoming request (to the RA) and combine this with a time-window during which devices are likely to connect based on pre-programmed schedules. While not completely secure, this is more of a good-enough approach.

6. One-time trust event

Finally, we can perform a one-time trust event – basically we assume a device to be true and authentic once, to be able to perform a device enrollment and provision it with an initial device identifier or ROT. The closer this is done to the manufacturing stage, or earlier in the supply chain, the better it is. However, this can also be done for devices that are guaranteed to be deployed in a secure environment. To mitigate risks, we can even provision a temporary or one-time use key that cannot be used if the device leaves and returns to that environment and/or system.

As you can see we’ve provided a number of options that can be used to construct your own device RA service and the policies that can be configured to accept or reject a device as authentic. Each type of verification is different and usually a combination of several factors must be used to guarantee that a device is who it claims to be. Also, once registration is performed, depending upon the credential’s validity or ecosystem policy we may need to perform registration on a periodic basis.

Older IT standards like IEEE 802.1AR specify long-lived device certificates called Initial Device Identifiers (IDevID) that essentially never expire, are being adapted and adopted for Industrial Internet of Things (IIoT). Again, these are simply birth certificates and can only be used for identity verification. These are then used to bootstrap into more deployment ecosystem specific credentials called the Locally Significant Device Identifier (LDevID) that can be used for authentication, authorization, secure communications, etc. LDevID certificates are typically shorter lived.

Implications for the IIoT

IIoT has very specific challenges that a Device RA (DRA) or IoT-specific RA can help solve.

First, the sheer breadth of use-cases and physical environments that an IIoT system is deployed in makes it very challenging to have a universal identity mechanism for all of your connected devices.

Secondly, there are machines that have existed for many years, and will continue to function for decades more – and we then introduce newer devices into this ecosystem that are very different than their older counterparts.

This mash up of greenfield and brownfield devices mandates that we cannot have a completely new, rip-and-replace approach. We need to build systems and solutions that work with existing technology and management platforms and provide options to gracefully on board these older devices onto newer IoT platforms. Finally, we need to meld the IT and OT systems into one. Since IT is already very familiar with PKI based identities, this isn’t a problem on their side. However, we need to educate and create enough context and value around said solution so that it caters to OT users and persons as well.

As an example, let’s take a look at the Smart Electric Grid, and some of the work being done by the Wireless Smart Ubiquitous Networks (Wi-SUN) Alliance and their Field Area Network (FAN) specification. This is a wireless mesh network architecture that allows Smart Meters to talk independently to each other, as well as to head-end controllers (put simply). This leads to more resilient and highly available network that can dynamically route traffic in the case of any failures to critical nodes. Newer devices can automatically enter and exit a given network. This happens completely autonomously. Hence, it is extremely important here for devices to be able to talk with each other directly and authenticate one another without the need of a third party. A local, device specific RA service is the best solution for such a scenario.

As you can see, PKI is evolving, and we are now applying some of the core tenets of cybersecurity that are part of PKI, to IoT use-cases. Remember, there is no need to re-invent the wheel – in this case, simply to develop new ways of using it. The Internet of Things is still the internet – the same security principles that have safeguarded networks for decades will continue to do protect this ‘new’ internet. We simply must be cyber-aware and implement security from the get go.