Skip to main content
A
aberdery
Visitor II
July 2, 2019
Solved

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

  • July 2, 2019
  • 2 replies
  • 1804 views

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.
    Best answer by LionelD

    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

    L
    LionelDAnswer
    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

    A
    aberderyAuthor
    Visitor 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.

    Terms & ConditionsAccessibility statement