From tomli at tomli.me Sat Feb 1 07:53:07 2020 From: tomli at tomli.me (Tom Li) Date: Sat, 1 Feb 2020 14:53:07 +0800 Subject: First Public Demonstration of STM32 Flash Readout Attack by Voltage Glitching Message-ID: <20200201065307.GA17624@localhost.localdomain> 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/ From gniibe at fsij.org Sat Feb 1 09:42:23 2020 From: gniibe at fsij.org (NIIBE Yutaka) Date: Sat, 01 Feb 2020 17:42:23 +0900 Subject: First Public Demonstration of STM32 Flash Readout Attack by Voltage Glitching In-Reply-To: <20200201065307.GA17624@localhost.localdomain> References: <20200201065307.GA17624@localhost.localdomain> Message-ID: <87r1zepukw.fsf@jumper.gniibe.org> Tom Li wrote: > 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. [...] > [1] https://blog.kraken.com/post/3662/kraken-identifies-critical-flaw-in-trezor-hardware-wallets/ Thanks for sharing important information. I guess that such a technique could be also applied to GD32F103 or even GD32VF103. Well, it is matter of how it's difficult (how much cost) to extract data from the chip, and/or, how long it takes time. Tom, I wish your situation is not that worse by 2019-nCoV. After the outbreak will be settle down, it's good if we can meet again. :-) -- From vagrant at debian.org Fri Feb 21 09:03:54 2020 From: vagrant at debian.org (Vagrant Cascadian) Date: Fri, 21 Feb 2020 00:03:54 -0800 Subject: Dropping RSA support (Re: Gnuk 1.2.15) In-Reply-To: References: Message-ID: <87d0a8e591.fsf@yucca> On 2020-01-24, NIIBE Yutaka wrote: > In 2020, I'm going to remove old features (like RSA and classic ECC) > from master, and I'd like to support modern ECC only. If my master key is RSA, but all the subkeys are currently ECC of some form, will this still be possible? What about old encryption keys? Use an extra gnuk just to decrypt those messages? live well, vagrant -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 227 bytes Desc: not available URL: