Topic: Bitcoin and Smart Cards (Read 5135 times)

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.

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.

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

You mean something like this: https://bitcointalksearch.org/topic/prevent-double-spend-by-using-smartcard-hardware-wallets-190046 ? 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".

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.

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

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.

How does this go?

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

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.

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.

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.

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

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

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.

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

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.

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

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