cancel
Showing results for 
Search instead for 
Did you mean: 

[secure boot] Is there a way to validate signed firmware externally (e.g without using BROM) ?

aberdery
Associate II

Hi,

I'm following https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot tutorial

I'd like to perform a few checks before programming OTP WORD 24 to 31 since, as usual, and as indicated in STM32MP1 reference manual:

An OTP word can be written in multiple shuts. The word value is updatable by adding bits to

1, but a bit already set to 1, cannot be written back at 0

I have generated signing keys.

I have TF-A firmware signed with them.

I can see TF-A header is indeed updated with a 512 bits signature value and a 512 bits pub key value (so as algorithm value).

Is there an existing implemented way to:

  • confirm publicKeyhash.bin is matching public key (and algorithm if I understand well) value embedded in firmware header ?
  • more generically, perform firmware authentication from an external host PC ?

This would be for me a way to be 101% sure before programming OTP.

Thanks in advance for any useful feedback.

Cheers,

Alexandre.

1 ACCEPTED SOLUTION

Accepted Solutions
LionelD
Associate II

Hi,

There is not yet a tool to manage such check.

If you use STM32 KeyGen tool and STM32 Signing Tool, there is no reason that your hash is not aligned with your key.

A quick check to confirm the HASH file from the binary signed can be (bash based):

dd if=$<signed_file> of=<key_file> bs=1 count=64 skip=108

sha256sum -b <key_file> | cut -f1 -d\ | xxd -r -p > <extracted_hash>

diff <extracted_hash> publickeyhash.bin

The most important is the way fuses are programmed and a tool is available in uboot to manage properly the fuse programming in the correct order. See https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot#Register_hash_public_key tool is stm32key.

Once it's done, fuses are programmed once for all but as the device is not closed, you can still use signed or non-signed images. If the HASH is wrong, authentication check will fail but board is not bricked (only warning in TF-A). You can still run non-signed binaries.

We are working to integrate a check inside the STM32 Signing Tool for this authentication check.

BR,

Lionel

View solution in original post

2 REPLIES 2
LionelD
Associate II

Hi,

There is not yet a tool to manage such check.

If you use STM32 KeyGen tool and STM32 Signing Tool, there is no reason that your hash is not aligned with your key.

A quick check to confirm the HASH file from the binary signed can be (bash based):

dd if=$<signed_file> of=<key_file> bs=1 count=64 skip=108

sha256sum -b <key_file> | cut -f1 -d\ | xxd -r -p > <extracted_hash>

diff <extracted_hash> publickeyhash.bin

The most important is the way fuses are programmed and a tool is available in uboot to manage properly the fuse programming in the correct order. See https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot#Register_hash_public_key tool is stm32key.

Once it's done, fuses are programmed once for all but as the device is not closed, you can still use signed or non-signed images. If the HASH is wrong, authentication check will fail but board is not bricked (only warning in TF-A). You can still run non-signed binaries.

We are working to integrate a check inside the STM32 Signing Tool for this authentication check.

BR,

Lionel

aberdery
Associate II

Fine for me.

On the other hand, I confirm that following https://wiki.st.com/stm32mpu/wiki/STM32MP15_secure_boot tutorial, secure boot is OK on my STM32MP1-DK2 device.

I also confirm that since my device is not "closed" I can continue using non signed firmware with it and that TF-A is clearly noticing the different use cases.

Thanks.