Saturday, September 9, 2017

Understanding and Deploying Azure IoT Hub Device Provision Service-Part-I


Lets get some context around what is this blog about and who and why should you care. (This is in reference to  Azure IoT Hub Device Provisioning Service)

If you are a manufacturer of devices or machines or appliances or something that needs to be connected that your customer or consumers buy, meaning you are producing 100s,1000s or millions of these products. When the end consumer gets your product, you want these products to connect to your IoT listening end point in the cloud (such as Azure IoT Hub),  in safe and secure way to the nearest geographical IoT end point and you want  all of this process to happen seamlessly. Seamlessly meaning at the manufacturing time, without you encoding a Device ID/Key in to your product that your your IoT Cloud End Point provides, Azure IoT Hub Device Provisioning (DPS) is something you should look at seriously and likewise all my global manufacturing customers are!  What we call semantically as a  “Zero-Touch Provisioning”.

How would DSP work for you?

You will make your products that support TPM/HSM (reference in IoT Hub Device Provisioning Service security concepts).  You ship these products to your customers across the globe. After receiving the product, for the first time your customer turns on the product. The product calls home (To the cloud IoT Hub Device Provisioning Service). This is where the magic happens. The IoT Hub Device Provisioning End Point validates your product by the TPM/HSM ID/Keys. Based on the geo location and based on the Enrollment option you have pre-configured in the DPS, the DPS will figure out which of IoT Hubs  is the best fit. These IoT Hubs are one of those that you had already pre created across the geo locations that you support your customers.

How can I test this DSP quickly without doing anything to product?

At the time of writing this blog, this DPS service was in preview. But I am going to reference these two articles in sequence and share my experience of an actual build out and provide clarity on the steps and some insights on results.  What we are going to be building out is like the  2nd article suggested, is simulate your what product would communicate with the DPS.

  1. Set up the IoT Hub Device Provisioning Service (preview) with the Azure portal 
  2. Create and provision a simulated device using IoT Hub Device Provisioning Service 

I won’t repeat what is already  been document in the above referenced articles, so I suggest you read the articles first and reference this blog for clarity on the steps. So continue with the steps in the article and compare my blog to make sure you get your steps correct. I have outlined each major sections to give you context of which section my guideline convers.

Steps described in the article 1 Set up the IoT Hub Device Provisioning Service (preview) with the Azure portal  are straight forward but here are the names I had used for reference in the future steps:



Steps described in Article 2 Create and provision a simulated device using IoT Hub Device Provisioning Service 

Prepare the development environment

In this section under the steps 7 where you are going to run the Simulator.exe, open another Git Bach command prompt, here I have actual run corrected path(at the time of preview).


The run will prompt for port opening in the Windows Firewall. Click on Allow access.


Create a device enrollment entry in the Device Provisioning Service

Step 1 opening the solution:





In the build output you will notice 1 failed as one of the project is marked for not to build. So your results are good.

Step 2:Right-click the tpm_device_provision project and select Set as Startup Project. .  .



Run the solution


The output window displays the Endorsement Key and the Registration ID needed for device enrollment.


Note down these values


Enter to continue the run time command closes.

Simulate first boot sequence for the device

Step 2. In Visual Studio on your machine, select the sample project named dps_client_sample and open the file dps_client_sample.c



Step 3. Assign the ID Scope value to the dps_scope_id variable. Notice that the dps_uri variable has the same value as the Global device endpoint.


Step 4. Right-click the dps_client_sample project and select Set as Startup Project. Run the sample



Notice the messages that simulate the device booting and connecting to the Device Provisioning Service to get your IoT hub information.

Now this is where, what your actual product would do when it calls home for the first time when the customer turns on your product. Lets review this sequence of operations and understand the handshake between your device and the DPS.

In the first communication, your device had established with the global DSP service. This global DPS end point is again geo distributed with globally single unique name making your device provisioning code consistent.


Next your device sends your TPM/HSM attributes. In this case as we choose to simulate the TPM, a registraionID , the protocol name “tpm” and the associated tpm endorsementKey.


Next you will notice the DPS will send 401 status requesting for an authorization, along with the new DSP provided unique authorizationKey.


Next your device will follow the instructions and send the SAS key


At this time the DPS responds acknowledging the authorization with 202 status code and sends the status that the DPS is now “assigning” the device to an IoT Hub


Now once the DPS is successful allocating the IoT Hub, your device will receive the status code of 200. The DPS will register/add your device in the corresponding IoT Hub (“assigniendHub”), there by acquiring a new “device ID” (This is an auto generated name, you should be able to provide a specific name), and all other registration signatures.  Next you should see device starts communicating directly with the allocated IoT Hub. 


Lets go to that corresponding Iot Hub in the Azure portal.Voila! You should see your device registered.


So this completes all the steps in the 2nd article.


We just simulated a single device provisioning and understanding the end-to-end flow of communication between your device and the Cloud.  Your next question is well we didn’t actually have more than one device nor more than one IoT Hub.  Sure,  read the next article Provision devices across load-balanced IoT hubs and I will follow up with a blog on Experimenting and Extending DPS with multiple simulated devices and multiple IoT Hubs-Part-II (coming soon….)