IoT solutions need devices to perform some sort of privilege escalation to go from zero privilege to a fully registered and operational device in that solution. While going from no privilege to full privilege there should be discrete and planned steps. Each step used to gain privilege must itself follow the approach of least privilege. Additionally, there may be existing identity and privilege systems which must be incorporated into the IoT solution.
An IoT solution can manage the challenges of bootstrapping a device by deconstructing those challenges into a flow across two distinct concepts: a registration authority and a privilege escalator.
A registration authority is the component that validates expected certificates, tokens, or shared credentials received from the device and then returns solution credentials for use by the device. A registration authority will at least be a collection of policies dictating the ability of un-registered devices to subscribe or publish to defined topics on the server.
A privilege escalator enables a device with short-lived, lower-privilege credentials to share more attributes about itself or to exhibit proper behavior before obtaining higher-privileges in the solution. A distinct privilege escalation step also enables the injection of human approval into the privilege escalation process, if the solution requires.
Although there are situations where an implementation might combine registration with the ability to obtain fully escalated privileges, by breaking down the challenges as this design does, each challenge can be addressed distinctly, using new or legacy systems.
The Device Bootstrap design shown in the following diagram can deliver this functionality.
When implementing this design, consider the following questions:
If no, then the device must have a mechanism to receive a secure token or certificate after the device is manufactured. Such a mechanism could involve configuring a device over a Bluetooth Low Energy (BLE) connection from a mobile application. This has the added advantage of being able to immediately associate a device to a customer while they are logged into a mobile application.
If yes - with token/shared credentials, In this case, it is important that the initial token or shared credentials are used to enable only the minimal privileges necessary to register with the solution. Once the registration authority validates the initial token or shared credentials, the rest of the steps of this design should be followed.
If yes - with certificate, the device can be manufactured in a secure manner and the need for a Registration Authority can be reduced if not removed altogether. This is easy to say and difficult to achieve as many manufacturing processes are purposefully disconnected from the cloud. Regardless, since the solution may have an entire step removed when keys are introduced by the manufacturer, the customer experience and overall system simplicity will benefit.
In almost all cases when devices are provisioned, we need to associate the device to either a customer or a device profile within an established system. This involves gathering additional information from the device to complete the device registration. Gathering this additional information can be accomplished with one or a combination of the following:
Although the thought of trying to provision every single device in a solution with a certificate can be daunting, it is by far the most secure way to provision devices. It is important to establish mutual authentication to prevent threats like man-in-the-middle attacks. When bootstrapping your devices, certificates should always be your first choice for device identity.
If yes, the design’s registration authority step can be implemented using an Application Programming Interface (API) in front of an existing customer solution. This API can then perform the registration authority job while leveraging the customer’s existing solution.
<tbd written scenario>