readout protection bug https://www.aisec.fraunhofer.de/en/FirmwareProtection.html even level 2 can be circumvented by cheap tools on STM32F series

[WojtekP1]

The question - is it fixed on STM32G and C series?

[Bubbles]

Hi @Community member​,

it's modified - improved. However some weakness remain in design. It's still true that the RDP defaults to level 1 in case of mismatch. But that's actually a requirement.

Completely different protection was introduced with STM32H5, which is now certified with security labs, being probably the best secure GP MCU offer on the market.

BR,

J

[Pavel A.]

@JHOUD​ Is your reply about the F series only or also about L, G or H7?

Documentation on RDP level 2 says that it is like a fuse, this means that undoing level 2 should be physically impossible? Isn't this the requirement for level 2?

Apologies for jumping in.

[Bob S]

Also apologies for jumping in :)

My understanding is that RDP 2 is "like" a fuse as treated by the internal microcode/boot code. But it is not a physical fuse, just FLASH bits. The attack in the referenced document requires de-encapsulating the chip and exposing the die to strong UV-C light in an attempt to sufficiently change the gate charge on a FLASH cell in the OPTIONS RDP bits to flip at least 1 bit. That changes the RDP from level 2 to level 1. They then use other methods to extract code from RDP 1.

[Bob S]

Forgot to add: Using UV-C light, with the side effect of also partially modifying the reset of the FLASH (i.e. corrupting the firmware image). The paper discusses the methods they used to try and avoid altering the main FLASH and only change the option bytes. Not an easy attack, but apparently not impossible, at least on the F1 series.

[S.Ma]

The usual fight and defense evolution level of any product. The level of defense grows with cost, and I guess most want security for free?

[Bubbles]

Hi @Pavel A.​,

the answer by @Bob S​ is very accurate.

For more context, you can see for example Introduction to STM32 microcontrollers security - Application note.

There are contradicting requirements between security, safety, ease of use, and many customers simply don't even care. I appreciate the questions and even scrutiny towards ST products, because security is very important for us and we want it to be a differentiating factor to choose our products over the competition.

Undoing the RDP2 is something we don't even do internally. It's in theory possible, as the paper points out, but to my knowledge it was not ever achieved practically.

Of course exception are the new products like the STM32U5, where the regression from RDP2 to RDP1 may optionally be password protected.

Also note that under the PRODUCT_STATE scheme introduced by STM32H5 there is no direct equivalent to the RDP1.

BR,

J

[Pavel A.]

Thank you Jarda. So I understand from your reply that there's no "real fuse", at least in all products based on CM0-CM7.

[Bubbles]

Hi @Pavel A.​,

if you mean fuse as conductor that ceases to connect by physically breaking, thus blocking a certain functionality, I thought that's a concept that was abandoned long ago, only remaining as a figure of speech for something based on checking the OB value. But following your question I dug deeper into the available materials and found out that the RDP2 is really using physical fuse to disable the debug interface for good. Maybe not on all products, but it's regularly present on many produced STM32.

So I'm sorry for previous misleading answer.

BR,

J

[Pavel A.]

Great, thank you!