Posted on January 14, 2018 at 14:05Well.... 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.
