Hardware Wallet Roundup

[paybitcoin]

[EDIT: Oops, I meant to post this in Project Development, can somebody move it please?  ]

In the interest of time for those searching and as part of my own research into hardware wallets, I have summarized all the developments of hardware wallets that I could find.

Please contact me if there are other projects/links or if I have made an error.

Update 2013-01-13!!! The contents of the post have been moved to the wiki page, so you can see all the hardware wallets here:

https://en.bitcoin.it/wiki/Hardware_wallet

[1714219882]

1714219882

[1714219882]

1714219882

[1714219882]

1714219882

[1714219882]

1714219882

[gmaxwell]

The closest so far to a mass market solution, incorporates a display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred. Possibly transactions could be delivered over giant QR codes.

We (people hanging around #bitcoin-dev) also believe this device leaks it ECDSA private keys.

[allten]

Thanks for starting this thread.
Nice to have all the links to all the Hardware wallet development going on.

FYI, Allten's PCB is based from Someone42's Prototype.
Someone42 has helped out significantly in the design of that PCB.
Please give him credit.

Thanks.

[Red Emerald]

Thanks for the thread.  I'd seen most of this, but not all of it.

The closest so far to a mass market solution, incorporates a display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred. Possibly transactions could be delivered over giant QR codes.

We (people hanging around #bitcoin-dev) also believe this device leaks it ECDSA private keys.

Well that sounds bad.

[paybitcoin]

The closest so far to a mass market solution, incorporates a display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred. Possibly transactions could be delivered over giant QR codes.

We (people hanging around #bitcoin-dev) also believe this device leaks it ECDSA private keys.

Yes, I have seen that, but that's a software bug (major, but still,) and could be fixed in an update. This list was not meant to be that comprehensive...

FYI, Allten's PCB is based from Someone42's Prototype.
Someone42 has helped out significantly in the design of that PCB.
Please give him credit.

Added, thanks.

[btchip]

Hi

Re. smartcards, we're introducing a new project on http://www.btchip.com , currently in beta.

This card is designed with simple goals in mind : secure private keys and keep the user in control, so that you can easily extract the keys or import new keys if you wish to do so.

You can find more details about the implementation on https://github.com/btchip/btchip-python as well as a sample integration into bitcoinj.

A few samples (~ 10-20) are available for interested client developers - just send a PM with your references.

I'll open a new thread to discuss the technical details and integration soon.

[paybitcoin]

Hi

Re. smartcards, we're introducing a new project on http://www.btchip.com , currently in beta.

This card is designed with simple goals in mind : secure private keys and keep the user in control, so that you can easily extract the keys or import new keys if you wish to do so.

You can find more details about the implementation on https://github.com/btchip/btchip-python as well as a sample integration into bitcoinj.

A few samples (~ 10-20) are available for interested client developers - just send a PM with your references.

I'll open a new thread to discuss the technical details and integration soon.

Cool, added your project. Good looking code and site.

Question though, what do you mean by: (link)

No asymmetric keys are kept on the dongle - the private keys are sent back and forth encrypted by a Triple DES context key.

Am I correct in understanding that it doesn't store the EC private key itself, but instead you need to take the 3DES-encrypted private key previously generated and encrypted by the device (using the device's internal 3DES private key) and transfer it back onto to the device when signing? Also, I am assuming the optional PIN generates the "3DES context key" to secure the channel between the host and device? That's a pretty interesting solution.

You may want to specify a bit more clearly in the README where the EC private key is stored during the lifetime of the device, and when it is encrypted and when in plaintext. As it reads now, it sounds like the private key is unencrypted in the (3DES encrypted) channel, but after looking at the code it has 80-bits of security (3DES.)

I'll be watching for the technical details thread. Thanks!

[btchip]

Cool, added your project. Good looking code and site.

thanks for the quick merge  

Am I correct in understanding that it doesn't store the EC private key itself, but instead you need to take the 3DES-encrypted private key previously generated and encrypted by the device (using the device's internal 3DES private key) and transfer it back onto to the device when signing?

yes exactly

Also, I am assuming the optional PIN generates the "3DES context key" to secure the channel between the host and device? That's a pretty interesting solution.

the optional PIN is an additional keyset (set of 3 keys, that's from GlobalPlatform) you can use to lock the context key to a Secure Channel - in this case, you'll need to open the Secure Channel first (i.e. show that you know the keyset) before being able to sign/generate anything with the dongle.

You may want to specify a bit more clearly in the README where the EC private key is stored during the lifetime of the device, and when it is encrypted and when in plaintext.

sure, I'll do this, thanks for the useful comments. Technical thread will be created over the week-end available over there https://bitcointalk.org/index.php?topic=134999.0.

[paybitcoin]

I have just posted the content to:

https://en.bitcoin.it/wiki/Hardware_wallet.

This will be its final resting place as soon as I get a chance to make the wiki look nicer.

[cbeast]

I have just posted the content to:

https://en.bitcoin.it/wiki/Hardware_wallet.

This will be its final resting place as soon as I get a chance to make the wiki look nicer.

This is great. There are so many projects going on. It's nice to be able to get progress updates on a wiki.

[Seth Otterstad]

Can I buy any of these yet?

[paybitcoin]

I am moving this page to the wiki since it looks nice there now. Thanks ripper234 and dree12 for the cleanups on the wiki!

Also, I have uploaded the previous images that I had here (and some newer ones for trezor/bitsafe.) I consider them to be under fair use, and have marked them as such.

Project owners, feel free to remove the images from the wiki if you feel like fair use doesn't go that far, and please consider replacing it with a properly copyrighted marketing image of your choice.

[allten]

Can I buy any of these yet?

https://www.bitmit.net/en/item/13429-micro-bitsafe-w-uusb-port-512-kb-flash-128-kb-sram-1-0mm-pcb

[paybitcoin]

!!!! awesome!

[Jan]

The closest so far to a mass market solution, incorporates a display, keypad, and radio (custom ISM band protocol.) Unfortunately it is fairly limited in terms of transaction I/O, requiring a radio gateway or another bitcoincard wherever funds need to be transferred. Possibly transactions could be delivered over giant QR codes.

We (people hanging around #bitcoin-dev) also believe this device leaks it ECDSA private keys.

Let me give a little more context on this. In the bitcoincard demo at the workshop last year in Vienna bitcoincard used the a fixed constant K when generating signatures. Also, the private keys were generated simply by hashing the 'nickname' of the card. These things were done in order to generate predictable outputs for testing, yes, this is very useful when debugging hardware and embedded software. This is obviously not something you should do in production as both scenarios will make it trivial to reveal the private keys.
This will obviously not be the case once they hit the market.