Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices

[someone42]

Edit: Please see https://bitcointalk.org/index.php?topic=78614.msg1327630#msg1327630 for an updated prototype.

Hardware Bitcoin wallet is a project which aims to implement a minimal dedicated Bitcoin wallet. Its main difference with every other Bitcoin client/wallet out there is its low resource requirements: the binary is currently 25 kilobytes large, it uses less than 2 kilobytes of RAM and requires only 160 bytes of non-volatile storage per wallet. With such low requirements, I reckon a production device would be smaller, more robust and cheaper than any other Bitcoin wallet.

The wallet stores private keys (actually, it only stores a seed for the deterministic key generator), parses transactions and signs transactions. It essentially doesn't do anything else. This is by design - simpler means a smaller attack surface. Private keys are generated on the device and never leave the device, except when doing a wallet backup. Even then, the seed is only displayed - it is never sent over the serial port. My intention is that physical access to a device is required in order to obtain private keys or to spend anything. As an additional layer of security, wallets can be encrypted. An encrypted wallet offers pseudo-two-factor authentication: in order to spend BTC, you need to know the wallet passphrase and you need to have the hardware Bitcoin wallet.

Here's a somewhat messy prototype:

The thing on the left is an Arduino clone (though I'm not actually using the Arduino IDE or libraries). The bunch of discretes on the lower part of the breadboard comprise a noise source, which is used to generate random numbers. The input user interface consists of two pushbuttons (bottom-left and bottom-right corners), where the user can approve or disapprove of actions. This gives you an idea of the necessary hardware peripherals required. Of course, a production device would be much more compact than this .


Here's the prototype signing a transaction:

Here's an actual transaction that it signed: http://blockexplorer.com/t/AEhoN6bzjd.

The code is hosted at: https://github.com/someone42/hardware-bitcoin-wallet. Currently, there's only a port for the ATmega328 microcontroller. However, most of the code is platform-independent; porting to another microcontroller "only" involves writing drivers for the microcontroller's peripherals.

I shall commit to being open and transparent, releasing source code and hardware specifications as I produce them. If people are interested, I might even design a production hardware Bitcoin wallet. From simple BOM and assembly cost estimates, such a device would cost 6 to 7 USD per unit to manufacture (for a quantity of 1000). If anyone has questions/suggestions, feel free to ask in this thread.

[John (John K.)]

Seems really nice!  Any way of doing a backup of the private keys as the hardware might be lost/damaged?

[da2ce7]

Seems really nice!  Any way of doing a backup of the private keys as the hardware might be lost/damaged?

yes you can display the seed.  so you could regenerate them on another system

[jim618]

Looks very nice !

What is the format of the data on the serial line for:
1) payment request
2) signed transaction

What data rate/ parity etc are you using on your IO ?

Basically: what does a piece of software have to do to interface with your device ?

[cbeast]

Bitcoin apparatus should all be wearable. Next we need human powered wearable asic running mining shoes made by Asics.

[Red Emerald]

Cool project!

[Xenland]

Nice!

[someone42]

yes you can display the seed.  so you could regenerate them on another system

Yeah, well you can in principle...though in practice wallet backups/restores aren't implemented yet. I shall implement this soon.

What is the format of the data on the serial line for:
1) payment request
2) signed transaction

What data rate/ parity etc are you using on your IO ?

Basically: what does a piece of software have to do to interface with your device ?

Serial parameters are: baud rate 57600, 8 data bits, no parity, 1 stop bit. The host and wallet exchange "packets", which are type-length-value triplets. For all the packet types, see: https://github.com/someone42/hardware-bitcoin-wallet/blob/master/PROTOCOL. It's almost the simplest protocol I could think of that is still somewhat extensible.

[jim618]

Hi someone42,

Looks nice and extensible.

I had a couple of comments on your protocol:
+ You do not specify the character encodings you are using. For the bitcoin addresses and public keys ASCII will be fine but for the wallet names I would use UTF8 to make it internationalisable (depends if you can display it I guess)
+ You have some powerful commands (format, change encryption key) that an attacker can use with no constraints on their use. For instance, a point of sale device that you only want to send sign requests can format your device. Or they can change the encryption password and hold your BTC to ransom.  Perhaps you need a 'hardware protect' physical switch to stop this - maybe you have this already.

Nice to be able to get the addresses out, exactly what is required for a watch only wallet.

[RodeoX]

Ima watch this! Cool idea.

[EhVedadoOAnonimato]

Quite cool, congratulations!

Even then, the seed is only displayed - it is never sent over the serial port.

Isn't this overkill? I mean, writing an encrypted copy of the seed on a USB key doesn't sound dangerous. And it's much easier and less error prone for the user than manually copying it from what's displayed.


I guess that it would increase complexity, but do you think it's feasible to implement "hidden volumes" like Truecrypt does, in order to have plausible deniability against this kind of attack (works as long as the attacker doesn't know for sure how much you've got)?

[EhVedadoOAnonimato]

+ You have some powerful commands (format, change encryption key) that an attacker can use with no constraints on their use. For instance, a point of sale device that you only want to send sign requests can format your device. Or they can change the encryption password and hold your BTC to ransom.  Perhaps you need a 'hardware protect' physical switch to stop this - maybe you have this already.

You're right that these are "powerful commands" and at least some sort of confirmation would be welcome. But I'm not sure this is the kind of device you want to take to a point of sale. There are two different use cases, that do not need to be accomplished by the same thing:

• Safely store your bitcoins.
• Easily spend them.

A dedicated air gapped device like this is a good candidate for the first use case, due to its high security.
For the second use case, easy of use and practical features are probably more important than security. A smartphone app with nice features, that communicates well with point of sales etc, is the perfect candidate for it, even if it's on a generic device which is more vulnerable to malware. You just don't load it with any amount of money you cannot afford to lose, pretty much like you do with cash in your physical wallet - you don't walk around with your entire salary in your pocket, do you?

Not saying that the same device can't potentially accomplish both functions. But it would need a lot of features (air gapped, unaccessible private keys, encrypted backups, plausible deniability, wireless communication, QR-scan, good display etc etc). Maybe it's easier to focus on only one use case at a time...

[jim618]

Good points - better to concentrate on the primary use case : air gapped bitcoin storage.

[anu]

How do you get on to the network?

[ThomasV]

cool! we should work together

[PawShaker]

I am hardware-phobic but very impressed. Do you wantto makethis device tamper proof? Like erase memory when you detect that someone is trying to open the case?

[jim618]

How do you get on to the network?

If I understand his protocol class correctly, somebody42's device talks via serial to another piece of software.

That software can ask it to generate keys, ask for the bitcoin addresses for the keys and give it transactions to sign. The other software would know about the blockchain, transmit the tx to the bitcoin network and monitor balances.

The hardware device is primarily a key store and can sign tx it is given if the owner presses the button to agree.

[EhVedadoOAnonimato]

That software can ask it to generate keys, ask for the bitcoin addresses for the keys and give it transactions to sign. The other software would know about the blockchain, transmit the tx to the bitcoin network and monitor balances.

The hardware device is primarily a key store and can sign tx it is given if the owner presses the button to agree.

That just makes me realize that an advanced malware could still steal from you by replacing every bitcoin address or QR-code your browser tries to display by an address in control of the attacker.

Damn. I just can't think of a way to protect against that.

The only partial defense against such a thing is to never use potentially compromised devices to make large amount transfers (like buying a car or moving your whole savings around). If you're transferring big amounts, make sure both ends - that which sings the transaction and that which provides the output addresses - are safe. Preferably air gapped safe.
But you're still vulnerable on daily purchases.

[jim618]

@EhVedadoOAnonimato - it is a bit off-topic but ThomasV has been thinking about how bitcoin URIs can be signed to prevent atackers replacing the addresses and come up with a couple of proposals.  I don't think it is trivial to solve though.

[EhVedadoOAnonimato]

That would require the device to recognize the signature. A standard like what's done for HTTPS could be created, with the device trusting a priori a set of CA root certificates, and people signing their URI's with a signed cert. But this set of root certs would need to evolve once in a while. The only way to "safely" update such set of trusted CA is by signing the update with a manufacturer's private key, which the device always trust. That only works as long as the manufacturer doesn't lose control to this key.

Difficult to implement, with some level of danger still, but yeah, a possibility, and certainly much better than nothing.
I don't know whether merchants would like to adhere to this protocol though. It would probably make their life easier if the same certificate they use for HTTPS could be used for this, at least they don't have to pay two different CA's.