Bitcoin and Smart Cards

[smartcardguy]

My backgrounds is in security and specifically in authentication technology like smart cards, I have been watching Bitcoin for some time but the recent security issues has prompted me to take a closer look.

Bitcoins use an algorithm called ECC, specifically it uses ECDSA; this is the same algorithm that is used on the most recent DoD smart cards (though they use different input parameters to the algorithm).

With that in mind it would not be terribly difficult to apply these same cards (or at least a derivative of them) to Bitcoin. This can have a number of positive side effects for example in the the typical smart card design pattern one can say:
1) The key material is generated on the card
2) The key material never leaves the card in clear text
3) All operations using the key material happen on the card
4) Access to perform operations with the key material require authentication
5) Failure to authenticate locks the card preventing use by the attacker
6) Cards are designed to be both tamper evident and resistant to different levels of attacks

Basically when properly used the keys cant be stolen, transactions are restricted to the card owner; in other words the current issues of wallet theft would not be possible, that is without a rubber hose.

There are downsides to this approach, though they can be mitigated to various degrees, some of them include:
1) If you lock the card you may lose access to the key (and the associated cash)
2) If you loose the card you will lose access to the key (and the associated cash)
3) They have a limited storage capability (you can only have so many keys on the card).

Hardware comes in lots of different form factors, some are fobs (no card, they look like flash drives though they typically do not have storage) as well as the traditional card form factors.

The cost of the hardware varies (volume and capability are the two largest factors) but my best guess is under $50 a user, and much lower if it was adopted broadly by the community (as little as 10 per user).

The reason I started this thread is I am curious how much interest there would be in something like this.

Ryan

[TraderTimm]

The form factor would be very interesting. Having some kind of card implementation of wallet storage would be highly desireable. (At least, speaking for myself.) I would have to do more research on what would be required to get some kind of smartcard system going.

Heck, how about a bitcoin ATM that really is just a secure linux implementation that assigns coins to your card based on currency deposits?

[elggawf]

I am by no means an expert in smart cards at all, but I think the chief problem with this approach is that you still have to trust the device reading it. Correct me if I'm mistaken:

Say we're in the future where we can carry our Bitcoin wallet around on a smartcard. I go to Meze Grill, order something delicious and stick my card in the card reader. It asks me to agree to the 0.5BTC or whatever the future price of something tasty is, I tap "yes", it passes the transaction to my smart card and asks it to sign the transaction, before pushing it to the network.

Assuming I'm not misunderstanding something, so far so good.

Now what if the reader is compromised some way? With a smart card approach, there's absolutely no readout or anything of that nature that I can trust. The reader might ask me to agree to 0.5BTC and then ask my smart card to sign a transaction for 50BTC. The risk is reduced at brick and mortar businesses, but it's still there.

The risk is also there for credit cards of course, but drastically reduced because you can charge back credit card transactions that are fraudulent - you can't charge back Bitcoin (that's one of it's charms).

I definitely think pocket-wallet devices are a possible future for Bitcoin, but without them having a readout of the amount I don't think it'll work... and unless I'm mistaken they don't make smartcards with neat little screens on them.

[hoo2jalu]

...
Basically when properly used the keys cant be stolen, transactions are restricted to the card owner; in other words the current issues of wallet theft would not be possible, that is without a rubber hose.
...
The reason I started this thread is I am curious how much interest there would be in something like this.

When per-account/transaction authentication is supported it would be nice to be able to use a smartcard or other trusted store (TPM, HSM, etc.) to launch the client (open encrypted wallet) and authorize transactions.

With the recent malware attacks on wallets themselves, attacking locally running bitcoind processes to make fraudulent transactions is sure to come next.

Multi-factor authentication and authorization as with smartcard systems you mention would be a convenient way to nullify this risk.

[hoo2jalu]

.... unless I'm mistaken they don't make smartcards with neat little screens on them.

You have to pay more for "secure display" capabilities but such devices do exist.

[smartcardguy]

The form factor would be very interesting. Having some kind of card implementation of wallet storage would be highly desireable. (At least, speaking for myself.) I would have to do more research on what would be required to get some kind of smartcard system going.

As far as form factor I thought fob would be more interesting at first in that there is not a need to cary a reader around when you want to use your wallet. That said the technical implementation is the same, it's a packaging question.

There would be some technical changes necessary to things like the wallet file for example it would need to be able to contain references to private keys in addition to containing them but My goal with this thread was to gauge interest, and float price as part of that.

Heck, how about a bitcoin ATM that really is just a secure linux implementation that assigns coins to your card based on currency deposits?

As for the ATM thing, on the surface it seams that the transactions of Bitcoin transaction prevent their use in a ATM like transaction without an intermediary making some sort of guarantee on the transaction. I can of course imagine that longer term but it's only viable in this model if the technical infrastructure is put into place and people are wiling to pay

[elggawf]

You have to pay more for "secure display" capabilities but such devices do exist.

Well now that might work - if it can show the amount of the transaction before it signs it.

Then again most everyone these days carries a mobile phone, so a phone + near field communication is probably the more "killer app".

[smartcardguy]

.... unless I'm mistaken they don't make smartcards with neat little screens on them.

You have to pay more for "secure display" capabilities but such devices do exist.

Yes they do, and it's possible to build systems where the card authenticates the reader cryptographically but such systems would require a arbitrator like Visa which philosophically may be hard to swallow in the BTC community. That said my interests are shorter term

[kjj]

I've started working on such a project, but it won't be a card, at least not the early models.  Only items 1 through 3 in your list are really critical here, at least to start.  Also, a display built into the unit is absolutely critical.  Without it, there can be no security at all.

[smartcardguy]

You have to pay more for "secure display" capabilities but such devices do exist.

Well now that might work - if it can show the amount of the transaction before it signs it.

Then again most everyone these days carries a mobile phone, so a phone + near field communication is probably the more "killer app".

Yes this is another natural evolution of such a solution, I have worked on several "virtual" smart cards in my career some of which use phones. That said right now the phone doesn't offer great security,just consider all major phone platforms now have malware variants of their own.

This approach, at least today also doesn't provide the same mitigations, they can be thought of more as a portable flash drive; though to be fair Much of the value of a smart card is getting the keys off the host and these virtual smart cards can have that property. Developing one of these, at least one with reasonable usability and security properties requires platform work from the phone vendors that has not been done.

[hoo2jalu]

... a display built into the unit is absolutely critical.  Without it, there can be no security at all.

Not quite true. You just need some mechanism to convey amount out-of-band. Banks have been successful using amounts SMS'ed to a phone or robo-dialed to an automated voice system, for example. Not really a "secure display" and certainly not integrated into the point-of-sale unit / terminal. Yet still absolutely effective.

[smartcardguy]

I've started working on such a project, but it won't be a card, at least not the early models.  Only items 1 through 3 in your list are really critical here, at least to start.  Also, a display built into the unit is absolutely critical.  Without it, there can be no security at all.

Interesting, I would be interested in knowing more if you would be willing to share; as for your display statement could you elaborate on the assumptions around that

[elggawf]

Not quite true. You just need some mechanism to convey amount out-of-band. Banks have been successful using amounts SMS'ed to a phone or robo-dialed to an automated voice system, for example. Not really a "secure display" and certainly not integrated into the point-of-sale unit / terminal. Yet still absolutely effective.

How do you do that through said hypothetical compromised/evil reader/payment device?

Edit: I guess you could sign the message, but then you have to rely on trusting the receiver of the message to be able to verify the signature - making SMS an unlikely candidate.

[smartcardguy]

I've started working on such a project, but it won't be a card, at least not the early models.  Only items 1 through 3 in your list are really critical here, at least to start.  Also, a display built into the unit is absolutely critical.  Without it, there can be no security at all.

I wanted to add that 4 is also very important, the next malware will just do transactions vs steal keys without it.

[kjj]

I've been thinking about wallet security too.  I think a second device is a good idea, but I see it working in a different way.

I see a portable dedicated device with very limited communications ability.  Just a serial port will do, which probably means serial over USB or serial over bluetooth.  It will also have a SD card socket for wallet backups.

The device will generate the key pairs, and store them.  The private key never leaves the device, except on the SD card backup, which could be encrypted.

I think it only needs 3 hooks into the PC client software.

1) It needs to be able to push public keys to the client.
2) It needs to be able to ask for (and receive) balance updates from the client.
3) It needs to be able to accept an address from the client, and generate a complete transaction to that address using an amount entered on a keypad.  (Or possibly accept an address and amount, then only ask for confirmation.)

I think this could help with the retail problem too; no reason why you couldn't plug it into a potentially hostile terminal.

I'm thinking Arduino.  It should already have all of the crypto libraries necessary, plus hookups for serial, USB, BT, and SD cards.  Probably going to order some hardware this week to get started.

I started with the assumption that my box is owned, and every retail terminal is owned (which is true, since they are literally owned by someone other than me).

You plug into your home computer or a retail POS, and the computer sends a payment request.  The device displays the address and amount, you press yes or no.  The device then generates a transaction, or doesn't.

Point 4 through 6 are unnecessary in this scenario, since I'm not worried (yet) about the device getting lost or stolen.  The only problem I'm looking to solve right now is the malware stealing your keys problem.

[smartcardguy]

I've been thinking about wallet security too.  I think a second device is a good idea, but I see it working in a different way.

I see a portable dedicated device with very limited communications ability.  Just a serial port will do, which probably means serial over USB or serial over bluetooth.  It will also have a SD card socket for wallet backups.

The device will generate the key pairs, and store them.  The private key never leaves the device, except on the SD card backup, which could be encrypted.

I think it only needs 3 hooks into the PC client software.

1) It needs to be able to push public keys to the client.
2) It needs to be able to ask for (and receive) balance updates from the client.
3) It needs to be able to accept an address from the client, and generate a complete transaction to that address using an amount entered on a keypad.  (Or possibly accept an address and amount, then only ask for confirmation.)

I think this could help with the retail problem too; no reason why you couldn't plug it into a potentially hostile terminal.

I'm thinking Arduino.  It should already have all of the crypto libraries necessary, plus hookups for serial, USB, BT, and SD cards.  Probably going to order some hardware this week to get started.

I started with the assumption that my box is owned, and every retail terminal is owned (which is true, since they are literally owned by someone other than me).

You plug into your home computer or a retail POS, and the computer sends a payment request.  The device displays the address and amount, you press yes or no.  The device then generates a transaction, or doesn't.

Point 4 through 6 are unnecessary in this scenario, since I'm not worried (yet) about the device getting lost or stolen.  The only problem I'm looking to solve right now is the malware stealing your keys problem.

Ah, you started with the retail terminal scenario; I started with the scenarios in use today thinking it could be expanded to those if the cost could get down low enough.

If I were to start with the terminal scenario I would have still do a smart card for form factor and cost reasons; implementation wise I would do a custom card applet that implements the bit coin wallet, communicated with a secured pin entry device (ped) or had onboard display and input mechanisms.

The approach you mention would work but I don't know if it could ever be scaled out to a currency card in a cost effective manner.

That said our two lines of thinking are compatible.

[smartcardguy]

That's interesting. But consider making it a Bitcoin ready multipayment device. Let's say you can store credentials for credit/debit cards, with all kinds of fancy features that justify the price of the device, but that it so happens to be able to store Bitcoin transaction keys and the means to use them in a transaction with security appropriate for carrying around daily spending amounts. It could provide a back-door for Bitcoin spending from a device that people are already carrying around.

It is one thing to provide enough support for doing a transaction through a reader. Maybe this is setting the bar a little high, but what if there were a way to transfer between Bitcoin and other payment methods right on the card? Let's say you are where you can only pay with a Visa/MC but most of your funds are in BTC. You could make a transfer on the card from BTC to a Visa/MC balance and then make your pruchase. The merchant doesn't even need to know anything about Bitcoin. Perhaps it could be as seamless as a single transaction...

I don't disagree one however requires much more technical and business work than the other and while it would enable new scenarios in the mean time the platform risks still remain.

It may turn out that there is insufficient interest to justify even the most basic project which would still be a significant financial investment if one was to make it scale to the community in an economical and usable way.

My thinking was crawl, walk, run.

Get the keys and wallet-into a crypto device, move much of the client into such a device, build pos infrastructure and account scenarios.... You get the idea....

[smartcardguy]

That's interesting. But consider making it a Bitcoin ready multipayment device. Let's say you can store credentials for credit/debit cards, with all kinds of fancy features that justify the price of the device, but that it so happens to be able to store Bitcoin transaction keys and the means to use them in a transaction with security appropriate for carrying around daily spending amounts. It could provide a back-door for Bitcoin spending from a device that people are already carrying around.

It is one thing to provide enough support for doing a transaction through a reader. Maybe this is setting the bar a little high, but what if there were a way to transfer between Bitcoin and other payment methods right on the card? Let's say you are where you can only pay with a Visa/MC but most of your funds are in BTC. You could make a transfer on the card from BTC to a Visa/MC balance and then make your pruchase. The merchant doesn't even need to know anything about Bitcoin. Perhaps it could be as seamless as a single transaction...

I don't disagree one however requires much more technical and business work than the other and while it would enable new scenarios in the mean time the platform risks still remain.

It may turn out that there is insufficient interest to justify even the most basic project which would still be a significant financial investment if one was to make it scale to the community in an economical and usable way.

My thinking was crawl, walk, run.

Get the keys and wallet-into a crypto device, move much of the client into such a device, build pos infrastructure and account scenarios.... You get the idea....

I should add that at least for us users it's trivial to encode the credit card data into a mag stripe on the back of the card but the issuers would through a hissy fit; in the eu this would be very problematic for technological reasons also.

[MeSarah]

The exchanges should offer smart cards to secure account. If it is applied to a wallet that might be interesting.

[kjj]

Ah, you started with the retail terminal scenario; I started with the scenarios in use today thinking it could be expanded to those if the cost could get down low enough.

If I were to start with the terminal scenario I would have still do a smart card for form factor and cost reasons; implementation wise I would do a custom card applet that implements the bit coin wallet, communicated with a secured pin entry device (ped) or had onboard display and input mechanisms.

The approach you mention would work but I don't know if it could ever be scaled out to a currency card in a cost effective manner.

That said our two lines of thinking are compatible.

Actually, I started by thinking of ways to get my keys off of my home box, and ways to make sure they never ever had to be exposed to a hostile environment (disregarding loss of possession for now).  Once I got going a little bit, I realized that it would work just as well at a retail POS as it would in my home.

You are probably right that it wouldn't be cost effective for the masses.  I'm thinking around $100 in parts for the first crude ugly prototype, plus many hours of labor.  I'm sure plenty of people here would pay that much, or double that, but we are not typical.