The internet of things (IoT) is no stranger to most of us at this point. IoT devices can be seen as belonging either to the consumer, medical, or industrial markets. Whether the device is a video doorbell, an insulin pump, or an industrial sensor, the user will face two significant challenges: 1) getting the device physically/logically connected to the network and 2) making sure that the device has the proper credentials to enable it to interoperate with other devices on the same network or with the server(s) that are expected to collect the device's data. These challenges can be largely grouped into a process known as provisioning.
The biggest challenge in the provisioning process is the ability to ensure that a device and the connection to the network/server are secure. This relies heavily on both asymmetric and symmetric encryption techniques and the existence of digital certificates.
In the case of asymmetric encryption, there is a mathematically related public/private keypair. If something is encrypted with the public key, then only the private key can decrypt it. This is as opposed to symmetric encryption, where the same key is used to both encrypt and decrypt the message. Symmetric encryption requires fewer resources (e.g., fewer bits in the key, which results in faster encryption) to achieve better security than with asymmetric encryption. However, symmetric encryption requires the keys to be exchanged in some way that can't be seen by an interloper. What is typically done is to use the destination's public key to encrypt a premaster key, send it to the destination and then the destination uses their private key to decrypt the premaster key and generate the shared session key. This is the way Diffie-Hellman key exchange enables the use of faster and stronger symmetric encryption using a handshake that leverages asymmetric encryption.
The first requirement for provisioning is that the IoT device has a unique identity mechanism. This can be a part of the device manufacturing process wherein an identity chip is part of the bill of materials, or what many microprocessor manufacturers are doing these days — burning a unique identity with public and private keys into the processor at manufacture. This is referred to as provisioning during the supply chain.
We can see that the basic steps being used for provisioning IoT devices either within the enterprise or with service providers such as Amazon Web Services, Google Cloud, or Microsoft Azure, all follow a similar process:
- Device Enrollment
Create a record at the server that includes metadata for the IoT device. That might include a serial number or other unique device identifier, location of the device, and other data that helps the enterprise using the IoT device to understand its role.
- Key Generation
If the IoT device has a unique identity chip such as a Trusted Platform Module (TPM) or otherwise has a set of public and private keys installed at manufacture time, then this key generation is already done. However, if a set of keys does not already exist, the installer can generate a set using tools such as OpenSSL. Or if one of the cloud providers is being used, the service provider will typically have a key generation mechanism. The public and private keys will need to be stored on the device, with the private key placed in some sort of protected storage to prevent it being read out of the device in the field. For security reasons, it is suggested that the keys be at least 2048-bits long or longer if RSA-based algorithms are used or 256 bits or longer for elliptic curve-based algorithms.
- Generate a Certificate
At activation time, the device generates a certificate signing request (CSR) and sends that CSR to a certificate authority (CA) for signing. The CA is typically a trusted third party such as Digicert, GlobalSign, or even the cloud service provider. The device sends its public key and some metadata in the CSR and the CA generates a secure socket layer (SSL) certificate (typically an X.509 certificate). It signs that certificate with the CA's private key before sending it back to the device. Once the device has a certificate, it can participate in a transport layer security (TLS) handshake that can establish an encrypted link to the server. Because the certificate is signed by the private key of a trusted third party, we can assert that the device that controls the private key associated with the public key in the certificate is known and trusted.
It is also possible to generate a “self-signed” certificate. If, for example, the device was manufactured in-house and used only by the manufacturer, there would be no need for an outside CA to certify it. Using tools like OpenSSL, the manufacturer could generate the public/private key pair and the certificate, and copy them to the secure storage on the device as the device comes off the manufacturing line.
- Provision the Device
With the keys and certificate, the device can now assert its identity to the service provider by initiating a secure link via TLS or the datagram version of TLS known as DTLS. The TLS/DTLS handshake establishes a symmetric encryption key that can be used for subsequent secure data transfer between the device and the service provider so the device can be enrolled, and the data stored in the record generated with the service provider in step 1.
The handshake is used to implement a secure key exchange to establish a symmetric encryption link. Once the link is established, data can be transferred from the device to the server without fear of compromise by cyberattacks. For example, man-in-the-middle (MITM) attacks, where an intermediary intercepts the communication in transit, will be prevented since the interloper lacks the symmetric key used in the bulk encryption. Newer versions of the TLS handshake (TLS 1.3) shorten this message exchange dramatically to support lower latency transfers from devices to the data collection systems.
Provisioning in Bulk
Up to this point, the provisioning discussion was focused on having a human in the loop for singleton or small numbers of devices. The security also largely focused on the use of encryption and the human being able to attest to the authenticity of the device by having taken it out of its original packaging. However, when working on industrial scales, this requirement of a human physically being involved is impractical.
For example, many of the newer smart buildings contain thousands of sensors, including ambient light sensors, air quality sensors, microphones to determine room occupancy, and temperature and humidity sensors, just to name a few. If a human had to provision each of these devices manually, it would quickly turn into a full-time job. However, the identities of these devices and their security credentials will need to be assured. So, how can devices be provisioned in bulk without human intervention?
First, we must understand that industrial IoT devices still have the two basic requirements that were discussed at the beginning. The operator will need to associate the devices with a network and verify the identity of the devices and their security before granting them access to the server or service provider that is collecting and analyzing the sensor outputs. The physical connection to the network will vary based on the communications media and being able to assert an identity will require the use of digital certificates. In order to support bulk provisioning, it is best to incorporate the public/private key pair and the device's certificate in the supply chain, so the device comes out of the box ready to generate the certificate signing request and handle the provisioning handshake.
Naturally, many IoT devices will be using a wireless protocol of some sort, especially if dealing with greenfield applications. There are a multitude of choices including cellular, Wi-Fi, Zigbee, LoRaWAN, SigFox, and more. However, if we are upgrading a legacy application, it is still possible that Ethernet, RS-485, ProfiBus, or many other older wired technologies, might be in use. In the case of the wired interfaces, gaining access to the network can be as simple as plugging the cable into the device. However, wireless protocols are somewhat more complicated.
If the connectivity is via a cellular connection, the provisioning is likely handled by the cellular provider in the form of a subscriber identification module (SIM) card or one of the newer embedded eSIM modules. When the carrier takes the device's International Mobile Equipment Identity (IMEI) identifier and associates it with a specific SIM/ eSIM in their internal databases, the carrier has a unique means to identify the device. This unique identity is used to validate the device as a legitimate member of the carrier's network and to provide provisioning to the device over the air. Therefore, by having a list of the IMEI numbers and their associated SIM/eSIM, all the devices can be activated/provisioned without further human intervention. This same sort of approach can be applied to other cellular-like wireless technologies such as LoRaWAN.
Technologies such as Bluetooth mesh, which is increasingly found in smart buildings, also have a built-in provisioning strategy based on the same concepts of a public/private key pair and a digital certificate embedded in the device. Through a well-defined provisioning protocol and associated security handshakes, a new device can be securely added to the network in a matter of milliseconds without human interaction. This same sort of provisioning scenario can be found across a number of IoT connection options.
IoT Provisioning Final Thoughts
Getting your devices connected and provisioned on your network requires some considerable thought to security and the provisioning process. Fortunately, with supply chain security credentials and new provisioning protocols and techniques, the process can be accomplished with a minimum of human interaction and significantly less time than was required in the past. Automated certificate generation and well-defined security protocols can ensure that our devices have a valid identity and will always use secure key generation and encrypted communications between themselves and the servers/service providers.
The major cloud service providers have put quite a bit of thought behind their provisioning mechanisms, with well-defined provisioning steps and protocols. Unfortunately, each service provider uses a different set of APIs and approaches. However, the general provisioning flow is the same between the vendors and can easily be automated for cases of mass deployments. There are also a multitude of companies that focus on IoT provisioning devices and automation approaches, if there are legacy or internal infrastructures needed for the enterprise. So, while everyone will need to consider the issues of provisioning at one point or another, be they consumer or enterprise, at least you will be able to capitalize on existing approaches and not have to blaze new trails.