Still quite major news for 90% of the users: http://www.netmarketshare.com/operating-system-market-share.aspx?qprid=10&qpcustomd=0

The question is whether it's doable remotely and if yes, what would be the price of such attack.

Also, what is the difference of power consumption if you read 36 bytes from one location VS reading 36 bytes from other location... If it causes data to be read from flash in one case and not in the othere, you would see it. Otherwise I doubt so. Maybe DPA attack is feasible agains the lib (but not against the Trezor), but as I said, SPA would be hard.

Edit: Also, if the two precomputed arrays were interleaved instead one after the other, it would make memory access pattern more difficult do distinguish. How would you say this would affect the security of the lib?

Recently I've seen couple of posts about timing attacks against the trezor-crypto library. Most notably this post: http://www.reddit.com/r/Bitcoin/comments/2u1wea/trezor_code_no_longer_lgplv3_but_now_more/co4iomt and the response to it + image https://i.imgur.com/ON4FxD5.png

I'd like to say here why I believe it's not an issue and I'm looking forward for answers, especially from the guys who claim this on reddit.

First of all, I want to acknowledge that library reveals some timing information. No doubt about it. I would never use it in multi-threaded environment of a web server. But I believe that exploiting it in Trezor is either impossible, or too expensive to be worth the effort. For use of DPA attack you would need to capture tens of thousands of signatures with the same key which is in contradiction with how Trezor is used in practice. And SPA attack is hard. Not impossible, but hard and expensive.

If the Trezor is stolen, you cannot sign transactions at all and if you could, you don't need to attack anything anymore. So let's talk about the remote attack: In this case I claim that you just don't have the accurate data to do SPA attack. I saw the antenna recordings: https://i.imgur.com/ON4FxD5.png from user 76951234, but guess what: If the library would not leak ANY side channel information, the readings would look EXACTLY the same, so this shows nothing.

So let's talk how precise data you would need to make a successful SPA attack against Trezor. Basically, you would need to know one by one, which elliptic curve points are being added. This is just one piece of code that you would need to know how it went:

On 9th line, there is tst instruction that branches the code to either: 12, 13, 14, 15, 16, 22 OR 19, 20, 21, 22 where lines 14 and 21 are calls to the same function point_add, but once with argument fp, and the other time with r9 (set at lines 1 and 2). In point_add you access memory at either fp or r9 so that may leak some timing as well, but it would be difficult to distinguish which memory is read, because all those data are in one continuous block. Also, point_add does not branch on the given data but rather on preprocessed values so again it's difficult from the timing of point_add to decide which branch in this code was taken. So it comes down to capture whether the sequence was 12, 13, 14, 15, 16, 22 OR 19, 20, 21, 22. Since 13 = 20 and 14 = 21 and instructions on lines 12 and 19 are similar, you basically need to read from side channel whether lines 15 and 16 were executed or not. I claim that if you can read such a precise information from side channel, it does not matter whether the code leaks or does not leak timing information. If you can read data on instruction level, then this is not fixable in code. I also think that if it's even possible, then such attack would require some kind of EXTREME equipment. Any thoughts?

Regarding altcoin integration, I believe satoshilabs are happy to add support in the device,but they won't create wallet for them. They said that many times. What it means is that if Electrum works with Trezor, Electrum-LTC will work as well. If there is ever in the future altcoin X that they decline to support, I'll type the one line here: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#Registered_coin_types and here: https://github.com/trezor/trezor-mcu/blob/ed2e0d081b1f92fd4cf165e7bd426ef0b49e9675/firmware/coins.c myself.

All what's happening now is sad, but myTrezor.com is NOT going down. I have no idea how that became a topic. I did not see alena, slush or stick comment on this yet which they eventually will. Let's voice opinion that we don't like it and let them reconsider and release some official statement. In the meantime keep calm and don't expect myTrezor to vanish.

My personal opinion is that they never gave a promise that ALL future versions of the device will be open source and it's foolish to expect that. If you don't like that buy other open source wallet (shame no other HW wallet is open source and I don't count BWallet as "other" wallet for that matter) or just stay at 1.3.0 firmware that was released as open source. I also think that the rebase of sources was a bad decision and it also has no effect. Bad decisions happen. Even I do them! It's a problem only if you don't reconsider. People retrieved latest version of the open-sourced code with GPL licences so nothing prevents anybody to use yesterday's sorces with GPL licence: https://github.com/rfree/trezor-mcu-gpl/commits/master-gpl if they change licence now, I don't care but it won't work retroactively.

This is a Bitcoin wallet and a "digital Bitcoin safe". When considering a real world, it's like a wallet. You can wear it in your pocket, it does not weight 100pounds or kilos. But in digital world, when connected to a computer, it should be as difficult to get inside as if it was a safe. Weight does not matter anymore, other things do...

Considering price, you might have heard that there are now Chinese who are selling a clone for 28$: http://www.reddit.com/r/Bitcoin/comments/2ti75t/only_28_to_buy_a_trezorlike_hardware_wallt/ Please note that Chinese cannot spell wallet in the reddit link so be cautious about buying one (especially when you don't speak or read Chinese).
The Satoshi Labs themselves declare the hardware cost as 19$ on the shipping package customs declaration and the remaining 100$ to be the software cost. Considering couple of people spend two years on development of the device and they sold "several thousands" of devices http://satoshilabs.com/news/2015-01-15-trezor-in-2014/ it seems to me that if several were 10 then this would be still way less then community spend here: http://fortune.com/2015/01/20/coinbase-raises-75-million-in-largest-ever-vc-round-for-bitcoin-company/ but Trezor being a much more important community effort since the security is the only thing preventing mass adoption.

Anyway, price will go down over the time. Maybe soon because of clones.

OFC, they don't match, because the one on the device leaks the seed through the side channel BTW: thanks for sharing.

/// just kidding

I think that this one is already resolved. (wrong passphrase was used)

But in general, if you plug in your Trezor and you don't see your transaction history and you see balance zero, there is nothing to worry about. The website is down/slow/whatever, but your coins are almost certainly secure. The only situation to worry about is when you see a transaction history with some new transaction you did not approve. (I've never saw someone report this)

Yeah, I know that. But looking at reddit and here, it seems to me that they may benefit from running more instances.

I don't understand why don't Satoshi Labs just run 2 or 3 instances of the web site. You could use the other one when the first one is down and also the spread load would mean less race conditions in the backend code. You don't even have to have a load balancer, just make it www1. www2. etc.

Exactly. AFAIK Trezor plans to implement this BIP once it's accepted (It's in the final draft stage now). But provided that BIP70 is used, device may be able to protect you against address replacing malware.

I agree that this is an interesting valid use-case. Still, I think that non-BIP70 transactions are a valid use-case for bitcoin as well.

I don't think that BIP70 is the answer to all these issues. What if I don't want to tie my address to my identity? I cannot use Bitcoin? I believe this would defeat one of the purposes for which Bitcoin was created.

Trezor is secure in two important points:
1. It will never share your private keys with a computer no matter how many viruses and troyans are on the computer.
2. When signing a transaction (which is created on computer so it potentialy may be incorrect, missleading or maliciously created), Trezor will display comprehensive information about the transaction and it will ask you to press the confirm button twice. As mentioned above me, this does not protect you against phising attack as described here: http://doc.satoshilabs.com/trezor-faq/threats.html#what-doesn-t-trezor-protect-against-yet but the important point is that Trezor would never sign this transaction without you seeing it and confirming it. So in case you know the address you want to send to, there is no way computer can trick you into signing something else.

Any alternative that works is as safe as myTrezor from the nature of the device. The only problem is that there is none released. There is Electrum 2.0 beta with this install tutorial:
http://www.reddit.com/r/TREZOR/comments/2jp9uk/tutorial_install_electrum_20_beta_with_trezor/

This reveals the amateurism of BCI. C'mon, using javascript rng and even failing at it when people are FOR YEARS saying that the only way to go is a fully deterministic signatures with RFC6979? WTF BCI?

If you have a deterministic signatures and tests: https://github.com/trezor/trezor-crypto/blob/master/tests.c#L360 then the BCI type of issue cannot affect you.

Edit: And by the way: Having a Trezor firmware signed by multiple people means than no single irresponsible programmer can do this with Trezor on his own. This again shows how SL processes are superior to those of BCI.

Disclaimer for JorgeStolfi: I did not claim nor I think that any mentioned systems are 100% safe, nor I believe that fake devices cannot be manufactured or that coins cannot be stolen thru social engineering.

JorgeStolfi: I was talking about a situation when you have TREZOR. Then this attack simply does not apply. I never said in my post that having a money in a fake bank is as safe as having them in a real bank. Please explain to me, how I'm denying this fact in my post.

However, I did say, that this is both blackbox testable before you start using the device and that maliciousness is backward provable after the device has been malicious. So the users who will be affected with this kind of attack have some tools to fight back.

Trezor is open source and running only the signed firmware. This attack is not feasible in such circumstances, because everybody would see the "malicious tx-signing code" on github.

Also, RFC6979 is the answer to this problem that Trezor implements. With it, there is not a choice of k, thus the attack is not possible.

With a piece of software writing skills, you can initialize Trezor, use it to sign a couple of transactions, then import master private key into bip32.org, generate all private keys and verify that RFC6979 was used. This can be used with real or fake inputs in "blackbox testing" OR it can be used after some coins go missing to prove the maliciousness of the firmware...

When?

The seed is stored in flash memory. It does not need power and the device does not have any internal batery. The minimal data retention of flash is usualy specified as 15 years, but this is the minimum that is guaranteed for devices stored in extreme conditions (85°C). When storing in normal temperatures, it should last at least 100 years according to this study: http://www.freescale.com/files/microcontrollers/doc/eng_bulletin/EB618.pdf