One of the first steps you come across when starting an Internet of Things (IoT) project is provisioning your IoT devices. This blog highlights the different provisioning methods you can use to connect your devices to AWS IoT Core.
Device provisioning in AWS establishes the first trust relationship between device and AWS. During the provisioning process, AWS registers the device, which defines the link between AWS and the device. Resources created vary depending on which provisioning method your use case utilizes. There are resource that are created on the device and resources that are created on AWS IoT Core.
Resources that are created on the device include X.509 Certificate, Private Key, and Amazon Trusted Service Root Certificate Authority (Root CA) or Signer Certificate Authority. All are used to authenticate and securely connect the device to AWS IoT Core.
X.509 certificates: Can be created by AWS IoT, or a certificate authority (ca) registered with AWS IoT that signed the X.509 certificate. X.509 certificates also support use of public and private keys on the device.
Amazon Root CA: Is an Amazon Trusted Service Root CA that your device will use along with the X.509 certificate to authenticate the connection with AWS IoT Core server. For more information check out server authentication.
Resources that are created in AWS IoT Core include IoT Thing, IoT Policy, and IoT Certificate. When the IoT Thing is created, an IoT Certificate (X.509) is also created (AWS best practices recommends that each IoT Thing to be configured with a unique certificate), also an IoT Policy (policies don’t have to be unique to each device). When the resources are created, the IoT Policy is attached to the IoT Certificate and the IoT Certificate is attached to the IoT Thing. This allows your device to access AWS resources.
IoT Thing is a representation of you IoT device in the AWS IoT Core.
IoT policy is a JSON document used to allow or restrict device access to the AWS IoT resources.
Single thing provisioning
The single thing provisioning method is usually adopted during development/testing phase. For example, you are testing the cloud connection between your device and AWS IoT Core. In this example setup, you will create a IoT thing in the AWS console or AWS IoT API and download the certificates to your local machine. You will also need to establish secure access to the device certificates that will be used to connect to AWS IoT Core. Then, you can create an IoT Policy and attach it to your certificate. After creating the IoT Policy you will then attach the policy to your certificate which is connected to your IoT thing. This method is commonly used for development, although it can be integrated to other provisioning method or external APIs in order to accomplish scalability.
Just in time provisioning
Just in time provisioning (JITP) is secure, easy and scalable way to provision devices at scale. For example, using this provisioning method is if you are able to get the unique client certificates securely loaded onto your device at the time of manufacturing. This method also requires your own Root Certificate Authority (root CA). When using JITP, device certificate auto registration must be enabled. With JITP you will use your own CA and register it with AWS IoT, then attach your JSON provisioning template which is used as a blueprint for the registration flow. When your device is connecting for the first time, the IoT device will present its unique device certificate signed by the Certificate Authority that was registered to AWS IoT Core. After the certificate is activated, an IoT thing will be created and registered, subsequently an IoT policy will be attached to the activated certificated. Using this provisioning method meets the use case of auto provisioning devices when they connect to AWS IoT for the very first time. For more information, check out this previous AWS blog post “Setting up just in time provisioning with AWS IoT core.”
Just in time registration
Just in time registration (JITR) can also securely provision devices at scale. JITR like JITP can be used when your trusted manufacturer can install the unique device certificate securely on every device. Like in JITP, in JITR a root CA needs to be registered with AWS IoT Core, but no provisioning template is necessary. In the JITR registration flow, when your IoT device connects for the first time and presents the signed unique device certificate, a registration event is published to an AWS IoT reserved topic. Also an AWS IoT Rule will be created and subscribed to the MQTT lifecycle event topic, when the MQTT message is sent to the IoT rule it will trigger an AWS Lambda function. The Lambda function can then perform additional verification checks. For example, the Lambda function can check the device certificate or device serial number against an allowed list in a database. After the Lambda function verified the device certificate, then the same lambda function can activate the certificate, create an IoT thing, and an IoT policy for the certificate. Your device will be able to successfully connect to the AWS IoT core after that. For more information, check out this previous AWS blog post “Just in time registration of Device certificates on AWS IoT.”
Multi-Account Registration (MAR) is a feature that can use the same device certificate across different AWS accounts and endpoints. MAR can now be used with JITP and JITR, thanks the latest feature that allows the registration of the same certificate authority using Server Name Indication (SNI) mode. With SNI mode you can register the Certificate authority throughout many accounts and regions, and now devices are able to initiate the JITP or JITR flow by simply pointing to the correct account endpoint. For more information, check out this blog “Simplify multi-account device provisioning and certificate authority registration when using AWS IoT Core.”
Fleet Provisioning
Unlike JITR and JITP, fleet provisioning does not require that you bring your own certificate authority nor requires unique device certificate before provisioning. It utilizes an AWS IoT generate device certificate which is signed by the managed Amazon trust root CA. Fleet provisioning uses the AWS IoT CA and creates a AWS unique device certificate with two distinct provisioning methods, which are provision by claim and provisioning by trusted user. Both provisioning methods uses a provisioning template.
Fleet provisioning by claim is usually applied when a trusted manufacturer can load all devices with a common bootstrap certificate. When the IoT device connects to AWS IoT Core for the very first time, it will connect using the bootstrap certificate which has a very restrictive policy. After connecting, the device must deliver the correct payload and parameters to a restricted and reserved topic. AWS IoT Core then generates a unique device certificate and delivers back to the device. This certificate is only activated after the parameters are evaluated by a Lambda function. For more information check “How to automate onboarding of IoT devices to AWS IoT Core at scale with Fleet Provisioning.”
Fleet provisioning by trusted user is a method usually applied when a device maker designs a companion application(app). The companion app, mobile or web app will call the Fleet provisioning API using credentials and permission that have been given to that trusted user. The API then respond with a temporary claim certificate, which is only active for five minutes. Once a temporary claim certificate is obtained from AWS, the app will then pass the temporary claim certificate to the device, the relationship in between companion app and device should be developed by the device maker, for example a secure Bluetooth connection. The device then uses the temporary certificate to connect to AWS IoT core and claim a unique device certificate. When connecting to AWS IoT core a provision template is used to create and attach a IoT policy to the new device certificate, a IoT thing will be created and registered, the device will then disconnect and reconnect with new device certificate.
Bulk Registration
Finally, we must cover Bulk provisioning, which can be used to provision your fleet of devices in bulk. For example, if you have a fleet of air conditioner units and they are being retrofitted with devices to connected to AWS IoT Core, in this case Bulk provisioning can help register and connect the devices during system delivery. Bulk provisioning is used when you have a list of attributes about your devices, such as model, serial numbers, firmware version and other attributes, organized as a JSON provision file. The file can be stored in an Amazon Simple Storage Service (Amazon S3) bucket. After that, you can run the bulk provisioning task to onboard your devices. Bulk registration is also commonly applied to device certificate rotation.
Conclusion
Whether you’re looking into AWS IoT Core for the first time and connecting your very first device or if your company needs to provision thousands or more devices at scale, AWS has many different provisioning methods to meet your use case. To continue learning more about device provisioning in AWS IoT Core, have a look at our Device Management Workshop and our Device provisioning and manufacturing guide.
Leave a Reply
You must be logged in to post a comment.
