EEVblog #1006 - Trezor Bitcoin Hardware Wallet Teardown

[thm_w]

* We confirm that the steps in the blog post describe an attack which used the fixed vulnerability. This issue was patched in 1.5.2.

So they admit that it is vulnerable to to what is described in the blog post. Of course the author glossed over many details, but the main idea of the hack was presumably legitimate (reset timing based?).
Anyway its good that its fixed now.

* TREZOR’s plastic case is ultrasonically welded, making it difficult to open. It would be evident if it was replaced by a new case. In case of doubt, you can always scratch the case in a unique way, so that it is more difficult and time-consuming to replace the case.

Ok, that's valid but I think the concern would be someone stealing the wallet and retrieving all of the money on it, not reprogramming it.

[dorin]

What a lot of people seem to miss is that the whole point of having an opensource security solution is NOT to have perfect security from the beginning, but to have it constantly evolve in a dynamic and transparent way. Vulnerabilities that are patched quickly are NOT vulnerabilities.

Having some "hard", obscure security mechanism does not guarantee it will be free of flaws, and fixing them in this case is more problematic, as practice has often shown us. This type of approach is good for you as a customer ONLY when the security provider can be held liable and you get compensation. Which I don't think could be the case with Bitcoin.

So stop bitching. These guys are doing a decent job.

[Marvin]

Trezor released a more technical explanation now:
https://blog.trezor.io/fixing-physical-memory-access-issue-in-trezor-2b9b46bb4522

Long story short:
Pre 1.5.2 when Trezor was running it copied the master seed and PIN code to RAM to random memory locations that the compiler decided. When one now wanted to update the firmware it was needed to reset the device while pressing down both keys. Trezor software was running on the assumption that this needs unplugging and plugging, meaning RAM contents is lost. A 3rd party came forward on 1st of August and notified Trezor that they have found a way where they can software reset the device meaning RAM contents stays intact. This means one could power up the device with official firmware, the device would load storage into ram (master seed, PIN, etc), one could now software reboot the device to bootloader and flash a custom compiled firmware and software reboot the device again. Bootloader would detect an unofficial firmware being installed and erase the internal storage. But the RAM contents from 2 reboots back is still in place. As the device is now running custom firmware anything can be done with it - for example dump whole RAM contents via USB.

So this explains the confidential SECTION setup that was made for 1.5.2:
https://github.com/trezor/trezor-mcu/commit/98e617d8740b85ae01d7d6e0dd3f49e66057a210

Before today it was not clear why they did that change but the explanation is:

We came up with a clever way how to fix this issue for devices with older bootloader versions (as bootloader cannot be updated). In embedded programming, you can be very explicit where in the device memory should a variable be placed. We went through the entire code of TREZOR and marked all potentially confidential variables with a special mark. During the final assembly of the firmware, also called linking, we instructed a tool called linker to collect all variables with the mark and place them at the beginning of the device RAM. This way, we can assure that the bootloader will always overwrite all critical data from firmware with its own variables.

This was fixed and released to the public on 16th of August, a public notice was sent on Trezor mailing list urging Trezor owners to update their devices ASAP. On 17th of August the sensationalist blog post was put up where the author claimed a bug fixed in 1.5.1 "can't be fixed" (DEFCON) and a bug fixed in 1.5.2 "can't be fixed either" (the RAM+software reset bug) - claiming, without a single line of code or clear description of anything, that the whole security of Trezor has been "broken and can't be fixed". The blog post furthermore wanted 20 BTC for the proof of concept for the supposed exploit that still works on 1.5.2.

This was an attack vector that Trezor probably should have thought about - software resetting a SoC is not really anything out of this world. But the sensationalist blog post blew this all out of proportion - especially claiming that the issue could not be fixed.

[Marvin]

And THIS is how it should have been, THIS is the link that should have made rounds yesterday!
http://saleemrashid.com/2017/08/17/extracting-trezor-secrets-sram/

The guy reverse engineered the exploit fixed in 1.5.2 from the same github commit and wrote a proof of concept.
Every detail about the exploit is described and even referenced from the original Trezor code.

[stick]

And THIS is how it should have been, THIS is the link that should have made rounds yesterday!
http://saleemrashid.com/2017/08/17/extracting-trezor-secrets-sram/

The guy reverse engineered the exploit fixed in 1.5.2 from the same github commit and wrote a proof of concept.
Every detail about the exploit is described and even referenced from the original Trezor code.

Yes, Saleem did a very quick evaluation from the public commits and was able to come up with the PoC very quickly. Then he wrote the mentioned blogpost and asked us when he can publish it. We agreed that we will publish our findings today and he can publish immediately after that.

Really stellar approach!

[Marvin]

Don't know if we are feeding the troll now. But let's do it once more...

The same sensationalist source has a new blog entry:
https://medium.com/@Zero404Cool/frozen-trezor-data-remanence-attacks-de4d70c9ee8c

The tone of the blog is still the same.

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.

This seems sketchy. The 1.5.1 fix was against this (page 27 in DEFCON paper):
"TREZOR (and all clones) did not enable Clock Security System in the MCU, allowing injection of clock faults."

So let's suppose that did not help against voltage glitching. He makes it look nontrivial - just do a short power glitch - this is not a trivial thing to do. But let's suppose the voltage glitching could be done - what would it accomplish? Glitch to what state? Bootloader? The moment bootloader loads it overwrites where the information that was in RAM in the first 32KB (this is the confidential section stuff from 1.5.2). And then he goes on about loading his custom firmware. Even at -110C the RAM contents has already been overwritten. And because he just flashed his firmware the storage area is erased before his custom firmware is executed first time. Even the DEFCON guys could voltage glitch out of simple loops, not "we do a simple voltage glitch and boom we are now running a different program".

I am calling this FUD. I have to give it to the guy - he should start some kickstarter project, he can generate quality bullshit material with fancy graphs and techy words but giving no real information.

[mallman]

Newbie question. Thinking about long term bitcoin storage.

When one uses Trezor, we get the 24 word recovery phase and need to save it safely, there is no way around that.  Given that, why don't we mover all of our bitcoin into the Trezor wallet, and then reset the Trezor to its factory settings?  Then all the discussion about hacking the hardware is moot.  When we want to access our coins, just recover the wallet.  This would seem to remove whatever hacking risk there is.

In fact, if we wanted to protect from the $5 wrench extortion, we could even lock the Trezor is a safety deposit box (away from the words).  Thus, even if someone breaks into our house, they would never find the device to crack or extort.  This is pretty close to a "brain wallet", only is secure via 24 random words and isn't prone to forgetting.

Isn't this the ultimate in security?

[thm_w]

Isn't this the ultimate in security?

At the cost of convenience and being able to easily spend any of the bitcoins, sure.

[dorin]

In fact, if we wanted to protect from the $5 wrench extortion, we could even lock the Trezor is a safety deposit box (away from the words).  Thus, even if someone breaks into our house, they would never find the device to crack or extort.  This is pretty close to a "brain wallet", only is secure via 24 random words and isn't prone to forgetting.

Isn't this the ultimate in security?

They would find the safety deposit box to extort 
The only way against extortion is plausible deniability. Of course, when everyone has that, it becomes much less.. plausible.

The ultimate in security is using your brain all the time and never rely 100% on solutions sold to you.

[EEVblog]

Newbie question. Thinking about long term bitcoin storage.

When one uses Trezor, we get the 24 word recovery phase and need to save it safely, there is no way around that.  Given that, why don't we mover all of our bitcoin into the Trezor wallet, and then reset the Trezor to its factory settings?  Then all the discussion about hacking the hardware is moot.  When we want to access our coins, just recover the wallet.  This would seem to remove whatever hacking risk there is.

In fact, if we wanted to protect from the $5 wrench extortion, we could even lock the Trezor is a safety deposit box (away from the words).  Thus, even if someone breaks into our house, they would never find the device to crack or extort.  This is pretty close to a "brain wallet", only is secure via 24 random words and isn't prone to forgetting.

Isn't this the ultimate in security?

The ultimate security is keeping the words in your head, but even then someone can put a gun to you or someone else's head.
It comes down to basic security measure for anything physical. Paper with the words, Trezor, cash, gold, whatever.
The paper is much more vulnerable then the Trezor, anyone who has that has the coins.

[Kjelt]

The ultimate security is keeping the words in your head

Only single hurdle is no good, at least three hurdles are needed for decent security:
 1 Sometihng you and only you know (password)
 2 Something you and only you have (chipcard or passport or something like that)
 3 Some biometric that proofs that you are who you are (DNA, fingerprint, iris scan)

Extra add ons could be:
 - a different person that will also check when you provide the credentials esp. from 3. (bank manager, sergeant of arms at the gate)
 

[Marvin]

This is an interesting article:
https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf

Trezor already implements the suggested countermeasure against RDP downgrade via decapping and using UV to flip bits, detailed in 3.2.4 in the article, link to code below.
Trezor already implements the suggested countermeasure against Debug interface abuse, detailed in 3.3.4 in the article, as RDP is already set to level 2.
https://github.com/trezor/trezor-mcu/blob/master/memory.c#L30

But it's an interesting article to read nonetheless.