Most Secure STM32 ?

[bsuthar]

Hello Team,

Good Day !

After Cloneed our two version of Hardware ( STM32F3 Series based ) by compititor , we are now more focused on Hardware Security aspects.

Can you Pls Suggest which STM32 MCU is the MOST Secure among all available MCU ? Considering Firmware Protection / physical  Attacks ? 

I would appriciate , if Higher Level Architecture with Device name is Provided.

We are also open for Paid Consultancy if any 3rd party ready to help...

Regards ,

Bhupendra

[Bubbles]

Hello @bsuthar ,

I'd suggest to try the reading the Introduction to security for STM32 MCUs - Application note first. The AN also includes tables comparing the security features found in different STM32 series.

Of the series on the market, I'd probably suggest the STM32H5 (crypto line) as the most secure. But the security is only working if the application uses all the security features correctly. 

BR,

J

[Pavel A.]

> We are also open for Paid Consultancy if any 3rd party ready to help...

Could you tell what is the kind of your device, so relevant experts could join?

For example: motor or drone controller? Industrial controller? Consumer, musical, game/toy? etc.

[bsuthar]

@Pavel A. 

yes , it is Industrial Motion controller.

Currently , It is based on STM32F303 Device. 
Unfortunately , It is clonned Two times ( along with Firmware). 

Last HW Version had Following Feature : 

------------------------------------------------------------

1. Custom BootLoader (WRP ON)

2. CRC Checksum check for Application Firmware (RoT) Authentication on Startup

3. RDP1

4. USB Communication Encrypted (Asymmetric)

--------------------------------------------------------------------------------

[bsuthar]

Yes, @Bubbles 

we had gone through this Docs and belive firmware extraction done through "Semi-Invasive Method" , for STM32F3 series MCU. 

[Ozone]

> 3. RDP1

Perhaps this is not sufficient.
An attacker could boot from System ROM, inject code into RAM, and thus break your protection.

Perhaps you are aware of Ghidra or similiar software packages : https://github.com/NationalSecurityAgency/ghidra
With such tools, you can easily convert binary code back into readable C code (without original variable names, of course).

Or, in the simplest case, the attacker just reads out the Flash into a file, and flashes it onto his clones.

While I have only superficial knowledge of this topic and scene, I would check out the size of the cloning competitors (financial & product output). For small ones, I would suspect minimal-effort cloning (i.e. the second, simpler case).
RDP level 2 might be too much of hurdle for those.

[bsuthar]

Hello @Ozone ,

yes , I am aware of Ghidra.

First point is , Attacket must not be able to extract firmware from Silicon. We wanted them to stop overthere.

If RDP1 is not sufficient than what else we can add to make difficult ? 

I request Hardware Security professional share some thoughts/ suggestion. 

[Ozone]

> If RDP1 is not sufficient than what else we can add to make difficult ? 

The next level, RDP2. Which usually disables booting from ROM and debugging (JTAG).
Which could easily brick boards during debugging, so one must be careful.

> I request Hardware Security professional share some thoughts/ suggestion. 

I am not one, just a fellow engineer who picked up some details along the way.
And I doubt a public forum is the best place to discuss this matter.
I would recommend to approach either a ST representative of local distributor for support.

[Bubbles]

Hi @bsuthar,

the RDP1 alone is not really an obstacle for determined attacker and only provides false sense of security. We are even dropping it from some of our newer products (STM32C5 for example). It can still be quite effective when combined with other protections like boot lock.

The main problem of RDP2 on older product was that regression was impossible in case of field return. With newer STM32 series, starting with STM32U5, the regression may be conditional to a secret passcode known only be the manufacturer. The STM32H5 may have the regression even protected cryptographically. This way there's no excuse not to deploy the product without (RDP2/closed) protection.

Still, it's better to combine even the RDP2 with boot lock, HDP and other protections available.

BR,

J

[bsuthar]

Hello @Bubbles ,

Appriciate your suggestion.

you mentioned Boot lock , But it seems not available with H5 Series as Per Application Note 5156.

However , I like the Feature OTFDEC on H5.

For RDP2 , I think it work as same as F3 Series , irrversible.  However , with RDP2 , can we update Firmware by Implementing Customised Bootloader ? i..e. Using USB CDC (VCP)

Regards,

Bhupendra