ECDSA Signature verify for a composite file (FW + GUI + Calibration data)

[Grogu]

Setup:

Device - STM32H7B3I-DK

Project - STM32H7B3I-DK\Applications\2_Images_ExtFlash

We have Composite firmware update file which contains and stored in external flash which Boot loader will process

• APP firmware (UserApp.sfb )
• GUI resources
• Calibration data
• Other blob (MCU stm32f4 APP image)

This composite file header contains signature of payload(app fimware + gui + calibration data + other blob of data) which is placed in external flash.

What are the API calls which i can make to verify the signature

• SE_CRYPTO_ReadKey_Pub will be able to get the key is this correct way?
• SE_CRYPTO_SHA256_HASH_DigestCompute - computes the hash
• ECDSAverify() - to verify the Signature.

What changes i have to keep in mind for this to work as this part of Secure engine ?

Thanks!

[Fred]

Hi,

I see 2 options here:

1. You consider that your image is "composite" and all the elements you indicate are part of a single .sfb
2. You leverage the multi-images support and you can have maybe 3 images: 1 for the APP firmware, one for the GUI resources, one for the rest

In both cases, at startup, SBSFU will verify the signature of your images in their respective slots.

See "SFU_BOOT_SM_VerifyUserFwSignature", in sfu_boot.c.

So I am not sure you need to make extra checks.

Can you clarify your requirement here ?

You want an extra check on top of what SBSFU is doing at startup ?

Thanks & Regards,

Fred

[Grogu]

Thanks @Fred​  for response

>> 1. You consider that your image is "composite" and all the elements you indicate are part of a single .sfb

Can you please more detail on this approach. Since components of composite file will be placed in different different section of external Flash(As the size of this file will be >32MB).

>>So I am not sure you need to make extra checks.

UserApp.sfu has checks for authenticity protection and integrity protection . I agree these are extra checks which are made. But composite file can contain N other files.

>>You want an extra check on top of what SBSFU is doing at startup ?

Just need to check composite file authenticity protection and integrity protection as it contains multiple other file which would be used by other MCU in system.

>>Can you clarify your requirement here ?

Other files/blob would be unsecure and placed in external flash memory. Just need to make authenticity protection and integrity check in SBSFU. Every boot SBSFU would compute the hash of files/blob in external flash to very integrity is intact.

[Fred]

So, what I understand is that:

1. you work with one composite image so 1 sfb
2. from this sfb, after installation by SBSFU, you split the content in several files ?
3. you want to check the integrity of each of these files

To me, it seems you may consider that each file is 1 image stored in 1 slot.

So, if you use SBSFU's multi-images support then the integrity of each of your images (so UserApp binary for 1 slot then files for the other slots) will be checked at startup without any extra code on your side.

You can find more information here:

https://www.st.com/resource/en/application_note/an5056-integration-guide-for-the-xcubesbsfu-stm32cube-expansion-package-stmicroelectronics.pdf

In section 3.2.4

Would this be convenient for you ?

Thanks & Regards,

Fred

[Grogu]

Hi @Fred​ 

thanks for providing few design choices above. I am experimenting with suggested routes above.

[Grogu]

Hi @Fred​ 

This related to my first question about crypto is there a way to implement additional API under SE_<FOO> in se_crypto_bootloader.c. I tried implementing a SE_FOO but the system reset as mentioned in document .

"Protected code and data are accessible through a single entry point (call gate mechanism) and it is therefore not possible to run or access any SE code or data without passing through it, otherwise a system reset is generated."

I want to have flexibility for Boot loader to decrypt/encrypt blob of data and also verify signature of blob of data. Which is separate from app image .sfb

[Fred · Accepted solution]

Hi Grogu,

the first thing you need to decide is:

1. do you want the bootloader to do this check, so update the bootloader ?
2. or do you want your application do do this check when starting (so leaving the bootloader untouched)

The latter option has the benefit of making sure you do not alter the bootloader nominal processing.

In any case, yes, you can extend the Secure Engine services.

I will take the example of option #2.

The idea is this one:

 

Then, you will have to tune the memory mapping probably:

This can also impact the slots, you may have to resize them.

But, please, remember that when you add more code in the Secure Engine, you add more code in the secure enclave and this code can access your secrets.

Thanks & Regards,

Fred

[Grogu]

@Fred​ thanks a ton! for comprehensive answer.

1. do you want the bootloader to do this check, so update the bootloader ?
2. or do you want your application do do this check when starting (so leaving the bootloader untouched)

If can you also guide with steps for "1.do you want the bootloader to do this check, so update the bootloader " - I intend to have part of bootloader .

https://community.st.com/s/question/0D53W00001L2A5YSAV/stm32-secure-engine-adding-additional-api-in-secryptobootloaderc - is tracking this specifically.

[Fred]

Ok, answered in the other thread.