Showing results for 
Search instead for 
Did you mean: 

readout protection cracked on STM32

dieter 123
Associate III
Posted on January 08, 2018 at 10:21

Am I correct that readout protection has a major issue and is not working at all? Are all STM32s affected? Any comments on this from ST?

See here:


Note: this post was migrated and contained many threaded conversations, some content may be missing.
Posted on January 12, 2018 at 18:55

The authors most likely say 'practically feasible' to emphasize that this really works and is not just a theoretical possibility.


Posted on January 12, 2018 at 19:08

I don't expect the MCU to be uncrackable (at least, not at realistic volume prices for manufacturing stuff), but I *do* hope it isn't trivially crackable at the high school student level.

Posted on January 12, 2018 at 19:17

Well, I guess that these days the attack as presented is not feasible at the high school student level these days. To get at the data in a RDP level 2 protected device they use fuming nitric acid, which is probably quite regulated and hard to obtain for a high-school student due to its uses in making explosives.

And, realistically, is it really that much worse for a device manufacturer, if a student can get at their data? The real threat is probably competitors, which could easily afford the 1000 € or whatever it takes to pay specialists to read the data.


P.S.: When I click the 'Transport' category on the

, I get to the page for their solutions for the banking markets. Is that working as it should? Every other category has its own page.
Posted on January 12, 2018 at 20:35

Philipp Krause wrote:

Well, I guess that these days the attack as presented is not feasible at the high school student level these days. To get at the data in a RDP level 2 protected device they use fuming nitric acid, which is probably quite regulated and hard to obtain for a high-school student due to its uses in making explosives.

Totally unnecessary. Bunnie (Andrew Huang) paid $50 to have his chips 'decapped' when he cracked the PIC. No nitric acid required.

Posted on January 12, 2018 at 21:37

You are complete missing the point.

ALL the microcontroller vendors have had their security cracked. Unless you are going to pay to create your own ASIC, your threat to 'migrate to a new vendor' is meaningless.

Even the Dallas Semiconductor (now Maxim) DS5002FP 'secure' processor


Like I said, anyone who counts on hardware locking for IP protection is a fool. You need to have a multi-layer strategy.

Posted on January 14, 2018 at 14:05

Well.... it is very hard to protect something that you are 'giving' to someone else. Once he has physical control, he has a big number of options and possible routes to defeating the security.... 

But there is a difference between protecting against the NSA with millions of dollars worth of equipment, an industrial competitor willing to spend a few thousand and a hobbyist willing to spend a few tens of dollars. 

I would expect the protection on my microcontroller to be resistant against the hobbyist and the industrial competitor, but not the NSA. 

In this case, ST does not protect even against the hobbyist. :(

A few simple changes based on what we learned in this incident can make things a lot more secure, so that the hobbyists and maybe even the 'industrial competitor' can be kept out. 

The 'read one word of memory before the lockdown' is simply a bug that should be fixed. Just delay ALL debug reads by two cycles and you're set. Or only the first. Something like that. This is a bug that can be fixed in newer revisions of the existing chip families. 

Now, I have two theories on how the bad coding for the lockdown states came about.... First, there is compatibility with the F1 family that didn't have the second level lockdown: Only a very specific bit combination will make the device behave differently from the F1 family. Secondly, maybe they did think about it, and decided that only a very specific combination should completely lock down a chip. 

Some highschool-level thinking can easily come up with a scheme that is better than the current situation. But this requires a change in interface and cannot be simply a bugfix to the existing chip families. 

How about modifying the debug interface to be able to go into a 'restricted mode'. NOTHING can be done except erase the whole flash. This is the default that happens when none of the other codes are detected. Actually maybe that's the intention of the current situation, except that the 'nothing' was too liberal. Reading RAM results in the CBS attach, and the bug with the slow shutdown allows reading of flash memory one location at a time.... Locking down the restricted mode a bit further might be an acceptable upgrade to existing chips: Who would program level1 protection and then expect to debug RAM? What if the datasheet from now on simply specifies that you can't do that? Sounds reasonable to me. 

The semi-restricted mode we have now could be moved to a specific configuration word (for the few people who expect this mode to exist). 

The bad thing is, that ST knows about the decap and UV attack: They specifically coded the different modes to be resistant to that attack: Big hamming distance between the codes and alternating ones and zeros. Those with an electron gun cannot simply add electrons to the flip ones to zeros and those with UV erasers cannot simply erase a few bits by masking out the other bits (like documented in the paper). 

Those companies offering to do this for $1000 or so probably have a few things. First they have some smart people who can find the attacks we see here today. Second: they have their own 'lab' with a bunch of tricks that they can apply. And third: they have some of the expensive equipment that makes things even easier. They have a big library of ways to break different CPUs They live off the simple ones like documented now. 

Posted on January 14, 2018 at 16:29

Thing is you don't have to own millions of dollars worth of equipment, merely have access, and what's that usually? A minimum wage janitor? A professor thrilled to see a practical application of his gear? A bored lab tech? A guy that filled his basement with industrial gear for pennies at auction?

The threshold conditions here aren't what you think they are.

Assume your adversary has a 20 point IQ advantage, and has the luxury of going over your design choices endlessly.

The other problem is that the bulk of people who get super excited about protecting their IP this way are functioning at high-school level, and protecting code that a some other high-schooler could write better. This is especially true in cultures where the first choice is to copy someone else's work.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
MANI Christophe
Associate II
Posted on January 15, 2018 at 17:42

To answer to your initial question


, the Fraunhofer institute is recognized enough to take their publication on the STM32F0 into account.

Now, as you know, it’s an organization with 25K employees and a budget of €2.1B. So, they have time and money to play as long as they want in that area.

After verification, the publication on that “Practically feasible�? debug access is anyhow limited to the STM32F0 only.

All other STM32 platforms are not affected by that mechanism.

What is important here is to keep in mind to use appropriate counter-measure depending on your own security target. Keeping some debug access open when your device is in the field may be a good idea if you want to be able to access it in some future. Now, if you don’t, as recommended it will be better to increase readout protection level to better protect your IP.

In addition to the read out protection, STM32 offer a wide range of hardware protection mechanisms which shall be activated to control or limit code debug and or executions rights. It will be important now to select the right mechanism linked to your own purpose. STM32 platforms are not equals in that area so it will be important to select the right protection mechanism and so the right product family for that point.

New technical literatures will be posted this year on the topic. For example, a first software package has been published on

(X-CUBE-SBSFU) to show how to develop in a secure way a firmware update solution even with the readout protection level 2 activated.

Posted on January 15, 2018 at 18:43

MANI Christophe wrote:

After verification, the publication on that “Practically feasible� debug access is anyhow limited to the STM32F0 only.

All other STM32 platforms are not affected by that mechanism.

That, my friend is completely bullshit. Even though the institute has a billion dollar budget, they can't spend all that on this single project. They have indicated that they were time and budget limited to the STM32F0 family. So that's what they tested. So for scientific correctness they only claim they verified their findings on STM32F0xx. 

But it would be very unwise that given this evidence, you would think you are safe because you're running an STM32F411 that was not tested. 

In security you must always assume the worst. So in this case: It has been proven that ST can get things wrong as to the security of your IP when loaded on a locked device. This extends to the other STM32 families and possibly other ST microprocessor families. 

In the past I've run/moderated a security mailing list. I have experimented with having a club of beta-testers who would beta-test the holes that were reported. When someone publishes a security hole, complete with demo code, about six out of ten security wizzes would report: 'Nope that hole is bullshit, the report is false, we're safe, the exploit does not work at all', about two would report: 'maybe'. and two would report: 'Yup hole verified, we're vulnerable!'. So when vulnerabilities are reported you really should err to the side of caution.

These guys who reported this issue are good, but not brilliant. They hint at: 'these are all the bugs that exist'. This is likely not true. Everybody who has researched such a subject for 6 months will think they have covered everything. The same holds for the ST engineers who designed this. They think they covered everything, but a hole was found. The only thing we can do is to fix this one and continue improving the hardware as more and more issues are found. 

For example, in the old days, you'd write crypto code as: if (bit_of_key (n)) do something.  Now with power-analysis you can find that the loop takes different amounts of time depending on the key bit. So once you figure out the time differences you have all the key bits. oops! So now you should write: if (bit_of_key(n)) do something else do something but discard the result. 

haha: This posting reads just fine even with the censorship. 

Posted on January 16, 2018 at 09:22

That, my friend is completely ********.

Roger, while I agree - what do you expect as 'official statement' ?

I suspect the statements to valuable large-volume customers reads a bit different.

BTW, would be nice if ST's website maintainance people would eventually get their job done.

I can only comment to threads on my message list, else I get 'unexpected errors'.

haha: This posting reads just fine even with the censorship.