2019-07-02 02:43 AM
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:
This would be for me a way to be 101% sure before programming OTP.
Thanks in advance for any useful feedback.
Cheers,
Alexandre.
Solved! Go to Solution.
2019-07-03 08:32 AM
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
2019-07-03 08:32 AM
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
2019-07-03 10:48 AM
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.