Frozen Trezor — Data Remanence Attacks!

UPDATE: Trezor is currently working on fixing “the issue” according to the CTO/Developer stickac.

Did you know that at low temperatures SRAM content is preserved for several seconds? That is called data remanence. Have you seen these two words on Trezor website, probably not?

So, when you disconnect your Trezor from a power source the SRAM content holding your private keys in plain text format can be preserved for prolonged time. This is like cryogenically freezing Trezor to resurrect him later on, only with a different mind (firmware) :-)

Here is a picture that shows the relationship between temperature and time on SRAM chips:

And a more recent study demonstrating the same thing on ARM Cortex-M4:

So, you think that you have to cool down your Trezor to -110 C using liquid nitrogen — not really. All you need is a $15 rapid Chip Freezer:

Thanks to the brilliant design, Trezor does not keep your private keys in SRAM in encrypted binary format. They are stored in plain text as seed words. Instead of storing a 250-bit number they are storing it as 1000-bit extended plain text with a lot of redundancy. Even if we lose 50% of this plain text, we can still with nearly 100% certainty restore the private keys. As you can see from the diagrams above, this significantly reduces the required cooling effort from -110 C down to -50 … -20 C range. That is why the chip freezer works perfectly for our purposes!

Why would anyone keep the secrets in memory like this? Why? I am literally banging my head against the wall!

Here is the full data extraction procedure

1. Decide if you are going perform freezing attack or the simple reset attack.

2. For simple reset attack, you must disassemble your Trezor. The ultrasonic welding breaks open really easily and seamlessly. Just a few seconds are needed for this step.

3. For FREEZING attack, instead of performing reset in step 7 you have to introduce a short power glitch (see DEFCON25 paper for help) while keeping the device at low temperature.

4. Use a fully charged laptop computer. It is important that you don’t lose power.

5. Connect Trezor to your computer.

6. Wait a few seconds until it initializes itself and you see a label on the screen.

7. If you are performing RESET attack, connect the RESET pin to Ground pin (just the two pins together), hold down two Trezor buttons and while doing that release the RESET. Otherwise, perform power glitch & release the two buttons. If you don’t succeed with this step, it is safe to start from step 5 again.

8. Execute from command line “tz_update fw_hacked_2017mar31.bin”. Since the firmware is tiny it only takes 4 seconds to flash it.

9. Follow instructions on Trezor screen but never disconnect it from power source anymore. You will lose your keys if you do that.

10. Press RESET when custom firmware upload is completed, take the risk to execute it. No need to do power glitch here.

11. Execute from command line “tz_dump” that will dump your seed, PIN, label and other information. Repeat step 11 if needed.

12. When you disconnect your Trezor ALL INFORMATION IS LOST.

13. With my flimsy fingers, it took me 18.6 seconds to perform all these steps.

14. You can also run “tz_update trezor-1.X.X.bin” to restore official firmware

15. After that you can use Trezor website and dumped seed/PIN/label to restore the Trezor into original state.

So, you say, JTAG — DEBUG PORTS — disabled? Really? We just used the RESET signal in the previous hack. This is part of the DEBUG PORT. Why is it even available on the production hardware?

Why could we freeze Trezor so easily, because there is no anti-tamper — NONE! If you search the internet you will find that various data remanence attacks have been performed on STMicro Cortex M4 processor. This is the one that Trezor v2 is planning to use. So, yes, all non-secure microcontrollers are certainly “doomed” if you try to use them to build secure hardware or if you think that you can run secure code on them — you can’t!