STM 32F4xx - what hacks are known around Level 2 security?

[PHolt.1]

It seems perfectly possible, under Level 2, to have a "boot block" which accepts a firmware block (say via USB MSC or via HTTP), encrypted with a key stored in the boot block, and you have a product whose firmware can be upgraded but can't be extracted. You can even publish the firmware block but with say AES256 "nobody" can decipher it. And obviously there would also be a CRC or a hash inside the encrypted block. Superficially there does not appear to be a vulnerability in this basic scheme. Internal software can freely program the CPU FLASH even with L2 set.

That's if Level 2 doesn't have a back door.

Googling yields various success stories but only for the 32F0 e.g.

www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf (STM32F051R8T6)
www.aisec.fraunhofer.de/en/FirmwareProtection.html (32F0 general)
community.st.com/t5/stm32-mcus-security/readout-protection-cracked-on-stm32/td-p/387997 (ambiguous but 32F0 again AFAICT)
community.st.com/t5/stm32-mcus-security/stm32f4xx-firmware-protection/td-p/133047 (someone asking about 32F4; no useful replies)

Does anyone know any more? The setup described for the 32F0 extraction is a fairly easy hobby job. I am not talking about de-packaging and etching off the passivation layer; that's pretty esoteric.

[Pavel A.]

Are you looking to crack somebody else's F4 or secure your own? ))

F0 and F4 are too old. Upgrade.

> I am not talking about de-packaging and etching 

You aren't going to de-package a properly secured product. It has more anti-tampering measures ))

[PHolt.1]

The latter.

The same Q would be applied to any other microcontroller, unless it is some very new design specifically provided with on-chip features to block stuff like etching and probing. Modern smart card chips have these features, and have had them for much longer than the 32F4 is old. I did a design ~30 years ago with a Siemens 44C200 which was supposedly secure from these hacks like VCC, clock and /RST tampering, and chip probing.
https://cordis.europa.eu/project/id/1728/de
But of course it could not run much "useful code" - it was a smartcard chip with hardware RSA.

Is there a drop-in version of say a 32F417 which has these features? I don't think so.

"Upgrade" could be a man-year :grinning_face:

[Pavel A.]

Then, as with almost anything else: get in touch with specialists in this field and they will come up with a solution. The more urgent it is needed, the more it will cost.

[PHolt.1]

I was hoping for somebody knowing about actual published hacks.

With this chip being over 10 years old, and very popular, I would expect somebody to have had a go.

It is a project I've been working on for about 5 years. It is now finished but there is a version I am looking at spinning off which would use the "secure" firmware update method described.

BTW "the latter" means the second option i.e. I am trying to secure my project, not hacking somebody else's.

[PHolt.1]

I posted some here too

https://www.eevblog.com/forum/microcontrollers/stm-32f4xx-what-hacks-are-known-around-level-2-security/

It turns out that ST fixed the 32F0 "race condition" back door a year before the above Fraunhofer paper came out. There is a bug in the 32F4 which is not being fixed but it appears to be only in that L2 can be downgraded by internal code, which is not really a problem AFAICT since internal code can rewrite the FLASH anyway.

[STea]

Hello @PHolt.1 ,

ST's Product Security Incident Response Team (ST PSIRT) supervises the process of accepting and responding to potential security vulnerabilities involving ST hardware and software products.
please follow this link Report potential product security vulnerabilities - STMicroelectronics
Regards

[PHolt.1]

That is for reporting issues but there is no information on RDP2 downgrading of the 32F4.

[STea]

Hello @PHolt.1 ,

The page https://www.st.com/content/st_com/en/security/report-vulnerabilities.html contains also ST public security advisories and bulletins.

Regards

[PHolt.1]

Nothing I see relevant to the 32F4 other than

https://www.st.com/resource/en/technical_note/dm01011952-.pdf

which is a zero-content paper stating the obvious :)