STM32 readout protection is broken

[eltar]

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

[Mr. Scram]

From what I've heard, there are companies that will decap almost any chip and read the contents for not a huge free. Securing your firmware will keep out hobbyists, but even small outfits will likely be able to afford these services.

[stmdude]

After reading the paper, it seems like it only works on STM32F0xx devices.

Still, I'm fascinated by the amount of effort people manage to put in to defeat security like this. In this case, they must have sat down and learned a lot of the intricacies of the SWD protocol just to get to the attack vector. That's a few weeks of work in itself, as the documentation is far from specific enough to be able to pull it off without a lot of trial-and-error and logic-analysis of working debuggers.

[eltar]

Another related thread (from 2014) mentioning broken readout protection on STM32F1: https://groups.yahoo.com/neo/groups/nuttx/conversations/topics/7310

[Siwastaja]

I'm not surprised at all. Almost every part and peripheral in STM32 has many silicon bugs, insane design choices, catastrophic documentation flaws, etc. In addition, they don't keep the errata sheets up to date, and ignore silicon bug tickets completely. Everything in STM32 screams "made in hurry", and "you are on your own".

It would be stupid to expect that the "security" features would differ from the general trend.

Although, I have a feeling that in 97% of the cases, no one really needs the flash protection, engineers know perfectly well it doesn't stop the copying at all, but the copying is still not going to happen because the device designed is most likely uninteresting; but the locking features need to be there for the clueless, non-technical middle management. In remaining 3%, security is really needed, and in those cases, I really hope that the said middle management is up to the task so that they understand it when the designer says resources are needed to harden the thing since some lock bits are completely insufficient.

[Rasz]

I was expecting power analysis, Micah Scott demonstrated couple of times how trivial it is to make older chips talk too much with glitching.
But CRC trick is a surprisingly neat side-channel attack exploiting logical error. Second attack is just hilarious, makes it look like an intern was responsible for protection circuit.

these guys read "secured" chips to preserve old arcade machines, interesting blog: http://caps0ff.blogspot.com/

[KL27x]

Although, I have a feeling that in 97% of the cases, no one really needs the flash protection, engineers know perfectly well it doesn't stop the copying at all, but the copying is still not going to happen because the device designed is most likely uninteresting; but the locking features need to be there for the clueless, non-technical middle management.

I have personally worked with shady hardware engineer who repeated asked for firmware. It started with my client asking me to send firmware to him for pcb testing, upon his request. I told my client very simply, no, they should not share it. He said it was common procedure and only for validation of the pcb. No. He asked if I could make it one-time use with a simple eeprom lock. LOL no. He also said he had a relationship with a great company for flashing the firmware on the chips at low cost, if I give him the firmware. No. (PIC, mind; Microchip does this at low cost and they are reputable). I made for him a simple firmware for pcb testing/validation that was otherwise useless. Later on in the project, he tells me how easy it is to copy a microcontroller in China. I tell him if someone wants to steal firmware, sure. Maybe no one can prevent it, other than suing after the fact. But that doesn't make it wise to openly hand over your firmware on a silver platter to anyone that asks.

Background: In the past, this same guy asked me to "slightly alter" a firmware for one of his clients. When I pressed, his explanation was that someone was copying his client's product. And he needed to make it slightly different from the guys copying it. And he couldn't give me the source code. Obviously, I said no. And I told our mutual client of my concerns.

Later on we discover he has been in multiple lawsuits, involving this kind of theft. Last two projects he did hardware design on, he and the other parties ended up in court over property rights, with both their companies selling the same product, same software, firmware, and hardware. After one company pays him to do the hardware design and pays for firmware and software design and marketing of a new product, he apparently managed to get his hands on software and firmware and sell a clone product under a different company name.

[Kjelt]

Only quickly scanned the document but as I read it they only attacked RDP level 1 which allows debugging. RDL Level 2 is still secure ?

[AndyC_772]

Read the whole paper, it's worth your time.

[Kjelt]

Yeah just read that they can downgrade level 2 to level 1 with UV.   

[jnz]

I read this paper a couple weeks ago, but something I didn't notice before... Are they claiming that because they created their own CRC flash checker bootloader - THAT is the way they read the firmware in level1 by accessing SRAM with the micro halted?

If their example bootloader wasn't CRC, but rather SHA/RSA/ECC signature, this attack is dead in the water, right?   

Because you'd still have SRAM during boot, and maybe you get lucky that it loads a block into SRAM to calculate and you can still build it up like that but more likely there is no reversing. Seems like an obvious omission in their mitigation techniques doesn't it? Shouldn't it just say "don't compute flash validation with a reversible method in SRAM"?


...
Obviously what I wrote above ignores the larger race condition hack on SWD.

[dgtl]

Shouldn't it just say "don't compute flash validation with a reversible method in SRAM"?

There's more than that. You can still leak information via stack as well. So unless you know very well, what the compiler did with your code, you can still be vulnerable if any function call arguments are written to stack or any local variables that get written to SRAM. Basically, any data touched by the cpu that is not in cpu registers, is reachable. I wonder, if the cpu registers are readable as well?
The easiest workaround would be DMA'ing to the internal CRC HW for parts that have CRC. The DMA bypasses cpu, so nothing can be leaked via SRAM or cpu.
At the same time, if you have encrypted FW update, this needs to be revised as well. And that is much more difficult to do without any cleartext or keys touching SRAM. For some use cases, the data may be more valuable than the code itself (ie encryption keys etc) and that is pretty much open to the world due to the SRAM issue.

[jnz]

Shouldn't it just say "don't compute flash validation with a reversible method in SRAM"?

There's more than that. You can still leak information via stack as well. So unless you know very well, what the compiler did with your code, you can still be vulnerable if any function call arguments are written to stack or any local variables that get written to SRAM. Basically, any data touched by the cpu that is not in cpu registers, is reachable. I wonder, if the cpu registers are readable as well?
The easiest workaround would be DMA'ing to the internal CRC HW for parts that have CRC. The DMA bypasses cpu, so nothing can be leaked via SRAM or cpu.
At the same time, if you have encrypted FW update, this needs to be revised as well. And that is much more difficult to do without any cleartext or keys touching SRAM. For some use cases, the data may be more valuable than the code itself (ie encryption keys etc) and that is pretty much open to the world due to the SRAM issue.

Ok, that makes sense. That their CRC method is only an example but even an ECC or PSA PKI might be hard to protect against here, and yes, I do think the CPU registers are also readable.

If the CPU registers are readable (and esp writable), yea, you only have to get a little creative to get around most other protections. Might be hard to figure out though, imagine you have clock cycle snapshots of memory and registers and can easily scroll through them, without the firmware it might be interesting on how quickly someone could put together a complex implementation.

[eltar]

SWD attack implementation using a BusPirate and PySWD module: https://gist.github.com/egirault/7b3fe7041e1bf5e2258ed5df7083f14d

[MT]

So, the upcoming NXP ARM mcu with encryption on external QUAD SPI bus is much securer?
https://www.nxp.com/products/microcontrollers-and-processors/arm-based-processors-and-mcus/i.mx-applications-processors/i.mx-rt-series:IMX-RT-SERIES

[Jeroen3]

Firmware image encryption will make it harder. But even that won't last forever either, since the decryption key will be in obfuscated OTP bits.
They already offer AES enabled chips, and there are some regulatory drawbacks with those for international market.

[tatus1969]

Anyone found a place with results from attacks to other members of the STM32 family? I am using their products, and have the vague hope that not all products are affected from the SWD interface race condition that enables the attack.

[Rasz]

F1 https://blog.zapb.de/stm32f1-exceptional-failure/
and now F2 and F4 https://blog.kraken.com/post/3662/kraken-identifies-critical-flaw-in-trezor-hardware-wallets/

[mac.6]

Anyone found a place with results from attacks to other members of the STM32 family? I am using their products, and have the vague hope that not all products are affected from the SWD interface race condition that enables the attack.

STM32F4 bootrom is trivially glitchable. Don't expect anything from non security hardened micros.

[S. Petrukhin]

Everything in STM32 screams "made in hurry", and "you are on your own".

Or they smoked good grass...