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.

[stm322399]

Posted on January 08, 2018 at 11:40

'not working at all' is a bit unfair.

1/ imho, cold boot stepping exploits a weakness of the bootloader, of course, any SRAM data is at risk (at RDP level1). Well lets use RDP level2.

2/ security downgrade from level2 uses probing. Are there any generic purpose MCU protected against probing ? Anyway, I agreed that the encoding of RDP is problematic.

3/ debug interface exploit looks really unreliable (how to sort FW from garbage?), even the author only says 'practically feasible'.

Security is often a trade-off between protection and effort (money). Imho RDP is (not perfect, but) good enough for a lot of needs, and probably brings more protection to your product than many software (unchecked user input, fw upgrade etc ...).

[dieter 123]

Posted on January 08, 2018 at 13:23

Is there any official statement from ST on this?  Are all STM32 series affected?

Does it also affect RDP level 2? 

>> how to sort FW from garbage?

quite simple, no?: flash it on a second stm32 and check functionality

[AvaTar]

Posted on January 08, 2018 at 13:55

Is there any official statement from ST on this?

I'd wonder if there is/comes anything substantial.

Usually, a great part of 'security by obscurity' is involved.

Only large customers are informed and receive support.

Ask Microchip ...

As said by gonzales.laurent, this is a cost-benefit consideration. Blocking the casual hacker/copyist, even commercial, is mostly deemed sufficient.

Attacks with >1000k equipment and teams with unlimited pocket depth are not covered.

At least for short-lived consumer electronics.

[dieter 123]

Posted on January 09, 2018 at 08:35

Hi

st.mcu

would you please comment on this? Is there an official statement from ST about this?

Thx

[Amel NASRI]

Posted on January 09, 2018 at 10:50

Hi,

We will come back to you with our official statement regarding this issue.

-Amel

[Steve H]

Posted on January 12, 2018 at 17:00

I am very interested in that response, especially as regards the STM32F2 series MCUs, since we use them in our products. It would be a shame to have to migrate to another vendor because your security model was irretrievably broken.

[MANI Christophe]

Posted on January 15, 2018 at 17:42

To answer to your initial question

dieter.dieter

, 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

http://www.st.com/

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

[re.wolff9]

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. 

[AvaTar]

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. 

;)

[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 ?

[AVI-crak]

Posted on May 16, 2018 at 04:24

Steal someone else's program code is possible, but very difficult. It is much cheaper to find a solution in a global network, and write your own version. This is much faster and cheaper than hacking.

How to protect your own program: for this there are 100500 ways, and some are not too honest. For example, the prohibition of executing program code from RAM. Forced memory cleaning. Checking for serial number in parts - in many small blocks - through intermediate data. The one who can pull out your firmware will shoot voluntarily.

Dirty tricks: using the data space of the periphery - to check for hacking. Your program code will have a self-destruct when run in the stimulator, or when using a debugger. At the same time, an insignificant at first glance error will remain, which does not lead to the state of system crash, but makes the final algorithm of the device completely useless.

Soot is more - you can keep your own right to the project even with its public publication. To do this, you have to confuse the program code to the state of the bloody shroud before your eyes. A special glamor is the use of abbreviations for variable names, the removal of spaces, and the use of macros on a huge scale. With filling in one very long line of a mash of single characters and signs of operations Ci.

Yes, the program code will work, but how it works will only be known to you.

[ranran]

If I understand correctly, this vulnerability is only when RDP level 1 is used.

Yet, Level 2 is not affected. Right ?

Thx,

ran

[re.wolff9]

If I understand and remember correctly, the problem can be triggered in RDP level 1.

However, they also showed that they can almost target a single bit erase. But that "almost" is enough to ALWAYs cause a level 2 -> level 1 downgrade.

As a user a level 2 protected device is "almost bricked". If you find a software bug, the device is bricked and can no longer be used. To prevent this from happening accidentally, a very specific bit pattern is used to enable level 2. So any single bit change in IIRC 16 bits of configuration flash bits will downgrade the level 2 to level 1.

All this depends on quite some effort of the attacker. Level 1 or level 2 will keep most hobbyist "lets read the code and see what it is doing" away. But bigger players, can spend the "a week to reproduce the findings in the article" or "$500 to have it done commercially", What the commercial "read protected chips" guys can do beyond what the article describes is unknown.

[A.rubley]

Looks like the F1 series is somehow (?) affected as well... https://blog.zapb.de/stm32f1-announcement/

Has somebody more information?