AVNET's iotconnect.io cloud platform is an online service that you can use to send data to, and then show it on a dashboard. In this blog series I'm learning how to talk to it with Node-RED.
In this post: authentication with a hardware support: Trusted Platform Module (TPM) sign-on.
Several of the previous posts work on generic Raspberry Pi, BB, ... . This one is different.
You need hardware that supports TPM. I'm using the Avnet SmartEdge IIOTGateWay. It has an Infineon (datasheet) IC on the pcb. This TPM module has a unique ID (+Endorsement Key (EK) and EK certificate). And it's supported by Linux kernel. See here for a breakout post: Infineon SLx9670 Trusted Platform Module (TPM) for IoT Security.
In essence, what happens in this post, for hardware and software, is identical to this post on GitHub, but on the SmartEdge, this is part of the out-of-box setup. Infineon has a module for Raspberry Pi that gives the same experience.
This is recent functionality. TPM is supported in the Python SDK since the first release of the SmartEdge.
I'm using a pre-release of the Node-RED modules here. Production release is imminent.
Register a TPM enabled device on IoTConnect portal, and let it connect and share sensor data.
Together with part 8b and later of this series (CA signed certificates), TPM authentication is a decent choice for industrial applications.
And the scenario isn't very different. CA Signed and TPM security both rely on certificates. CA Signed via software, TPM via a hardware module.
The TPM approach uses 3 functions of the Infineon chip:
- get the unique identification
- retrieve an endorsement key (EK, equivalent to public key), that can be used to register the device on IoTConnect cloud.
- use the on-silicon key to validate sign-on.
CA Signed and TPM are both strong solutions.
An advantage of TPM is that you can't accidently share the private key because it can't be retrieved from the IC.
An advantage of CA based authentication is that it doesn't need additional components to the BOM (this may become less of an issue when microcontrollers and processors come with on-board TPM).
Provisioning can be automated for both solutions.
This is one intrusion vector less. Software attacks to retrieve the private key will not work.
I am assuming at this point that you have a Linux box with TPM support. See the header block of this post for details.
Like the previous solution, you can script the provisioning via an REST API, but I'm doing the steps manually here.
Create a template that supports TPM authentication
I've created a number of templates in this series. Everything is the same, except that this time I select TPM as Authentication Type.
Like the other examples, I create the attribute.
I've also created a longitude and latitude attribute. That's for later, when I'm going to show the portal's capability to show a device on a map.
Provision a device
The keys to register a TPM on IoTConnect, are ihe unique ID of the hardware TPM and the Endorsement key of that module.
IoTConnect cloud runs on Azure, and the Azure utility tpm_device_provision is used to get that data.
Source code is available on GitHub. On the SmartEdge, it's installed out of box.
The utility uses the Linux TPM driver to get the info, and can be executed from the command line:
The output has all info I need. Not in a friendly way to collect from a command line, but the Avnet Python samples show how you can retrieve the relevant data.
id_ek = cmdline("yes 2>/dev/null|/opt/avnet-iot/iotservices/tpm_device_provision") # ... lines = id_ek.splitlines() uniqueId = mystr(lines, 'utf-8') EndorsementKey = mystr(lines, 'utf-8')
The Avnet example then uses the REST api to provision the device. Here's the same process via the portal:
Node-RED Config and Test
On the device's Node-RED flow, you have to set the Registration Id from the previous step as unique id.
Like all previous posts, the CPID is retrieved from the IoTConnect portal.
The Scope ID is a value you also get from Avnet when registering. For trial subscriptions, you can usually find it back in the IoTConnectSDK.conf.default they provide.
That is it. The rest of the flow is exactly the same as in all previous posts.
When you enable the flow, you should see the green embelishment and Connected label under the IoTConnect node.
As usual with security, the end result doesn't look spectacular.
The real power is behind the scenes: hardware based authentication.