Device provisioning - IoT Lens

Device provisioning

In IoT, device provisioning is composed of sequential steps. The most important outcome is that each device must be given a unique identity and authenticated by your IoT application using that identity.

The first step to provisioning a device is to install an identity. The decisions you make in device design and manufacturing determines if the device has a production-ready firmware image, a unique client credential, or both by the time it reaches the customer. Your decisions determine whether there are additional provisioning-time steps that must be performed before a production device identity can be installed.

Use X.509 client certificates for your IoT devices — they tend to be more secure and easier to manage at scale than static passwords. In AWS IoT Core, the device is registered using its certificate along with a unique thing identifier. The registered device is associated with an IoT policy. An IoT policy allows you to create fine-grained permissions per device. Fine-grained permissions ensure that only the device has permissions to interact with the right MQTT topics and messages.

The registration process ensures that a device is recognized as an IoT asset and that the data it generates can be consumed through AWS IoT to other AWS services. One of the ways to provision a device, is through fleet provisioning. AWS IoT can generate and securely deliver device certificates and private keys to your devices when they connect to AWS IoT for the first time. AWS IoT provides client certificates that are signed by the AWS Private Certificate Authority (AWS Private CA). Fleet provisioning provides two ways to implement this: by trusted user or by claim. Let us look at the process flow for fleet provisioning by claim.

Some devices do not have the capability to accept credentials over a secure transport, and the manufacturing supply chain is not equipped to customize devices at manufacturing time. AWS IoT provides a path for these devices to receive a unique identity when they are deployed.

Device makers must load each device with a shared claim certificate in firmware. This claim certificate should be unique per batch of devices. The firmware containing the claim certificate is loaded by the contract manufacturer without the need to perform any customization. When the device establishes a connection with AWS IoT for the first time, it exchanges the claim certificate for a unique X.509 certificate signed by the AWS certificate authority and a private key. The device should send a unique token, such as a serial number or embedded hardware secret with its provisioning request that the fleet provisioning service can use to verify against an allow list.

Diagram showing registration flow between the device, AWS IoT Core, AWS Lambda, and Amazon DynamoDB.

Figure 1: Registration Flow

  1. Device connects with claim certificate to AWS IoT Core.

  2. The fleet provisioning service creates a new certificate and private key assigned with AWS Private CA.

  3. Device writes the unique private key and certificate to secure storage.

  4. With the parameters published from the device, the fleet provisioning service starts the pre-provisioning Lambda function.

  5. The Lambda function performs additional verification logic, such as checking the hardware secret against a DynamoDB table with verified devices.

  6. The fleet provisioning service create IoT thing, policy, and activates certificate based on provisioning template and publishes this to the device.

  7. Device applies the new configuration and connects with the unique private key, certificates, and configuration.