Bitcoin Forum
December 06, 2016, 02:12:12 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 4 »  All
  Print  
Author Topic: Hardware Bitcoin wallet - a minimal Bitcoin wallet for embedded devices  (Read 40301 times)
someone42
Member
**
Offline Offline

Activity: 78

Chris Chua


View Profile
April 30, 2012, 03:23:38 PM
 #1

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 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.
1481033532
Hero Member
*
Offline Offline

Posts: 1481033532

View Profile Personal Message (Offline)

Ignore
1481033532
Reply with quote  #2

1481033532
Report to moderator
1481033532
Hero Member
*
Offline Offline

Posts: 1481033532

View Profile Personal Message (Offline)

Ignore
1481033532
Reply with quote  #2

1481033532
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481033532
Hero Member
*
Offline Offline

Posts: 1481033532

View Profile Personal Message (Offline)

Ignore
1481033532
Reply with quote  #2

1481033532
Report to moderator
John (John K.)
Global Troll-buster and
Legendary
*
Offline Offline

Activity: 1092


Will read PM's. Have more time lately


View Profile
April 30, 2012, 04:13:50 PM
 #2

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

My BTC Tip Jar: 1Pgvfy19uwtYe5o9dg3zZsAjgCPt3XZqz9 , GPG ID: B3AAEEB0 ,OTC ID: johnthedong
Escrow service is available on a case by case basis! (PM Me to verify I'm the escrow!)

da2ce7
Legendary
*
Offline Offline

Activity: 1218


Live and Let Live


View Profile
April 30, 2012, 04:33:08 PM
 #3

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

One off NP-Hard.
jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
April 30, 2012, 06:17:23 PM
 #4

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 ?


MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
cbeast
Donator
Legendary
*
Offline Offline

Activity: 1722

Let's talk governance, lipstick, and pigs.


View Profile
April 30, 2012, 08:54:00 PM
 #5

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

Any significantly advanced cryptocurrency is indistinguishable from Ponzi Tulips.
Red Emerald
Hero Member
*****
Offline Offline

Activity: 742



View Profile WWW
April 30, 2012, 08:59:30 PM
 #6

Cool project!

Xenland
Legendary
*
Offline Offline

Activity: 980


I'm not just any shaman, I'm a Sha256man


View Profile
May 01, 2012, 01:09:31 AM
 #7

Nice!
someone42
Member
**
Offline Offline

Activity: 78

Chris Chua


View Profile
May 01, 2012, 05:16:59 AM
 #8

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
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
May 01, 2012, 07:21:33 AM
 #9

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.


MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
RodeoX
Legendary
*
Offline Offline

Activity: 2100


The revolution will be monetized!


View Profile
May 01, 2012, 04:47:53 PM
 #10

Ima watch this! Cool idea.

The gospel according to Satoshi - https://bitcoin.org/bitcoin.pdf

Free bitcoin=https://bitcointalk.org/index.php?topic=1610684
EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 616



View Profile
May 01, 2012, 05:11:20 PM
 #11

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
Hero Member
*****
Offline Offline

Activity: 616



View Profile
May 01, 2012, 05:25:21 PM
 #12

+ 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
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
May 01, 2012, 05:45:30 PM
 #13

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

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
anu
Legendary
*
Offline Offline

Activity: 938


P2P Everything


View Profile WWW
May 02, 2012, 12:21:35 PM
 #14

How do you get on to the network?

Zero Reserve - A distributed Bitcoin Exchange

Install - Getting Started - BitcoinTalk Thread - Github Source
ThomasV
Legendary
*
Offline Offline

Activity: 1722



View Profile WWW
May 02, 2012, 12:26:16 PM
 #15

cool! we should work together

Electrum: the convenience of a web wallet, without the risks
PawShaker
Full Member
***
Offline Offline

Activity: 140



View Profile
May 02, 2012, 02:34:26 PM
 #16

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?

1FQkH63k6hkexFMTRzLtJEE6ZAaTBRhjiS
jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
May 02, 2012, 05:12:08 PM
 #17

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.

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 616



View Profile
May 03, 2012, 08:01:03 AM
 #18

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
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
May 03, 2012, 10:44:11 AM
 #19

@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.

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
EhVedadoOAnonimato
Hero Member
*****
Offline Offline

Activity: 616



View Profile
May 03, 2012, 11:56:36 AM
 #20

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.
Pages: [1] 2 3 4 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!