[ESHOP launched] Trezor: Bitcoin hardware wallet

[JorgeStolfi]

A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalk.org/index.php?topic=581411.msg9856659#msg9856659

[chrisrico]

A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalk.org/index.php?topic=581411.msg9856659#msg9856659

I would hope that RFC6979 deterministic signatures would be the standard for hardware wallets (that's what Trezor uses). Anyway, I doubt this would be used as an attack vector, since it's not guaranteed that the attacker would be the one claiming the funds (see: white hat returning lost BC.i funds).

[JorgeStolfi]

A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalk.org/index.php?topic=581411.msg9856659#msg9856659

I would hope that RFC6979 deterministic signatures would be the standard for hardware wallets (that's what Trezor uses). Anyway, I doubt this would be used as an attack vector, since it's not guaranteed that the attacker would be the one claiming the funds (see: white hat returning lost BC.i funds).

If I read that paper correctly, with that attack the attacker (the person who wrote the malicious tx-signing code) would be the only person able to recover the private key from the transaction signature (or even to notice that the signature is leaking the key).  Thus, that attack it is more subtle than the BCI fiasco -- where everybody had a copy of the faulty RNG, and thus could reproduce the k values, identify the compromised addresses, and sweep them.

[marcus_of_augustus]

A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalk.org/index.php?topic=581411.msg9856659#msg9856659

I would hope that RFC6979 deterministic signatures would be the standard for hardware wallets (that's what Trezor uses). Anyway, I doubt this would be used as an attack vector, since it's not guaranteed that the attacker would be the one claiming the funds (see: white hat returning lost BC.i funds).

If I read that paper correctly, with that attack the attacker (the person who wrote the malicious tx-signing code) would be the only person able to recover the private key from the transaction signature (or even to notice that the signature is leaking the key).  Thus, that attack it is more subtle than the BCI fiasco -- where everybody had a copy of the faulty RNG, and thus could reproduce the k values, identify the compromised addresses, and sweep them.

If you read the paper correctly would you like to place a numerical estimate on how likely this attack is ...e.g. 50%, 10%, 1%, 0.001%?

Thanks in advance for reducing the FUD spreading.

[sandpaper]

Just following up letting it be known that I received mine yesterday 12-15-14. I ordered it on 11/17/14 and it was shipped 11/18/14. I am east coast usa. Not too bad shipping wise. Less than a month from EU with no DHL shipping.

[klokan]

A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalk.org/index.php?topic=581411.msg9856659#msg9856659

I would hope that RFC6979 deterministic signatures would be the standard for hardware wallets (that's what Trezor uses). Anyway, I doubt this would be used as an attack vector, since it's not guaranteed that the attacker would be the one claiming the funds (see: white hat returning lost BC.i funds).

If I read that paper correctly, with that attack the attacker (the person who wrote the malicious tx-signing code) would be the only person able to recover the private key from the transaction signature (or even to notice that the signature is leaking the key).  Thus, that attack it is more subtle than the BCI fiasco -- where everybody had a copy of the faulty RNG, and thus could reproduce the k values, identify the compromised addresses, and sweep them.

If you read the paper correctly would you like to place a numerical estimate on how likely this attack is ...e.g. 50%, 10%, 1%, 0.001%?

Thanks in advance for reducing the FUD spreading.

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...

[keithers]

I am still using my trezor daily since I got it months ago.   I want to try out that new USB hardware wallet that came out recently too...

[JorgeStolfi]

A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalk.org/index.php?topic=581411.msg9856659#msg9856659

I would hope that RFC6979 deterministic signatures would be the standard for hardware wallets (that's what Trezor uses). Anyway, I doubt this would be used as an attack vector, since it's not guaranteed that the attacker would be the one claiming the funds (see: white hat returning lost BC.i funds).

If I read that paper correctly, with that attack the attacker (the person who wrote the malicious tx-signing code) would be the only person able to recover the private key from the transaction signature (or even to notice that the signature is leaking the key).  Thus, that attack it is more subtle than the BCI fiasco -- where everybody had a copy of the faulty RNG, and thus could reproduce the k values, identify the compromised addresses, and sweep them.

If you read the paper correctly would you like to place a numerical estimate on how likely this attack is ...e.g. 50%, 10%, 1%, 0.001%?

Thanks in advance for reducing the FUD spreading.

I would say 90% chance that someone will try that attack sometime in the next 10 years, either a blanket attack (sell hundreds of fake devices on eBay or on a local eletronics store, then scoop whatever falls into the net) or an attack directed against some specific fat target.

[JorgeStolfi]

A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalk.org/index.php?topic=581411.msg9856659#msg9856659

I would hope that RFC6979 deterministic signatures would be the standard for hardware wallets (that's what Trezor uses). Anyway, I doubt this would be used as an attack vector, since it's not guaranteed that the attacker would be the one claiming the funds (see: white hat returning lost BC.i funds).

If I read that paper correctly, with that attack the attacker (the person who wrote the malicious tx-signing code) would be the only person able to recover the private key from the transaction signature (or even to notice that the signature is leaking the key).  Thus, that attack it is more subtle than the BCI fiasco -- where everybody had a copy of the faulty RNG, and thus could reproduce the k values, identify the compromised addresses, and sweep them.

If you read the paper correctly would you like to place a numerical estimate on how likely this attack is ...e.g. 50%, 10%, 1%, 0.001%?

Thanks in advance for reducing the FUD spreading.

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...

Trezor is well designed and certainly better than using a PC, even an off-line PC with air gap.  But it is not 100% safe.  I already explained how a criminal can get around its safety features, by using social engineering or fake malicious hardware.  The fact that people keep denying those risks only makes those risks more significant.

[klokan]

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...

Trezor is well designed and certainly better than using a PC, even an off-line PC with air gap.  But it is not 100% safe.  I already explained how a criminal can get around its safety features, by using social engineering or fake malicious hardware.  The fact that people keep denying those risks only makes those risks more significant.

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.

[mmortal03]

BTW: I am old enough to remember the Year 2000 bug - millions of $$$ worldwide went into trying to fix it - but at the end... it was only a big IT FUD... Are you from that generation JorgeStolfi?

Off topic, but since you brought it up -- Y2K was a real issue that the preparations worldwide actually fixed.

[JorgeStolfi]

Trezor is well designed and certainly better than using a PC, even an off-line PC with air gap.  But it is not 100% safe.  I already explained how a criminal can get around its safety features, by using social engineering or fake malicious hardware.  The fact that people keep denying those risks only makes those risks more significant.

@JorgeStolfi:  doomsday again? Please give us a break, will you?

Your repeated and repeated and repeated comments only makes you more ... well... less significant.

BTW: I am old enough to remember the Year 2000 bug - millions of $$$ worldwide went into trying to fix it - but at the end... it was only a big IT FUD... Are you from that generation JorgeStolfi?

No, sorry, I was busy at Troy, desperately trying to warn my compatriots that that Greek horse could be a trojan horse.  But they just told me to stop spreading FUD and fuck off.

The Y2K bug was not a disaster because, thanks to the harping by the FUDsters, it was mostly fixed or hacked around in time.  How can you tell that it was pointless FUD and waste of money?

Unfortunately, 95% of people cannot believe that a real risk can happen until they see it happening.  The other 5% are dismissed as paranoids and FUDsters before it happens, and quickly forgotten afterwards.  One could fill volumes with cases where warnings by "FUDsters" were ignored, and then the disaster happened much worse than their worst case scenarios. See Fukushima.

The BCI debacle was caused by a bug accidentally introduced in the javascript that people downloaded to generate the keys and sign the transactions.  The bug was fixed after a few hours, but even so it affected hundreds of people and allowed the "theft" of more than 500 BTC -- fortunately, most of them by a "benevolent thief" who returned them to BCI.  In fact, the extent of the damage is still not known precisely, more compromised accounts are still being found.

The BCI javascript was open source, and the buggy version was duly posted on github.  It was not discovered by looking at the code, but because the "benevolent thief" was continuosly monitring the blockchain for certain type of weak signatures, and started seeing many of them.  The programmer who committed the bug acted irresponsably, but apparently within his normal privileges and habits.  Couldn't it have happened with the Trezor firmware instead of the BCI javascript?

Now imagine a criminal aiming his skill and resources to expliting that type of attack...

[klokan]

The BCI javascript was open source, and the buggy version was duly posted on github.  It was not discovered by looking at the code, but because the "benevolent thief" was continuosly monitring the blockchain for certain type of weak signatures, and started seeing many of them.  The programmer who committed the bug acted irresponsably, but apparently within his normal privileges and habits.  Couldn't it have happened with the Trezor firmware instead of the BCI javascript?

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.

[TwinWinNerD]

Is there a safe alternative to mytrezor? Because it is getting really unreliable. I can't use it for my business funds, if it isn't connecting to bits of proof 2 times a day....

[klokan]

Is there a safe alternative to mytrezor? Because it is getting really unreliable. I can't use it for my business funds, if it isn't connecting to bits of proof 2 times a day....

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/

[Mickeyb]

Is there a safe alternative to mytrezor? Because it is getting really unreliable. I can't use it for my business funds, if it isn't connecting to bits of proof 2 times a day....

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/

Is there a windows tutorial somewhere?

Thanks

[JorgeStolfi]

You may like to know that the display-less competition has a serious weakness.

The risk is a malicious software on the PC that plays the man-in-the-middle attack: it displays the merchant's address to the user, but uses the thief's address in the thansaction that is given to the device to sign.

The Trezor guards against that attack by displaying the address on its own window and asking the user to confirm through a Trezor button.  The malware on the PC cannot interfere with that step.

The competition's device instead asks the user to pick a few specific letters from the displayed address, look them up in a code card provided by the manufacturer, and enter the corresponding codes on the PC keyboard.  The malware on the PC does not know the code table, so it cannot convince the device to sign a different address...

... well, not right away, no.  However, while signing a transaction honestly, the malware on the PC can record the letters shows to the user, and the corresponding codes that he typed.  After honestly signing a certain number of transactions, it will know enough entries of the code table to pull the man-in-the-middle attack.

[btchip]

You may like to know that the display-less competition has a serious weakness.

Which is why it'll be upgraded soon, but well, you need to bootstrap something at some point. Also, surprisingly, we still have a thread, which is, even more surprisingly, still not self administrated since the last few times I mentioned that to you => http://bitcointalk.org/index.php?topic=134999.0

[JorgeStolfi]

You may like to know that the display-less competition has a serious weakness.

Which is why it'll be upgraded soon, but well, you need to bootstrap something at some point. Also, surprisingly, we still have a thread, which is, even more surprisingly, still not self administrated since the last few times I mentioned that to you => http://bitcointalk.org/index.php?topic=134999.0

Thanks for the reminder, but I suppose that you have already discussed that problem over there.

[btchip]

Thanks for the reminder, but I suppose that you have already discussed that problem over there.

That's kind of easy to check by yourself, isn't it ? This is the Trezor thread, it'd be great if you could keep it Trezor related, otherwise 2015 is going to be fun when you'll feel the need to compare Trezor to Bitcoincard, Bitstash, Case, Coolbitx, our next devices and the few others similar things that'll be out next year and other people feel the need to do the same in each manufacturer thread.

Please feel free to open a hardware wallet comparison thread instead. End of derailing for me, sorry for the inconvenience.