Can I use HAB SRKs for dm_verity?

Technical Support
, , , ,
1

Dear Toradex community,

HAB is working fine on my Verdin iMX8M Plus. The device is closed. Bootloader signature checking and FIT image signature checking - as described on Secure Boot is working correctly. My next goal is to get rootfs signature checking with dm_verity working as well.

From the meta files meta-toradex-security/classes/tdx-signed-fit-image.inc (FIT_GENERATE_KEYS=1) and openembedded-core/meta/classes/kernel-fitimage.bbclass (do_kernel_generate_rsa_keys), I can see that dm_verity would generate new RSA keys for checking the rootfs signature by default.

But, I already have the SRKs (super-root keys) for HAB. So, why should I generate yet another pair of keys!? Would it be reasonable to use the same SRK for dm_verity as for HAB?

If yes, should I use the CSF subkeys for UBOOT_SIGN_KEYNAME and the IMG subkeys for UBOOT_SIGN_IMG_KEYNAME?

Thanks,
Burkhard

2

Hi, I’m the Toradex AI Assistant. I’m in early beta, and I would appreciate your feedback.
The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:

Hello Burkhard,

Using the same Super Root Keys (SRKs) for dm-verity as for High Assurance Boot (HAB) on your Verdin iMX8M Plus is technically feasible and can simplify your secure boot and verification setup. However, it’s important to consider the security implications and best practices of reusing keys across different components and stages of the boot process.

The SRKs are primarily intended for securing the initial boot process, including verifying the bootloader and any subsequent images loaded by the bootloader, such as the Linux kernel and device tree in a FIT (Flattened Image Tree) format. dm-verity, on the other hand, is designed to ensure the integrity of the runtime filesystem, verifying blocks of the filesystem against a precomputed hash tree.

Reusing SRKs for dm-verity could streamline your security setup, as you mentioned, by not requiring the generation and management of an additional set of keys. However, this approach consolidates the risk; if the SRKs were to be compromised, it would potentially expose both the boot process and the filesystem integrity verification to vulnerabilities.

If you decide to proceed with using the SRKs for dm-verity, you should indeed use the appropriate subkeys for their respective purposes. The CSF (Command Sequence File) keys, typically used for signing the bootloader and kernel, could be repurposed for UBOOT_SIGN_KEYNAME, while the IMG keys, if designated for image signing, could be used for UBOOT_SIGN_IMG_KEYNAME. This aligns with the general principle of using keys for their intended security domains, even within the scope of reusing the SRK set.

It’s crucial to ensure that the keys are securely managed and that their usage for both HAB and dm-verity does not introduce any unintended security weaknesses. Regularly reviewing your security posture and considering the implications of key reuse in the context of your overall system security strategy is advisable.

Best regards,
Toradex AI Assistant

Please, also check if these links can help you solve your problem:

Secure Boot on Torizon OS | Toradex Developer Center.

3

Greetings @bstubert,

Before we get into any discussions. Just want to make sure I understand your use-case. It sounds like you just want to use the same set of keys/credentials in multiple parts of your system? Is that correct, more or less?

I assume this is just for ease-of-use or convenience or is there a reason for this?

Best Regards,
Jeremias

4

Hi Jeremias,

Not quite. I need to decide whether it’s better to use the same set of keys (the HAB SRKs) for bootloader/FIT image signature checking and for rootfs signature checking (verity) - or not. I lack the experience for such a decision.

How do your customers typically decide? And why?

My reason for using the same keys is not only ease-of-use (sure, keeping one set of private keys is easier than two sets - but only minimally). My reason is morethat the public keys are nearly impossible to screw with, as they are in the e-fuses. One attack vector less. Where are the public keys stored if I choose to generate them for dm_verity (FIT_GENERATE_KEYS=“1”)? I don’t know.

Thanks,
Burkhard

5

whether it’s better to use the same set of keys (the HAB SRKs) for bootloader/FIT image signature checking and for rootfs signature checking (verity) - or not.

From a purely objective security standpoint, the answer would be no. Using the same set of keys/credentials for everything creates a singe point of failure in terms of possible attack vectors. Getting this single set of keys would make it technically possible for an attacker to access everything, rather than just the part the keys were used for.

Now whether this is a realistic risk, depends on your system. Maybe it doesn’t introduce much risk at all to your system, it’s a case by case basis when it comes to security risk.

How do your customers typically decide? And why?

We’re not privy to all of our customer’s security/key handling since it’s a sensitive topic that not all customer’s want to share. I can say at least with customers that are initially playing with our security meta-layer they just stick with default settings for the most part. Meaning different signing keys for different parts of the system. Now whether they stick with this in production I can’t say for sure.

My reason is morethat the public keys are nearly impossible to screw with, as they are in the e-fuses.

Could you elaborate regarding this concern. What is your fear with something happening to your public keys?

Generally it’s the security of the private key you should be concerned about.

Where are the public keys stored if I choose to generate them for dm_verity (FIT_GENERATE_KEYS=“1”)? I don’t know.

Okay, this is two different topics now to be clear. FIT image signing and dm verity are two separate things that aren’t inherently connected.

FIT image signing is a standard feature in U-Boot as described here: u-boot/doc/usage/fit/signature.rst at master · u-boot/u-boot · GitHub

The FIT image which is a collection of device trees, kernel, and other binaries is signed by your private key. The public key is stored in the device tree of U-Boot. This allows U-Boot to verify the FIT image prior to using it to boot.

DM verity is a kernel feature: dm-verity — The Linux Kernel documentation

This mechanism doesn’t use keys in the same way FIT image signing does. Here the root file system is generated using the dm-verity kernel feature. This produces a root hash that represents the root file system. This hash is then added to the ramdisk at build time. During boot, the root hash for the current root filesystem is calculated. If it does not match the hash that was stored in the ramdisk, then that suggests the root filesystem may have changed from the original build. With dm verity the filesystem partition is setup as read only so changes “shouldn’t” happen.

Best Regards,
Jeremias

1 Like
6

Thanks for your instructive answer.

Could you elaborate regarding this concern. What is your fear with something happening to your public keys? Generally it’s the security of the private key you should be concerned about.

We go to great lengths to store the public keys for the bootloader signature check in one-time progammable memory (e-fuses). We abandon this caution with the public keys for the FIT image (containing the Linux kernel, DTBs, possibly the root hash for dm_verity, etc.). Why?

I think this asymmetry makes the following attack easier. If an attacker has found a way to download files like the FIT image to the device, he can get a malicious FIT image running. He signs the FIT image with his own private key and puts the public key on the device for passing the signature check.

I think that such an attack is not possible, if the public keys are stored in e-fuses, where they can’t be modified. The attacker would need the original private keys to sign the FIT image. At least, this would be an explanation why we store the SRKs in e-fuses. I might be wrong though.

And yes, you are absolutely right that the FIT keys and the dm_verity root hash are two very different things.

Cheers,
Burkhard

7

I think this asymmetry makes the following attack easier. If an attacker has found a way to download files like the FIT image to the device, he can get a malicious FIT image running. He signs the FIT image with his own private key and puts the public key on the device for passing the signature check.

You’re thinking of each competent (HAB, FIT image) in a vacuum separate from one another. The reason we employ these different verification/security techniques is to form a more rigid chain-of-trust.

If you have HAB and FIT image signing properly implemented then this scenario you proposed would not be easily possible.

As I said previously the public keys for the FIT image are embedded in U-Boot’s device tree, which is part of the U-Boot binary itself. For an attacker to place his own public keys they would have to replace U-Boot. But if they replace U-Boot, then HAB would detect this and prevent the device from booting. As you discussed this is much harder to break since now the keys for HAB are in the e-fuses.

U-Boot can be trusted because of HAB. U-Boot then verifies the FIT image and because we trust U-Boot we can trust the FIT image now, and so on for subsequent components.

In a chain of trust like this an attacker can’t just try and attack one part, they’d have to break the entire chain of trust to get anywhere in most cases. If you only had just FIT image signing on your system, then yes the scenario you proposed would be an issue indeed. But, that’s why the chain of trust is implemented in the way it is.

Best Regards,
Jeremias

1 Like
8

Hi Jeremias,

Knowing that the key for the FIT image is stored in the u-boot device tree was the last puzzle piece I need.

Thanks for your helpful explanations,
Burkhard

1 Like
9

Glad I was able to help clarify.