readout protection cracked on STM32

[dieter 123]

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:

https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

#stm32-rdp-read-protection Note: this post was migrated and contained many threaded conversations, some content may be missing.

[Francesco CARIATI]

Posted on January 19, 2018 at 05:07

wolff.roger wrote:

I did not realize that MANI works for ST. 

All the ST employees on the ST Community have the ST blue badge next to their username and it's automatically assigned by the forum software. 

[MANI Christophe]

Posted on January 22, 2018 at 17:47

Declaring SWD pins as output pins will not work in that case. Pin configuration is also Reset and Debugger can be connected.

[MANI Christophe]

Posted on January 22, 2018 at 18:05

Under Read out protection level 1, except mentionned into the product user manuals, SRAM is accessible to the debugger. It's a standard feature of our products.

Now, code executed from the SRAM cannot access the Flash in that condition.

[T J]

Posted on April 22, 2018 at 07:27

Specifically 'F091

Whats wrong with Level 2 protection ?   Surely it works,

If it doesn't stop all hacks, what does ?

What else can you do exactly ?

VBAT and Tamper ?  softcode in BackedRam, is it feasible? not on the '091

What is the best method for 1,000,000% security ?

On the H753 Security

• ROP, PC-ROP, active tamper, secure firmware, upgrade support, Secure access mode

will this be enough ?

[T J]

Posted on April 23, 2018 at 09:32

I contacted our friends at fraunhofer.de about this issue,

They didn't test every different processor but found the F4 series is not susceptible to their attack because the extra routing layers in metal obscure the Option bits from external tampering.

They surmised the H7 will have the same overlay protection.

[re.wolff9]

Posted on April 23, 2018 at 09:46

The article, and again this remark you report hint at too much confidence. They say they tried everything (they could think of) and that only these attacks work. The part in the parentheses is important. They cannot have thought of everything. They do not have all possible equipment. etc etc. It is entirely possible that someone with a different machine or a slightly modified way of doing things will get a different result. 

So for the 'more metal layers, you cannot see the option bits from above'... What if you shine an UV laser on a specific spot? With the proper optics you can aim pretty good. I find it plausible that the gaps in the metal layers will leak enough to flip a few bits. If there is a solid layer on top specifically to try to thwart this attack, you can blast away the metal with a pulse of just the right amount of energy. 

This then becomes an attack where the first time it costs quite some money: You will blast a few CPUs away before you find the right energy setting and spot. 

[T J]

Posted on April 23, 2018 at 10:55

Can I ask ?

what is best practice for now ?

[re.wolff9]

Posted on April 23, 2018 at 11:13

Well. Manufacturers like ST will  have to try to take all known bugs into account and implement a fix for them. And they should try to think ahead and try to prevent possible exploits before they happen. So the masking the important flash cells with a metal layer is a trick I happen to know microchip uses. That's publicly known. Should have been implemented by ST. 

ST used to be 'nobody tried to break it (and publish the results)'... If you find another manufacturer with no known way to break the chips, you might be lucky that someone smart already tried and didn't publish: 'I tried but failed'. 

With the 'cold boot start' hackmethod I thought that would be quite a coincidence if that happened to work, but by now it has been shown to actually work! I.e. a protected chip 'in the field' has been read out..... 

[AvaTar]

Posted on April 23, 2018 at 13:02

Well. Manufacturers like ST will  have to try to take all known bugs into account and implement a fix for them.

That might depend - only if the vendor expects significant sales for the affected silicon, to customers who care about it.

Otherwise, he (the unspecified vendor) would just kick the can down the road, and recommend a new, improved device.

Dunno why, but writing this lines, associations of 'MS' and 'Vapourware' come up ...

[re.wolff9]

Posted on April 23, 2018 at 16:59

yeah, you're right, but they are going to make a very bad impression if they release silicon say 1 year from now that STILL has the old bugs that we're discussing today.