STM32 security flaws

[Dolence]

I'm starting two new projects which initially would make use of STM32F1 and STM32F4 MCUs but after reading some articles detailing how easy would be to disable RDP1 and even downgrade RDP2 to RDP1 I become very concerned.

Please, anyone with more experience could explain to me if these methods affects every STM32 MCUs? If so, how could I protect my firmware? Apparently there is no way to permanently disable debug/jtag... What if I use a custom bootloader? I'm lost here.

[TDK]

Please link the articles you're talking about specifically.

Limitations of the extremely old STM32F1 are not present in all STM32 families. Newer families have more security features.

[Dolence]

STM32F1 process is described here​

​

STM32F0 methods are described in here. There is a mention to RDP downgrade without ​losing firmware.

​

​

[TDK]

Thanks for linking. It's more helpful to discuss specifics.

> STM32F0 methods are described in here. There is a mention to RDP downgrade without ​losing firmware.

I mean, the "exploit" to downgrading from RDP 2 to RDP 1 (not even RDP 0), is for the attacker to physically decapsulate the chip, then use UV light to flip bits in the hope of getting one or more related to the RDP. Plus, it's still in RDP 1 at the end of this, and the firmware has been modified. Is that really so useful? From the article itself:

Nevertheless, the CBS approach is not feasible afterwards. The attack does not only flip bits of the RDP setting. Despite security becomes downgraded, such a coarse full-chip illumination causes too much damage to the firmware.

If your adversary has physical access an unlimited resources, there's probably not much you can do. However, I think people in general vastly overestimate the value of compiled firmware.

[TDK]

> Should I stick to F0?

> Should I be concerned?

It's really up to you to decide the needs of your project. If you're uncomfortable with the exploits out there, certainly don't choose that product. Just be aware the exploits that require physical access are going to be hard to prevent. It's certainly not something that only affects STM32 chips.

> maybe newer chips not affected?

I would assume newer families with enhanced security features to be more resistant against attacks. Perhaps look at what is out there and decide what is acceptable for your project.

https://www.st.com/resource/en/application_note/dm00493651-introduction-to-stm32-microcontrollers-security-stmicroelectronics.pdf