Can the STM32H723VGH6 implement an encrypted bootloader?

[shffhsdfhse]

The STM32H733VGH6 datasheet specifically mentions "Bootloader with security services support (SFI and SB-SFU)," while the STM32H723VGH6 does not. Does that mean that I can't use encrypted firmware on the STM32H723VGH6?

I tried to do some research, but it is hard to decipher what are hardware versus firmware requirements.

[Pavel A.]

STM32H723 differs from STM32H733 by not having crypto accelerators and secure flash area, SFI and SB-SFU, octo-SPI flash decryption.

It still is possible to implement encrypted firmware but it will be harder.

-- pa

[shffhsdfhse]

Thanks for your answer. I didn't realize that those devices didn't contain just a crypto acceperator, but also a secure flash area. So I read up on the secure flash area and understand it better now.

Unfortunately due to availability issues, I might be restricted to the H723 version. As you said, it will be harder to implement, and I'm assuming less secure as well. Do you know if the X-CUBE-SBSFU middleware can do a "best attempt" for H723, or does SBSFU require devices to have a secure flash area? Assuming the latter, I'm guessing I would have to write custom security related code. From everywhere I've read, rolling your own encryption/security code is a bad idea unless you are extremely experienced in it.

[Pavel A.]

I am not a security expert even remotely but will try to reply while you're waiting for authoritative answers.

Based on UM2622, 2262 fig. 5 secure memory area is essential for SB-SFU for H7 family.

What is possible in your situation really depends on your requirements and attack vectors.

The standard mechanism (RDP level2) often is enough.

Lack of hardware crypto accelerators can be covered by software (the free software library provided by ST or whatever), as performance is not critical for firmware update.

Yes, rolling your own crypto requires expert knowledge - this is where specialized consulting companies may help.

Regards,

Pavel A,

[shffhsdfhse]

Thanks for your response. What I'm trying to do is make it so that I can distribute encrypted firmware, making it harder to reverse engineer the product. I think this is a pretty simple scenario since we won't be running any third-party code. Readout protection would be sufficient for our needs as far as protecting code inside the device, but then we wouldn't be able to release updated firmware (it could then be installed into cloned hardware or reverse engineered). Our team is small, so we don't want to spend too much effort on something that might be futile anyways.

[Piranha]

> does SBSFU require devices to have a secure flash area?

Take a note that it works with many other series and devices without the secure flash area functionality. Therefore, even if it does require it for H7, modifying shouldn't be too complex. But I could be wrong, as I'm using my own secure bootloader implementation. =)

> From everywhere I've read, rolling your own encryption/security code is a bad idea unless you are extremely experienced in it.

That means not implementing cryptographic algorithms on your own. But for this there are plenty of choices: X-CUBE-CRYPTOLIB, Mbed TLS and other. Especially for MCU usage BearSSL and uECC can be recommended. And especially for software implementations, if you can choose the encryption algorithm, I suggest using ChaCha20, as it beats AES in absolutely all aspects simultaneously. It's faster, smaller, more secure, simpler design and simpler to use.

[Piranha]

Pavel meant UM2262 figure 5. =)

[Pavel A.]

Yes UM2262. Thank you.

[shffhsdfhse]

Thanks to everyone for their answers. I've taken the time to read through UM2262 and it was very helpful. (I feel like 50% of microcontroller work is just learning where to find the document or information that you didn't even know you needed).

Having said that, and by looking through the protection schemes for all the different families, it seems that the "secure user memory" is a nice security feature that makes it easier and less error prone, but not required.

If someone could make sure I am understanding this part correctly, however, I would appreciate it. At the moment, I don't intend to allow third-party code to running on my device. I just want to be able to use an encrypted bootloader and protect the decryption keys from ever being read out of the device. Does that mean that I only need to worry about "protections against outer attacks" (as UM2262 calls it), and don't need to worry about "protections against inner attacks"?

[Pavel A.]

Inner attack means exploiting your application or bootloader to give out the secret or do something else unwanted.

You decide whether such attack is worth worrying.

-- pa