[ESHOP launched] Trezor: Bitcoin hardware wallet

[dnaleor]

the recovery procedure "helps" you with a drop down list of words. I don't really think it is needed to test. If somewhere in the future some usefull linux program is pubished so I can test it on my raspberry, I will probly do that (need to buy a second trezor first, because I don't want to move all the funds before wiping my Trezor)

But I'm pretty confident that I have done it correctly. I checked several times

[anarchoatheist]

Does wiping the Trezor then restoring the seed in any way lessen the security of that particular seed? I feel a little uncomfortable moving my fortune onto the wallet without first testing that I can restore it. Before creating my final wallet, I did extensive testing with creating then restoring wallets with and without passwords. Even though I now feel like I am experienced, I feel an uneasy sense not testing the final wallet. What if somehow I wrote the seed down wrong or something. Is this just my O.C.D. messing with me? I would like to test it but I dont like the idea of typing my seed words of my final wallet into the computer either. I know there are a few other wallets that have you confirm that your wallet seed backup is good such as Electrum or Mycelium.

Yes it does. Not to the point of breakability, but it's less secure if keylogged: https://bitcointalk.org/index.php?topic=122438.msg8243033#msg8243033
If you plan to test it, then it's a good idea to do it on a secure computer.

I think I figured out a method to test/restore the seed to the trezor with maintaining 100% security as before. Here is what I did:

1. I ran an Ubuntu live disk
2. While connected to the internet, I opened firefox then navigated to mytrezor.com and installed the plugin.
3. I then unplugged my ethernet cable insuring that I was no longer connected to the internet.
4.I then went back to the still open firefox tab containing mytrezor.com.
5. I wiped the trezor
6. I then proceeded to restore my seed while still disconnected from the internet.
7. When the seed was finally finished, i got an error on mytrezor.com claiming that the restore failed. I was thinking that it was saying this because it had no access to the internet to validate the wallet. So I plugged in my restored trezor to another computer and there it was, fully restored.
8. I then rebooted the computer that was running the live ubuntu cd before replugging my ethernet.

One thing I noticed though while restoring the seed while offline, the trezor never asked me to type in random words that werent part of my seed to throw off any keyloggers as it had done in the past, when i restored other seeds. its as if trezor knew I was on a secure computer.

[stick]

One thing I noticed though while restoring the seed while offline, the trezor never asked me to type in random words that werent part of my seed to throw off any keyloggers as it had done in the past, when i restored other seeds. its as if trezor knew I was on a secure computer.

Not true :-) We changed the behaviour in 1.2.1 firmware to "TREZOR always asks for 24 words" - i.e. asks for 0 fake words for 24 word mnemonic (was 12 fake words); asks for 6 fake words for 18 word mnemonic (was 9 words); asks for 12 fake words for 12 word mnemonic (was 6 fake words).

[dnaleor]

One thing I noticed though while restoring the seed while offline, the trezor never asked me to type in random words that werent part of my seed to throw off any keyloggers as it had done in the past, when i restored other seeds. its as if trezor knew I was on a secure computer.

When using a 24 word seed, no random words are added. I would be in favour of using at least a few random words. Restoring a seed is not a daily task, so typing in 24 or 36 words doesn't really matter to me...

[anarchoatheist]

One thing I noticed though while restoring the seed while offline, the trezor never asked me to type in random words that werent part of my seed to throw off any keyloggers as it had done in the past, when i restored other seeds. its as if trezor knew I was on a secure computer.

Not true :-) We changed the behaviour in 1.2.1 firmware to "TREZOR always asks for 24 words" - i.e. asks for 0 fake words for 24 word mnemonic (was 12 fake words); asks for 6 fake words for 18 word mnemonic (was 9 words); asks for 12 fake words for 12 word mnemonic (was 6 fake words).

ah ok I was confused from when I was testing restoring the 12 and 18 word seeds. I restored a 24 word seed once before. Not sure why I didnt notice that it didnt have random words included while restoring it before.

[stick]

Is there a way to toggle the "request-password"-flag in the trezor without reinitializing it?
As no-password results in the same wallet as an empy password it would be nice to be able to switch between the settings (without having to generate a new seed).

I second this feature request.

We'd need to update the firmware to extend the API to allow this change. I noted that in my Trello board and once we ship this feature via a version update then we can add it to myTREZOR.

[dnaleor]

Sorry to bother you here guys, but can you please look into my e-mail concerning a bulk purchase of 100 trezor devices? I am organizing a Bitcoin congress and we would like to be able to sell a Trezor Device to the people who show up. Most of them are not tech savvy and in one of the sessions we will be explaining the different wallet options. We would like to explain them how the Trezor works and I guess a lot of them will want to buy one.

Sorry for posting it here. I know you are busy, but the event takes place at the end of september. So we would like to know if it will be possible to have them delivered before that deadline.

[blossbloss]

Is there a place online that has the history and details of myTREZOR.com and firmware updates?

[stick]

Is there a place online that has the history and details of myTREZOR.com and firmware updates?

Probably now what you would expect, but Github has nice commit history: https://github.com/trezor/trezor-mcu (firmware) + https://github.com/trezor/webwallet (mytrezor)

[truthstalker]

Is this just as secure as a paper wallet? I should imagine it isn't because it requires you the manufacturer to actually have access to the private keys?

[blossbloss]

Is there a place online that has the history and details of myTREZOR.com and firmware updates?

Probably now what you would expect, but Github has nice commit history: https://github.com/trezor/trezor-mcu (firmware) + https://github.com/trezor/webwallet (mytrezor)

A bit too complicated for us non-developers.  Hopefully a more consumer-friendly summary will be maintained someday.

[gmannn]

Is this just as secure as a paper wallet? I should imagine it isn't because it requires you the manufacturer to actually have access to the private keys?

The keys are generated using entropy from the trezor plus entropy from the computer you plug into.  There's no way for the manufacturer to know your keys.

[Perlover]

Hi, stick!

Can you answer what do you plan with same problem?
I described it into 113th page. But i didn't find your answer. But it can be very seriously

I think the mytrezor.com site has the future vulnerability
...
2) He will be able to change address for receiving to his fishing addresses (right in browser instead mytrezor's generated addresses)

If it possible here may be some workarounds:
...
2) This vulnerability can fix by checking new generated addresses in computer with showing new address in Trezor screen. For example: we ask to mytrezor.com generate new address for receiving. Site sends new address (path of BIP32) to the Trezor by HID interface, the Trezor knows private seed key, knows path of new generated address it generates same address too and shows it in screen. User checks both addresses and if ok - he uses new address for money receiving. It's ideal solution as i think. Because fishing address will differ completely (very difficult to make quickly even 1-3 prefix or sufix) i think will be enough to check 3-4 letters before (prefix) and 3-4 after (sufix) in addresses.

Here is only my fix now: path not BIP32 but path of BIP44
This problem can occur not only with infected computer but by using middle man attack in any part of routing.

And other user already asked you about this after my post:

Another question:

I like the confirmation on the TREZOR when I am sending to an address to ensure that the myTREZOR site has not been compromised.  However, it does not appear that there is any confirmation of the addresses shown on myTREZOR for receiving funds.  When I see an address on myTREZOR (to provide to someone to send me money), how can I be sure that it is actually an address associated with my TREZOR (and not a rogue address on a malicious computer)?  I would hope to be able to see the selected address on the computer replicated on the TREZOR so that I can be sure it is legitimate.  Is this how it works, but just not in the documentation?

Please don't suggest import xpub to other device. xpub key to be showed by mytrezor.com too so if computer was infected or there middle man attack the xpub key can be changed too. So i think you should add the check option for receiving addresses right in the Trezor.

If you think well, now there is no reliable way to trust and verify addresses for receiving money. Is not it so?

[JorgeStolfi]

Is this just as secure as a paper wallet? I should imagine it isn't because it requires you the manufacturer to actually have access to the private keys?

The keys are generated using entropy from the trezor plus entropy from the computer you plug into.  There's no way for the manufacturer to know your keys.

Well, if the manufacturer of a hardware wanted to get the client's keys, they could do it very easily. 

If you use a special-purpose hardware to store your keys, you have to trust the manufacturer.  I see no way around it.

[molecular]

I just realized I had very bad security practices involving the trezor:

I use it with electrum (don't do this yet, it's not for the faint of heart, wait for electrum release 2.0).

I just leave my wallet (electrum) open with the trezor plugged in. That's a bad idea.

For some reason I assumed the PIN would be asked every time. But it seems the trezor will remember passphrase and pin auth, so anybody could walk up to my computer and make a transaction without knowing password or PIN.

So note to self: always unplug the trezor when done, especially when having entered the PIN.

Suggestion/question: could the trezor have a timeout on the PIN and re-ask after it has elapsed? Same for passphrase.

[chrisrico]

For some reason I assumed the PIN would be asked every time. But it seems the trezor will remember passphrase and pin auth, so anybody could walk up to my computer and make a transaction without knowing password or PIN.

It's the same with myTrezor, I believe the Trezor caches the PIN for some period of time or until it's unplugged, I'm not sure which.

[molecular]

For some reason I assumed the PIN would be asked every time. But it seems the trezor will remember passphrase and pin auth, so anybody could walk up to my computer and make a transaction without knowing password or PIN.

It's the same with myTrezor, I believe the Trezor caches the PIN for some period of time or until it's unplugged, I'm not sure which.

Hm, just searched a bit in the firmware code.

Couldn't find anything about a timeout.

But there's a "session_clear()" function which clears the PIN, cached root node and cached passphrase. There's also an accompanying protocol message to invoke it. Maybe it's the wallets responsibility to clear the session via this message.

[blossbloss]

Got my Trezor today.

I have successfully set up the multi-passphrase encryption structure.

It appears that every time that I access the Trezor, I have an opportunity to create a new hidden volume.  Out of curiosity, is there a limit to the number of volumes?  If I reach the limit, how will the Trezor behave when a new volume is attempted to be made.

My real question is about the no-passphrase entry.  I tried it, and it appears that I have no access to anything when a passphrase is not entered.  I recall reading somewhere about different behavior based on whether a passphrase box is checked.  Does anyone have any clarity on pitfalls to watch out for?

Overall, I'm very impressed with the Trezor!

[JorgeStolfi]

Is this just as secure as a paper wallet? I should imagine it isn't because it requires you the manufacturer to actually have access to the private keys?

The keys are generated using entropy from the trezor plus entropy from the computer you plug into.  There's no way for the manufacturer to know your keys.

Well, if the manufacturer of a hardware wanted to get the client's keys, they could do it very easily. 
If you use a special-purpose hardware to store your keys, you have to trust the manufacturer.  I see no way around it.

The hardware can be checked and the software is open source.

Checking the hardware is viable only with sophisticated lab equipment.  To check the software, someone whould have to carefully check the source code (at every release) for malicious backdoors or weaknesses, and then the client would have to check that the compiled firmware that he is loading, duly signed by the manufacturer,  matches that source code.  Obviously neither is viable in practice, except after the fact.

[chrisrico]

Checking the hardware is viable only with sophisticated lab equipment.  To check the software, someone whould have to carefully check the source code (at every release) for malicious backdoors or weaknesses, and then the client would have to check that the compiled firmware that he is loading, duly signed by the manufacturer,  matches that source code.  Obviously neither is viable in practice, except after the fact.

The hardware can be checked by feeding it known inputs and checking that the output matches what's expected.

Their build process is deterministic, so you can in fact check that the signed binary matches the open source code. It is also not true that every individual has to check the code every time there is a release, it can be done on an ongoing basis by a community of semi-trusted individuals.

You're really reaching, aren't you? What's your angle here exactly?