Encrypting In Yocto With fscryptctl

I admit, I made a tiny mistake. In the file system encryption blog text, I talked about fscrypt. Both the kernel feature fscrypt and the userspace tool with the same name. However, since I’m mostly focusing on the embedded side of things in this blog, a better userspace tool to recommend for a small Linux system would most likely be fscryptctl. It is basically a simplified version of the fscrypt tool that can manage encryption keys, set up an encryption policy for a directory, and then lock & unlock the encrypted directory. To make up for my mistake, I’ll quickly go through how to add it to the Yocto build and show how to use it.

Yocto

Like fscrypt, also fscryptctl is available in meta-security. If you read my file system encryption blog text in full, you may remember that I complained about a broken fscrypt recipe. Upon closer inspection, it seems that there’s been some weird fusion between fscrypt and fscryptctl recipes that has caused the fscrypt recipe to get (at least) its SRCREV and version from fscryptctl recipe.

Anyways, to add the fscryptctl to your image, all you need to do is add it to IMAGE_INSTALL after you’ve added meta-security to your build:

IMAGE_INSTALL:append = " fscryptctl"

In addition to this, you’ll need a partition you can encrypt. If you’re using a .wic file to define the image, you can add something like the following line to it:

part /crypted --ondisk mmcblk0 --fstype=ext4 --mkfs-extraopts="-O encrypt" --label crypted --align 4096 --size 100

This is meant for Raspberry Pi image, other systems may require some tweaking. The important part is the --mkfs-extraopts option.

The size difference between the two fscrypt userspace tools is quite significant. fscrypt binary is 5.6MB (and an additional 5MB for the PAM library if you’re using that), while fscryptctl is a mere 67KB! Therefore, if you intend to do simple automated locking and unlocking of encrypted directories on a resource-constrained device, fscryptctl should be the go-to choice.

Example of fscryptctl Use

These instructions are quite similar to the key file protector instructions presented in the fscrypt example in the file system encryption blog text (this is the last time I’ll mention it, I promise). The fscryptctl commands here originate from the fscryptctl README. These commands are meant to be run on a live system after the device has been flashed with the built image that contains fscryptctl and a partition that is suitable for encryption.

First, we create the mount point and mount the example partition:

mkdir /crypted
# Your device type or number may be different
mount /dev/mmcblk0p3 /crypted

Then we’ll create a key file and the directory that should be encrypted:

# Note: This key should be stored securely!
# Leaving it to root with default access is not a good idea
dd if=/dev/urandom of=/secret.key bs=1 count=64
mkdir /crypted/test_dir

After that, we can add the key to the mount point and a policy to the directory:

# The first command outputs the key ID that is required when setting policy
fscryptctl add_key /crypted < /secret.key
fscryptctl set_policy <KEY_ID> /crypted/test_dir

We can use the key_status and get_policy commands to get some information about the encryption status. For example, with the key ID 5d08dbef6c1b0e80ba5f535343a9e175 following prints might be present:

root@raspberrypi4-64:~# fscryptctl key_status 5d08dbef6c1b0e80ba5f535343a9e175 /crypted
Present (user_count=1, added_by_self)

root@raspberrypi4-64:~# fscryptctl get_policy /crypted/test_dir
Encryption policy for /crypted/test_dir:
        Policy version: 2
        Master key identifier: 5d08dbef6c1b0e80ba5f535343a9e175
        Contents encryption mode: AES-256-XTS
        Filenames encryption mode: AES-256-CTS
        Flags: PAD_32
root@raspberrypi4-64:~#

Now it is possible to create files in the directory, for example, by using a simple echo command. Then, to lock the directory, we can remove the key from the mount point:

echo "Super secret stuff" > /crypted/test_dir/test_file
fscryptctl remove_key <KEY_ID> /crypted

This should encrypt the directory, and the file names should now be garbled. To unlock the directory and regain access to the sweet, sweet example files, add_key command can be run again:

fscryptctl add_key /crypted < /secret.key

Conclusion

I think I have now corrected my mistake. Thanks for reading, and like always, I hope you found this useful. If you want to learn more about fscrypt, I recommend reading my blog text about it (okay, this was the last time I’ll mention it).

Tags: encryptionlinuxsecurityyocto