Hello,
I’m building my own image in Yocto based on the torizon-minimal and want to use fscrypt for encryption.
fscrypt needs the active option “encrypt” in ext4: GitHub - google/fscrypt: Go tool for managing Linux filesystem encryption
Is it possible to enable this option when creating the filesystem with the Easy Installer?
I tried by adding
TEZI_ROOT_FSOPTS += "-O encrypt"
to my local.conf
. But I get the following error:
Best regards,
Markus
Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!
Did you like my answer?

Hello!
Yes, you can enable encryption when creating the filesystem using the Toradex Easy Installer. This is achieved by utilizing the mkfs_options
property within the content section of your image.json
file. You can find more details about this in the Toradex documentation here and here.
To enable encryption, you can modify your image.json
file as follows:
{
"content": {
"filesystem_type": "ext4",
"mkfs_options": "-O encrypt",
"label": "RFS"
}
}
The mkfs_options
property allows you to pass additional options to the mkfs
command when creating ext3/ext4/fat filesystems. More information on this can be found here.
If you are working with the Yocto Project, you might find it helpful to review the article on building reference images with Yocto Project/OpenEmbedded, which is available here.
I hope this helps! If you have any more questions, feel free to ask.
Best regards,
Toradex AI Assistant
Ok, this is weird.
When adding the encryption option to the mkfs_option
by
TEZI_ROOT_FSOPTS += "-O encrypt"
then the image.json
file looks like this:
"mkfs_options": " -O encrypt",
There is a leading space before the -O
which seems to be the problem. When I remove this space the installation of the image with the Easy Installer works without problems.
Best regards,
Markus
Greetings @Mowlwurf,
Just to clarify, did adding the mkfs options as you describe result in the encryption support you were looking for?
As for the mysterious space. Looking at our bbclass that handles the logic for Easy Installer: image_type_tezi.bbclass « classes - meta-toradex-bsp-common.git - Toradex BSP layer, recipes common to all modules
I don’t see anywhere where we may be adding an explicit space. I believe the issue may be with the appending logic in Yocto. When using the +=
appending assignment it adds an implicit space as documented here: 3 Syntax and Operators — Bitbake dev documentation
Best Regards,
Jeremias
Hello @jeremias.tx,
yes, adding "-O encrypt"
to "mkfs_option"
gives me the encryption option enabled in the ext4 filesystem.
$ tune2fs -l /dev/mmcblk0p1 | grep features
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent 64bit flex_bg encrypt sparse_super large_file huge_file dir_nlink extra_isize
It is also better to use TEZI_ROOT_FSOPTS:append = " -O encrypt"
in the local.conf
instead of the += appending assignment.
Now fscrypt would be ready to use:
$ fscrypt status
filesystems supporting encryption: 1
filesystems with fscrypt metadata: 1
MOUNTPOINT DEVICE FILESYSTEM ENCRYPTION FSCRYPT
/ /dev/mmcblk0p1 ext4 supported Yes
But unfortunately the /.fscrypt
directory doesn’t survive an update with aktualizr-torizon. So the access to encrypted data will be lost after an update.
Is there any chance to make this work? Or do I have to use an alternative solution for filesystem based encryption (e.g. gocryptfs)?
Best regards,
Markus
Is there any chance to make this work? Or do I have to use an alternative solution for filesystem based encryption (e.g. gocryptfs)?
I see, my assumption here is that this got lost during the update since it was kind of added outside of OSTree, therefore OSTree wasn’t tracking it and it got lost during the update. To be clear, we haven’t tried this exact use-case ourself so I can’t say at the moment if there is a proper method to make this work in the expected way.
But, first maybe let’s take a step back. From what I can gather here you want to do something with filesystem encryption. Could you maybe elaborate on your exact use-case, just so that we have a better understanding of what it is you want to achieve and what you expect.
Best Regards,
Jeremias
With pleasure.
We are developing a kind of measuring device with Torizon as the basis, in which the user can create several projects. These are stored in the torizon user’s home directory.
Since we have to comply with the CRA, this user data must be protected against unauthorized access. As it is easy to read or manipulate this data with the Easy Installer via the COM interface, and access via the COM interface is to be maintained for service purposes, the data must be encrypted.
As far as I understand it, there are two basic methods of encryption: block-device and file system based.
I have read the Toradex documentation on block-device encryption. The problem of this variant is that we do not have a TPM on our carrier board and the implementation, test and transfer to production of CAAM + Secure Boot is currently not possible for us in sufficient time. Our personnel resources are quite limited…
Or is it possible to provide this type of encryption via a device update?
Implementing encryption on the basis of an existing file system therefore seemed to be a better solution for us. I have found three possible tools, all of which have one major drawback:
So I’m kind of stuck right now.
Best regards,
Markus
Howdy,
Have you looked at the meta-toradex-security layer?
You could use this to provide partition encryption via the tdx-enc-handler service.
This layer will also add the required kernel configs to enable what is required.
Hi @izzycoding,
thank you for your hint.
I know that Toradex offers partition encryption with dm-crypt. But as I wrote in post #7, we would have to use CAAM and therefore Secure Boot because of a missing TPM. And we currently don’t have the manpower for that.
And since file system-based encryption would be completely sufficient, that seemed to me to be the simpler option.
Best regards,
Markus
Hi @Mowlwurf,
What is your timeline for needing something like this?
I did mention your use case internally with our team, but it’s admittedly something we haven’t tried yet. Meaning it would take us some time to provide anything here. We can discuss this further with our team if it’s vital and urgent for your system.
Best Regards,
Jeremias
I don’t believe you need SecureBoot to use the CAAM for encryption. Admittedly it will be using a temp key until you do the SecureBoot fuse. But that doesn’t make it not work.
We originally only used the partition encryption bit and the did SecureBoot and then added signed rootfs.
Just add “tdx-enc-handler” to you INSTALL:append for your image and set the relevant variables to point at the required partition.
Also to note you can just use a password instead of using CAAM until you have time to sort SecureBoot as an initial stop-gap.
Hi @jeremias.tx,
Since your colleague @bruno.tx was able to give us a suitable alternative for data encryption (Write recipe for gocryptfs - #3 by bruno.tx), there is currently no urgency for fscrypt to work with ostree.
However, since fscrypt is a much more convenient and secure solution than GnuPG or OpenSSL, it would definitely be an interesting feature.
Best regards,
Markus
I see, that’s good to hear then. Glad you were able to find a path forward. Also appreciate the feedback on your use-case.
Best Regards,
Jeremias