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.

[Dolence]

However the debug port method can be done by anyone with little effort. Did you saw the F1 method? Should I stick to F0? I saw something about F4 too while browsing, I will try to find it again.

[Dolence]

STM32F4​ voltage glitching article mentioned downgrade can be done trough this and the method seemed to be way easier than decoupling+uv and without the side effects of ruining firmware. Even if a RDP1 to RDP0 is not feasible, the article describes how to re-enable JTAG and SWD trough voltage glitching. The hardware cost to do this is said to be around 75 USD.

STM32F0 method using a buspirate ​

I've been thought a steep learning curve​, coming from the way simpler AVR 8-bits. STM32 are amazing devices, given how much you get for what they cost. I've been learned so much and having so much fun in the process. Now I feel more comfortable in using it on real world products. Unfortunately after I have found about the flaws and started to​ dig deeper, more and more methods showed off. Should I be concerned? Is there any kind of counter measure or maybe newer chips not affected?

[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