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

Great !

Will do. PM sent.
I presume they will be coming to the UK from the Czech Republic - that's where you guys are aren't you ?

There is all the Java BIP32 wallet work to do as well but I figure it is worth derisking the low level communications first.

I do all my dev on a Mac put I think I will pick up a Windows laptop to test hardware compatibility on that too.
80% of my downloads are to a Windows machine so I presume the Trezor usage will be similar.

Jim

We should have first RasPi shields in our hands in a week or too. Then we have to perform some tests. Please, send your address to slush as PM, so we have it, once we are ready to ship! :-)

On the desktop software front, I think I should have some free time in February to start work on Trezor integration.
It would be good to get started on the code that talks via USB.
Are the RaspPi shields with the emulator available now ?

They don't have to be a 100% faithful emulation yet - I just want something 'at the other end' of the USB to start talking to.

Even sending few thousands coins to /dev/null may be a fun for some people.

However I think I found some workaround for this. Device can enforce the rule, that change address (that address used in transaction output, but going back to the same wallet) can be just few indexes in every direction far away from some already used address (confirmed by SPV validation). By enforcing this rule, the space is drastically reduced and clients can make lookups for such change addresses, so the chance to lost coins by such attack is minimal.

We just sent first small batch of PCBs into production. Can't wait to see the results!

I thought about such attack operated by a ransomware - pay me and I'll tell you where your coins are - but it's definitely far fetched. Maybe we should start a new (development) thread to discuss theorical attacks against hardware wallets & smartcards and keep the healthy paranoia there

So that'd just destroy the money, right? What is the attackers motive? Is it not possible to heuristically detect such shenanigans?

I think ease of use is really important, moreso than being immune to every possible attack. The book "Security & Usability" by O'Reilly is a superb manual to how theoretically secure systems end up being broken because they were too complicated or awkward to use. If a user can be confused by the output on their device, they will just end up blindly confirming things they don't understand and the whole thing gets a lot weaker. SSL suffered this fate.

OK, so stick had already deleted his reply. But let me clarify some points:

1) I understand why ethics discussion is not a good use of time when the business is in its most critical phase: late development but before revenue stream had started. The permanent lockout is one of the early decisions that you may regret afterwards.

2) You have many options to deliver variants of bootloader/firmware from the earliest stage:

2a) initially unlocked but lockable with an upgrade
2b) initially locked but unlockable with an upgrade
2c) on demand switching between 2a) and 2b)
2d) locked forever and not upgradeable

3) If you really do your cases by CNC mill (and not some form of molding) then it is quite cheap to add some trivial decorarive modification to the milling program to remove some more source material in a way that marks device as open and that is difficult to physically patch up.

4) I now regret mentioning 3DO withoout explicit context. 3DO is one of the first companies that used 768-bit(?) RSA signatures to lock out the renegades. It may have locked some renegades, but for sure locked out many developers and partners of 3DO. There was fairly detailed case analysis for that in Harvard Business Review (or similar publication for MBAs). The resounding failure of 3DO had relatively little to do with its take up in the target market of gamers. Briefly: imagine having to judge and sign competing releases by fiercely adversarial business partners; something like BFGminer and CGminer, but with actual staffing and funding for propaganda. Their lock code was in the mask-programmable ROM portion of their chip.

5) My thinking from (2) and (3) is that you could offer lock state as another option during ordering, similar to the color of the case. You'll have a first hand feedback channel on who's ordering: geeks or grandmas.

I was a big fan of EA in the early days. I was all for 3DO too, but instead went with Amiga. I lost a lot in that market though it had so much potential. Amiga users were far more fanatical and it was devastating what the company did to that technology. Bitcoin is very very different. There is no point of failure. The devices that are being experimented with are prototypes. Bitcoin development is still in its infancy, but even as an infant it is beyond the understanding of mere mortals. This Trezor device is to Bitcoin as the match is to fire. Wait until the flamethrower is invented.

Thank you for your reply. I fully understand that you don't want to spend time on the discussion of ethics. But sooner or later you will have to, like everyone who had ever shipped a device with secured flash update. Its either early and easy when done with friends or late and difficult when done under duress of hacking or lawsuits.

Something really simple, like when bootloader signature check fails pop a question: do you want to continue flashing/booting unsigned software? Press X for yes, Y for no. Given small size of the screen probably some iconic rebus will be helpful.

No matter what you think about me right now, I really wish you guys well. But I've seen really close guys who failed while trying to take the paternalistic way, starting with Trip Hawkins and 3DO. It is easy to score cheap demagoguery points like cbeast did, but you aren't going to win with them.

Again, good luck, no matter what you think about me right now.

2112, I really don't want to start philosophical discussion on this topic, but device alowing signed firmware updates is clearly more open than the locked device which we wanted to deliver originally.

If you really care about absolute openess, pick Raspberry Pi version. Trezor is aiming to common users and there's no way how to reflash the device in secure way on insecure Windows computers, except allowing only digitally signed firmware...

Yes, I'm sure you would also want your personal belongings stored in a safe with the combination 1 2 3 4.

I was expecting this announcement. So now we'll have to wait for a jailbreak for Trezor. We've seen the enemy and its us!

This is actualy a good lesson on how voluntary slavery is sold as safety and security.

slush & stick: please do the ethical thing: allow explicit signature override by a special combination of keypresses. You know, something similar to what EFF asks from Microsoft.

As Stick said, implementing bootloader was easier than he expected . Now it is possible to start Trezor in special mode when it acts as USB mass storage device. Reflashing is done simply by copying new firmware to the storage and restarting Trezor.

Next version of bootloader will check digital signature of the firmware so Trezor won't accept unauthorized code. Without such feature devices may be tampered during the distribution to the customer...

+1
Can't wait

Any ideas how much longer you will need to bring this to the market?

I welcome this. Maybe it'd be a good idea to have the casings of the flashable trezors a certain color and the non-flashable another one?

After long discussions with Stick, we decided that we'll offer also unlocked devices (bootloader + refreshable memory), so people will be able to update firmware. I think this is important especially in the beginning, when some bugfixes and new features may happen.  Reflashing will be protected by pressing both buttons during power on. Then the Trezor will appear as USB mass storage device and user will be able to upload its own firwmare to the device.

All memory will be erased on firmware update, including seed (remember, user has his seed written on paper on safe location). So user will be able to detect if firmware has been changed by someone (device will be unitialized or will have another seed) and attacker won't have a chance to read seed from the device.

Trezor displays OTP on display, user re-type it to computer...


We were thinking about this already and although I'm slighly inclining to hiding change addresses, there are still few open questions. Facts:
a) Trezor can detect change address (it can check that address has been generated from its seed).
b) Trezor has no chance to check if change address provided by the computer is sane.

The most safe solution is that Trezor will display *all* outputs, including change address. As change address can be detected, it can be marked/highlighted somehow. Problem is that user who's not aware of concept of bitcoin transactions may be confused by the fact that Trezor is signing two outputs when he typed only one outgoing address.

In the oposite, by completely hiding change addresses, some attack vectors are possible. Let's imagine hacked client which sends all coins from change addresses to BIP32 address on index 2^32, 2^32, 2^32, 2^32. Although these coins are still owned by the user, good luck finding the address used in change output...


I'm looking forward payment protocol as well, I think it will work perfectly together with Trezor...

How does the "type OTP" thing work? There are only two buttons, right? I didn't really understand that part.

BTW confirming each address+output might be confusing in the case of the change output. Maybe you can suppress that one?

Just re-iterating my hope that you make the firmware split (fixed bootloader and reflashable main part), that way, when the payment protocol work is progressing it will be a smooth upgrade to have Trezors show names instead of addresses.