In the last blog in our IoT device fleet management series, we explored device cybersecurity and introduced the concept of device provisioning. In this installment, we look at provisioning in more detail. Every cloud provider, from Amazon Web Services (AWS) to Microsoft Azure to Google Cloud Platform (GCP), offers its own proprietary mechanisms to manage authentication and device provisioning. That means provisioning flows vary and there is no single industry standard.
Despite this, you need the OTA platform and the cloud to coexist in a single ecosystem in order to manage the full cycle of IoT device fleets. So how can you create a system that establishes secure communication channels between the IoT core server and the IoT client device in the cloud environment?
There are a variety of provisioning approaches, including bulk, by claim and by trusted user. Here’s an overview.
Bulk provisioning allows for devices with similar configurations to be deployed as a group. The groups can be defined based on some characteristic common to all of the devices in a group, such as their functional role. Deployments can encompass many thousands of devices.
Provisioning by claim uses a bootstrap certificate (X. 509 certificate and a private key) that can be included on edge devices during the manufacturing process. The claim certificate is shared between all devices in a fleet. This poses a risk for the whole fleet. Device makers that use this approach must maintain a fleet provisioning template and AWS Lambda function with additional verification logic. The claim certificate must be protected and frequently audited to prevent misuse.
Devices must implement the logic necessary to publish and subscribe to fleet provisioning MQTT topics (MQTT is a standard messaging protocol for the IoT), accept the permanent credentials, and write the credentials to secure storage. The claim certificate will be exchanged for a real durable certificate once the mTLS connection is secured.
Fleet provisioning by claim should be used only when it is not possible to provision unique credentials in the device, and when the manufacturing supply chain is secured throughout by trusted individuals all the way from the contract manufacturer to the end customer. Devices that enter insecure channels, such as a via third-party distributor, should not use this approach.
Fleet provisioning by trusted user – in which the device’s credentials are never exposed to the manufacturing supply chain – is recommended when a high degree of security is needed. It is also appropriate when the manufacturing chain is not trusted or when it isn’t possible to provision devices in the manufacturing chain due to cost or technical limitations.
Here’s how it works. The device leaves the manufacturing facility with no unique credentials, and only trusted users are able to provision the device with its unique credentials. An installer uses a mobile application and authenticates with AWS, for example. Using the trusted user APIs, the installer receives a temporary X.509 certificate and a private key valid for five minutes.
Using the mobile application, the credentials are delivered to the device. The device connects to AWS IoT and exchanges the temporary credentials for a unique X.509 certificate signed with the AWS CA and a private key. During this workflow, the AWS resources including device name, policy, and certificate are set up in the AWS system.
Devices must have the ability to accept temporary credentials over a secure connection, such as Bluetooth Low Energy, WiFi or USB. Devices must implement the logic necessary to publish and subscribe to fleet provisioning MQTT topics, accept the permanent credentials, and write the credentials to secure storage. Device makers that use this approach must develop and maintain a mobile application that exercises the Trusted User APIs.
Regarding medical devices, some cloud providers such as AWS offer HIPAA-compliant options for IoT fleet management. AWS’ option for instance incorporates provisioning by claim and then by trusted user as a subsequent flow to identify devices in the system. This approach is an attempt to offer the best of both worlds.
In the final installment in our fleet management series, we’ll discuss how to choose the right system and explore popular solutions from leading providers including Torizon, Mender and Balena. For more on IoT fleet management, read 7 Reasons Fleet Management is Vital to IoT Success.