EEVblog Electronics Community Forum
EEVblog => EEVblog Specific => Topic started by: EEVblog on July 13, 2017, 05:43:57 am
-
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 (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.
https://www.youtube.com/watch?v=BzxGoJdd8a4 (https://www.youtube.com/watch?v=BzxGoJdd8a4)
-
(https://imgs.xkcd.com/comics/security.png)
-
(https://imgs.xkcd.com/comics/security.png)
Social hacking ;D
-
Commonly known as 'Rubber hose cryptanalysis (https://en.wikipedia.org/wiki/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 (https://jochen-hoenicke.de/trezor-power-analysis/). 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 (https://arstechnica.com/gaming/2010/12/ps3-hacked-through-poor-implementation-of-cryptography/).
-
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.
-
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 (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 (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-faq/) https://doc.satoshilabs.com/trezor-user/ (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.
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
-
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.
-
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.
-
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.
-
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.
-
(https://imgs.xkcd.com/comics/security.png)
Social hacking ;D
Social Fracking ;D
-
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 (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.
-
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...
-
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).
-
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.
-
Maybe send it to Micah Elizabeth Scott? She's really good at reverse engineering embedded systems.
-
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 (http://www.twit.tv/sn)
-
Maybe send it to Micah Elizabeth Scott? She's really good at reverse engineering embedded systems.
Already sent her a package today! :-)
-
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.
I guess that is reasonable.
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".
Right now, bitcoin is using more energy than Lithuana. Estimates say, that it will use more than Denmark by 2020. And Denmark actually provides cookies and slightly overrated beers, and Lego. Bitcoin is pretty much just a bunch of useless bits (in the grand scheme of things). That energy can be put into use, instead of providing a untraceable platform to pay for drugs and sex slaves.
And there is the side effects. It is impossible to buy mid-tier graphic cards, because they are just bought for etherium mining. ROI is like a few months, and people buy dozens a time just to make money with it. Because they have access to cheap electricity, I need to pay twice as much for a RX480 for example.
There are second layer solutions coming ... so the energy used to perform a transaction will go down.
Than is much needed, because right now, its not economical, nor sustainable.
I understand, that you have a product, and you want to earn money with it. Its fine, good luck. I mean it.
I am not happy about the grand scheme of things that are happening with cryptocurrencies. It was never supposed to work like that.
-
There is great talk by Christopher Tarnovsky about Semiconductor Security https://www.youtube.com/watch?v=WXX00tRKOlw (https://www.youtube.com/watch?v=WXX00tRKOlw)
It's a little bit off topic but I think many interested in Trezor will find this very interesting.
-
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 (http://www.stellaw.info/blog/2015/12/22/i-built-my-own-trezor-clone-dinosaur-hiphop-zero)
I used to do a lot of hacking using IMX.6 processor (Former Freescale now NXP). It have decent security but does not require any NDA (to my best knowledge). I'm aware that it's expensive and powerful processor so not suitable for such design.
-
Bitcoin inherently has a mechanism to keep mining just barely profitable on average. Unprofitable miners leave, causing the difficulty to drop. The price rising or advances in mining technology add more miners to the network, causing the difficulty to rise to keep things balanced.
For now, most of the energy used is for generating new coins. As time goes on, the mining profits will go more and more towards transaction fees as opposed to new Bitcoins.
There are altcoins that are far more energy efficient to mine as compared to Bitcoin, but they suffer from the "ratchet effect". The reason being that if mining still returns more than the cost of energy used, the miners will keep running. That's particularly true of coins that are mined using hard drives or smartphones, where the cost of electricity isn't even factored into the profit calculation.
-
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 (http://www.stellaw.info/blog/2015/12/22/i-built-my-own-trezor-clone-dinosaur-hiphop-zero)
Oops!
https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8 (https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8)
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.
Double oops!
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.
Seems that wasn't such a good idea :palm:
-
Trezor says version 1.5.2 is safe?
Also, the hack is being sold?
Alexander.
-
Trezor says version 1.5.2 is safe?
They have not clarified if it's both the physical attack and the USB attack, or just one.
Also, the hack is being sold?
Yep, for 0.5 BTC (> AUD$2500)
-
Their main point about not using a secure processor is valid, you need an NDA so it makes 3rd part auditing not easy.
But I'm thinking they could have maybe used a two chip solution for decoupling the USB interface from the micro using a (secure?) USB chip and the ST ARM micro as they currently have it, and then added physical security by potting the whole thing?
That should prevent any direct USB attack on the ST micro, surely?
-
You should make a follow-up showing this hack Dave.
-
You should make a follow-up showing this hack Dave.
Looks like I have to pay 0.5 BTC to get the hack though?
-
To RGB255_0_0 and all other sensationalist guys.
The FUD on the "exploit" page is CRAZY. Like literally fake news worthy. I am not in any ways involved with the company that produces the Trezor but this kind of a page would be laughed at if they would have anlogous text about a remote root exploit for Linux. And it seems that everyone is falling to this sensationalist hype.
They are not providing ANY information that is not available, the whole talk about "exploit" is based on the DEFCON presentation that was fixed with this commit:
https://github.com/trezor/trezor-mcu/commit/c8ddd904099d4b082220a684980806108a2eae47
Where they saw what was presented at DEFCON and fixed it.
Yesterdays 1.5.2 release has not been discussed in depth by the company but from github one can see that this is the major change:
https://github.com/trezor/trezor-mcu/commit/98e617d8740b85ae01d7d6e0dd3f49e66057a210
Where they implement a custom reset handler in this file:
https://github.com/trezor/trezor-mcu/blob/98e617d8740b85ae01d7d6e0dd3f49e66057a210/startup.s
And last - they were asking for !!! 20BTC !!!! before taking the 1.5.2 "exploit" link down.
This all thing stinks.
-
Here is the DEFCON talk about voltage glitching, bad quality until official steams are but up in a month or so:
https://www.youtube.com/watch?v=EMOp7Z3ZSUc (https://www.youtube.com/watch?v=EMOp7Z3ZSUc)
Slides:
https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Datko-and-Quartier-Breaking-Bitcoin-Hardware-Wallets.pdf (https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Datko-and-Quartier-Breaking-Bitcoin-Hardware-Wallets.pdf)
-
From the comments of the article page:
FUD, this doesn’t work with the recently released 1.5.2, since it wipes the seed when an unsigned firmware is loaded.
The fact that the hack is being sold is really fishy.
Alexander.
-
Don't want to edit posts so clarifying my last posts.
What I meant with "They are not providing ANY information that is not available" - they are providing NO new information, zero, there is literally 0 information abou the supposed exploit. The description of the "exploit" is something that I would come up if someone asked me "read this code change, describe what was fixed as a breake in vector". And the code change is free for anyone to read on the official trezor github page.
And the screenshot about the supposed output? That shows ABSOLUTELY NOTHING. Literally a text file. They don't show the trezor booting. One can download the the whole trezor source code and compile their own firmware. Upon flashing that on the device the device instantly zeros internal storage and displays this screen every time it boots:
https://pbs.twimg.com/media/B_CRZYqW0AAhSmh.jpg
This check is done by the bootloader that can NOT be updated. If the firmware is not signed by the trezor company it will display that message and erase internal storage. This is the only real weakness - if someone somehow gets their hands on the signing key. But this weakness exist for ALL hardware device that have signature checking for firmware.
Without showing a trezor being disconnected and connected to a USB cable and the "exploit" at work this is most probably a firmware that was checked out and just writing the internal storage content out. And this is unencrypted by design as it brings nothing in security wise having it for example encrypted by the PIN code (has been suggested on reddit etc today).
-
To RGB255_0_0 and all other sensationalist guys.
The FUD on the "exploit" page is CRAZY. Like literally fake news worthy.
Their response to me when I asked on twitter was "The article is not 100% accurate".
When asked what was wrong, they responded:
15s is awfully short. SW fix is possible and was released. Weakness fixed in FW 1.5.2. No information about the "advanced" method.
So their main complaint is that they think the time to crack it was was exaggerated, so what?
Fact remains it was hacked and the seed words were removed from the SRAM in plain text! Sure they might have fixed it now, but what a ridiculously embarrassing oversight!
They seem to have no knowledge of the "advanced" software only hack, so if that turns out to be real then that's a third hack (the current one being the 2nd they have had to patch)
-
And the screenshot about the supposed output? That shows ABSOLUTELY NOTHING. Literally a text file.
Umm, it shows the entire seed key in plain text and the pin number. How is that nothing? If true, it's EVERYTHING!
-
And the screenshot about the supposed output? That shows ABSOLUTELY NOTHING. Literally a text file.
Umm, it shows the entire seed key in plain text and the pin number. How is that nothing? If true, it's EVERYTHING!
It shows the internal storage. But there is no way to verify how this was read out. You can flash your trezor with a custom firmware and add a function to print out the internal storage. The internal storage is NOT crypted. It's protected by the bootloader that erases it first time it detects a new unsigned firmware. After that you can set your trezor up again, have it generate new wallet and boom - print out the internal storage. But every time you now boot your trezor it will complain that you are running unofficial firmware. There is NO proof on the exploit site that this was NOT done.
-
And the screenshot about the supposed output? That shows ABSOLUTELY NOTHING. Literally a text file.
Umm, it shows the entire seed key in plain text and the pin number. How is that nothing? If true, it's EVERYTHING!
It shows the internal storage. But there is no way to verify how this was read out. You can flash your trezor with a custom firmware and add a function to print out the internal storage. The internal storage is NOT crypted. It's protected by the bootloader that erases it first time it detects a new unsigned firmware. After that you can set your trezor up again, have it generate new wallet and boom - print out the internal storage. But every time you now boot your trezor it will complain that you are running unofficial firmware. There is NO proof on the exploit site that this was NOT done.
Err, then why have Trezor said they have fixed it if it wasn't possible?
They don't seem to be jumping up and down creaming that this is complete and utter BS. They have admitted a flaw was found and have implemented a fix.
-
What makes this whole situation sad - I have mad respect for you Dave. But you had literally 0 verification of the source when you started to push about this on twitter. This is literally batteriser level stuff. Some guy (it's not a known group of hacker or even a known hacker) literally wrote a blog page having sketchy images and NO information. Only his word - "batteriser will extend the lifetime of your battery by 95%" vs "“Absolutely, yes!”?—?that’s the answer we got at DEFCON 25. So, the ST32F05 chip is really doomed." Even that is totally wrong. His first stance is already wrong. And he goes on with providing absolutely NO proof, no real exploit description, no proof of concept. ZERO.
You did no source analysis before claiming - I called it! And you are a know figure. This is basically like putting your name on the exploit - approved by Dave Jones:"I called it, this is 100% true!" Like the supposed scientists validating that batteriser works.
-
Err, then why have Trezor said they have fixed it if it wasn't possible?
They don't seem to be jumping up and down creaming that this is complete and utter BS. They have admitted a flaw was found and have implemented a fix.
They fixed a firmware injection bug with 1.5.2. The supposed exploit page is EXTREMELY vague about anything. But from what I've read from their comments on twitter/reddit - a 3rd party came forward with a real existing proof of concept about something related to firmware injection. And they fixed that with 1.5.2. They are waiting for other manufactures of trezor clones before disclosing the full details (they now said they will move forward with the process and not wait for other manufacturers to patch their code trees).
So this is all they have to base their response on - they are responding to a blog post that is unbelieveably vague and as they just fixed a new bug in 1.5.2 and the code is up on github, the code itself speaks about an attack vector thru reset nonmasking interrupts. So this is the closest thing what described in the blog post resembles. And they fixed that in 1.5.2.
-
Ok, we get it. You're in damage control mode.
None of this changes the fact that the points Dave raised about the hardware design, the comparisons of the Trezor to other similar security devices he's looked at, all those things... Dave was spot on with his calls.
Fact: a patch was released for a found exploit.
The blog post Dave tweeted had some interesting things to say about a topic directly related to content he made, and a discussion on his forum. Nobody ever said it was anything more than that. Dave also asked @Trezor specifically what was incorrect in the blog post. Their answer was the time needed to perform the hack. Nothing else.
Until you have some other evidence to present, you aren't adding anything useful to the discussion.
-
I am a sysadmin. I spend most of my days at work reading security advisories and looking at new exploits and what needs to be patched to countermeasure them. Watching CCC (Chaos Computer Club) or DEFCON presentations is part of my work, mandatory.
This so called exploit blog post has NOTHING that would make it legitimate. Everything about it is off.
If the exploit is real the guy went really really wrong way disclosing it. First time I've seen someone ask money for a proof of concept code outside of 0-day darknet forums where they sell exploits.
-
Full disclosure: I own a single Trezor device and have been looking their github commits from the time when the side channel attack came out. The same German guy who found that out has been making the most important patches since that (Trezor hired him).
-
Trezor has now published an official response:
https://blog.trezor.io/addressing-concerns-about-trezor-firmware-1-5-2-4c1f766034c7
Debunking general claims:
* It is misleading to say that a generic chip is “doomed”. A generic chip, alongside with open-source code, is auditable and allows the community to participate. Anyone can read the code, analyze it, search for mistakes, criticize, and contribute. We do not believe in security by obscurity.
* Arguably, it would take more than 15 seconds to hack into a TREZOR. Flashing a malicious firmware would already take some time. Also, TREZOR’s case is difficult to open, as described below, so the required time is grossly underestimated.
* 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.
* It is false to state that there is a combination of vulnerabilities in both hardware and software of the device which cannot be fixed without replacing the device. We fixed the issue in 1.5.2 and there are no other outstanding issues that need fixing.
Analyzing the described attack vector:
* We cannot verify if the author discovered the hack a long time ago, as they did not disclose it responsibly. Therefore, there is no proof that the hack existed at that time. We were notified via Responsible Disclosure earlier this month by different reporter and released a fix on August 16th.
* Moreover, while the article mentions the DEFCON talk, its findings are unrelated to this issue. DEFCON suggestions were already implemented in firmware version 1.5.1.
* 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.
* The blog post skips several steps. Also, it mentions an advanced version of the hack, but there is no proof that it exists. There is no description how it works, there are no photos or videos showing it in action.
* There is no way to dump RAM/storage just by connecting two pins. An attacker would need to have a custom firmware. Firmware 1.5.2 fixes the vulnerability that allowed this attack vector.
* While we fixed the issue and released the firmware, we did not disclose the details about the issue to give users time to update and other vendors to apply our fixes.
Other notable points:
* TREZOR’s JTAG is completely disabled, you cannot extract any information from the flash memory or RAM or attach a debugger through this way.
* If you use passphrase protection, you enjoy an additional safety measure against physical attacks. Also, you can hide your wallets.
-
* 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.
-
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.
-
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.
-
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/ (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.
-
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/ (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!
-
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.
-
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?
-
Isn't this the ultimate in security?
At the cost of convenience and being able to easily spend any of the bitcoins, sure.
-
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 :-DD
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.
-
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.
-
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)
-
This is an interesting article:
https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdf (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 (https://github.com/trezor/trezor-mcu/blob/master/memory.c#L30)
But it's an interesting article to read nonetheless.