STM32 Secure Engine adding additional API in se_crypto_bootloader.c.

[Grogu]

Is there a an option to implement  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

[Fred]

If this can help, please find an "exercise" you can do:

Objective:

•Write some isolated code running in Secure Engine

•This code must be available for the user application (runtime)

•Objective #1: implement a basic copy of data (memcpy)

•Objective #2: try using the AES GCM encrypt/decrypt services

[Fred]

But, please be careful when adding your own code in Secure Engine:

• this code runs in the secure enclave
• this code has access to all the secrets protected by Secure Engine
• this code can endanger the bootloader services

So you have to be very careful, this code must be "trusted".

[Fred]

If you really want to do it in the bootloader, the strategy is similar.

You will update:

• se_crypto_bootloader.c
• se_interface_bootloader.c/h

And you won't need to propagate the API to the UserApp so no se_interface.txt to be updated.

Only SBSFU will call the new services.

But, be careful, by invoking these services you will change the bootloader flow.

[Grogu]

@Fred​ implemented a simple service SE_FOO in Secure Engine from instruction provided above and its working as expected.

[Jocelyn RICARD]

Hello @Grogu,

Good to see things working fine!

I would like to raise just 2 points, relative a previous post you did.

You are apparently using the STM32H7B3.

If you add functions inside secure engine, you need to know the following

1) the code you put in the secure engine cannot be updated. This constraint is common to all STM32 series.

2) you will not be able to use the secure memory capability of the STM32H7 that isolates the SBSFU from the rest of the application.

Best regards

Jocelyn

[Fred]

Good points.

Regarding the point #2 => as Grogu wants to call the service from the bootloader, this is fine. But yes, you are right, on STM32H7 there is no runtime secure services for the user application.

So, if STM32H7 is the target then only the bootloader can proceed as requested.

[Grogu]

Thanks @Jocelyn RICARD​ , @Fred​ ��

For the more insights on potential trade off to consider.