EEVblog #1006 - Trezor Bitcoin Hardware Wallet Teardown - Page 1
Forum section: electronics / general

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2017, 05:43:57 am
content: 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/-f1CLARIFICATION: 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.

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2017, 06:49:52 am
content: Quote from: FrankBuss on July 13, 2017, 06:34:24 amSocial hacking

author: tombi
author_rank: Regular Contributor
timestamp: July 13, 2017, 07:11:53 am
content: 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

author: `
author_rank: Newbie
timestamp: July 13, 2017, 07:52:00 am
content: 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 byanother 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 whichdirectly leaked their private keys.

author: tszaboo
author_rank: Super Contributor
timestamp: July 13, 2017, 09:26:20 am
content: 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?

author: `
author_rank: Newbie
timestamp: July 13, 2017, 09:41:43 am
content: Quote from: NANDBlog on July 13, 2017, 09:26:20 amYou 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.

author: stick
author_rank: Newbie
timestamp: July 13, 2017, 10:05:02 am
content: 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-zeroQ: 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 PINbeforeevery 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#DatkoQ: 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 fundsbeforethe 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.

author: stick
author_rank: Newbie
timestamp: July 13, 2017, 10:07:06 am
content: Quote from: ` on July 13, 2017, 07:52:00 amUntrue, we worked with Jochen to rewrite all crypto to constant-time. See my longer post with Q&As.

author: stick
author_rank: Newbie
timestamp: July 13, 2017, 10:10:21 am
content: Quote from: ` on July 13, 2017, 09:41:43 amTrue, you backup the device by writing down the 12 or 24 words which encode the master private key.Quote from: ` on July 13, 2017, 09:41:43 amActually, the devices come uninitialized (so you can be sure we don't have your private keys) and one has to initializeandperform backup (as it is a part of initialization procedure) before it can by used in any way.

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2017, 11:06:23 am
content: Quote from: NANDBlog on July 13, 2017, 09:26:20 amThat'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.

author: tszaboo
author_rank: Super Contributor
timestamp: July 13, 2017, 12:51:04 pm
content: Quote from: EEVblog on July 13, 2017, 11:06:23 amOk, 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.

author: stick
author_rank: Newbie
timestamp: July 13, 2017, 01:05:37 pm
content: Quote from: NANDBlog on July 13, 2017, 12:51:04 pmThe 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.Quote from: NANDBlog on July 13, 2017, 12:51:04 pmNot 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".Quote from: NANDBlog on July 13, 2017, 12:51:04 pmThere 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).

author: EEVblog
author_rank: Unknown
timestamp: July 13, 2017, 01:52:51 pm
content: Quote from: stick on July 13, 2017, 10:05:02 amThanks for joining and sharing technical info directly, the community always appreciates that.

author: Kjelt
author_rank: Super Contributor
timestamp: July 13, 2017, 04:09:18 pm
content: 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.

author: bittumbler
author_rank: Contributor
timestamp: July 13, 2017, 04:27:50 pm
content: Quote from: Kjelt on July 13, 2017, 04:09:18 pmAnd also remove anything that draws lots of power, such as LED, buzzer, etc.

author: stick
author_rank: Newbie
timestamp: July 13, 2017, 05:41:59 pm
content: Quote from: Kjelt on July 13, 2017, 04:09:18 pmHave you read my Q&A post above? It is full of interesting information. Also thanks for Riscure tip.

author: Fungus
author_rank: Super Contributor
timestamp: July 13, 2017, 06:17:31 pm
content: Quote from: bittumbler on July 13, 2017, 04:27:50 pmI'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.

author: f4eru
author_rank: Super Contributor
timestamp: July 13, 2017, 08:18:08 pm
content: Quote from: EEVblog on July 13, 2017, 06:49:52 amSocial Fracking

author: jiro
author_rank: Contributor
timestamp: July 13, 2017, 08:35:21 pm
content: Quote from: stick on July 13, 2017, 10:05:02 amIs 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.

author: crisr
author_rank: Contributor
timestamp: July 13, 2017, 09:13:53 pm
content: 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...

author: crisr
author_rank: Contributor
timestamp: July 13, 2017, 09:38:49 pm
content: Quote from: NANDBlog on July 13, 2017, 12:51:04 pmHardware 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?Quote from: NANDBlog on July 13, 2017, 12:51:04 pmThat 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).

author: stick
author_rank: Newbie
timestamp: July 13, 2017, 10:37:56 pm
content: Quote from: crisr on July 13, 2017, 09:13:53 pmThese 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: July 14, 2017, 02:05:35 am
content: Maybe send it to Micah Elizabeth Scott? She's really good at reverse engineering embedded systems.

author: jh15
author_rank: Frequent Contributor
timestamp: July 14, 2017, 04:06:53 am
content: 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 onhttp://www.twit.tv/sn

author: stick
author_rank: Newbie
timestamp: July 14, 2017, 10:51:35 am
content: Quote from: NiHaoMike on July 14, 2017, 02:05:35 amAlready sent her a package today! :-)

author: tszaboo
author_rank: Super Contributor
timestamp: July 14, 2017, 01:44:35 pm
content: Quote from: stick on July 13, 2017, 01:05:37 pmI guess that is reasonable.Quote from: stick on July 13, 2017, 01:05:37 pmRight 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.Quote from: stick on July 13, 2017, 01:05:37 pmThan 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.

author: wintermute101
author_rank: Newbie
timestamp: July 14, 2017, 03:06:24 pm
content: There is great talk by Christopher Tarnovsky about Semiconductor SecurityIt's a little bit off topic but I think many interested in Trezor will find this very interesting.

author: wintermute101
author_rank: Newbie
timestamp: July 14, 2017, 03:18:03 pm
content: Quote from: stick on July 13, 2017, 10:05:02 amI 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.

author: NiHaoMike
author_rank: Super Contributor
timestamp: July 15, 2017, 02:51:43 pm
content: 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.

author: EEVblog
author_rank: Unknown
timestamp: August 17, 2017, 11:52:04 am
content: Quote from: stick on July 13, 2017, 10:05:02 amOops!https://medium.com/@Zero404Cool/trezor-security-glitches-reveal-your-private-keys-761eeab03ff8QuoteDouble oops!QuoteSeems that wasn't such a good idea

author: firewalker
author_rank: Super Contributor
timestamp: August 17, 2017, 12:17:25 pm
content: Trezor says version 1.5.2 is safe?Also, the hack is being sold?Alexander.

author: EEVblog
author_rank: Unknown
timestamp: August 17, 2017, 12:28:52 pm
content: Quote from: firewalker on August 17, 2017, 12:17:25 pmThey have not clarified if it's both the physical attack and the USB attack, or just one.QuoteYep, for 0.5 BTC (> AUD$2500)

author: EEVblog
author_rank: Unknown
timestamp: August 17, 2017, 12:31:50 pm
content: 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?

author: RGB255_0_0
author_rank: Frequent Contributor
timestamp: August 17, 2017, 12:34:19 pm
content: You should make a follow-up showing this hack Dave.

author: EEVblog
author_rank: Unknown
timestamp: August 17, 2017, 12:37:22 pm
content: Quote from: RGB255_0_0 on August 17, 2017, 12:34:19 pmLooks like I have to pay 0.5 BTC to get the hack though?

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 12:43:08 pm
content: 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/c8ddd904099d4b082220a684980806108a2eae47Where 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/98e617d8740b85ae01d7d6e0dd3f49e66057a210Where they implement a custom reset handler in this file:https://github.com/trezor/trezor-mcu/blob/98e617d8740b85ae01d7d6e0dd3f49e66057a210/startup.sAnd last - they were asking for !!! 20BTC !!!! before taking the 1.5.2 "exploit" link down.This all thing stinks.

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 12:48:01 pm
content: Here is the DEFCON talk about voltage glitching, bad quality until official steams are but up in a month or so:Slides:https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20presentations/DEFCON-25-Datko-and-Quartier-Breaking-Bitcoin-Hardware-Wallets.pdf

author: firewalker
author_rank: Super Contributor
timestamp: August 17, 2017, 01:08:15 pm
content: From the comments of the article page:QuoteThe fact that the hack is being sold is really fishy.Alexander.

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 01:15:33 pm
content: 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.jpgThis 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).

author: EEVblog
author_rank: Unknown
timestamp: August 17, 2017, 01:48:37 pm
content: Quote from: Marvin on August 17, 2017, 12:43:08 pmTheir response to me when I asked on twitter was "The article is not 100% accurate".When asked what was wrong, they responded:QuoteSo 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)

author: EEVblog
author_rank: Unknown
timestamp: August 17, 2017, 01:51:08 pm
content: Quote from: Marvin on August 17, 2017, 01:15:33 pmUmm, it shows the entire seed key in plain text and the pin number. How is that nothing? If true, it's EVERYTHING!

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 01:54:26 pm
content: Quote from: EEVblog on August 17, 2017, 01:51:08 pmIt 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.

author: EEVblog
author_rank: Unknown
timestamp: August 17, 2017, 02:08:35 pm
content: Quote from: Marvin on August 17, 2017, 01:54:26 pmErr, 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.

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 02:11:53 pm
content: 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.

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 02:26:43 pm
content: Quote from: EEVblog on August 17, 2017, 02:08:35 pmThey 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.

author: funkyant
author_rank: Unknown
timestamp: August 17, 2017, 05:18:15 pm
content: 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.

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 06:07:12 pm
content: 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.

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 06:12:01 pm
content: 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).

author: Marvin
author_rank: Contributor
timestamp: August 17, 2017, 06:20:23 pm
content: Trezor has now published an official response:https://blog.trezor.io/addressing-concerns-about-trezor-firmware-1-5-2-4c1f766034c7Quote

author: thm_w
author_rank: Super Contributor
timestamp: August 17, 2017, 11:14:30 pm
content: QuoteSo 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.QuoteOk, 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.

author: dorin
author_rank: Contributor
timestamp: August 18, 2017, 04:30:16 pm
content: 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.

author: Marvin
author_rank: Contributor
timestamp: August 18, 2017, 04:44:49 pm
content: Trezor released a more technical explanation now:https://blog.trezor.io/fixing-physical-memory-access-issue-in-trezor-2b9b46bb4522Long 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/98e617d8740b85ae01d7d6e0dd3f49e66057a210Before today it was not clear why they did that change but the explanation is:QuoteThis 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.

author: Marvin
author_rank: Contributor
timestamp: August 18, 2017, 05:58:52 pm
content: 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.

author: stick
author_rank: Newbie
timestamp: August 18, 2017, 06:05:40 pm
content: Quote from: Marvin on August 18, 2017, 05:58:52 pmYes, 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!

author: Marvin
author_rank: Contributor
timestamp: August 18, 2017, 09:00:22 pm
content: 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-de4d70c9ee8cThe tone of the blog is still the same.QuoteThis 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.

author: mallman
author_rank: Newbie
timestamp: August 22, 2017, 03:33:29 pm
content: 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?

author: thm_w
author_rank: Super Contributor
timestamp: August 22, 2017, 08:57:01 pm
content: Quote from: mallman on August 22, 2017, 03:33:29 pmAt the cost of convenience and being able to easily spend any of the bitcoins, sure.

author: dorin
author_rank: Contributor
timestamp: August 23, 2017, 09:16:28 am
content: Quote from: mallman on August 22, 2017, 03:33:29 pmThey would find the safety deposit box to extortThe 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.

author: EEVblog
author_rank: Unknown
timestamp: August 23, 2017, 09:26:50 am
content: Quote from: mallman on August 22, 2017, 03:33:29 pmThe 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.

author: Kjelt
author_rank: Super Contributor
timestamp: August 23, 2017, 10:09:08 am
content: Quote from: EEVblog on August 23, 2017, 09:26:50 amOnly 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)

author: Marvin
author_rank: Contributor
timestamp: August 30, 2017, 10:37:13 pm
content: This is an interesting article:https://www.usenix.org/system/files/conference/woot17/woot17-paper-obermaier.pdfTrezor 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#L30But it's an interesting article to read nonetheless.