Skip to main content
aberdery
Associate II
July 2, 2019
Solved

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

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.

This topic has been closed for replies.
LionelD
LionelDBest answer
Visitor II
July 3, 2019

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

2 replies

LionelD
LionelDBest answer
Visitor II
July 3, 2019

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
aberderyAuthor
Associate II
July 3, 2019

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.