Pages:
Author

Topic: [ESHOP launched] Trezor: Bitcoin hardware wallet - page 91. (Read 966173 times)

legendary
Activity: 1260
Merit: 1000
World Class Cryptonaire
Mickeyb, your private keys are on your trezor and never leave it, thus any malware on your PC can't get your private keys. The transaction is created on your PC, then sent to your trezor to be signed. The trezor then requires your pin code to sign the transaction and then the signed transaction is sent back to your PC to be broadcasted. So in that regard, yes your bitcoins are 100% safe.


Now a weakness of having viruses on your computer could be that the address that you want to send the coins to can be modified before your PC displays it. IE you receive a PM and the virus changes all bitcoin addresses in your webrowser to their address or if you copy/paste it changes the addresses in the clipboard. So then when you THINK you're sending the bitcoins to the right person, it could actually be the wrong address. That is the #1 thing I would watch for.

I'm sure the trezor team can give you better descriptions, but that's my 2 cents.



By the way, I finally received my trezor 2 days ago and I LOVE IT. Amazing product guys, keep up the good work. Also future integration with electrum is PERFECT for me Cheesy
hero member
Activity: 798
Merit: 1000
Move On !!!!!!
So I have been arguing with my best friend about the trezor. I keep telling that it is safe to use trezor even on compromised machines, but he keeps telling me this cannot be possible. So for the sake of the argument, if I have several malwares on my computer, couple of trojans, keyloggers etc.. are my funds safe by using trezor?

I want to show him the replies on this question and shut his mouth once and for all!

Thanks all!
hero member
Activity: 770
Merit: 500
🌟 COMSA ICO: 10/02/17 🌟
how long would it take to ship it to east coast in usa?  I read it could take 1 month or so?
full member
Activity: 155
Merit: 104
is there anywhere I can find information on a problem I have had occurring twice so far when sending BTC from myTrezor.com?

the symptom is that a transaction is shown as uncomfirmed for many hours. In the first case, it kind of solved itself after a while, but this caused problems, as this was a bitpay payment that arrived late, so I had to bother support and pay more in the end.

Also, the txid is not found on blockchain.info.

Further symptoms: account balance is showing MORE than wallet actually contains and warning message appears:

Warning! Account balance information is inconsistent.

what causes this and how can it be avoided?

I use Windows 7 Pro, IE11 in private browsing mode (Chrome does not load the plugin). I have tried clearing cache etc.

Thanks for help.
sr. member
Activity: 475
Merit: 250
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.


Challenge accepted.
hero member
Activity: 623
Merit: 500
CTO, Ledger
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.
hero member
Activity: 910
Merit: 1003
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 => https://bitcointalksearch.org/topic/now-available-btchip-ledger-hw1-bitcoin-hardware-wallet-in-a-usb-smartcard-134999

Thanks for the reminder, but I suppose that you have already discussed that problem over there.
hero member
Activity: 623
Merit: 500
CTO, Ledger
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 => https://bitcointalksearch.org/topic/now-available-btchip-ledger-hw1-bitcoin-hardware-wallet-in-a-usb-smartcard-134999
hero member
Activity: 910
Merit: 1003
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.
hero member
Activity: 798
Merit: 1000
Move On !!!!!!
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
full member
Activity: 120
Merit: 100
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/
legendary
Activity: 1680
Merit: 1001
CEO Bitpanda.com
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....
full member
Activity: 120
Merit: 100
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.
hero member
Activity: 910
Merit: 1003
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...
legendary
Activity: 1762
Merit: 1011

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.
full member
Activity: 120
Merit: 100

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.
hero member
Activity: 910
Merit: 1003
A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalksearch.org/topic/m.9856659


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.
hero member
Activity: 910
Merit: 1003
A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalksearch.org/topic/m.9856659


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.
legendary
Activity: 1456
Merit: 1001
This is the land of wolves now & you're not a wolf
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...
full member
Activity: 120
Merit: 100
A simpler way by which a malicious fake hardware wallet could steal your coins:

https://bitcointalksearch.org/topic/m.9856659


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...
Pages:
Jump to: