Using a Trusted Platform Module for endpoint device security in AWS IoT Greengrass

Co-authored by Aniruddh Chitre, AWS Solutions Architect

This post demonstrates how AWS IoT Greengrass can be integrated with a Trusted Platform Module (TPM) to provide hardware-based endpoint device security. This integration ensures the private key used to establish device identity can be securely stored in tamper-proof hardware devices to prevent it from being taken out of the devices for impersonation and other malicious activities.

With the ever-increasing adoption of IoT in various industries, managing the security of device fleets is a priority for any successful implementation. Industrial IoT also has to contend with devices deployed in remote, unmanned areas that cannot be easily secured. A compromised device can have ripple effects across the complete IoT solution ecosystem (equipment, devices, applications and network) with potentially damaging consequences for consumers and organizations.

Normal IT-related scenarios, software countermeasures, e.g. usage of Anti-Virus software, are taken for granted to secure the system. These programs are active only after the boot sequence completes and the OS takes control of the system and launches the antivirus program.

However, in IoT, another type of attack vector, commonly called bootkit or bootloader rootkit, can infect the master boot record. These bootkits subvert the normal booting process and allow for malicious programs to be executed before loading of the operating system. The bootkits escape detection by standard OS processes as they reside outside of the file system.

To handle these scenarios, the Trusted Computing Group (TCG) has developed Trusted Computing paradigm to protect computing infrastructure and billions of IoT devices. The TCG has created the specifications of a TPM that enforces specific behaviors and protects systems from unauthorized changes and attacks, such as malware and bootkits.

What is a TPM?

A TPM is a cryptographic processor present on most commercial PCs and servers. Ubiquitous in nature, it can be used for a wide variety of use cases, such as storing keys for VPN access and encryption keys for hard disks, or preventing dictionary attacks to retrieve private keys.

While a typical TPM provides several cryptographic capabilities, three key features are relevant for this post:

• Establishing a root of trust
• Secure boot
• Device identification

Establishing a root of trust

A TPM can prevent a bootkit attack by providing a trusted sequence of boot operation. The following questions often arise in a running system:

• Is the operating system that is running appropriately secure?
• Is the firmware booting the OS appropriately secure?
• Is the underlying hardware appropriately secure?

Each layer has to trust the layer below, as illustrated in the following diagram.

At the root of this chain is the hardware, which has to be inherently trusted and forms the base on which the chain of trust has been established. In more technical terms, a root of trust is all of the following:

• Set of functions in a trusted computing module that is always trusted by the firmware/OS
• Prerequisite for secure boot process
• Component that helps in detection of bootkits

Secure boot

A secured boot builds on the underlying notion of a root of trust to protect the boot process from being compromised on the device. This whole process by which the trustworthiness of a device is established right from the chip is called a “Secure Boot”. In case a chain of trust is broken, the boot process is aborted and the device attempts to go back to its last known good state.

An extension to secured boot process is a measured boot – where the device does not halt the boot process. Instead, it records the identity of each component that participates in the boot process so that these component identities can be verified later against a list of approved component identities for that device. This is called a measured boot.

These two processes are illustrated in the following diagram.

A typical sequence of a measured boot is as follows:

• The boot ROM acts as the root of trust.
• Upon a device reset, each image that forms part of the boot sequence is validated (measured) before execution.
• The measurements are stored in a TPM.
• Each measurement serves as the proxy for the root of trust for the subsequent step in the boot sequence.
• Normally, only critical and security-sensitive process and configuration files are considered for the measurement.
• After the security-sensitive processes are completed, the device enters the unmeasured boot stage before entering normal system operation state.

Device identification

In IoT solution deployments, it is important to check the identity of the device that is communicating with the messaging gateway. The usual method is to generate key pairs for the devices, which are then used to authenticate and encrypt the traffic. However, key pairs residing on the disk are susceptible to tampering.

The TPM steps in here by storing the keys in tamper-resistant hardware. The keys are generated inside the TPM itself and are thereby protected from being retrieved by external programs. In fact, even without harnessing the capabilities of a hardware root of trust and secure boot, the TPM is also valuable just as a hardware key store. The private keys are protected by the hardware and offer far better protection than a software key.

The rest of this post focuses on how to integrate and use features of TPMs to protect the edge gateways running AWS IoT Greengrass. This integration uses the PKCS#11 protocol as the interface to the TPM.

What is AWS IoT Greengrass?

AWS IoT Greengrass is software that extends cloud capabilities to local devices. Specifically, AWS IoT Greengrass provides cloud-based management of application logic that runs on devices. This enables devices to collect and analyze data closer to the source of information, react autonomously to local events, and communicate securely with each other on local networks. AWS IoT Greengrass developers can use AWS Lambda functions and pre-built connectors to create serverless applications that are deployed to devices for local execution.

The following diagram shows the basic architecture of AWS IoT Greengrass.

Using AWS IoT Greengrass, devices securely communicate on a local network and exchange messages with each other without having to connect to the cloud. Locally deployed AWS Lambda functions and connectors are triggered by local events, messages from the cloud, or other sources. If connectivity is lost, AWS IoT Greengrass provides a local pub/sub message manager that can intelligently buffer messages to preserve inbound and outbound messages to the cloud.

An AWS IoT Greengrass core is an AWS IoT thing (device). Like other AWS IoT devices, a core exists in the registry, has a device shadow, and uses a device certificate to authenticate with AWS IoT. The core device runs the AWS IoT Greengrass core software, which enables it to manage local processes for Greengrass groups, such as communication, shadow sync, and token exchange.

During the registration of the AWS IoT Greengrass core, the keys and the certificates generated are stored in the local drives of the devices by default and are easily accessible. The following sections provide a deep dive into how the keys can be securely stored in tamper-proof hardware provided by the TPM.

Securing AWS IoT Greengrass with Infineon OPTIGA TPM

We will look at the steps required to secure AWS IoT Greengrass with the Infineon OPTIGA TPM products.

This integration requires the following components:

• A Raspberry Pi 3B+ running Raspbian Stretch.
• AWS IoT Greengrass v1.7+.
• Infineon OPTIGA TPM. This blog uses the Infineon OPTIGA SLB 9670. However the other supported OPTIGA TPMs are OPTIGA SLI 9670 and OPTIGA SLM 9670 which can also be used for automotive and industrial applications respectively.

Setting up AWS IoT Greengrass on Raspberry Pi 3B+

Because the AWS IoT Greengrass core is an AWS IoT device, it has to be registered with the AWS IoT Core and comply with all security restrictions. It should have the following:

• A private key and public key pair.
• A certificate signed by a certificate authority (CA).

For more information, see the following documentation:

• Setting up a Raspberry Pi for AWS IoT Greengrass
• Installing AWS IoT Greengrass Core Software

As part of the setup, the keys and certificate are stored in the folder /greengrass/certs/. After the device is registered with AWS IoT, you must take additional steps to ensure that the device keys are secured.

From v 1.7.0, AWS IoT Greengrass supports the use of Hardware Security Modules (HSM) through the PKCS#11 interface for secured storage and offloading of the private keys. This prevents the keys from being exposed or duplicated in software. The private keys can be securely stored on hardware modules such as HSMs, Trusted Platform Modules (TPM) or other cryptographic elements.

AWS has partnered with TPM manufacturers to protect the private keys inside a TPM. One of the TPM Manufacturer is Infineon Technologies, who provide a hardware TPM based security solution with their OPTIGA TPM products which can be used on embedded PC, mobile and other IoT Devices. All the OPTIGA TPM products comply with the Trusted Computing Group (TCG) standards.

The rest of the blog provides a step-by-step guide demonstrating how to use an Infineon OPTIGA TPM as an HSM for AWS IoT Greengrass on a Raspberry Pi 3 Linux environment. It can be performed with one of the following Infineon Iridium OPTIGA TPM SPI Boards:

• OPTIGA TPM SLB 9670 TPM2.0
• OPTIGA TPM SLI 9670 TPM2.0
• OPTIGA TPM SLM 9670 TPM2.0

This example uses the OPTIGA TPM SLB 9670 TPM2.0 for the AWS IoT Greengrass HSM integration.

Prerequisites for setting up the TPM on the Raspberry Pi

The Infineon OPTIGA TPM uses the SPI interface to connect to the Pi on the GPIO Pins. Once the OPTIGA™ TPM is plugged into the PI, it should look as follows:

Go through the following steps to validate the initial setup of the TPM and to check if the Raspberry Pi is able to recognize the TPM on reboot. For more information, see Preparation and Hardware Setup.

• Reboot your Raspberry Pi and check that /dev/tpm0 is available. Update your system with the following command:

sudo apt update && sudo apt upgrade

• Install latest kernel using the following command:

sudo rpi-update

• Edit /boot/config.txt and add the following line:

dtoverlay=tpm-slb9670

• This value for the dtoverlay parameter applies to SLB 9670, SLI 9670 and SLM 9670)
• Restart your Raspberry Pi and check if the TPM is recognized on reboot using ls /dev/tpm*. The output should resemble the following:

A detailed verification can also be done by running a small utility, eltt2, provided by Infineon Technologies AG and available on GitHub. All of the following setup packages are created and built under the infineon-tpm directory.

mkdir infineon-tpm 
git clone https://github.com/infineon/eltt2
cd eltt2
make
sudo ./eltt2 -g
cd ..

The output of the preceding command should resemble the following:

This output confirms that the TPM is working correctly. Understanding the different properties of the TPM is not required for the rest of the integration.

Integrating AWS IoT Greengrass with Infineon OPTIGA TPM

For a TPM to function, it requires a complete software stack including drivers, resource managers, and other tools. Each of these components is available from GitHub (see links in the following sections) and has been built to the specifications laid out by the Trusted Computing Group (TCG). These software components include:

• TPM TSS Library: This library consists of the TCG’s TPM2 Software Stack (tpm2-tss) specification. This library comprises various software components that implement the low-level and high-level APIs, transmission of commands to the TPM, and the marshalling and un-marshalling of all the data structures defined by the TPM2 specification.
• TPM PKCS#11: The PKCS#11 is a public key cryptography standard that defines a standard method to access cryptographic services from tokens or devices such as HSMs or smart cards. In this example, the Infineon TPM serves as the HSM.
• TPM2 Access Broker and Resource Manager: These are system daemon processes that implement the TPM2 Access Broker (TAB) and Resource Manager (RM) spec from the TCG.

Though all the above APIs are required for the proper functioning and use of TPM operations, AWS IoT Greengrass uses only the PKCS#11 APIs for storing and retrieving the primary keys.

Installation preconditions

Before installing the software stack and tools, ensure that the Raspberry Pi has all the packages required to build the TPM libraries. This includes upgrading the SSL and PKCS#11 packages, as the default packages in the Raspberry Pi are outdated.

sudo apt update && sudo apt upgrade
sudo apt -y install autoconf automake libtool pkg-config gcc libssl-dev \

libcurl4-gnutls-dev libdbus-1-dev libglib2.0-dev autoconf-archive libcmocka0 \

libcmocka-dev net-tools build-essential git pkg-config gcc g++ m4 libtool \

automake libgcrypt20-dev libssl-dev uthash-dev autoconf doxygen pandoc \

libsqlite3-dev python-yaml p11-kit opensc gnutls-bin libp11-kit-dev \

python3-yaml cscope

sudo apt-get build-dep libengine-pkcs11-openssl1.1

The preceding steps build the basic dependencies to update the Raspberry Pi with the required libraries for compiling the source code in the subsequent steps.

Download the TPM2 software repositories

Download the following repositories:

• git clone https://github.com/tpm2-software/tpm2-tss
• git clone https://github.com/tpm2-software/tpm2-tools
• git clone https://github.com/tpm2-software/tpm2-abrmd
• git clone https://github.com/tpm2-software/tpm2-pkcs11
• git clone https://github.com/OpenSC/libp11.git

Install a recent version of libp11

Unfortunately, the version of the libp11 PKCS#11 engine for OpenSSL provided on Raspbian Stretch is too old (0.4.4) and not compatible with this software. Install it manually from the repositories. Compile and install the correct version:

cd libp11
git checkout libp11-0.4.9
./bootstrap
./configure
make -j4
sudo make install
cd ..

Download the autoconf-archive and deploy to the projects

The version of autoconf-archive provided on Raspbian Stretch is not compatible with the TPM software stack. Download it manually and copy it to the respective repositories.

wget https://github.com/autoconf-archive/autoconf-archive/archive/v2018.03.13.tar.gz
tar -xvf v2018.03.13.tar.gz
cp -r autoconf-archive-2018.03.13/m4/ tpm2-tss/
cp -r autoconf-archive-2018.03.13/m4/ tpm2-abrmd/
cp -r autoconf-archive-2018.03.13/m4/ tpm2-tools/
cp -r autoconf-archive-2018.03.13/m4/ tpm2-pkcs11/

Install the TPM2 Software Stack library

Install the tpm2-tss library.

cd tpm2-tss
git checkout 740653a12e203b214cba2f07b5395ffce74dfc03
./bootstrap -I m4
./configure --with-udevrulesdir=/etc/udev/rules.d --with-udevrulesprefix=70-
make -j4
sudo make install
sudo useradd --system --user-group tss
sudo udevadm control --reload-rules && sudo udevadm trigger
sudo ldconfig
cd ..

Install the TPM2 Access Broker and Resource Manager (tpm2-abrmd)

Install the TPM2 Access Broker and Resource Manager.

cd tpm2-abrmd
git checkout 2.1.1
./bootstrap -I m4
./configure --with-dbuspolicydir=/etc/dbus-1/system.d \
with-systemdsystemunitdir=/lib/systemd/system \
with-systemdpresetdir=/lib/systemd/system-preset \
datarootdir=/usr/share
make -j4
sudo make install
sudo ldconfig
sudo pkill -HUP dbus-daemon
sudo systemctl daemon-reload
sudo systemctl enable tpm2-abrmd.service
sudo systemctl start tpm2-abrmd.service
dbus-send --system --dest=org.freedesktop.DBus --type=method_call \
print-reply /org/freedesktop/DBus org.freedesktop.DBus.ListNames \
| grep "com.intel.tss2.Tabrmd" || echo "ERROR: abrmd was not installed correctly!"
cd ..

Install the TPM2 Tools (tpm2-tools)

Install the TPM2 Tools.

cd tpm2-tools
git checkout 3e8847c9a52a6adc80bcd66dc1321210611654be
./bootstrap -I m4
./configure
make -j4
sudo make install
cd ..

Install adaptation of PKCS#11 for TPM2 (tpm2-pkcs11)

Install the adaptation of PKCS#11 for TPM2.

sudo mkdir -p /opt/tpm2-pkcs11
sudo chmod 777 /opt/tpm2-pkcs11
cd tpm2-pkcs11/
git checkout a82d0709c97c88cc2e457ba111b6f51f21c22260
./bootstrap -I m4
./configure --enable-esapi-session-manage-flags --with-storedir=/opt/tpm2-pkcs11
make -j4
sudo make install
cd ..

Using the PKCS11 Provider for AWS IoT Greengrass hardware security.

In this section, you create a keystore in which you create the keys and refer to the same in the AWS IoT Greengrass configuration.

Initializing the keystore and token

The keystore is created under /opt/tpm2-pkcs11. The location should be readable and writeable to the logged-in user.

cd tpm2-pkcs11/tools/

Initializing the keystore

Use the following command:

./tpm2_ptool.py init --pobj-pin=123456 --path=/opt/tpm2-pkcs11/

The details of the options used in this command are:

--pobj-pin POBJ_PIN   The authorization password for adding secondary objects under the primary object.
--path PATH           The location of the store directory.

Initializing the token

Use the following command:

./tpm2_ptool.py addtoken --pid=1 --pobj-pin=123456 --sopin=123456 --userpin=123456 --label=greengrass --path=/opt/tpm2-pkcs11/

The details of the options used in this command are:

--pid PID             The primary object id to associate with this token.

--sopin SOPIN         The Administrator pin. This pin is used for object recovery.

--userpin USERPIN     The user pin. This pin is used for authentication for object use.

--pobj-pin POBJ_PIN   The primary object password. This password is use for authentication to the primary object.

--label LABEL         A unique label to identify the profile in use, must be unique.

--path PATH           The location of the store directory.

Adding a key

Use the following command:

./tpm2_ptool.py addkey --algorithm=rsa2048 --label=greengrass --userpin=123456 --key-label=greenkey --path=/opt/tpm2-pkcs11/

The details of the options used in this command are:

--id ID               The key id. Defaults to a random 8 bytes of hex.

--sopin SOPIN         The Administrator pin.

--userpin USERPIN     The User pin.

--label LABEL         The tokens label to add a key too.

--algorithm {rsa2048,ecc256}
                      The type of the key. Only RSA 2048 and ECC 256 are supported.

--key-label KEY_LABEL
                      The key label to identify the key. Defaults to an integer value.

--path PATH           The location of the store directory.

Finding the PKCS#11 URL

AWS IoT Greengrass and other tools use a PKCS#11 URL to find the token and key object. This URL can be determined using p11tool:

This yields a result similar to the following:

pkcs11:model=p11-kit-trust;manufacturer=PKCS%2311%20Kit;serial=1;token=System%20Trust
pkcs11:model=SLI9670;manufacturer=Infineon;serial=0000000000000000;token=greengrass

A screenshot of the same in this setup looks similar to the following:

The URL for the private key can then be determined using the following command:

$ p11tool --list-privkeys pkcs11:manufacturer=Infineon

This yields a result similar to the following:

Object 0:
    URL: pkcs11:model=SLI9670;manufacturer=Infineon;serial=0000000000000000;token=greengrass;id=%37%33%61%36%62%30%31%37%39%66%39%33%39%38%62%38;object=greenkey;type=private
    Type: Private key
    Label: greenkey
    Flags: CKA_NEVER_EXTRACTABLE; CKA_SENSITIVE;
    ID: 37:33:61:36:62:30:31:37:39:66:39:33:39:38:62:38

The result is shown in the following screenshot:

The URL can be trimmed of certain components, as long as it remains unique, such as in the following example:

pkcs11:model=SLI9670;manufacturer=Infineon;token=greengrass;object=greenkey;type=private

This setup uses the complete URL, as follows:

pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=greengrass18;object=greenkey;type=private

The PIN can be appended to the URL:

pkcs11:model=SLI9670;manufacturer=Infineon;token=greengrass;object=greenkey;type=private;pin-value=123456

This is the URL to use for the AWS IoT Greengrass configuration.

Generate a certificate signing request

Use the following command to generate a certificate signing request:

openssl req -engine pkcs11 -new -key "pkcs11:model=SLI9670;manufacturer=Infineon;token=greengrass;object=greenkey;type=private;pin-value=123456" -keyform engine -out /tmp/req.csr

Answer the questions that OpenSSL asks you for the certificate signing request. This information is incorporated into the certificate.

After you have completed the request, log in to AWS and navigate to the AWS IoT console. On the left navigation pane, under Security, choose Certificates, Create.

Choose Create with CSR and select the CSR file that you created using OpenSSL (for example, /tmp/req.csr).

Download the root.ca.crt and the resulting xxxxxx-certificate.pem.crt, where xxxxxx stands for a unique ID, and copy both to /greengrass/certs/.

Before closing the window, activate the certificate and attach it to an object or policy in the dialog on the AWS IoT security page.

Configure and run AWS IoT Greengrass with HSI

To enable and use the TPM as HSI, enable it in the AWS IoT Greengrass config. Edit /greengrass/config/config.json and replace the configuration with the content based on your OpenSSL configuration and location of the keys. A complete example of the AWS IoT Greengrass configuration with the setup completed in the preceding sections resembles the following:

{
  "coreThing" : {
    "thingArn" : "arn:aws:iot:<AWS_REGION>:<AWS_ACCOUNT_NUMBER>:thing/<GG_Thing_Name>",
    "iotHost" : "XXXXXXXXXXXXXXX-ats.iot.us-east-1.amazonaws.com",
    "ggHost" : "greengrass-ats.iot.us-east-1.amazonaws.com",
    "keepAlive" : 600
  },
  "runtime" : {
    "cgroup" : {
      "useSystemd" : "yes"
    }
  },
  "managedRespawn" : false,
  "crypto" : {
    "PKCS11": {
	"OpenSSLEngine": "/usr/lib/arm-linux-gnueabihf/engines-1.1/pkcs11.so",
	"P11Provider": "/usr/lib/arm-linux-gnueabihf/pkcs11/libtpm2_pkcs11.so",
	"SlotLabel": "greengrass18",
	"SlotUserPin": "123456"
    },
    "principals" : {
      "IoTCertificate" : {
        "privateKeyPath" : "pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=greengrass18;object=greenkey;type=private",
        "certificatePath" : "file:///greengrass/certs/2330b4c8b2-certificate.pem.crt"
      },
      "MQTTServerCertificate" : {
        "privateKeyPath" : "pkcs11:model=SLB9670;manufacturer=Infineon;serial=0000000000000000;token=greengrass18;object=greenkey;type=private",
        "certificatePath" : "file:///greengrass/certs/2330b4c8b2-certificate.pem.crt"
      }
    },
    "caPath" : "file:///greengrass/certs/root.ca.pem"
  }
}

Adjust the certificatePath, privateKeyPath, thingArn and iotHost accordingly. After this, you can start your AWS IoT Greengrass daemon using the following commands:

cd /greengrass/ggc/core
sudo ./greengrassd start

Conclusion

This post demonstrated how a TPM helps improve endpoint device security by providing a secured location for the storage of device primary keys. We hope this post was useful. Feel free to let us know your thoughts and feedback in the comments.