First Public Demonstration of STM32 Flash Readout Attack by Voltage Glitching

[Tom Li]

Hello,

Back in 2018, Niibe Yutaka noticed several companies from China claim to
offer flash read-out services, I pointed out that it's not a new threat [0] -
they probably have came into existence as early as 2012 for creating cheap
clones by rogue competitors. Unfortunately, no public information can
confirm the authenticity of these attacks, and no technical details were
known, only educated guesses. In the original reply, I said,

> It's commonly believed STM32F1 is easy to crack, both through physical
> IC decapping, physical IC decapping, or by mounting a fault injection
> attack to disable the flash readout protection, or exploiting the
> bootloader, who knows...

Today, I read in the news that the first public demonstration of such an
attack has been published by a group of security researchers. The targets
of the attack were STM32F205 and STM32F427 in order to attack the Trezor
Bitcoin wallet, but presumably it also applies to other STM32 series as well.

Unfortunately, it was exactly what I was worrying about - the attack method
involves both a fault injection attack, and an exploiting of the bootloader
using the fault. You can read the original article at [1], but here's a summary.

1. The original STM32 has RDP Level 2, i.e. JTAG/SWD debug interfaces are all
disabled, flash readout is prohibited. By using a voltage glitching attack on
boot, it's possible to corrupt the RDP Level and downgrade it to Level 1, re-
enabling all debug interfaces and the original bootloader. 

2. Although the same technique cannot be used to downgrade RDP Level to 0,
but it's possible to use another voltage glitching attack at the same time
when the flash readout command is issued, thus corrupting and bypassing the
security check of the readout command.

3. The attack only requires a FPGA and costs less than 100 USD. 

> The STM32s used in wallets like the Trezor One are set to RDP Level 2 at
> manufacturing time. This deativates all debugging features and disables
> the integrated BootROM bootloader. With voltage glitching it is possible
> to corrupt the RDP value being read from the Option Bytes, as shown in the
> Wallet.Fail research. This effectively allows an attacker to downgrade the
> security configuration of a target device from RDP Level 2 to RDP Level 1.
> A downgrade from RDP Level 1 to RDP Level 0 was determined to be infeasible
> in practice, due to the hamming distance between RDP Level 0 and RDP Level 2.
> By performing a voltage-glitch during BootROM execution it is possible to
> re-enable the JTAG and SWD debugging interfaces. It was determined that the
> integrated BootROM bootloader can be re-enabled in a similar fashion.

> However, since it was determined that for certain commands, i.e. Read Memory,
> the BootROM bootloader command handler checks if the RDP Level of the device
> is RDP Level 0 for each command issued to it. A voltage glitch timed to
> coincide with the RDP Level check of the command handler while processing
> commands that are disabled for RDP Levels other than RDP Level 0 can result in
> a bypass of the RDP Level check and the command succeeding as a result. This
> means that it is possible to glitch commands that should fail based on the
> device’s RDP configuration (i.e. bypassing the command handler that should
> have returned a NACK). As a result, it is possible to execute commands that
> are not available at RDP Level 1 or RDP Level 2. If applied to the Read Command,
> it is possible to arbitrarily read flash memory from the microcontroller. Since
> the cryptographic seeds of many STM32-based wallets are stored in the STM32
> flash, the seed storage of these devices can be compromised.

> A Digilent Arty A7 FPGA development board was used for glitch and pulse
> generation, as well as instrumenting the STM32 and accurately timing the glitch.
> An FTDI FT232H-based breakout board, the Adafruit FT232H, was used for UART
> serial communication with the BootROM bootloader command handler. A Maxim
> MAX4619 multiplexer was used to multiplex between a nominal operating voltage
> for the STM32 CPU core voltage and the glitch voltage, i.e. GND or 0v. A
> BreakingBitcoin board was used to simplify interacting, which is a pin-
> compatible Trezor breakout board. The same attack could be performed
> in-situ on a hardware wallet. However, removing the microcontroller and
> placing it in a socket was deemed to be easier than soldering all the
> connections (brimarily Boot0 and Boot1) for the in-situ attack. 

As we see, it's an attack that is easy to implement by anyone. And although
the original targets are STM32F2 and STM32F4, but it's highly likely that it
also applies to other devices. 

For now, I strongly recommend all Gnuk users to use a high-entropy PIN, with
newer GnuPG with KDF-DO feature enabled - it's not the end of the world, Gnuk
will still protect one's private key from attackers without physicial access
of the token.

And in the long run,

1. It's necessary to evaluate all security chips (and microcontroller designed
for security applications) on the market that don't require an NDA. A security
element (chip) is not guaranteed to be secure, it can be vulnerable to different
attacks as well, but empirically, the financial cost is higher, which is the
reason to adopt it.

2. And as I mentioned previously, it's also unnecessary to fully trust the
security element when if it's used. The goal is only to keep an unpowered Gnuk
more expensive to attack, so a double-encryption scheme can be used to provide
fallback to KDF-DO + Gnuk AES even if the security element is vulnerable. The
only downside is an additional latency/overhead, but I don't think it's
significant.

3. A community-wide effort is needed to develop a FPGA-based secure element, in
hope that it'll offer a more free and open implementation of a security element
than what's commercially available on the market without an NDA. 

Happy Hacking,

Tom Li
Beijing GNU/Linux User Group.

[0] https://lists.gnupg.org/pipermail/gnupg-users/2018-June/060616.html
[1] https://blog.kraken.com/post/3662/kraken-identifies-critical-flaw-in-trezor-hardware-wallets/