Protecting MQTT Communication and Device Data via Trusted Platform Module

Wherever connected devices are utilized, it is essential to pay special attention to security. It is crucial to assess the existing risks in order to implement appropriate measures. A device that is publicly accessible, such as a surveillance camera, requires more careful consideration than a device that is physically secured and accessible only to authorized personnel.

This article examines a project that employed a Trusted Platform Module (TPM) to mitigate the assessed security risks. A Trusted Platform Module serves a multitude of important use cases that enhance device security. It can generate, securely store, and manage cryptographic keys, providing a robust foundation for data protection. Additionally, a TPM is capable to verify the integrity of software and firmware during the boot process, ensuring that only authentic and untampered components are loaded. By establishing secure boot environments, it safeguards the system from potential threats right from startup. Furthermore, the TPM plays a vital role in authentication and attestation, enabling devices to prove their identity and integrity, thereby confirming that they are indeed what they claim to be.

The following sections will detail the setup, the challenges encountered, and the chosen solution.
Additionally, it will illustrate how to integrate the TPM into Yocto and provide general guidance on working with the TPM.

Initial Situation

The hardware in use is a custom development based on the Raspberry Pi Compute Module 4. This hardware functions as an edge device, designed to facilitate both local and cloud access. External hardware is connected to the edge device, utilizing protocols such as Modbus TCP or Modbus RTU. To support these functionalities, the edge device is equipped with the necessary hardware modules.

The connection to the cloud is established via MQTT. All locally generated data is synchronized with the cloud using this protocol. Device settings can be configured both locally and through the cloud interface.

Local access to the device is difficult for unauthorized individuals. The edge device is typically located on the premises and is additionally secured within a restricted area. If someone were to gain physical access, the potential breach of the edge device would be the least of the concerns (a matter of weighing risks). However, the connection to the cloud and external access must be restricted and secured.

Key data of the system:

Hardware: Custom hardware based on Raspberry Pi Compute Module 4
Operating System: Yocto Linux (Kirkstone – by the time of writing this article)
Update mechanism: AB updates (Mender)
Partitioning: 2x rootfs (AB), 1x data partition, which is not affected by updates, read-only rootfs, no execute flag for data partition
TPM: Infineon SLB9670

There are two key issues that need to be addressed:

1. Serial Number Storage: Each device has a unique serial number that must be stored securely. It is essential that this serial number remains intact through factory resets, system updates, and even after a full flash of the storage. Consequently, it cannot be stored within the device’s storage itself.
2. MQTT Credentials: The device requires MQTT credentials from the Cloud, which must be encrypted for secure transmission. It is important to note that each device will have its own distinct MQTT credentials.

Approach

Serial number

A TPM offers the possibility to store the serial number in non-volatile (NV) space during the device provisioning process. This method ensures that the serial number remains intact through factory resets, updates, and even a full flash of the storage. Furthermore, the serial number is accessible to everyone since it is not stored in an encrypted format. To prevent accidental overwriting, it should incorporate some form of write protection. However, it is important to note that with root access, it remains possible to delete the serial number and reset it. How to define the NV space and how to store the serial number is explained in detail in the Chapter Store serial number in NV space.

MQTT

Since we are having a read-only rootfs and a no-execute flag on the /data partition, this offers the possibility to encrypt a password with a public key or a TPM key and store this file on the /data partition. Only the TPM can decrypt this password, since the private key is kept safe and cannot be extracted from the TPM. Furthermore, the TPM can only be accessed with root permissions, and the only application that is able to interact with the TPM is our own. The attacker has to obtain root access to get the password, but in this case the attacker has a lot of other possibilities, which might be way more interesting for him.

The following diagram illustrates the simplified communication between the edge device and the cloud during the initial boot. An additional authentication step is involved, but is not depicted here. For simplicity, envision that during provisioning, the serial number is briefly activated on the cloud side to facilitate the registration process.

Provisioning

Understanding the provisioning process of a device is essential, and the following key steps are involved:

• The serial number is automatically written to the NV storage of the TPM.
• The Yocto image is automatically flashed onto the device.
• The device undergoes automated testing to ensure, among other things, that the externally connected hardware is functioning properly.
• The device is registered in the cloud. At the time of writing, this process was partially automated, requiring a manual step to accept the device on the cloud side.

Hands on Yocto

This chapter outlines the necessary adjustments to Yocto for supporting the TPM.
Given our custom hardware, we have introduced a new machine configuration based on the Raspberry Pi Compute Module 4 configuration. This machine configuration details all hardware-related aspects that differ from the Compute Module 4, providing an ideal location to incorporate the requirements for the TPM.

The extension of the machine configuration file is as follows:

Since our custom hardware supports the tpm2 feature set, this is set as MACHINE_FEATURE.

The operating system requires accurate information on how to interact with the TPM. To facilitate this, a Device Tree Overlay is necessary, as it provides the essential details about the additional hardware. For the overlay to be loaded during the device’s boot process, it must be included in the config.txt file (specific to Raspberry Pi). This is achieved by appending the name of the Device Tree Overlay to the RPI_EXTRA_CONFIG setting.

Additionally, several packages are required to effectively use and interact with the TPM from a user or application perspective (IMAGE_INSTALL). For instance, tpm2-tools installs all tpm2 commands in the /usr/bin directory. To enable the installation of these packages, it is essential to add the meta-security layer to the bblayers.conf file.

The device tree overlay looks like the following:

The Device Tree Overlay is primarily based on the one provided by Infineon, with minor adjustments, such as setting the chip select to 1 for this specific hardware. This configuration may vary depending on your hardware design. Furthermore, the TPM is connected to the Serial Peripheral Interface of the Raspberry Pi, utilizing GPIO pins 18-21, which is also reflected in the Device Tree Overlay.

To incorporate the Device Tree Overlay, the linux-raspberrypi recipe must be extended using a .bbappend file (named linux-raspberrypi_%.bbappend):

Hands on TPM

Store serial number in NV space

This chapter details the process of storing the serial number in NV space using CLI commands on the device. In our setup, this operation is performed automatically via script during the provisioning of each device.

How to define a NV space

In order to store the serial number of the device a NV storage space needs to be defined.
This space should be only writable once to prevent that it will be accidentally overwritten by the application. The serial number is written during the provisioning of the device. The NV space can be deleted with root access which offers the possibility to change the serial number (e.g. for refurbishing).

First, an authorization session is initiated to establish a policy using TPM2_CC_NV_Write, which ensures that the NV space can only be written once. This policy is then saved in the nvwrite.policy file.

The “c“ at the end of tpm2_policynvwritten is not a typo; it is an argument that signifies the expected written state of the NV index. In this case, „c“ represents a clear state.

Occasionally, it is advisable to flush the context to prevent the TPM from running out of transient memory. This can be accomplished using the tpm2_flushcontext command.

The nv space is then defined via:

• -s = size in bytes
• -L = policy file
• -a = attributes
  • policywrite: A policy is required in order to write to this space.
  • authread: Authentication, e.g. a password, is required for reading. However, in this instance, the password is not provided; therefore, reading can be performed without a password.
  • ownerread: The TPM owner can read the data from nv space.

The output of this command is the NV index that is utilized, typically the next available index. In our scenario, the first usable address is 0x1000000.

The result of this can be seen via tpm2_nvreadpublic:

How to write to the NV space

First a policy session has to be initiated again with the TPM2_CC_NV_Write command code.

Afterwards the NV space can be written once via:

The contents of testWrite.txt will be written to address 0x1000000. It is important that the file size does not exceed the defined NV space size, which in this case is 20 bytes (as noted in the previous chapter). A policy session can be specified using the -P option.

As a result, the written attribute is now set, and any further write operations will be denied (as confirmed by tpm2_nvreadpublic):

If an attempt is made to write to this NV space again, the following error message will be displayed:

How to read the NV space

The read command is straightforward compared to the write command, as anyone is permitted to access this space.

• -s = size in bytes
• -C = context from which the read operation is performed. o refers to the owner context of the TPM.

Create key pairs for exchanging MQTT credentials

This chapter outlines the process of generating an RSA key pair for the encryption and decryption of MQTT credentials via CLI commands. In our setup, the key pair is generated by the application during the initial boot.

Create RSA Key for encryption and decryption (CLI)

The initial command, tpm2_createprimary, is used to create a primary key under the owner hierarchy (default). This command generates a context file, saved as primary.ctx, which facilitates further interactions with the TPM. Given that the TPM is not a particularly powerful computing unit, this process may take some time—approximately 35 seconds in our setup.

Subsequently, a default key is generated using tpm2_create. This key pair is then loaded with tpm2_load, producing a testkey.ctx file that can be utilized for encryption and decryption.

Keys can be recreated with the TPM, and using the same sequence and parameters will yield identical results, allowing for the consistent regeneration of this key pair whenever needed. To optimize this process, the key can be made persistent using tpm2_evictcontrol. This action results in a handle that can be employed for future interactions.

Encryption

The encryption of, for example, the content of a .txt file can be accomplished using tpm2_rsaencrypt:

The first parameter specifies the address of the persistent handle, while the second parameter indicates the output destination. In this instance, the encrypted data is saved to a file named encryptedFile in the current directory. The file secret.txt contains plain text, such as “hello world,“ which will be encrypted using the public key of the key pair.

After executing the command, the encryptedFile will not contain any readable text, for example:

Decryption

A decryption can be accomplished using tpm2_rsadecrypt:

The first parameter specifies the address of the persistent handle, which remains the same as for encryption. The second parameter indicates the output destination. In this case, the previously encrypted file will serve as input for decryption, and the output will be saved to a file named decryptedFile.

Get public key from persistent handle

The public key has to be transferred to the Cloud in order to encrypt the MQTT credentials e.g. via openssl.

It can be extracted using the following method:

• ${HANDLE} represents the persistent handle (stored via tpm2_evictcontrol, see previous chapter)

The public key is stored in testkey.pub and has the following format:

In order to encrypt with openssl the command looks like the following:

The MQTT credentials encrypted with OpenSSL can be decrypted directly on the device using tpm2_rsadecrypt. There is no need to utilize OpenSSL for the decryption process.

Summary

In this article, we explored how to utilize a TPM for securely storing a serial number in NV storage, ensuring its persistence through factory resets, system updates, and even complete storage flashes. We also discussed how to leverage a TPM to encrypt MQTT credentials for secure transmission between the device and the cloud, as well as the integration of a TPM into the Yocto environment.