STM32 readout protection is broken - Page 1
Forum section: electronics / general

author: eltar
author_rank: Newbie
timestamp: October 23, 2017, 09:13:06 pm
content: https://www.aisec.fraunhofer.de/en/FirmwareProtection.html

author: Mr. Scram
author_rank: Super Contributor
timestamp: October 23, 2017, 09:32:04 pm
content: 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.

author: stmdude
author_rank: Frequent Contributor
timestamp: October 24, 2017, 06:52:55 am
content: 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.

author: eltar
author_rank: Newbie
timestamp: October 24, 2017, 04:29:37 pm
content: Another related thread (from 2014) mentioning broken readout protection on STM32F1:https://groups.yahoo.com/neo/groups/nuttx/conversations/topics/7310

author: Siwastaja
author_rank: Super Contributor
timestamp: October 24, 2017, 07:32:07 pm
content: 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 onereallyneeds 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.

author: Rasz
author_rank: Super Contributor
timestamp: October 24, 2017, 10:40:20 pm
content: 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/

author: KL27x
author_rank: Super Contributor
timestamp: October 25, 2017, 12:02:09 am
content: QuoteI 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.

author: Kjelt
author_rank: Super Contributor
timestamp: October 25, 2017, 08:36:49 am
content: 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 ?

author: AndyC_772
author_rank: Super Contributor
timestamp: October 25, 2017, 08:39:33 am
content: Read the whole paper, it's worth your time.

author: Kjelt
author_rank: Super Contributor
timestamp: October 25, 2017, 08:45:07 am
content: Yeah just read that they can downgrade level 2 to level 1 with UV.

author: jnz
author_rank: Frequent Contributor
timestamp: October 25, 2017, 05:18:55 pm
content: 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.

author: dgtl
author_rank: Regular Contributor
timestamp: October 26, 2017, 12:20:33 pm
content: Quote from: jnz on October 25, 2017, 05:18:55 pmThere'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.

author: jnz
author_rank: Frequent Contributor
timestamp: October 26, 2017, 04:13:36 pm
content: Quote from: dgtl on October 26, 2017, 12:20:33 pmOk, 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.

author: eltar
author_rank: Newbie
timestamp: October 26, 2017, 07:37:21 pm
content: SWD attack implementation using a BusPirate and PySWD module:https://gist.github.com/egirault/7b3fe7041e1bf5e2258ed5df7083f14d

author: MT
author_rank: Super Contributor
timestamp: October 26, 2017, 09:22:38 pm
content: 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

author: Jeroen3
author_rank: Super Contributor
timestamp: October 28, 2017, 02:06:03 pm
content: 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.

author: tatus1969
author_rank: Super Contributor
timestamp: October 29, 2017, 08:23:20 am
content: 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.

author: Rasz
author_rank: Super Contributor
timestamp: February 05, 2021, 08:48:24 am
content: F1https://blog.zapb.de/stm32f1-exceptional-failure/and now F2 and F4https://blog.kraken.com/post/3662/kraken-identifies-critical-flaw-in-trezor-hardware-wallets/

author: mac.6
author_rank: Regular Contributor
timestamp: February 05, 2021, 08:40:47 pm
content: Quote from: tatus1969 on October 29, 2017, 08:23:20 amSTM32F4 bootrom is trivially glitchable. Don't expect anything from non security hardened micros.

author: S. Petrukhin
author_rank: Super Contributor
timestamp: February 08, 2021, 03:02:18 pm
content: Quote from: Siwastaja on October 24, 2017, 07:32:07 pmOr they smoked good grass...