Secured boot with a secured & non-secured application

[ranran]

Hello,

I now understand that I should have asked the question differently.

Let's say we have 2 applications: secured and non-secured application.

The secured is placed in inetrnal flash, just as done in the demo of SBSFU,

But the non secured should be placed in external flash.

And we don't need it to be encrypted.

Is it that the root bootloader os SB will try to decrypt or authenticate it before jumping to that non secured application in external flash ?

The bootloader should decide if jumping to the secured or non-secured according to GPIO (by the way, is it secured ?)

Thanks

ranran

[Tesla DeLorean]

If you don't secure everything you end up leaving holes a hacker can exploit. You'd probably want to salt a hash of the NOR application using secret keys you hold main firmware.

[alister]

The application would be able to download the encrypted app and store somewhere. Next boot the SBSFU integrity-checks, decrypts and installs it in internal flash.

Decrypting the app to external memory is in-advisable. But you may choose to do this if it doesn't contain secrets. Even without secrets in the app, the risks you'd face include (a) your app binary board could be lifted, disassembled and your ideas stolen, and (b) with less effort your app binary could be re-wrapped so it may be loaded and executed on illicitly manufactured boards with someone else's non-secure bootloader.

In the X-CUBE-SBSFU, the key(s) for decrypt and integrity/authentication are in the SECoreBin (not in the app), and on the STMH743 this should be protected by PCROP, RDP, DAP, and optionally MPU.

[ranran]

Hi,

I now understand that I should have asked the question differently:

Let's say we have 2 applications: secured and non-secured application.

The secured is placed in internal flash, just as done in the demo of SBSFU,

But the non secured is placed in external flash.

And we don't need it to be encrypted.

Is it that the root bootloader os SB will try to decrypt or authenticate it before jumping to that non secured application in external flash ?

The bootloader should decide if jumping to the secured or non-secured according to GPIO (by the way, is it secured ?)

I will now edit my original question exactly as I wrote here...

Thanks,

ran

[alister · Accepted solution]

I'm not expert, and this is testing me 🙂

You can change the X-CUBE-SBSFU any way. You may change it so uploaded apps are encrypted (it decrypts as it installs to internal flash), internal apps are ver or, if the GPIO's asserted, it executes an app in external flash like in AN5188.

But anything might be executed from external flash.

The SBSFU might launch the external app with MPU enabled and unprivileged and you'd code it to access whatever peripherals it needs and not use interrupts, or dispense with MPU protection.

The external app could read out the installed app. Equipped with one legit board and your software updates, and if your board manufacturer sells them boards, they can sell both your boards and your software.

If you think you're secure against that, you need to protect your key in the SE.

I'd guess RDP level 1/2 doesn't treat execution from external flash as an intrusion and doesn't offer any protection

The X-CUBE-SBSFU example protects the key with PCROP. You can change it so PCROP protects the entire SE sans rodata. The SE callgate checks it's called only from a dedicated interface area. If there's no MPU protection, a hacker could experiment to find addresses and arguments that return and study what its results mean. They wouldn't have to target only the callgate. Any function in the SE might provide some detail. They'd get clues from X-CUBE-SBSFU too if they got their hands on it.

[ranran]

Hello,

I would like to ask one last question on this topic please:

Just to be sure,

the secured boot method described in X-CUBE-SBSFU does not involve any ST's tool or bootrom or any other vendor built-in capability, but only example of how to use open source crypto libraries for doing the authentication (or encryption) ,

Right ?

I ask because I also consider using my own ssl/rsa library for authentication instead of using this package.

Thanks

[alister]

The X-CUBE-CRYPTOLIB (UM1924 Rev 4) isn't open. Only its include file and library are provided in X-CUBE-SBSFU.

The STM32H743 doesn't have secure access or CRYP peripheral. The X-CUBE-CRYPTOLIB library for H7 supports all the H7 variants.

For security, the H743 is similar to the F7 except adds PCROP. X-CUBE-SBSFU V2.1.0 for F7 doesn't need any special system rom. It includes a python script to prepare an encrypted app binary suitable for field upgrade and a combined SBSFU and app binary that may be used for production. If you used your own security library you'd need to adapt of prepare your own scripts.

[ranran]

I think I understand now.

I thought at first that "secured boot" is a kind of signature/encryption authentication that vendor does internally starting from boot rom/system rom (that is what I am familiar with from other chips),

But with stm32, I see that it is just a software *demonstration* of how to do the authentication and encryption using software library. (of course there is the memory/flash protection which is vendor's feature but I less relate it to "secured boot" terminology ).

Thank you very much for help in understanding all this.

[zyh]

I am also trying to understand the secure boot function of STM32.

Now it seems that there is no other hardware on the STM32 series chip to ensure that the BIN file that can pass the verification can be used to enable the bootloader to run the official application after it is enabled. It is just a pure software solution. In other words, the full range of STM32s can support the SECURE BOOT function as long as the FLASH and RAM resources are sufficient.

Is that right?

[alister]

If the chip has RDP AND at least PCROP or firewall or MPU, then a developer may implement a purely software secure boot.

Every STM32 chip has different capabilities.

Different capabilities and designs will yield different strength security.