[ESHOP launched] Trezor: Bitcoin hardware wallet

[marcus_of_augustus]

  good call slush/stick ... in the long run, when its comes to financial security people will always pay premium for brand ... e.g., swiss banks, old money funds, etc.

[Carlton Banks]

when its comes to financial security people will always pay premium for brand

Not integrity? By that logic, we'd all be using mainstream banking, credit/debit cards with Norton Internet Security Suite on brand new Windows 8.1.

[marcus_of_augustus]

when its comes to financial security people will always pay premium for brand

Not integrity? By that logic, we'd all be using mainstream banking, credit/debit cards with Norton Internet Security Suite on brand new Windows 8.1.

ummm, most people are ... and I agree that it is not logical.

Bitcoiners are a discerning bunch seeking integrity, in the vanguard of what will become the premium brands. By definition, most people involved with bitcoin before now are trend-setters, not followers.

[bitcool]

Thank you for staying open source. I still have high confidence in you and your company's integrity.  Had been a miner in your pool for a long time and bought 3 Trezors not long ago. 

[kkurtmann]

Thank you for staying open source. I still have high confidence in you and your company's integrity.  Had been a miner in your pool for a long time and bought 3 Trezors not long ago. 

Same as my story.

[freebit13]

I agree, thank you for chucking out that Microsoft license and reverting back to open-source. Good to see you didn't let those lowlife copycats drag you down to their level. I hope the rest of the community will support you for this; I already have 3 and will continue to recommend your product as the #1 hardware wallet because it's obvious to me that the original developers are going to have the safest and most up-to-date product.

There's a saying I learned in Germany: "Wer billig kauft, kauft zweimal" - "If you buy cheap you will buy twice" 

[dnaleor]

During the recovery card stage of initialization I wish there was an option for "card splitting" using Shamir's Secret Sharing. I could write down the seeds on 3 cards knowing that at least 2 have to be combined for a restoration of funds or even the option to pick how it's split. It would be useful for giving the cards to family for safe keeping. It also would be more secure as you could lock up the cards in different locations.

How I did it:

CARD A: words 1-16
CARD B: words 9-24
CARD C: words 1-8 + 17-24

you can add some dummy words to get 24 words on the card and make it look like a full seed if you are paranoid

[jackbox]

I agree, thank you for chucking out that Microsoft license and reverting back to open-source. Good to see you didn't let those lowlife copycats drag you down to their level. I hope the rest of the community will support you for this; I already have 3 and will continue to recommend your product as the #1 hardware wallet because it's obvious to me that the original developers are going to have the safest and most up-to-date product.

There's a saying I learned in Germany: "Wer billig kauft, kauft zweimal" - "If you buy cheap you will buy twice" 

Yes, it is nice to have a backup. Some people that bought the original Trezor have had to buy twice due to various reasons. So better if less expensive to start with.

[freebit13]

I agree, thank you for chucking out that Microsoft license and reverting back to open-source. Good to see you didn't let those lowlife copycats drag you down to their level. I hope the rest of the community will support you for this; I already have 3 and will continue to recommend your product as the #1 hardware wallet because it's obvious to me that the original developers are going to have the safest and most up-to-date product.

There's a saying I learned in Germany: "Wer billig kauft, kauft zweimal" - "If you buy cheap you will buy twice" 

Yes, it is nice to have a backup. Some people that bought the original Trezor have had to buy twice due to various reasons. So better if less expensive to start with.

I think you may have misunderstood the meaning of the saying. What it means is that if you buy cheap, you will probably end up also buying the original because the cheap one will break or just be crap... in this case insecure.

[klokan]

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:

Code:

1 :         ldr     r9, .L68
2 :         ldr     fp, .L68+4
3 : 
4 : .L68:
5 :         .word   secp256k1_cp
6 :         .word   secp256k1_cp2
7 : 
8 : 
9 :         tst     r1, #1
10:         beq     .L49
11: 
12:         mla     r0, r7, r4, fp
13:         mov     r1, r6
14:         bl      point_add
15:         mov     r4, r5
16:         b       .L46
17: 
18: .L49:
19:         mla     r0, r7, r4, r9
20:         mov     r1, r6
21:         bl      point_add
22: .L46:

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?

[btchip]

SPA is about power analysis, not time. Reading memory from different areas will result in different power signatures for that code. Of course balancing this is highly tricky and architecture dependent.

Performing SPA on the TREZOR crypto scalar multiplication code is harder when USE_PRECOMPUTED_CP is defined (otherwise you're doing a textbook SPA), but I believe it's still doable (you read 2 bits pattern together)

It's definitely not the main concern if you have physical access to it though

[klokan]

but I believe it's still doable

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?

[dnaleor]

Received 2 trezors today I am reselling. No Trezor lanyards were in the package.
Are they now packed in the seald box or did you just forget to include them?
(Or is it not included anymore?)

If you forget to include them, no problem, but it would be a nice gesture to include them in my next order (not determined yet when I will buy again).
I know the guys in person so I can give them at a later date.

[JorgeStolfi]

but I believe it's still doable

A complete demonstration would be in order.

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

The pickup antennas could be hidden in any place where people are likely to use a Trezor: a hotel  desk, a conference room table, the boss's desk at work, a PoS terminal...  (Unless the antennas need liquid nitrogen cooling or something of the sort.)

There must be already several hardware wallets out there with 100 k$ worth of bitcoins in it; and the number is likely to increase as those devices become more popular.  The hackers need to catch only one rich and overconfident victim for their investment to pay off.   Alas, many hardware wallet owners do not seem to be aware of the remaining risks (and the makers obviously will not go out of their way to point them out).

[JorgeStolfi]

By the way, beware of buying hardware wallets second-hand or from random shops.  Buy only direct from the manufacturer or from their approved  secure-shipping resellers.

[btchip]

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?

I'd say that it wouldn't change much because you'd still have distinct memory access patterns, but overall it's better to stick to well known methods rather than trying to improve existing code that wasn't designed with SPA in mind - we're currently working on some SPA resistant Open Source ECC library for our next product.

but I believe it's still doable

A complete demonstration would be in order.

Feel free, I have hardware wallets to design

By the way, beware of buying hardware wallets second-hand or from random shops.  Buy only direct from the manufacturer or from their approved  secure-shipping resellers.

old troll is old

[JorgeStolfi]

By the way, beware of buying hardware wallets second-hand or from random shops.  Buy only direct from the manufacturer or from their approved  secure-shipping resellers.

old troll is old

Old truth is still truth

[dillpicklechips]

I've been thinking about how to compete against the clones.

You could split the Trezor into 2 units:

-Trezor -upgrade-able and full featured but costs more
-Trezor-Lite -firmware is locked but really cheap


The Trezor-Lite could sell for as cheap as $30 or less and people will just use the features that come with it. As firmware is developed and more features are added in the future those same customers may re-buy the devices to get the new features. This helps fund development even though they are cheap because people are upgrading.

I think it would work IF people are more willing to pay $30 for a locked Trezor compared to a $30 clone that is upgrade-able. I think the fact that SatoshiLabs signs the Trezor-Lite would be ample incentive to chose it over a unknown clone.

[gweedo]

Then the trezor-lite is basically unusable right now since no other wallet supports the trezor.

[freebit13]

I wouldn't buy a trezor with locked firmware. What if a new bug or exploit is discovered, do you just throw it away and buy a new one?