Bitcoin Forum

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

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?

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. :(

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.

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

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.


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 :)

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 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 :)

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.

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.

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.

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

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.

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

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.

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.

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

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.

I agree, with the crypto card approach additional cost for this for almost nothing.

I setup this wiki page, in order to gather information:
https://en.bitcoin.it/wiki/Smart_card_wallet

please let me know if you are interested

The same way bitcoin handles it now.  You empty the entire contents of the private key, and give the remainder to a different PUBLIC address in the same wallet.  Then even if they get the private key, who cares, there's nothing left in that address.

Swing and a miss. Smartcards don't generally divulge keys (that's pretty much the whole point of them), and I said nothing about divulging keys being the issue.

watching this thread..

I thought maybe a usb computer stick would make a nice prototype such as a teensy, these do probably not lock the key that well in case of theft, but I'd be okay with that. Just want a small thing I could charge with a few btc's and carry around to different computers.

FYI, I setup this page to gather resources on how to achieve this goal:
https://en.bitcoin.it/wiki/Smart_card_wallet

How does this go?

Any progress on this? This seems to me to offer the highest practically attainable security. If someone has to steal the card in order for me to lose the coins, it's good enough for me.

in December, slush talked about implementing an Electrum client in a USB stick with a small screen

Am I late to the party? :)

I though O was thinking on something new! But clearly I wasn't. Almost everything I thought is already on that wiki page (with not only words as I did) except for one thing.

I have something to add: If the merchanr have to wait for 6 confirmations then this card is practically useless, also if the wallet is deterministic for it to be recoverable; again it merchants would need to wait for 6 confirmations to avoid double-spend attempts.

But if the merchant has for sure that the Smart Card user can't spend the coins twice, he can let the buyer go with even none confirmation.

For this to happen the user shouldn't know the private key that Smart Card is carrying (it can't be taken from the card on any way). To aproach this, without losing the chance to recover the funds in xase the Smart Card is stolen, the private key need to be created in a vanitygen way, where one carries part of the key and the other keeps the other part, but both are only combined securely inside the card.

For example:

The User purchase the Smart Card from a Issuer. Then in a registration procces the users gets a part of the key and the Issuer the other part, so the Issuer insert his part in the un-configured Smart Card. The Issuer sends the Smart Card to the User's house, he insert his part and the private key is generated securely inside the Smart Card.

The private key never see the light, it is stored securely inside the Smart Card. In case the Smart Card is stolen or destroyed, the User can enter his key part in the Issuer website (encripted/hashed I think), sending a request for the other part to the Issuer, and generate the private key to recover its funds. This process would take 24 hours, so any pending transaction gets confirmed. Any merchant can accept payments this way without havin to wait for any confirmation because he knows that it is not possible to double-spend with that SmartCard.

You mean something like this: https://bitcointalk.org/index.php?topic=190046.0 ? I like the split-key generation idea, however that would require the issuer to remain in business for at least as long as the cards are used. If the keys are generated on the card, the user loses the ability to recover his funds if the card is lost / stolen / destroyed, but the issuer only needs to publish a list of "green addresses" - the ones belonging to the cards that have been issued. That list can be mirrored and re-published by anyone. If the issuer goes out of business, all previously "green" addresses remain "green" forever and cards can still be sold to users, they just won't be listed anywhere so they'll only work as regular Bitcoin addresses, not "green addresses".

The idea is to be sure the buyer will not double spend. If the Issuer dissappear (and is and honest company) they can publish all the key part they have with the addresses associated and then Users will be able to get their priv-key. But I think spending the funds to one address to left the SmartCard in a trash can because the Issuer doesn't existe anymore would be easier.

I don't think the User's addresses need to be listed as "green addresses" if an User pays with one of those SmartCards and the reader is from the comany too, the address can be verified trough an API, or there's no need even for that. That SmartCard will only work with official readers. So the User can pay and go!

--
rdymac

I'm not sure what you mean by "verified through an API"... at the time of the payment, the merchant must ensure that the payment comes from a smartcard that is running the correct software that doesn't leak the private keys or allow double spending. The merchant terminal also needs to be online in order to post the transaction to the Bitcoin network, so verifying the address is just an HTTP call to the "green address" list server (or servers).

Also, the split-key scenario must be very carefully designed to prevent the user from reassembling the private key outside the card. Otherwise the user could simply do the double spend from another device loaded with the reassembled private key.

I think I've read that SmartCards do protect the content on them, I don't think you can take information from them if they are not programmed for that purpose. The Bitcoin Card (that vimeo video on the web) could be an example. I don't know much about those cards.