mbedTLS version 2.28.2.v2 upgrade on secure boot

[mr.1]

I would like to use the mbedTLS version 2.28.2.v2 on the secure boot for stm32h743ii controller. I have downloaded SBSFU v2.6.2 and Built the secure boot binary on top of the example project from H753 2_images_OSC folder. Secure boot is running the target hardware. But the .sfb file is not upgradable with the secure boot and it throws the FW authentication error.

I suspect that the .sfb file created by windows executable exe is not using the integrated mbedTLS version 2.28.2.v2 somehow. Please suggest the next step.

Regards,

Rakkumuthu R

[Bubbles]

hi @mr.1 ,

what was the reason to replace the crypto engine in the first place?

The encryption and authentication of the sfu is based on the algorithms you select in the SECBOOT_CRYPTO_SCHEME define, in the app_sfu.h source file. These must correspond to those used by the PC SW called by the post-build script when building the new app. Along with the keys and IV.

You probably modified something on one side and not on the other. It should not matter what exact version of cryptographic library you use, as long as they all implement the correct crypto algorithm.

BR,

J

[mr.1]

Thanks for your reply @Bubbles . I have replaced the entire mbedTLS source code with newer version (2.282.2) of mbedTLS files and built the SBSFU. No other modifications on the source code. Now the SBSFU image is available with newer version 2.28.2 of mbedTLS and it runs on the hardware. At very first time SBSFU waiting for an image via ymodem protocol. User application firmware is built and sent via ymodem protocol. But, sbsfu does not receive the entire package instead it receives the header and failed at validation of image.

As you mentioned that i have done the changes on the SBSFU side. But i have not done any changes on the post build script and prepareimage.py files. May i know what are all other changes i need to take care while the changes of version at SBSFU side?

Please suggest the next step and let me know if you need further information on this

Regards,

Rakkumuthu R

[Pavel A.]

> Please suggest the next step

Undo the change on the firmware side?

[mr.1]

@Pavel A. Undo the changes at firmware side will work. But there mbedtls version is older 2.16.2. I don't want the older version to be run on the hardware. 

[Bubbles]

Hi @mr.1,

the mbedTLS is not product of ST. Only SBSFU is.

Some interface may have changed, there may be a different endianness configuration, change in padding, number of small details could have caused the failure.

Check the change log of the library, it may give you a clue.

BR,

J

[Jocelyn RICARD]

Hello @mr.1,

I copy paste here the answer I made to your colleague in OLS:

I took version 2.28.2 from here  https://github.com/Mbed-TLS/mbedtls.git

I copied the content in SBSFU\V2.6.2\Middlewares\Third_Party\mbed-crypto\

instead of the old one.

I cleaned my SBSFU projects.

Rebuilt the 3 project.

Everything works fine.

After downloading SBSFU\V2.6.2\Projects\NUCLEO-H753ZI\Applications\2_Images_OSC\2_Images_UserApp\Binary\SBSFU_UserApp.bin

to the target, the application is immediately authenticated, and launched.

I can also perform an update without any issue.

So, there is no specific issue on my side using v2.28.2 tag:

The commit I'm using is this one:

commit 89f040a5c938985c5f30728baed21e49d0846a53 (HEAD, tag: v2.28.2, tag: mbedtls-2.28.2)

Merge: 5c581dd60 d6f774f63

Author: Dave Rodgman <dave.rodgman@arm.com>

Date:  Mon Dec 12 15:17:36 2022 +0000

  Merge pull request #978 from Mbed-TLS/mbedtls-2.28.2rc0-pr

  Mbedtls 2.28.2rc0 pr [DO NOT MERGE]

Best regards

Jocelyn

[mr.1]

Hi @Jocelyn RICARD 

That is not correct. You have replaced the unused crypto library files. Below are the reference,

6.2.3 Cryptographic Library
Three different cryptographic middleware are supported:

 X-CUBE-CRYPTOLIB supports symmetric and asymmetric key approaches (AESGCM,
AES-CBC, ECDSA) as well as hash computation (SHA256) for decryption and
verification. Software cryptographic functions are used to avoid storing secret keys in
hardware Crypto IP registers that are not protected.

 mbedTLS: cryptographic services delivered as open-source code. Similarly as for
X-CUBE-CRYPTOLIB, the symmetric and asymmetric key approaches (AES-GCM,
AES-CBC, ECDSA), as well as hash computation (SHA256) for decryption and
verification, are supported. Examples are provided for the 32L496GDISCOVERY,
B-L475E-IOT01A, STM32F413HDISCOVERY, STM32F769IDISCOVERY,
P-NUCLEO-WB55, and NUCLEO-H753ZI boards under the folder 2_images_OSC.

 mbed-crypto: cryptographic services delivered as open-source code. This middleware
provides a PSA cryptography API implementation. Examples are provided for B-L4S5IIOT01A
board, under the folders 2_Images_KMS and 2_Images_STSAFE.

You have replaced the mbed-crypto folder content which is not used in our project. Please replace the mbedTLS 2.28.2 version into Third-party/mbedTLS folder and test it. 

Please let me know if you need further information

Regards,

Rakkumuthu R

[Jocelyn RICARD]

Hello Rakkumuthu,

Yes, my mistake.

Replacing mbedTLS instead of mbedCrypto, I needed to add 2 new files in the SECoreBin project.

Then, I can reproduce the issue.

On first boot I get:

= [SBOOT] STATE: VERIFY USER FW SIGNATURE
= [SBOOT] STATE: HANDLE CRITICAL FAILURE
= [SBOOT] STATE: REBOOT STATE MACHINE

This needs some investigation. I'm not available right now, so probable next week.

Best regards

Jocelyn

[Jocelyn RICARD · Accepted solution]

Hello Rakkumuthu,

I found some time to have a look

Just checking the output of mbedtls_ecdsa_verify in se_crypto_bootloader.c , the result is -16.

This error code means: MBEDTLS_ERR_MPI_ALLOC_FAILED

So, I increased the heap provided to SECodeBin in Projects\NUCLEO-H753ZI\Applications\2_Images_OSC\2_Images_SECoreBin\STM32CubeIDE\STM32H753ZITx.ld from 0x1000 to 0x1200:

_Min_Heap_Size = 0x1200; 

Authentication is now passing correctly.

Best regards

Jocelyn