Creating Encrypted Data Partitions Using the Yocto meta-toradex-security Layer

Introduction

In the previous article, we introduced how to create a separate partition using the meta-toradex-security layer. Next, we will explain how to use encryption features on that partition, perform read and write performance tests, and if you are still interested, the final section will elaborate on the principles behind partition encryption. The technical implementation details are hidden within the recipes of meta-toradex-security, allowing users to enable partition encryption with just a few simple configurations.

Yocto Project Configuration

As in the previous article, we first need to set up the #Yocto Project build environment. Here, we will take the Verdin #iMX8MP as an example. Simply add the following two lines of configuration at the end of local.conf.

INHERIT += "tdx-tezi-data-partition tdx-encrypted"
TDX_ENC_STORAGE_LOCATION = "/dev/mmcblk2p3"

<span>tdx-encrypted</span> has been added, allowing the compiled image to use partition encryption. TDX_ENC_STORAGE_LOCATION is used to configure the partition that needs to be encrypted. On the Verdin iMX8MP, the eMMC will be mounted under /dev/mmcblk2, and mmcblk2p3 is the third partition that needs to be newly created. ‘TDX_ENC_STORAGE_LOCATION’ can also be set to /dev/sda1 or /dev/mmcblk0p1, corresponding to external USB drives, SD cards, etc.

To provide security and efficiency for encryption, meta-toradex-security can utilize cryptographic units, such as the CAAM (Cryptographic Accelerator and Assurance Module) module on the iMX8M Plus SoC. It also supports external TPMs; for example, on the Verdin AM62, where there is no built-in cryptographic unit in the SoC, meta-toradex-security can use the TPM on the baseboard, such as the Mallow baseboard. For modules using TPM, TDX_ENC_KEY_BACKEND = “tpm” also needs to be added to local.conf.

Then, use the bitbake command to compile the image.

bitbake tdx-reference-minimal-image

Partition Encryption Testing

After installing the system and rebooting, you can see /dev/mapper/encdata, which is the encrypted device corresponding to the /dev/mmcblk2p3 DATA partition, mounted at the /run/encdata directory. In the local.conf file, the TDX_ENC_STORAGE_MOUNTPOINT parameter can be used to change the mount path.

~# mount -l
/dev/mapper/encdata on /run/encdata type ext4 (rw,relatime)

Creating Encrypted Data Partitions Using the Yocto meta-toradex-security Layer

The Linux file system RFS uses a non-encrypted partition. We will write and read a 1GB file to both the encrypted /run/encdata and the non-encrypted /home/root directories to compare the impact of encryption on read and write operations.

#write
fio --name=test --filename=testfile.tmp --size=1G --bs=256k --iodepth=64 \
    --readwrite=write --direct=1 --ioengine=libaio --gtod_reduce=1 

#read 
fio --name=test --filename=testfile.tmp --size=1G --bs=256k --iodepth=64 \
  --readwrite=read --direct=1 --ioengine=libaio --gtod_reduce=1

The test results are as follows:

/run/encdata

/home/root

Writing 1GB file

32.8MB/s

61.9MB/s

Reading 1GB file

32.6MB/s

314MB/s

Implementation Principles

As previously mentioned, enabling and using encrypted partitions with meta-toradex-security is very straightforward, and for applications, the underlying encryption is transparent. If you are still interested in the implementation principles, please continue reading the content below.

Creating Encrypted Data Partitions Using the Yocto meta-toradex-security Layer

The #i.MX8 SoC has a CAAM module that can be used for key generation, encryption, and decryption operations. Typically, users do not directly call the CAAM API for related operations. To better protect the keys, we use a Linux kernel feature called Trusted Keys. Trusted Keys can generate and maintain a key in kernel space, while in user space, it is an encrypted file (encrypted blobs) that cannot be directly accessed. The encryption and decryption of the key are performed on CAAM, which serves as the Trust Source for Trusted Keys. For platforms without CAAM as the Trust Source, such as Verdin #AM62, we can also use an external #TPM or even a #TEE (Trusted Execution Environment). These are all supported in meta-toradex-security.

Another kernel feature, dm-crypt, implements transparent partition encryption. dm-crypt uses a key to encrypt files that need to be written to the /run/encdata directory. This key can be stored in a directory under the filesystem partition RFS, defaulting to /var/local/private/.keys/tdx-enc-key.blob. If RFS is a read-only filesystem, tdx-enc-key.blob can also be directly stored on eMMC. However, tdx-enc-key.blob is not the key used directly for encryption and decryption. As mentioned earlier, the maintenance of the key is handled by Trusted Keys.

In CAAM, an encryption key is first generated, which never leaves CAAM. This key is encrypted using either the Test key or OTPMK Key, also located in CAAM, and handed over to Trusted Keys in kernel space for maintenance. Trusted Keys maps a key for dm-crypt and stores it in /var/local/private/.keys/tdx-enc-key.blob. When an application in user space needs to read or write files in /run/encdata, dm-crypt submits tdx-enc-key.blob to Trusted Keys. Trusted Keys finds the corresponding key in kernel space and hands it over to CAAM. In CAAM, the Test key or OTPMK Key can be used to decrypt the encryption key, which is then used to encrypt or decrypt data in CAAM. Throughout this process, the Test key/OTPMK Key and encryption key never leave CAAM, and all encryption and decryption operations are performed within CAAM. Since /var/local/private/.keys/tdx-enc-key.blob is not the key used directly for encryption and decryption, even if this key is leaked, it will not compromise the data originally located in /run/encdata.

For modules using CAAM, such as Verdin #iMX8MM, Verdin iMX8MP, Apalis #iMX8QM, etc., if the Secure Boot feature is not enabled, as mentioned earlier, CAAM will use a pre-provisioned Test key to encrypt the key, which is not secure and is not recommended for production environments. Once Secure Boot is enabled, CAAM will use the OTPMK Key to encrypt the key. This is a 256-bit randomly generated key that is burned into CAAM during the fuse process. Therefore, this key must be kept secure.

Conclusion

With the help of meta-toradex-security, users can easily and securely use encrypted partitions to protect data and applications. More practical features from meta-toradex-security will be introduced in subsequent articles, so stay tuned.

Leave a Comment