EEVblog #1006 - Trezor Bitcoin Hardware Wallet Teardown

[EEVblog]

What's inside the Trevor hardware bitcoin wallet?
A teardown to look at any physical hardware security, and a look at a possible side channel power line attack.
For a new stable attempt at cryptocurrency, check out Corion:
http://corion.io/-f1
CLARIFICATION: SatoshiLabs does not hold your wallet private key, it is encoded on the hardware with your custom PIN. Satoshi Labs only holds the private keys for the signing of the firmware.

[FrankBuss]

[EEVblog]

Social hacking 

[tombi]

Commonly known as 'Rubber hose cryptanalysis'

Would you really use this if you had millions in coins? Surely you would use a proper FIPS HSM or something. Sure it would cost a few coins..

Tom

[`]

For quite a while the software running on the Trezor was hopelessly vulnerable to power and timing sidechannel attacks in the ECDSA code, some of this was published by another researcher. The implementation was poor enough (it was originally manually transliterated python) that you could potentially extract the secret nonce during signing remotely just with the amount of noise emitted by the CPU, but this attack was never published. They've since improved the software somewhat but it is by no means constant time throughout, the inverse function in particular probably leaks bits of private information. ECDSA implementations need a lot of care to not expose information about certain parts of signature creation, single bits over multiple signatures is enough to leak private keys. It's hard to be worse than Sony's implementation in the PS3 however, which used a static nonce over multiple signatures which directly leaked their private keys.

[tszaboo]

Let's be realistic. Would anyone trust a third party hardware wallet, to keep for example 10.000 EUR? Like would you trust it, that it would not break, the software on it would not do something stupid, like jump somewhere due to ESD. Or your OLED would go tits up, and then your money is lost? Really?

[`]

Let's be realistic. Would anyone trust a third party hardware wallet, to keep for example 10.000 EUR? Like would you trust it, that it would not break, the software on it would not do something stupid, like jump somewhere due to ESD. Or your OLED would go tits up, and then your money is lost? Really?

You can back the devices up using deterministic key generation (usually by writing a master key / seed down on paper, encoded as a series of words), expecting users to follow directions and make a complete backup of the seed has proven unwise in the past however. Trust is a very real issue though, there's no real way of being able to work out if a device has been rigged to generate back doored keys, or leak information about keys through a side channel, or any number of malicious activities. It's an opaque silicon blob you hope actually came from the manufacturer and isn't malicious, but honestly that applies to almost all computer hardware.

[stick]

Hello Everyone!

I am a big fan of Dave and EEVblog and I was very pleased today when I saw the newest video. I did not know that Dave is a Bitcoin user, nor that he knows about TREZOR. Really really nice surprise! 

Now for some clarification points.

Q: Why didn't you use Secure Element or Secure Chip?

A: We want to keep TREZOR as open as possible (both firmware and hardware are completely open source and available at our GitHub). If we used Secure Element we would limit hobbyist and hackers in creating their own clones, because you cannot use Secure Element in your design unless you sign a non-disclosure agreement with the vendor. By using standard off the shelf components, we make that really easy. I am aware of Secure Element advantages, but we are trying to fix most disadvantages of generic MCU in the software (see below). Also there is a blog post of a community member gbg describing how he built such clone: http://www.stellaw.info/blog/2015/12/22/i-built-my-own-trezor-clone-dinosaur-hiphop-zero


Q: Why didn't you use epoxy like it was suggested in the video?

A: I see three reasons why use epoxy.

   First is to increase the durability of the device. We feel that TREZOR is durable enough even without the epoxy.

   Second, to obfuscate components you are using in your design. This is not needed as the design is open source.

   Thirdly, to make access to the MCU harder. If you are highly motivated, epoxy will just slow you down, not stop you. Also MCU has disabled JTAG, so there is no need to block access to MCU pins.


Q: What's up with the side channels attacks?

A: Side channel attacked described by Jochen Hoenicke were fixed by rewriting all crypto functions to use constant time. Jochen did almost all of the fixing and we've been collaborating ever since on various security and non-security related improvements. We love our community! Also we ask PIN before every operation involving a private key (e.g. generating of the public key), so even if there was some side channel attack left, you still need to know the PIN to trigger it.


Q: How about MCU glitching?

A: We did our best to protect the MCU against glitching (e.g. when we check the PIN, we first increase the PIN failure count, write it to flash, verify that write was OK, then check whether the PIN was correct and if it was correct then we reset the PIN failure count). That way you cannot glitch the PIN increase write. That said, recently, we received couple of ideas for further improvements from Josh Datko and he'll talk about the issues (and fixes we are together working on) in his Defcon talk later this month: https://www.defcon.org/html/defcon-25/dc-25-speakers.html#Datko


Q: My neighbour has an one million dollar microscope equipment and he is examining my TREZOR. Should I worry?

A: No. There is a big difference between attacks on smart cards and TREZOR. If your smart card is stolen and one can read the secrets from it, you can basically do nothing about it. (You don't have the secrets and only attacker has them). TREZOR is a different animal. You have the backup so you can use that to send your funds before the attacker has access to them.

   Also we have introduced a concept of so-called passphrase. If you use passphrase, you are requested to enter your passphrase before the signing operation. This passphrase is combined with the secret stored in the device, resulting in creation of a completely new secret key and thus a completely new wallet! If an attacker has successfully extracted the secret from the device and he does not know your passphrase, he still cannot access your funds! Also because passphrase does not act like password (it is not not compared against known value but rather combined with the secret, making _every_ passphrase valid), it provides a plausible deniability. If you are interrogated, you can give any passphrase you want and attacker will see empty wallet. (Or you can use passphrase "lonelypumpkins" where you store millions and passphrase "funnyspirit to create a wallet where you just send a few dollars - to make it look like it's being really used).

For more information about the concepts I described here, please check our FAQ and User Manual:  https://doc.satoshilabs.com/trezor-faq/   https://doc.satoshilabs.com/trezor-user/

TL;DR: We try to combine hardware and software effots to create a really open security device. We are not big fans of security through obscurity and we rather introduce smart logical concepts which are unbreakable by design, rather than relying on chance that hardware vendor did the good job obfuscating the design.

[stick]

the inverse function in particular probably leaks bits of private information

Untrue, we worked with Jochen to rewrite all crypto to constant-time. See my longer post with Q&As.

[stick]

You can back the devices up using deterministic key generation (usually by writing a master key / seed down on paper, encoded as a series of words),

True, you backup the device by writing down the 12 or 24 words which encode the master private key.

expecting users to follow directions and make a complete backup of the seed has proven unwise in the past however.

Actually, the devices come uninitialized (so you can be sure we don't have your private keys) and one has to initialize and perform backup (as it is a part of initialization procedure) before it can by used in any way.

[EEVblog]

Let's be realistic. Would anyone trust a third party hardware wallet, to keep for example 10.000 EUR? Like would you trust it, that it would not break, the software on it would not do something stupid, like jump somewhere due to ESD. Or your OLED would go tits up, and then your money is lost? Really?

That's not how it works. If the device fails then you can recover to a new device or some other compatible wallet using your printed out 24 word seed.

[tszaboo]

Let's be realistic. Would anyone trust a third party hardware wallet, to keep for example 10.000 EUR? Like would you trust it, that it would not break, the software on it would not do something stupid, like jump somewhere due to ESD. Or your OLED would go tits up, and then your money is lost? Really?

That's not how it works. If the device fails then you can recover to a new device or some other compatible wallet using your printed out 24 word seed.

Ok, that is reasonable. I see it was actually overlay text.
Then what is preventing someone to just taking the 24 word and "recover" my money?

And it still, there is the issue with the volatility of Bitcoin. And the fact that we waste power on it for no good reason. Some estimated, that a simple transaction takes more than 100KWh of energy. Imagine if people actually start using it to pay for commodity items. Completely unsustainable.
Not an issue of the device, the issue with the cryptocurrency.

[stick]

Then what is preventing someone to just taking the 24 word and "recover" my money?

The idea behind the (paper) word backup is that people are generally good in protecting their physical assets but quite bad when it comes to protecting their digital assets. Surely you can find a safe place for your backup (grandma's attic, deposit box in the bank, etc.). Also there is a passphrase I describe in my Q&A post above which renders this backup basically useless if attacker does not know the correct passphrase.

And the fact that we waste power on it for no good reason.

Not true, the power is not wasted but used to make the whole "thing work". You use power to verify the transactions and provide so called proof-of-work. Your claim is no different from claiming "VISA/Mastercard waste power in their datacenters for no good reason".

Some estimated, that a simple transaction takes more than 100KWh of energy. Imagine if people actually start using it to pay for commodity items. Completely unsustainable.

There are second layer solutions coming (similar to what VISA/Mastercard do at the end of the day - where they just exchange the difference in balances between the two, not every transaction between the two), so the energy used to perform a transaction will go down. (Because not every transaction would be commited to main blockchain, but rather just an aggregate of transactions).

[EEVblog]

Hello Everyone!
I am a big fan of Dave and EEVblog and I was very pleased today when I saw the newest video. I did not know that Dave is a Bitcoin user, nor that he knows about TREZOR. Really really nice surprise! 

Thanks for joining and sharing technical info directly, the community always appreciates that.

[Kjelt]

Sorry stopped watching this after the presumed power SCA.
That is not how you perform an PSCA.
For a good SCA you have to starve the uC of current, you remove all capacitors or place them as far away as possible without the uC going down and measure directly on the Vcc pins of the micro and measure the current. This takes a lot of time, preparation and experimentation.

If you really would like your device tested properly for SCAttacks hire a pro firm like Riscure in the Netherlands, they can also perform timing, glitching, emc, field and other SCAs. But seeing you use a standard STM32 I think I already can predict the outcome. However there is always a balance between security and costs. As long as the value of the device is not an order greater than the cost of the effort to hack it I would not loose any sleep over it.

[bittumbler]

That is not how you perform an PSCA.
For a good SCA you have to starve the uC of current, you remove all capacitors or place them as far away as possible without the uC going down and measure directly on the Vcc pins of the micro and measure the current. This takes a lot of time, preparation and experimentation.

And also remove anything that draws lots of power, such as LED, buzzer, etc.

[stick]

If you really would like your device tested properly for SCAttacks hire a pro firm like Riscure in the Netherlands, they can also perform timing, glitching, emc, field and other SCAs. But seeing you use a standard STM32 I think I already can predict the outcome. However there is always a balance between security and costs. As long as the value of the device is not an order greater than the cost of the effort to hack it I would not loose any sleep over it.

Have you read my Q&A post above? It is full of interesting information. Also thanks for Riscure tip.

[Fungus]

That is not how you perform an PSCA.
For a good SCA you have to starve the uC of current, you remove all capacitors or place them as far away as possible without the uC going down and measure directly on the Vcc pins of the micro and measure the current. This takes a lot of time, preparation and experimentation.

And also remove anything that draws lots of power, such as LED, buzzer, etc.

I'm sure Dave knows this. He also knows it's a waste of time because this thing is hardened against it so there's not much point in doing it well.

I think he was just showing the basic technique but only Dave knows for sure.

[f4eru]

Social hacking 

Social Fracking

[jiro]

Q: Why didn't you use Secure Element or Secure Chip?

A: We want to keep TREZOR as open as possible (both firmware and hardware are completely open source and available at our GitHub). If we used Secure Element we would limit hobbyist and hackers in creating their own clones, because you cannot use Secure Element in your design unless you sign a non-disclosure agreement with the vendor. By using standard off the shelf components, we make that really easy. I am aware of Secure Element advantages, but we are trying to fix most disadvantages of generic MCU in the software (see below). Also there is a blog post of a community member gbg describing how he built such clone: http://www.stellaw.info/blog/2015/12/22/i-built-my-own-trezor-clone-dinosaur-hiphop-zero

Is nice to see more open iniciatives like this <insert a beer here>   

Nice move if we see how the payment methods and currencies seems to be moving in that direction (cryptocurrencies, wallets like the google and apple) even better whe you see it is open.

[crisr]

The thing about the non-existent physical security side (e.g.: battery-backed SRAM, intrusion switches and meshes, ambient light sensors, etc.) on Trezor is that on things like credit card PIN-pads they are actually protecting the company's private keys (or something like that), not necessarily the user's private keys.

Since basically anyone has access to these pin-pads, compromising one of them could actually compromise the entire network as well as the credit card users. On Trezor and other hardware wallets, the only secret is what the user puts in them. So compromising one Trezor would not compromise others.

In order for someone to access your private keys that way they would have to first get their hands on YOUR Trezor, not anyone else's. And in the time it would take for someone to do it, and combined with passphrase security (which is not stored on the hardware), you could, using your seed and another wallet, transfer your coins to other addresses, basically rendering the stolen one useless.

On top of that, even if you have your seed backed up (or especially if it is stored somewhere difficult to access and protected under several layers of security), you don't want to accidentally lose you private keys if you drop your device and the case cracks...

[crisr]

Ok, that is reasonable. I see it was actually overlay text.
Then what is preventing someone to just taking the 24 word and "recover" my money?

Hardware wallets are used mostly for the convenience of not having to use (several) paper wallets and/or air-gapped computers to sign transactions, while maintaining most of the security. Since you do not have to ever use your 24-word seed unless you break / lose your hardware wallet, it can be very well protected - hidden, obscured, split in several places, whatever (not to mention passphrase protection combined with the 24-word seed). In that respect, security is even greater this way, because on air-gapped computers and paper wallets you need access to the private key on each transaction. What would stop anyone just taking my paper wallet and recovering my money?

And it still, there is the issue with the volatility of Bitcoin. And the fact that we waste power on it for no good reason. Some estimated, that a simple transaction takes more than 100KWh of energy. Imagine if people actually start using it to pay for commodity items. Completely unsustainable.
Not an issue of the device, the issue with the cryptocurrency.

That is another thing, but bitcoin is hardly the only cryptocurrency out there. Trezor itself and other hardware wallets can work with several of them. Some of those do not rely on power-hungry Proof-Of-Work coin generation, but other validation techniques such as Proof-Of-Stake which are very efficient. Some also can sustain several thousand transactions per second with current infrastructure, compared to bitcoin's current three or so. And volatility happens because, in spite of rising real-world usage, speculation plays a big part in the price; once cryptocurrencies start gaining mainstream usage and market cap, volatility tends to diminish (and prices to go, albeit stabler, a lot higher).

[stick]

Since basically anyone has access to these pin-pads, compromising one of them could actually compromise the entire network as well as the credit card users. On Trezor and other hardware wallets, the only secret is what the user puts in them. So compromising one Trezor would not compromise others.

In order for someone to access your private keys that way they would have to first get their hands on YOUR Trezor, not anyone else's. And in the time it would take for someone to do it, and combined with passphrase security (which is not stored on the hardware), you could, using your seed and another wallet, transfer your coins to other addresses, basically rendering the stolen one useless.

These two are spot-on observations! Congratulations! I am always very happy when someone is able to understand these, not so very easy to grasp, concepts.

[NiHaoMike]

Maybe send it to Micah Elizabeth Scott? She's really good at reverse engineering embedded systems.

[jh15]

Is any of this on Security Now?

This is a security show on for 10 years or so, but I haven;t checked for a couple weeks. I think the host, Steve Gibson mined some coins early on, overnight. 30, I think.

Any of you gurus would be great to listen to on the show.

Tuesdays on http://www.twit.tv/sn