[ESHOP launched] Trezor: Bitcoin hardware wallet

[makomk]

http://www.nxp.com/documents/application_note/AN10968.pdf

Chapter 3 (page 4) describes security level of the chip we currently want to use. Do you know about some cheap and quick solution how to skip this protection and read the seed from the device?

Well, it's going to be fairly easy to bypass CRP Level 1 via the exact method they suggest unless you put a fair amount of effort into preventing this. Not sure about higher levels though.

[Ente]

[..]
2.  (extra point) As we know, Bitcoin users of all backgrounds have a tendency to not trust anyone or anything but themselves.  For this reason, they may not be inclined to trust this device that could've been malciously designed, or tampered with to produce keys that can be predicted by someone else.  However, if they can use any application of their choosing to upload their own source of entropy, the device would have no choice but to use the user's trusted entropy instead of its own.  Not to mention that users doing this would be much better prepared to create paper backups and watching-only wallets.   
[..]

Excellent point!
I didn't even think of this yet. But now I fully agree!
I would be wary to trust my long-long-term bitcoin savings to anything. My paperwallet works and is pretty secure. If I can import my own keys I would feel much more secure to put larger amounts of Bitcoin into a third-party-device.

So, what is the niche for this hardwarewallet?
-Small amounts and amounts to spend on burgers and beer: android, bitinstant, mtgox
-Long-term and large amounts: offline (paper) wallets

Ente

[beekeeper]

Slush, would you kindly ask Mr. stick for additional information to substantiate the above claim?

http://www.nxp.com/documents/application_note/AN10968.pdf

Chapter 3 (page 4) describes security level of the chip we currently want to use. Do you know about some cheap and quick solution how to skip this protection and read the seed from the device?

It is probably possible to read memory with high level laboratory equipment, but purpose of seed protection is that attacker need some time to read memory, so original owner can reload the seed to another device and send his coins out of compromised seed.

That MCU family does not seem designed for secure applications. There are probably 100 ways to read it, despite CRP/ERM/xRR (whatever) level. You should look for a smartcard if you want some protection.

[jim618]

@Ente

I think it caters for a pretty wide niche : people who do not know what a private key is and are not interested in finding out.

If they are fairly techy they can set one up themselves and it should be plug and play with their desktop bitcoin wallet.

I imagine we are all informal IT support for our family. For people who trust you, you could set one up for them and keep the mnemonic phrase in a sealed envelope. They can use it and not think about private keys. Then if/ when they call you for help because they have lost their WhateverItIsCalled you can sort them out.

[novusordo]

@Ente

I think it caters for a pretty wide niche : people who do not know what a private key is and are not interested in finding out.

If they are fairly techy they can set one up themselves and it should be plug and play with their desktop bitcoin wallet.

I imagine we are all informal IT support for our family. For people who trust you, you could set one up for them and keep the mnemonic phrase in a sealed envelope. They can use it and not think about private keys. Then if/ when they call you for help because they have lost their WhateverItIsCalled you can sort them out.

Eh, it'd be better to let them keep their own envelope, perhaps in a safe or something. I can just imagine a situation where that "informal IT support" guy's house burns down, along with all of his family/friends' seeds to their funds.

"Gee, that's too bad about your house burning down. By the way, I lost my WhateverItIsCalled, can you help me out?"

[jim618]

Perhaps:
You give them them the hardware wallet and envelope at the same time, telling them to put the envelope in their safe. In the envelope is a sheet of paper with a step by step guide of what to do to recover their bitcoins with their specific mnemonic phrase specified.

They need to trust you though as you might have a copy of the mnemonic phrase somewhere (perhaps intentionally as a backup to them losing their envelope).

[2112]

That MCU family does not seem designed for secure applications. There are probably 100 ways to read it, despite CRP/ERM/xRR (whatever) level. You should look for a smartcard if you want some protection.

I on the other hand think that sitck and slush made excellent choice. I only have an issue with the original claim that it is impossible to extract the keys from the device after a theft. Just reduce the claim somewhat and you'll be more than fine.

The main problem with using "real smartcard" device lies in the unvieldy development process for the "real crypto stuff".

On the other hand the choice displayed here (looks like LPCXpresso LPC1343) and in the similar thread https://bitcointalk.org/index.php?topic=78614.0 (mbed LPC11U24) is an excellent starting point for learning and development. It is important to stress that anyone involved in Bitcoin development will be about €30-€60 away from being able to actively test and develop the future Bitcoin wallet device protocol.

I always wanted to expand to dedicated hardware just like this, but my hardware skills are nil.

It would be a good idea to agree on a common wire protocol, for the sake of Bitcoin client developers. My current wire protocol is documented here: https://github.com/someone42/hardware-bitcoin-wallet/blob/master/PROTOCOL.

I know this forum is full of people capable of programming (or willing to learn programming) therefore I'm going to post some links for the people who may find this project interesting from the purely programmatic side, disregarding for now the actual design of the hardware.

The good starting devices are the two following: mbed LPC11U24 and LPCXpresso LPC1347 (LPCXpresso LPC1343 is now obsolete). The first one comes with an online IDE suite at http://mbed.org/handbook/mbed-Compiler , the second one is supported by a free (as in beer) LPCXpresso IDE http://www.code-red-tech.com/RedSuite5/lpcxpresso-5.php .

Both boards seem to be the designs from http://www.embeddedartists.com/ , they just differ in how they are marketed.

You probably will not be well served by buying the higher end mbed LPC1768 or LPCXpresso LPC1769 boards because they lack the on-chip EEPROM (a.k.a. parallel, byte-erasable NOR flash). You don't want to go into the tribulations of programming NAND flash in your first embedded project.

For me none of those choices is good because the Cortex-M processors in those controllers don't execute the legacy ARM code, only the new-fangled Thumb code. So I'm still looking for a nice small USB-powered ARM development board.

[beekeeper]

That MCU family does not seem designed for secure applications. There are probably 100 ways to read it, despite CRP/ERM/xRR (whatever) level. You should look for a smartcard if you want some protection.

I on the other hand think that sitck and slush made excellent choice. I only have an issue with the original claim that it is impossible to extract the keys from the device after a theft. Just reduce the claim somewhat and you'll be more than fine.

The main problem with using "real smartcard" device lies in the unvieldy development process for the "real crypto stuff".

At least use a smart card to store secure key while the device is powered off, not the MCU flash. When device is powered on, require some password (add device unique key) and read the secure part from smartcard (or some other secure device).

[2112]

At least use a smart card to store secure key while the device is powered off, not the MCU flash. When device is powered on, require some password (add device unique key) and read the secure part from smartcard (or some other secure device).

Too complex. The real problem here is that most of the Bitcoin software developers are not familiar with the restrictions and challenges of bare metal embedded programming.

The choices of someone42/slush/stick are so great and so beautiful because anyone who tries them will have their first trivial embedded project working on the same evening that the package was delivered.

The real challenge now is not to be super-secure. It to to agree to a common hardware wallet protocol that could be sensibly implemented bare-metal on a simple hardware, not a discared Intel laptop or obsolete Android phone/tablet with their attendant problem of the security of the underlying OS.

[beekeeper]

It is possible that this platform will be standard design for BTC hardware wallets in the future. Better, at least, take in account the possibility to add security and plan some reliability for the platform, like batter battery backup, option to backup one wallet to a new one, option to add 3G modem, etc.
Look at most used software wallet.

[molecular]

For me none of those choices is good because the Cortex-M processors in those controllers don't execute the legacy ARM code, only the new-fangled Thumb code. So I'm still looking for a nice small USB-powered ARM development board.

sorry for offtopic. http://www.kickstarter.com/projects/paulstoffregen/teensy-30-32-bit-arm-cortex-m4-usable-in-arduino-a/posts/343893

My brother recently got one of these, I've been playing around with it. Don't know if this counts as a "development board", but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:

[2112]

It is possible that this platform will be standard design for BTC hardware wallets in the future. Better, at least, take in account the possibility to add security and plan some reliability for the platform, like batter battery backup, option to backup one wallet to a new one, option to add 3G modem, etc.
Look at most used software wallet.

I have to repeat to you: hardware choice is secondary. The good protocol design comes first. The available hardware in the ARM space changes so furiously fast that it simply doesn't make sense to choose it now. Post the communication protocol-level suggestions related to the hardened crypto devices, not the hardware suggestions.

I'm still browsing around and I've found a ready made LPC11U37 kit with an LCD display, 8 touch sensors instead of buttons and various other expansion options for €69 and still within the 128kB limit of the free LPCXpresso IDE:

http://www.embeddedartists.com/products/app/lowpower_oryx

It has everything required to build a secure Bitcoin wallet without a need to solder a single wire. Only programming talent is required.

but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:

I'm not getting anything Cortex-M even if it is free. I really need to be able to run classic ARM code, not just Thumb.

[Jutarul]

It is possible that this platform will be standard design for BTC hardware wallets in the future. Better, at least, take in account the possibility to add security and plan some reliability for the platform, like batter battery backup, option to backup one wallet to a new one, option to add 3G modem, etc.
Look at most used software wallet.

I have to repeat to you: hardware choice is secondary. The good protocol design comes first. The available hardware in the ARM space changes so furiously fast that it simply doesn't make sense to choose it now. Post the communication protocol level suggestions, not the hardware suggestions.

I'm still browsing around and I've found a ready made LPC11U37 kit with an LCD display for €69 and various other expansion options:

http://www.embeddedartists.com/products/app/lowpower_oryx

but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:

I'm not getting anything Cortex-M even if it is free. I really need to be able to run classic ARM code, not just Thumb.

That said, what about using old, obsolete devices as a target platform? E.g. I have an old iphone 3g sitting around here, doing nothing. The advantage is that using obsolete devices from an ongoing series (androids, iphones, etc...) would offload the device creation to established companies. As a business you'd buy old devices for low cost and install all the necessary gadgets to augment it into a hardware wallet...

[2112]

That said, what about using old, obsolete devices as a target platform? E.g. I have an old iphone 3g sitting around here, doing nothing. The advantage is that using obsolete devices from an ongoing series (androids, iphones, etc...) would offload the device creation to established companies. As a business you'd buy old devices for low cost and install all the necessary gadgets to augment it into a hardware wallet...

We had this discussion already. Search the past posts of etotheipi, Jan and  ThomasV for the analysis of various problems with these choices.

[Jutarul]

That said, what about using old, obsolete devices as a target platform? E.g. I have an old iphone 3g sitting around here, doing nothing. The advantage is that using obsolete devices from an ongoing series (androids, iphones, etc...) would offload the device creation to established companies. As a business you'd buy old devices for low cost and install all the necessary gadgets to augment it into a hardware wallet...

We had this discussion already. Search the past posts of etotheipi, Jan and  ThomasV for the analysis of various problems with these choices.

Ah. Ok. Sorry for the noise.

[stick]

You're free to use any of the code in https://github.com/someone42/hardware-bitcoin-wallet. It's (mostly) BSD licensed. My current prototype uses the NXP LPC11U24 microcontroller; I believe it is very similar to the chips in the LPC134x series. Thus there could be some useful stuff in the lpc11uxx/ directory.

Slush showed this to me and I looked at the code. Protocol seems to be very low-level for what we need. But I'll keep your project in mind ...

That MCU family does not seem designed for secure applications. There are probably 100 ways to read it, despite CRP/ERM/xRR (whatever) level. You should look for a smartcard if you want some protection.

Please don't get too hooked on LPC13xx thingie. I was experimenting with this platform, because that's what I have pretty good knowledge of. Now we are trying with TI Stellaris Launchpad (LM4F) and this might or might not be the final platform. MCUs evolve too quickly and if there is a better alternative for our usecase and it's not too late to switch we'll use it.

[beekeeper]

Well, gl.. LM4F120H5QR is very buggy, just read the errata, it has some retarded memory alignment issues.. Almost to trow it away first day when I tried to compile something which was not their example..

PS: In case you are looking for alternatives to ARM, there is PIC32, a cheap MCU based on MIPS. Has some bugs too, not as much as TI lm4f120, and runs at 80Mhz.

PSS: I was looking over microchip product page, and they have this new board based on new low cost family (I think running at 40Mhz):
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en555947
Board will be available in November and will cost $109.

[someone42]

Slush showed this to me and I looked at the code. Protocol seems to be very low-level for what we need. But I'll keep your project in mind ...

It is indeed low-level (perhaps a bit too low level). But that's because it's a wire protocol for an embedded device. The need for abstraction is diminished greatly because a lot of the low-level details (eg. transaction format) of Bitcoin aren't likely to change, and if they do, any embedded devices will become incompatible by virtue of their essentially fixed firmware.

Here's a bit of the motivation behind the wire protocol. By separating transfers into type-length-value packets, the device can skip any unrecognised packets. This allows for some extensibility. For example, if a new wallet feature is implemented which requires an extra byte in the "new wallet" packet, old wallets will see this extra byte, skip the entire packet and return "unrecognised command" to the host. The host can then tell the user "your device doesn't support this new feature" and perhaps fall back to not using the new feature.

IMHO, the biggest flaw with the wire protocol I've proposed is that it is quite specific to certain use cases. Thus I'd like your opinion on generalising it. But I'm quite averse to unnecessary abstraction.

[molecular]

but the teensy 3.0 is ARM (Cortex-M4), really small and usb powered, around $30:

I'm not getting anything Cortex-M even if it is free. I really need to be able to run classic ARM code, not just Thumb.

Allright, got it. I'm not into that stuff much so I don't even know what "thumb" is.

[slush]

Are you not interested in being compatible with Armory?

I'm interested in being compatible with any existing and future bitcoin wallet, including Armory. I'm working on library written in python for interfacing with the device, so implementing it into the Armory should be super trivial. I'm aware of Armory's offline wallets and I think there's almost everything prepared for such type of device.

The reason why I contacted Jim instead of you is because Multibit is written in Java and I need some clarification that he's interested in such kind of device and that there's a way how to talk with this device from Java.

there are lots of ways to do this kind of device, but there's one mode of operation I think it should have:  the device has a hardware switch on the back behind a little door that is accessible, but impossible to flip by accident.  The switch allows for uploading new wallet data.  Data that is uploaded to the secure chip is not downloadable -- it's a one-way channel. 

Although "downloading" the seed from the device into the computer won't be possible, there'll be a way how to upload custom seed from attached computer. There won't be any need for special hardware switch on the device, it just displays request if you want to rewrite current seed by that provided by the computer.

The user creates their full wallet using Armory/Multibit/Electrum on a temporarily-offline computer (live session), they print off a couple paper copies, create a watching-only copy, then they flip the switch to allow uploading the wallet to the device.  Copy the watching-only wallet to the online computer, stash your paper copy in a safe-deposit box, and then flush the original copy on the computer by rebooting.  Now you're ready to go.

Yes, this would be possible (except that hardware switch, as I mentioned above.

There's other modes of operation to consider, but I think the flexibility of managing the wallet initially from a laptop/desktop is ideal.  This gives lots of options for watching-only wallets, making address lists, etc. 

Device will handle just the master private key and it will derive every address from it. It won't allow you to handle private keys for custom address. This is limitation which will make the interface much easier.

The device could also have a separate memory bank for downloading the watching-only wallet from it.

I don't plan this. Device will just provide master public key to the computer and then it will be just able to sign for addresses derived from this master key.

This stuff is already available in Armory, it just uses a different wallet format and data transfer format (BIP 10).

I wasn't aware of BIP10. I'll read it and maybe I'll have some more questions. I'm also going to support P2SH, but maybe I'll need some help with it...