Distributing IoTHub credentials using TPM

I bet, most of the time you have seen Azure IoT demos or most of the time you have programmed an IoT Uwp app yourself, you hard coded device credentials for the IoT hub. Yes, I’m guilty too 🙂

And this is, of course, a bad practice.

Not only, there is a risk these credentials are shared by checking them in into your version control system (like public Git). But it’s also inconvenient because, for each device running that production code, you will have to alter the credentials in the code and deploy again.

We could use configuration files. But this is still worthless in perspective of distribution.

We would like to pass the credentials to known devices separately, apart from the applications. We want to use a second channel. And this is possible with the current Windows IoT Core infrastructure.

All we need is a TPM. This is a Trusted Platform Module:

“Trusted Platform Module (TPM) is an international standard for a secure cryptoprocessor, which is a dedicated microcontroller designed to secure hardware by integrating cryptographic keys into devices. TPM’s technical specification was written by a computer industry consortium called Trusted Computing Group (TCG). International Organization for Standardization (ISO) and International Electrotechnical Commission (IEC) standardized the specification as ISO/IEC 11889 in 2009.^[1]”

Why do we need it? Microsoft provides a separate mechanism to write credentials into the module which acts like a vault.

In this example, we will look at Windows 10 Core running on a Raspberry Pi. And we will use IoT Hub device credentials stored in a TPM.

Advertentie

Azure Functions as watchdog for missing telemetry or devices

Once you are working with the Azure IoT platform, there comes a moment where you want to add notifications.

In a previous blog, we looked at how to send notifications when telemetry values did not match certain ranges. Although this is great, there are even more cases where we want notifications.

Here I am referring to watchdog functionality. When no telemetry is arriving anymore or devices are disconnected, the complete IoT platform is not working as designed. So we want to be informed when something fails.

In this blog, we will build a simple watchdog using Azure Functions.

The only thing standing between IoT Hub and Functions are Consumers groups

Traditionally, when telemetry arrived at an Azure IoT Hub, it was a rule of thumb to pass it to a Stream Analytics job. But when routing was introduced in the IoT Hub, it became possible to push the telemetry directly into an EventHub or a Service Bus too.

I still favor the many possibilities of the Stream Analytics job, working with temporal and geospatial data eg. is so much easier that way.

But I can configure a lot of other, new Azure resources after the Event Hub or the Service Bus.

For example, IoT Hub routing to an Event Hub makes it possible to pass telemetry to Azure Functions (using the EventHubTrigger). This opens a whole new world of Azure opportunities using only an EventHub in this case! But it can be done even simpler…

Test the protocol availability of your Azure IoT Hub

Yesterday I discovered this little gem on Github. This NodeJS tool is advertised as:

“This tool is provided to help diagnose issues with a device connecting to Azure IoT Hubs.”

What it basically does, is calling your IoT Hub and trying to make a connection using Ping, AMQP, AMQP-WS, HTTPS and MQTT. It just checks the availability.

This is the outcome of a typical call:

I can think of calling your service once or more times every day, to check the availability.

What do I have to do for this to get it running?

How to run Azure IoT Suite a few days more (before running out of Azure credits)

Microsoft provides a great IoT platform on Microsoft Azure. And next to the resources (IoTHub, StreamAnalytics, etc.) available on Azure, Microsoft also offers a great introduction named Azure IoT Suite. and they are very serious about it!

To be clear, The IoT Suites are not complete solutions to be used as-is or even to be sold as-is. They have to be handled as a reference architecture… Use them to get started, use them to demonstrate the capabilities of the Azure IoT platform or use them as a piece of discussion for your future solution. Microsoft even helps you by providing the inner logic as open source. So you can extend it yourself. And they even show some examples on how to extend these suites.

At this moment, there are three preconfigured solutions:

1. Remote Monitoring
2. Predictive Maintenance
3. Connected Factory

These are all three great solutions. There are simulated devices and you can add your own devices too. For example, the Connected Factory can connect to real devices using the OPC technology.

Note: For now, Predictive Maintenance and Connected Factory are out of scope for this article.

But there is one issue: it’s ‘expensive’. For example, this is what’s generated for the Remote Monitoring example:

• 1 Azure Active Directory application
• 1 IoT Hub (S2 – Standard tier)
• 1 DocumentDB Account (S1)
• 2 Event Hubs (Basic throughput unit)
• 1 Storage account (Standard-GRS)
• 3 Stream Analytics jobs (1 streaming unit per job)
• 1 Azure App Service Web App for Website (P1 – Premium: 2 small)
• 1 Azure App Service Web App for Web jobs (S1 – Standard: 2 small) running 25 simulated devices by default

Here are some examples. The S2 IoT Hub itself costs 421 euros. The two App Service Plans behind the web services consume 250 euros together. And there are three Stream Analytics jobs, each will cost 75 euros.

So if you demonstrate or test this IoT Suite, you can burn your MSDN account in a couple of days. Is it possible to change this?

So here is a collection of easy changes you can do yourself on this particular Predictive maintenance IoT Suite.

The IoT Hub can run as good on an S1 and it costs only 42 euros. That’s a cost reduction of 350+ euros or more than ten euros per day. With the steps below, you can reduce the total costs to fifteen euros or so per day…