Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices

[allten]

So many great minds on here. I started working on the same project for the last few weeks knowing there had to be someone already doing the same thing.
Well, tonight I discovered this thread.

I'm not about making a profit or anything; I would just like to see this product available.

I've been coding for a MICROCHIP PIC 32 bit MCU.

[irritant]

alten maybe you can help    i also want to see this project become a real product, but i dont have those skills ..

However, I have no experience with production-grade hardware, only "once-off" hardware. I would also like to see this project become a real product, but I have no experience with marketing, distribution, compliance testing, supply chain management etc.

[someone42]

I have just completed an improved prototype.

Here is a picture of that prototype. An Australian 20 cent coin (comparable in size to the US half dollar) is shown for scale. It is signing the same transaction as in the OP.


The firmware has received substantial improvements. Here is a summary of current features:

• Wallet encryption. Wallets are encrypted using AES-128 in XTS mode. Encryption is optional.
• All potentially dangerous operations (eg. formatting storage) require user confirmation.
• When signing a transaction, all output addresses and amounts are displayed, as well as the transaction fee.
  
• The transaction parser supports P2SH addresses.
• Deterministic wallets. All addresses are generated from a random seed, so that once a backup is done, no further backups are necessary.
• Wallet backup/restore. A wallet's deterministic seed can be displayed on-screen, giving the user the opportunity to write it down. Wallet backups can be (but don't have to be) encrypted.
• Multiple wallets. A single device can hold many wallets. Each of these wallets are independent - they can have different addresses and different encryption keys.
• Hidden (plausibly deniable) wallets. Erased wallets consist of random data. Since encrypted data is statistically indistinguishable from random data, (theoretically) the existence of a hidden wallet cannot be confirmed without the correct encryption key.
• Secure formatting. Formatting a device does a multipass, low-level (i.e. bypasses any wear levelling) overwrite with random data.
• Dedicated hardware entropy source. A thermal noise source is sampled to collect entropy. The source is continually tested for signs of failure and interference. A persistent entropy pool mitigates the impact of more subtle failures

Here is the current prototype doing a wallet backup:

Note that the entire seed is displayed over three such screens; only the first one is shown.

These are some features that I would like to implement for the future:

• BIP0032-compatible deterministic wallets.
• Resilience to sudden power-off events. In other words, data corruption should be avoided if power is suddenly removed at any time. This is necessary because the wallet is USB powered.
• P2SH address generation. This will enable some secure multisig use cases, such as the secure reception of funds.
• Software ("bit banged") low-speed USB host for USB keyboard input. This will enable the input of wallet encryption keys in a way which bypasses software keyloggers.
• Firmware updating. I intend to allow this only simultaneous with the erasure of all wallets. That way, firmware updates cannot be used to extract the contents of a wallet, and the firmware update feature cannot be used to install a backdoor without the user noticing (provided the user creates their wallets on a clean device).

Some additional statistics:

• Firmware binary size: 22.9 kilobytes.
• Required RAM: 8 kilobytes.
• Required non-volatile memory per wallet: 160 bytes. The included 4 kilobyte EEPROM fits about 23 wallets.
• Microcontroller: NXP LPC11U24, a 32-bit ARM Cortex-M0 microcontroller running at 48 Mhz.
• Display: SSD1306-based OLED display, with a resolution of 128x64. That's enough to display 4 lines of 16 characters.

Firmware source is available from https://github.com/someone42/hardware-bitcoin-wallet. A schematic of the circuit in the top picture is available from https://github.com/someone42/hardware-bitcoin-wallet/blob/master/lpc11uxx/hardware/hwrng.jpg.

I have teamed up with someone else (allten on this forum) who is doing hardware development. This means that the next prototype will probably be much cleaner and more robust.

[jim618]

Hello someone42,

It looks like you are making great progress on your hardware wallet.

Have you considered if/ how your users can hook up to their desktop wallets ?
I ask as I am sure you are aware of the Slush/ Stick wallet and I wonder if you could consolidate your 'wire protocol' so that desktop clients only have one API to work against.

By 'wire protocol' I mean the message format and the method calls between the hardware device and a host computer that gives it the transactions to sign.

I ask as, to be honest, there is quite a lot of software effort in supporting hardware devices so having a common interface would really help their rollout.

Of course it is not always easy to get something that works both across devices and across desktop clients but it would be a great result if we could do it.

Jim

[2112]

Some additional statistics:

• Firmware binary size: 22.9 kilobytes.
• Required RAM: 8 kilobytes.
• Required non-volatile memory per wallet: 160 bytes. The included 4 kilobyte EEPROM fits about 23 wallets.
• Microcontroller: NXP LPC11U24, a 32-bit ARM Cortex-M0 microcontroller running at 48 Mhz.

Thank you very much for the additional information you gave.

I clicked around on the NXP's web site to see how thin is the ice you are skating on. It is very thin: 32kB is the maximum firmware size in the chips you selected.

LPC11U2x family is 24-32/1-2-4/6-8 Flash/EEPROM/SRAM

LPC11U3x family is 40-48-64-96-128/4/8-10-12 Flash/EEPROM/SRAM

I didn't to a thorough price research but the random price comparison gave me $2.26 for 11U24 and $3.14 for 11U37.

The very important additional information is that the free version of LPCXpresso platform will allow the user to build an executable of any size, but there is a restriction in terms of code download which is 128kB.

The target market here is open-source tinkerers. They are not going to be much affected by a price difference of about $5.

So I suggest switch to the top-of-the-line LPC11U37 with the compatible package if possible. People will buy it just for the opportunity to tinker with it.

Edit: Thanks again for posting the address space utilization numbers. I wasn't really aware how thinly shaved some of the ARM-licensed designs are. I was talking about NEON and SIMD-like coding and these devices have a software integer division in ROM! Sorry. The oldest and smallest embedded design I ever worked on used full 8-bit address space of 64kB divided between DRAM and EPROM.

[someone42]

Thank you very much for the additional information you gave.

I clicked around on the NXP's web site to see how thin is the ice you are skating on. It is very thin: 32kB is the maximum firmware size in the chips you selected.

LPC11U2x family is 24-32/1-2-4/6-8 Flash/EEPROM/SRAM

LPC11U3x family is 40-48-64-96-128/4/8-10-12 Flash/EEPROM/SRAM

I didn't to a thorough price research but the random price comparison gave me $2.26 for 11U24 and $3.14 for 11U37.

There's a reason for this: back when I was looking at dev kits to purchase, the LPC11U3x series hadn't been released yet, though I was aware of their impending release. Fourtunately, the LPC11U3x series are all fully binary and pin-compatible with the LPC11U24. Future prototypes will definitely use a microcontroller with more program memory.

I'd like a hardware wallet where you can import your own keys, like vanity keys, or your own generated private keys. It should be a one way write only function. It can never be read from, so there would be no way to extract the private keys.

I do see the merit of this, in that it increases interoperability with the existing Bitcoin infrastructure. I've considered allowing a few (maybe 4?) imported private keys per wallet. However, I see this feature to be slightly beyond the scope I had in mind for this project, so it's quite low on my feature priority list.

[Ente]

Where is this!
Give me that Hardware Wallet!
Shut up and take my money!

Seriously, what's the current status? Is this here the most recent thread?

Ente

[someone42]

Here's an update:

In October 2012, allten contacted me. He had designed some hardware but needed some firmware, while I had some firmware but only a hardware prototype. So we combined our efforts. He sent me a special development version of the BitSafe:




I spent some time porting the firmware to the BitSafe. I think the BitSafe will be the "home" of the hardware-bitcoin-wallet firmware, though much of that codebase is and will remain platform-independent. If you want to get your hands on some actual hardware, see https://bitcointalk.org/index.php?topic=152517.0.

The images above make the BitSafe look misleadingly large. This one gives a better sense of scale:


My immediate goals for the firmware have concentrated on integration with other parts of the Bitcoin infrastructure.

• The deterministic wallet implementation now uses the (proposed) BIP 0032 specification. This should allow wallets to be imported/exported across other BIP 0032-compatible Bitcoin clients.
• The wire protocol is being changed to make it more similar to that of slush/stick's Trezor. This should make it easier for Bitcoin clients to support hardware wallets in general.
• I began working on a P2SH (multisignature) address generator, to facilitate secure multisignature reception of funds. However, I've put that on hold to focus on more basic use cases.

Finally, since the last update, a difficult but significant goal has appeared. Gavin Andresen proposed a secure payment protocol (see https://gist.github.com/gavinandresen/4120476) which makes address rewrite attacks much more difficult. The problem with asking "Send 0.0461 BTC to 1QLbz7JHiBTspS962RLKV8GndWFwi5j6Qr?" is that an attacker could covertly rewrite this address and it is difficult for a user to determine whether a given address is genuine or not. With the proposed payment protocol, the prompt would be something like "Send 0.0461 BTC to mtgox.com?", where the name is validated using some sort of certificate chain.

Such a solution has been alluded to in this thread (see https://bitcointalk.org/index.php?topic=78614.msg880376#msg880376) and elsewhere, but Gavin Andresen's proposal looks likely to become "the standard". So I would like to implement it.

[XcelR]

We have been looking through your project and your github. We are going to take on the task of Building our Own Hardware wallet for our Coin XcelR.

[Ente]

We have been looking through your project and your github. We are going to take on the task of Building our Own Hardware wallet for our Coin XcelR.

Resistance is futile.

[potificate]

Here's an update:

In October 2012, allten contacted me. He had designed some hardware but needed some firmware, while I had some firmware but only a hardware prototype. So we combined our efforts. He sent me a special development version of the BitSafe:

https://i.imgur.com/ylEx0PE.jpg
https://i.imgur.com/D1ERR5c.jpg

It's been ages since this has been posted.... what have you been up to? (Tried DMing you, but BCT still thinks I'm a noob and blocks me from such things.. I've been on for a while but mostly lurk.)

This was so amazing that you started this before anyone else... just curious what's been going on over the past 5 years. :-)

Potificate

[Pmalek]

It's been ages since this has been posted.... what have you been up to? (Tried DMing you, but BCT still thinks I'm a noob and blocks me from such things..

I doubt you would have gotten far by PMing the user. If you check his profile he has not been online since November 2017 - https://bitcointalk.org/index.php?action=profile;u=38146
Took a quick look at this posting history in search for an email or other way to contact him but couldn't find anything except for a few github repositories and dropbox links.

[potificate]

It's been ages since this has been posted.... what have you been up to? (Tried DMing you, but BCT still thinks I'm a noob and blocks me from such things..

I doubt you would have gotten far by PMing the user. If you check his profile he has not been online since November 2017 - https://bitcointalk.org/index.php?action=profile;u=38146
Took a quick look at this posting history in search for an email or other way to contact him but couldn't find anything except for a few github repositories and dropbox links.

Oh man.. that's such a shame considering such important work. Thanks for looking!