Hi again,

for reference this is my solution for the Problem below:

1. Do NOT use CONFIG_MULTI_DTB_FIT if using cipher or signature In this case all DTBs are added in FIT Image. All DTBs are added before u-boot.dtb, so you have at least two entries. U-Boot does not search this list for cipher and signature, it uses the first entry ONLY. In the U-Boot Hexdump you find the cipher and signature entries, but they are in the SECOND DTB and not found.

2. Do NOT add '-1' or '#1' in cipher or signature U-Boot only looks for 'cipher' and 'signature' I did not realize this problem, because the Host Tools fit_check_sign accepts 'cipher-1' and 'signature-1', but U-Boot NOT.

If you have any of the above problems, U-Boot silently ignores the cipher and signature entries.

----------------------------------

Hi everyone, new User here.

First let me explain how we are using U-Boot: NXP MX6 Hardware, load FIT Image with Kernel, DTB, RamFS as one FIT-Image from MMC, bootm To secure the FIT we are hashing all 3 Parts using sha256 und signing the Config with our Certificate. In short we are following this process:

1. Generate Cert, name it "required-company-cert" here

2. Attach this Cert to dts/dt.dtb of U-Boot using mkimage -k <dir-with-above-cert> -K dts/dt.dtb -r

3. make U-Boot to attach the Cert with it, store it at a secure place and put it on several devices In 2. you can see that I used -r to store this cert as required. Using "fdtget u-boot.dtb /signature/required-company-cert required" I get "conf". So the Cert is attached to U-Boot and is marked as required for configurations. (To be sure, I used a hex editor to find the cert and the required in the final U-Boot image)

It is planned to never change U-Boot and FIT Updates are done using a dual image system (bootcount, altbootcmd) We create FIT images "test.itb" with Kernel, DTB, RamFS. 3 images using sha256, one configuration using above certificate.

For the following test I used the u-boot git master from today, using "make sandbox_defconfig". The FIT Images are checked using "tools/fit_check_sign -f <itb> -k u-boot.dtb"

1. Using the correct Cert I get:

Verifying Hash Integrity for node 'conf-1'... sha256,rsa4096:required-company-cert+

Verified OK, loading images

Signature check OK

2. Using no Cert I get:

Verifying Hash Integrity for node 'conf-1'... error!

for '(null)' hash node in 'conf-1' config node

Failed to verify required signature 'key-rtu-fit-sign'

3. Using the wrong Cert "tamper" I get: Verifying Hash Integrity for node 'conf-1'... sha256,rsa4096:tamper- error! Verification failed for '(null)' hash node in 'conf-1' config node Failed to verify required signature 'required-company-cert'

So fit_check_sign acts correctly by finding the cert 'required-company-cert' as required in u-boot.dtb

If I load any of these FIT Images in U-Boot only the sha256 hashes are checked, and nobody cares about the Certificate. (using iminfo here and bootm on our ARM Hardware) I can load any FIT Image with wrong Certs, or any Cert at all!

On analyzing the Problem in the Source Code I saw that U-Boot does not check Certs if it finds no "required" entry. In common/image-fit-sig.c, method "fit_config_verify_required_sigs" the "required" node is searched. As far as I can tell any FDT operation is done on the loaded FIT, I saw no access of the u-boot.dtb included in u-boot.

This makes no sense to me, as the u-boot.dtb included in u-boot must have the final word which Cert is to be used and required. Any information in the FIT must be regarded as possible tampered from a 3rd party.

Regards, Thomas