Idea for a hardware-based Bitcoin savings account

[bitcoin_idea]

Benjamindees:

Smartcards are an interesting suggestion.  If there were an ECDSA card out there, it sounds like a private key could not be extracted from it, even for backup purposes.  Is this correct?


If the implementation were done on a non-ECDSA javacard, something like a computer or smartphone would still have to interface with it, correct?

My concern is that a compromised machine could tamper with the input to the javacard, such that the destination address and/or amount is changed when a user wants to make a transfer.

On the other hand, the idea of using a smart card kept in a safe as a bitcoin savings account seems pretty sexy from a usability standpoint.  For people like allinvain who want to keep around 25,000 BTC for a long period of time, is a smartcard something he'd want to keep it on?

(ben-abuya you posted right around when I was going to and it looks like we have similar concerns about the smart card as a savings account)

[googlebot1]

Nice idea!

[ben-abuya]

Benjamindees:

Smartcards are an interesting suggestion.  If there were an ECDSA card out there, it sounds like a private key could not be extracted from it, even for backup purposes.  Is this correct?


If the implementation were done on a non-ECDSA javacard, something like a computer or smartphone would still have to interface with it, correct?

My concern is that a compromised machine could tamper with the input to the javacard, such that the destination address and/or amount is changed when a user wants to make a transfer.

On the other hand, the idea of using a smart card kept in a safe as a bitcoin savings account seems pretty sexy from a usability standpoint.  For people like allinvain who want to keep around 25,000 BTC for a long period of time, is a smartcard something he'd want to keep it on?

(ben-abuya you posted right around when I was going to and it looks like we have similar concerns about the smart card as a savings account)

Wow, just found this:

http://www.gemalto.com/products/top_javacard/download/TOP_DL_v2_Sept10.pdf

Looks like it's got everything baked in. I bet you could do some cool stuff with an app running on windows and mac that would handle all the administrative stuff, while leaving all the key generation and storage to these cards.

One idea I just had is for card A to generate a wallet and encrypt it with a random string. It splits the random string into two and encrypts half the random string with card B's public key. The host computer transfers the encrypted half to card B. Then you'd either have to securely delete the orignal wallet.dat and random string on card A, or copy the first half of the random string to card C and securely destroy card A. I don't know enough about how smart cards work to know if this is possible, but the possibilities seem endless.

Also, these would be great for small wallets, for using like a credit card.

[benjamindees]

 If there were an ECDSA card out there, it sounds like a private key could not be extracted from it, even for backup purposes.  Is this correct?

This depends on the implementation.  It could be anything from the card generating the key and never revealing it, to the client generating the key and just storing it on the card in an insecure fashion.  It's up to you.

It would even be possible to store the key weakly such that it requires a pin, and that brute-forcing the pin would take a week or so.  That way it would provide some protection against loss or theft while you could always break in if you forgot the pin.

If the implementation were done on a non-ECDSA javacard, something like a computer or smartphone would still have to interface with it, correct?

A smart card would only be useful as a secure wallet, not a complete implementation.

[bitcoin_idea]

 If there were an ECDSA card out there, it sounds like a private key could not be extracted from it, even for backup purposes.  Is this correct?

This depends on the implementation.  It could be anything from the card generating the key and never revealing it, to the client generating the key and just storing it on the card in an insecure fashion.  It's up to you.

It would even be possible to store the key weakly such that it requires a pin, and that brute-forcing the pin would take a week or so.  That way it would provide some protection against loss or theft while you could always break in if you forgot the pin.

If the implementation were done on a non-ECDSA javacard, something like a computer or smartphone would still have to interface with it, correct?

A smart card would only be useful as a secure wallet, not a complete implementation.

I think multiple  ideas  here are viable and similarly good.  I'll think about which one I'd want to implement and in the mean time, this discussion may strike up the interest of anyone with skills more applicable to either of these devices

[CAFxX]

Don't reinvent the wheel: http://code.google.com/p/opencryptotoken/

[n2liquid]

Okay, I think we really need an IRC channel for this development. It's funny that I found this after posting a proposal to do almost exactly that (http://forum.bitcoin.org/index.php?topic=18717.0).

I just recently bought some hardware to try this out. It's certainly very overkill for this project (a 400 MHz ARM920T; I'd be very surprised if it couldn't timely handle the crypto functions, even without a floating-point unit, and yeah, I'm a noob and I don't even know if floating point can or is used for cryptography; please forgive me there), but proof-of-concepts are something lacking here, right? I also bought a very good starters FPGA (Altera EP2C5 family).

FPGA's have the advantage that they generally solve stuff much, much, much more efficiently than a CPU, at a lower cost, and are just as flexible.

If a CPU is just good enough to run an algorithm timely and you have to change the algorithm, you're very likely to discover your CPU is not good enough anymore, and have to change it. FPGA's can also become useless if the change is too drastic, but I'm pretty inclined to believe it's harder to happen.

I think we should've got things straight by now already. I'll try to write down what I think.

I think all the options currently available to protect your wallet are just plain bad. Let's go through each one by one:

1 - Solution: Encrypt your wallet.dat.

Problem: When you decrypt it to use it there's always a breach. You have to trust that your computer was properly configured, and trust that it's not compromised at system level (something I think is pretty common on Windows).

In short, this solution has the problems of being hard to achieve (there's no handy program that does all that for you yet, afaik), being Linux-only (personal opinion of mine; one could argue), and, sum it all yourself, it's just terrible for non-geeks.

2 - Solution: Encrypt your wallet.dat under Linux.

Problem: You have to use Linux. If you're a Linux user that's fine, but if you're not, that solves nothing. Not to mention, if you don't use a pendrive of sorts, your wallet.dat is tied to a particular computer. If you travel, you either take it along or connect through SSH to make transactions. Not very practical.

3 - Solution: Encrypt your wallet.dat, put it on a data traveller and decrypt it using Linux when you need it.

Problem: ... none, if you're a Linux user. But you can't use it when you're away from your Linux laptop.

4 - Solution: Encrypt your wallet.dat and put it inside a bootable medium such as a pendrive, CD, or DVD.

Problem: None again, unless you're stuck with some public computer that's configured not to boot from media it's not originally meant to. This is very common in workplaces, schools, etc. Plus, you have to reboot your computer just to make transactions. You can use this just for your big-money account, but it's still a bit unpractical, especially for non-geek users.

5 - Solution: Place your (hopefully encrypted) wallet.dat on the cloud.

Problem: It sounds like going back to bank days where you have to trust someone to send and receive money. I, for one, think this is totally not Bitcoin-style.

6 - Solution: Encrypt your wallet.dat and put it inside a small, cheap device that stands for itself, requires zero-configuration and can be used from any computer that can at least open up a USB mass storage device and run an executable, and, most importantly, do this in total safety, because the password (which might as well be your fingerprint) is entered on a dedicated device you fully trust. Frankly, I feel safer doing this than doing internet banking! It's perfect!!

I think I've gotta be a die-hard advocate of this hardware wallet project.

There's a catch to this USB Wallet thing, though. If these USB Wallets become popular like I strongly believe they should become, it would be a shame if they couldn't be upgraded. If something real bad happens to the Bitcoin network, like someone entirely or partially craking the transaction signature system (I know it's VERY unlikely, but hey, it can happen, and we're not dealing with private e-mails anymore, we're dealing with damn money from lots of people, so I'm assuming the Bitcoin was designed in some way that can be upgraded... right? Please tell me I'm right..!), people would be so scared about it that making them buy new hardware would just push them more away from the market, which is really bad for the people who stay in.

So the USB Wallets should be easily expansible to support changes in the Bitcoin cryptosystem. FPGA's, I think, are generally better suited for that than a microprocessor like Arduino/Atmel's AVR (wish I'm not sure can even handle signing a transaction in, like, less than a minute; I mean, many of them are effing 8-bits and extremely underclocked, is that really enough?), or even some powerful ARM processor.

I think an FPGA is something really worth having in a USB Wallet, but that's something we can all discuss, try out, etc.

All in all, an IRC channel would be very welcome, wouldn't it? Any suggestions where we can set our HQ?

[CAFxX]

So the USB Wallets should be easily expansible to support changes in the Bitcoin cryptosystem. FPGA's, I think, are generally better suited for that than a microprocessor like Arduino/Atmel's AVR (wish I'm not sure can even handle signing a transaction in, like, less than a minute), or even some powerful ARM processor.

I think an FPGA is something really worth having in a USB Wallet, but that's something we can all discuss, try out, etc.

The link I posted above says that the atmega8 (an 8-bit low-end microcontroller) can do

On-token private key operations (ECDSA Sign) with acceptable speed (~2seconds/sign for prime192v1 NIST curve)

Also consider that there are faster drop-in replacement like the atmega328 (cost < $3)

[n2liquid]

@CAFxX, that's interesting, but are Bitcoin signatures ECDSA? I heard they're some specific elliptic algorithm + two SHA-256. Atmega328 is also 8-bits, right? I'm still shocked that's enough for crypto math, but it seems it's true.

Anyway, would you join the IRC channel and lend us a hand from time to time?

[CAFxX]

@CAFxX, that's interesting, but are Bitcoin signatures ECDSA? I heard they're some specific elliptic algorithm + two SHA-256.

Yes they are ECDSA: https://en.bitcoin.it/wiki/Protocol_specification#Signatures
IIRC SHA-256 is even less computationally-intensive than ECDSA. I wouldn't be surprised if creating/signing a transaction would require less than 3s.

Atmega328 is also 8-bits, right? I'm still shocked that's enough for crypto math, but it seems it's true.

yes, they're identical apart from different amount of flash memory (32kb vs 8kb) and max clock speed.

Anyway, would you join the IRC channel and lend us a hand from time to time?

I'll be done with my master's thesis in a couple of weeks. Afterwards I'll gladly try to help.

[CAFxX]

Anyway, would you join the IRC channel and lend us a hand from time to time?

BTW, which IRC channel is it?

[makomk]

Also consider that there are faster drop-in replacement like the atmega328 (cost < $3)

The atmega328 isn't actually faster, it just has more memory. Also, it might be worth looking at one of the cheaper low-end ARM microcontrollers with integrated USB; they have a lot more processing power and aren't much more expensive.

Also, one very important warning: do not screw up and use a weak random number source. Your users will never forgive you.

[CAFxX]

Also consider that there are faster drop-in replacement like the atmega328 (cost < $3)

The atmega328 isn't actually faster, it just has more memory. Also, it might be worth looking at one of the cheaper low-end ARM microcontrollers with integrated USB; they have a lot more processing power and aren't much more expensive.

Hmm, no. ATmega8 runs at 16MHz while the ATmega328 can run at 20MHz, so it's roughly 25% faster.

Also, one very important warning: do not screw up and use a weak random number source. Your users will never forgive you.

IIUC the project I linked above is using a capacitor connected to one of the ADC as a source of randomness. It might not be as good as one of those TRNGs, but with some decent entropy estimation, followed by equalization and whitening it should make a decent entropy source.

[CAFxX]

Just a quick note... the project above wouldn't be really secure as is, because a secure design would at least require a display and confirmation button (to be secure against arbitrary software running on the host and - to a limited extent - against theft of the key).

[makomk]

Hmm, no. ATmega8 runs at 16MHz while the ATmega328 can run at 20MHz, so it's roughly 25% faster.

Ah, I'd forgotten about that - most of the designs out there are at least vaguely Arduino-based and so run at the slower 16MHz speed.

IIUC the project I linked above is using a capacitor connected to one of the ADC as a source of randomness. It might not be as good as one of those TRNGs, but with some decent entropy estimation, followed by equalization and whitening it should make a decent entropy source.

Hopefully, yeah. I was vaguely looking at a chip with an integrated RNG for a similar project, but it's way overkill and a bit too expensive and hard to work with. (Plus, I dropped the project after discovering there were bigger security issues related to Bitcoin *cough*exchanges*cough*.)

Just a quick note... the one above wouldn't be really secure as is, because a secure design would at least require a display and confirmation button (to be secure against arbitrary software running on the host and - to a limited extent - against theft of the key).

Which is a pain, yeah. There are various potential options out there such as clones of Nokia LCDs though.