Torizon: enabled encryption of ext4 with TEZI

Technical Support
, , ,
1

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:

grafik
grafik839×542 65.5 KB

Best regards,
Markus

2

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

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

3

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

4

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

5

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

6

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

7

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

8

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.

9

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

10

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

11

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.

12

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

13

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