RoadTest: Infineon Trust Platform Module + Raspberry Pi 3 B
Author: Jan Cumps
Creation date:
Evaluation Type: Development Boards & Tools
Did you receive all parts the manufacturer stated would be included in the package?: True
What other parts do you consider comparable to this product?: there are limited comparable products available. I used a software simulator service from IBM
What were the biggest problems encountered?: The documentation and application notes available from a link on the Infineon product page are outdated and do not work anymore (Jessie and Stretch moved out of the main support line). The version of the same app note that's available from a link in the printed Quick Start guide works.
Detailed Review:
TPM stands for trusted platform module. It's a hardware security device.
Under the skin, the IC is a microcontroller designed for secure operation.
It has a number of anti-tamper mechanisms, and part of the memory can't be retrieved externally.
That controller is programmed with firmware that implements the TPM API.
There is no known way to get the root certificates out of the IC. The firmware API doesn't expose it, when you try to open the package it destroys the content.
Measures are taken that you can't derive from power profile or execution time that you have a key match or mismatch (or if you're close to finding the match).
When the IC detects that brute force attempts are done, it makes itself unusable for a while.
Main functions and uses:
Reference: Systematic collection of TPM 2.0 chips attributes on Linux, Bachelor’s Thesis, Daniel Zaťovič. Chapter 3: vulnerabilties.
The board is essentially an Optiga IC with the necessary passives around it to make it work as a SPI slave on a Raspberry Pi
image: my road test kit, a Raspberry Pi 3B with the Infineon Optiga TPM9670 module
The hardware integration is easy. You just have to plug the board on the Pi header.
The software is more work. It involves compiling libraries and utilities from source.
Luckily, since the Raspberry Debian Buster Linux distro, enabling the device and driver has simplified a lot. More on that in the Software chapter.
The schematic is straightforward. You have the SLB9670 at the heart of the design.
The SPI signals are routed to the Pi header. The same connector also supplies power.
A set of bypass capacitors to deal with power stability.
A few unused pins are tied to VDD or ground, as specified by the manufacturer.
The interrupt pin is available as a test pad, and routed to the Pi header.
There's a reset mechanism with options.
The board resets itself at power on via C3. There's also a button for user reset.
By moving a jumper, you can also enable a reset from the Pi.
image source: Infineon Optiga kit hardware documentation Infineon-Iridium_1-0_9670_HD-AdditionalTechnicalInformation-v01_01-EN
The stack, as the name implies, has a set of layers that work together to expose the functionality.
The diagram below, taken from the documentation for the Linux software support, has the low level at the bottom.
By moving up the stack, you transition from low level API to functional user utilities, and integration in existing Linux security services (e.g.: OpenSSL).
image source: Infineon application note Integration of the Open Source TPM Software Stack 2.0 on a Raspberry Pi® 3 Linux environment with OPTIGA™ TPM SLx 9670 TPM 2.0
The current Raspberry Debian Linux distributions (starting at Debian Buster) have the support for the hardware on board.
The kernel is compiled with SLx9670 support. Enabling the driver is done by listing an overlay in the boot configuration.
dtparam=spi=on dtoverlay=tpm-slb9670
This setup can be done immediately after flasing the OS to the SD card, by editing the config.txt file in the boot partition.
You can also do this from the Pi after starting it up (requires reboot).
Before I received the kit , I also tried to use the App Notes that are listed on the Infineon product landing page.
These documents explain how to patch/enable the OS support in Debian Jessie and Stretch.
This exercise isn't easy.
And because both distributions have gone to non-support status, you have to resolve a stream of issues, incompatibilities and package unavailability.
Compared to that, enabling the IC on Buster is a walk in the park.
To test success, run this command:
ls /dev/tpm0
If the character device is available, the driver and the hardware are functioning.
Once the OS is set up, it's time to build the TSS (Trusted Software Stack) software libraries and utilities.
The image below shows what will be installed when you follow the Integration of the Open Source TPM Software Stack 2.0 on a Raspberry Pi® 3 Linux environment with OPTIGA™ TPM SLx 9670 TPM 2.0 application note.
(I additionally installed and used Azure Cloud authentication, more on that later.)
You have to read this diagram again from bottom to top.
image source: Infineon application note Integration of the Open Source TPM Software Stack 2.0 on a Raspberry Pi® 3 Linux environment with OPTIGA™ TPM SLx 9670 TPM 2.0
The list of modules (and installation order):
1. TPM Software Stack 2.0 (tpm2-tss)
2. TPM2 Access Broker & Resource Manager (tpm2-abrmd)
3. TPM2 Tools (tpm2-tools)
4. TPM2 TSS Engine (tpm2-tss-engine)
5. Cryptsetup (cryptsetup)
6. PKCS#11 (tpm2-pkcs11)
The bottom layer is the one we discussed in the OS Kernel and Driver section.
Item 2, Access Broker & Resource Manager, is the management layer that helps the core TSS talk to the Linux driver.
It makes the other libraries hardware agnostic. IBM even released a software based simulator as open source (I installed that earlier).
Item 1 , TSS itself, has 3 different libraries.
The low level SAPI only exposes the TPM2 functions. Nothing added, nothing taken. It's also the most complex one to use.
If you run the stack on a low resource device, this may be the one you end op using.
ESAPI is one step up. It provides utility functions to make life easier, like encrypt/decrypt helpers, ...
The FAPI is the richest interface, that exposes TPM2 operation as functional features.
Item 3 are command line utilities that give access to both ESYS and FAPI functionality.
After building this block, similar Linux executables for both interface options are generated.
Item 4 builds the dynamic engine that can be used by OpenSSL Integration
This allows you to use the TPM IC as the encryption, key generation, signature engine, in a normal SSL session.
Items 5 sets TPM as the server for crypto functionality.
The Linux libcryptsetup.so is replaced by a library that uses the SLx9760 to perform the functionality.
The 6th and last item of the application note, tpm2-pkcs11, integrates the IC as provider in the OpenSC pkcs11-tool.
The remaining section of the application note tests all libraries and utilities.
This is an elaborate section that covers the majority of options and service integrations
As example, I'm showing below how to sign a file with the OpenSSL integration:
and a random data generator:
This section of the Appnote also explains how to use the libraries in your own (C) programs.
My main goal was to use TPM as the identification and authentication mechanism of a Thing on Azure Cloud.
The Thing is the Raspberry Pi that came with the kit.
The Optiga module mounted on it will give Azure info on what Thing tries to talk to it, and will reply to any authentication requests.
I need two things: the Azure provisioning utility and firmware that talks to Azure.
The provisioning utility is part of the Azure IoT SDK for C. I will build the firmware in Node-RED.
I have done the majority of this exercise before. I have an Avnet SmartEdge IIOT Gateway.
It comes with the hardware, OS driver and Azure provisioning utility pre-installed.
In this exercise, I start from source.
Microsoft published the Azure IoT SDK for C. It uses the TPM IC to generate two attributes, and to authenticate requests.
The build instructions are available on the SDK github. The Optiga quick start guide links to them.
The instructions suggest to run apt-get upgrade.
If you do that, you'll have to relink the OpenSSL .so symbolic link again, because the upgrade installs and enables the latest OpenSSL version.
After building the SDK and provisioning utility, you get access to the TPM Registration Id and Endorsement key.
The key is needed when you register your device on the cloud, and later to identify and authenticate it.
I used Avnet's iotconnect.io cloud solution. It's hosted on Azure and uses the same TPM mechanism.
I documented the full explanation of that set-up: Connect to AVNET iotconnect.io with Node-RED - part 10: Trusted Platform Module (TPM) Security .
I used the same mechanism.
First I created a template with TPM as authentication requirement:
To be able to test the setup, I defined one parameter that can be exchanged between thing and cloud: a numeric attribute called firmwareversion.
Then I registered the Raspberry / Optiga combination as a thing:
This is where the endorsement key is entered. Use the registration Id as unique ID.
Once registered, the Thing shows as Released. The cloud hasn't seen it yet.
Check this series for the details. Note that the endorsement key isn't part of the configuration.
We tell the connector what the unique ID is, and some more attributes that you have when creating an application on Azure (customer ID and solution ID).
The flow has 4 options on the left side of the screen.
A button to send the firmware version to the cloud. It always injects this payload:
A second injector under that generates a random firmware version each hour (hey, this is a demo) and sends it to the cloud.
Options 3 and 4 let you manually disconnect and connect to cloud service.
Once the firmware flow is activated, the first connection is made.
The device now shows as acquired.
The payload arrives and is accepted,
and you can show it on a dashboard:
I tried to show what a TPM device is, and how the module is used on a Linux device. With real world examples.
What I haven't done yet, is to run the API validation test set against the stack. That will happen after the road test.
There is more that's not touched here:
Top Comments
R1 and R2 aren't populated, and aren't on the kit's schematic.
They go to the Raspberry I2C #1 SDA and SCL pins
Looks like there is an option to connect via I2C:
source: https://www.geeks3d.com…
Follow up: I'm running a benchmark: https://gitlab.com/daniel.zatovic/tpm2-algtest
Great review. I'm curious about some physical properties. How would you case such a configuration? The interface board sits above the height of the RJ45 network socket. Can't use a standard case. Vendor…