Re:Hacking the most popular cryptocurrency hardware wallets ...
by Scoundreller on Thursday December 27, 2018 @07:39PM
(#18773939)
Quick summary for those that can't watch the stream (to the best of my understanding):
0. All units tested were easy to open up to access PCB.
1. The security stickers are easily removed and reattached. (There have been clones created).
2. A hardware implant could be created to remotely "hit" the "OK" button for transaction authorizations sent to the hardware with minimal $partcount.
3. Ledger Nano S has an easy-to-access interface (e.g. with pogo pins) for its STM32 MCU (used for its insecure tasks). There is also a 'Secure Enclave" STM31. A compromised STM32 could send malicious transactions to the ST31. Unsigned firmwares used to be loadable, but not anymore. But the bootloader doesn't verify flash on each boot (after a firmware upgrade), instead verifying a space in memory. But STM32's memory map mirrors some addresses. So you can write to the mirrored location the constant it wants to see and load your own unsigned firmware.
4. STM32 sends the firmware to the STM31 to verify it. But they had a workaround with compression and RAM to send the original firmware to the STM31, while running something else. Youtuber: LiveOverflow has further info on this.
5. The Ledger Blue. Has a BT LE module. It doesn't have it enabled, but does have an antenna (on the PCB). With a USB cable as an antenna, they could sniff PIN input. They believe it was probably because the PIN input changes the colour of the button when pressed. They were likely sniffing the display output. 90% accuracy per input. They used AI with automated physical input to train.
6. Trezor 1: Vulnerabilities to glitching attacks. They admit that they couldn't find any other vulnerabilities into it.
Using an STM32 again. The Tresor protects against a formerly published UV-based security downgrade attack (Obermaier attack). They attempt to downgrade the Read-Out bytes to give them access (which are in flash). They knew based on how long MCU takes to boot from boot ROM and when application execution is to narrow down when to try to glitch. They used an FPGA to get the timing right (their timing is predictable). A multiplexer was used to switch voltages. Just glitch and see if they have JTAG access. Rinse repeat. Took 3 months to get a successful glitch. They couldn't read the flash, only RAM. Seed is stored in flash. So needed method to get seed into RAM. Upgrade procedure is designed to allow firmware upgrades without erasing seed. It does this by copying seed to RAM. So they would start the firmware process, then dump the RAM. Voila, seeds are plaintext in the dump. And the PIN.
They've built a Trezor glitcher (would require desoldering the chip and placing it in the device socket). They think an Arduino could be fast enough to do the glitch.
To protect against this glitch attacks, a passphrase should do it.
0. All units tested were easy to open up to access PCB.
1. The security stickers are easily removed and reattached. (There have been clones created).
2. A hardware implant could be created to remotely "hit" the "OK" button for transaction authorizations sent to the hardware with minimal $partcount.
3. Ledger Nano S has an easy-to-access interface (e.g. with pogo pins) for its STM32 MCU (used for its insecure tasks). There is also a 'Secure Enclave" STM31. A compromised STM32 could send malicious transactions to the ST31. Unsigned firmwares used to be loadable, but not anymore. But the bootloader doesn't verify flash on each boot (after a firmware upgrade), instead verifying a space in memory. But STM32's memory map mirrors some addresses. So you can write to the mirrored location the constant it wants to see and load your own unsigned firmware.
4. STM32 sends the firmware to the STM31 to verify it. But they had a workaround with compression and RAM to send the original firmware to the STM31, while running something else. Youtuber: LiveOverflow has further info on this.
5. The Ledger Blue. Has a BT LE module. It doesn't have it enabled, but does have an antenna (on the PCB). With a USB cable as an antenna, they could sniff PIN input. They believe it was probably because the PIN input changes the colour of the button when pressed. They were likely sniffing the display output. 90% accuracy per input. They used AI with automated physical input to train.
6. Trezor 1: Vulnerabilities to glitching attacks. They admit that they couldn't find any other vulnerabilities into it. Using an STM32 again. The Tresor protects against a formerly published UV-based security downgrade attack (Obermaier attack). They attempt to downgrade the Read-Out bytes to give them access (which are in flash). They knew based on how long MCU takes to boot from boot ROM and when application execution is to narrow down when to try to glitch. They used an FPGA to get the timing right (their timing is predictable). A multiplexer was used to switch voltages. Just glitch and see if they have JTAG access. Rinse repeat. Took 3 months to get a successful glitch. They couldn't read the flash, only RAM. Seed is stored in flash. So needed method to get seed into RAM. Upgrade procedure is designed to allow firmware upgrades without erasing seed. It does this by copying seed to RAM. So they would start the firmware process, then dump the RAM. Voila, seeds are plaintext in the dump. And the PIN.
They've built a Trezor glitcher (would require desoldering the chip and placing it in the device socket). They think an Arduino could be fast enough to do the glitch.
To protect against this glitch attacks, a passphrase should do it.