Pages:
Author

Topic: Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices - page 4. (Read 44696 times)

legendary
Activity: 1708
Merit: 1066
Good points - better to concentrate on the primary use case : air gapped bitcoin storage.
hero member
Activity: 630
Merit: 500
+ 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...
hero member
Activity: 630
Merit: 500
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)?
legendary
Activity: 3066
Merit: 1147
The revolution will be monetized!
Ima watch this! Cool idea.
legendary
Activity: 1708
Merit: 1066
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.

member
Activity: 78
Merit: 11
Chris Chua
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.
legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
hero member
Activity: 742
Merit: 500
donator
Activity: 1736
Merit: 1014
Let's talk governance, lipstick, and pigs.
Bitcoin apparatus should all be wearable. Next we need human powered wearable asic running mining shoes made by Asics.
legendary
Activity: 1708
Merit: 1066
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 ?

legendary
Activity: 1222
Merit: 1016
Live and Let Live
Seems really nice!  Grin 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
legendary
Activity: 1288
Merit: 1227
Away on an extended break
Seems really nice!  Grin Any way of doing a backup of the private keys as the hardware might be lost/damaged?
member
Activity: 78
Merit: 11
Chris Chua
Edit: Please see https://bitcointalksearch.org/topic/m.1327630 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 Smiley.


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.
Pages:
Jump to: