IoT Device Provisioning with TPM on AWS and Azure
When designing IoT platforms, a crucial aspect is device provisioning or registration also known as device onboarding. In this blog post, I will discuss device provisioning in general and explore the options available on Azure and AWS cloud platforms, focusing on state-of-the-art techniques.
The simplest approach to device provisioning involves manual device registration in AWS using the AWS Console or AWS CLI, and in Azure, using the Azure portal or Azure CLI. This method is commonly adopted by most teams, particularly in R&D/Engineering. However, for production purposes, this approach is not feasible to meet all the non-functional requirements (NFRs) of DPS (Device Provisioning Service).
The common NFRs for DPS include:
Security of device identity and mutual authentication with service endpoints.
Security of the end-to-end provisioning process.
Integration with high-volume manufacturing.
Integration with contract manufacturing.
Ease of installation and commissioning of devices.
Bulk onboarding of devices.
Ownership transfers.
Re-provisioning of devices.
Device hardware replacement.
Device certificate rotation.
Support for multi-tenancy.
Load balancing.
Geo-sharding of devices.
In order for an IoT device to connect and communicate with service endpoints or other device endpoints, it is necessary to establish trust with those endpoints. This trust is established through mutual authentication between the device and the endpoints, using security principals. Whether the endpoints belong to AWS IoT Core or Azure IoT Hub, the device must have the following security principals.
Device Key Pairs: Each device has a unique set of private and public key pairs. It's important to securely store the private key, and TPM chips are the state-of-the-art technology to secure private keys.
X.509 Device Certificate: The device must have a certificate signed by a Certificate Authority (CA). The service side should possess the appropriate CA Certificate to validate the device's certificate.
Service Endpoints: AWS and Azure provide service endpoints for device communication.
Signing CA Certificate: The CA certificate is used to sign the X.509 device certificate.
Service Root CA Certificate: This certificate verifies the authenticity of the service endpoints, allowing the device to trust the endpoints it communicates with.
When designing an IoT platform, it is crucial to carefully consider the installation, activation, and generation of cryptographic key material and certificates on IoT devices. The architecture must ensure both the security and scalability of the installation and commissioning process.
One of the key factors which influence the design of this architecture is the end-to-end device supply chain.
Broadly, the options to add the Principals into the IoT device are:
During manufacturing
If the security principals need to be injected during the manufacturing process, it is necessary to assess the security of the manufacturing supply chain. The objective is to determine the suitable stage in the manufacturing process where these principals can be generated or injected into the IoT device. It may be necessary to develop a factory utility tool to generate and inject the principals.
During installation
If the security principals need to be injected during the installation and commissioning of IoT devices, it is crucial to develop an application, typically a mobile app, that includes features such as barcode scanning or serial number entry. When designing the workflow and app, it is important to evaluate the user persona involved, ensure usability, and consider the time required to complete all the necessary steps while maintaining the security of the entire process.
The principals generated and/or injected at any stage are not permanent; they require periodic renewal for security purposes. Therefore, the architecture must include audit and renewal mechanisms to ensure enduring security.
Both the AWS documentation and Azure documentation provide valuable information and guidelines on this topic. I have included links to the documentation in the references section below for further reading.
Difference between Azure and AWS
Azure provides a managed service called Azure Device Provisioning Service (DPS), which extends Azure IoT Hub.
Azure DPS addresses multiple scenarios like
Zero-touch Provisioning (ZTP)
Load balancing
Multi-tenancy
Solution isolation
Geo-sharding
Ownership transfer
Re-provisioning.
Azure DPS is available at highly affordable pricing, for instance, in the east US2 region, it is $0.10 per thousand operations. This makes it an extremely cost-effective choice.
AWS offers IoT Core APIs and other necessary building blocks for constructing the required DPS service, along with vital documentation, whitepapers, and guidelines that include reference architectures for device provisioning setup. However, unlike Azure DPS, there is no consolidated managed service provided by AWS. It is the responsibility of the Architecture team to assemble and manage all the required building blocks. The cost of ownership for the device provisioning service may be slightly higher on AWS compared to Azure, although this may not be a significant factor.
In my opinion, Azure DPS is simpler to work with compared to AWS, where one has to put together multiple components.
Below are the references for further reading: