Prevent double-spend by using smartcard hardware wallets

[drazvan]

Hello,

I was wondering if anyone with more knowledge of the Bitcoin inner workings thought about preventing double-spends by using a smartcard-based wallet (or signature system) that keeps track of inputs used and prevents the user from double spending. This would obviously mean generating the private key on the smartcard and only using it internally to sign but never exposing it to the outside world (the user would never know his private key).

I wonder if addresses generated this way could be marked in some way to tell merchants that the funds have been spent using a "double-spend preventing wallet on a smartcard", giving them the OK to provide the service/goods immediately, without having to wait for confirmations.

I'm working on such an implementation myself (on a smartcard), but I'm not sure how to approach the "tagging" part. One way (a bit convoluted) would be for each wallet to come with a separate private key that can be used to sign each of the public keys it generates, certifying that they have been generated on-card and not imported. The public key for each smartcard could sit on a server somewhere, allowing anyone to receive the "certificate" together with the payment and verify that the public key is one of the safe ones.

Any ideas?

Razvan

[grue]

Double spending in bitcoin refers to a malicious user attempting to spend the same inputs twice. It's not about your funds being stolen.

[fpgaminer]

Double spending in bitcoin refers to a malicious user attempting to spend the same inputs twice. It's not about your funds being stolen.

I think you misunderstood OP.

One way (a bit convoluted) would be for each wallet to come with a separate private key...

Yeah.  The risks here are:

A) Need to trust third party not to perform double spends themselves.
B) Signing key could be stolen off the smartcard.
C) Users cannot read their own private keys.


C is a real deal-breaker, in my opinion.  A multi-sig address, where one sig comes from a trusted anti-double spend authority, could solve B and C, but still requires trust, and any money sent to such an address could be lost if the authority disappears.

EDIT: To be clear about C, I believe hardware wallets need the option for encrypted backup, in case the wallet becomes lost, damaged, or stolen.  I don't mean to imply the private keys should be exposed unencrypted  Though this isn't as big a deal for a day-to-day wallet where a user only stores small sums of money.

[drazvan]

@grue, I know very well what double spending means. What I'm proposing is a way to make it easier for merchants to accept payments with 0 confirmations (=immediately) by making double spending by a malicious user less likely.

@fpgaminer . Regarding A, the third party is just a signing authority, it cannot spend any funds, it has no access to the private keys. It simply certifies that the private key corresponding to the public key / paying Bitcoin address was generated on the smartcard and that the smartcard actively prevents double spends. Of course, the risk is not entirely 0, as you said there are hardware attacks against smartcards, but the merchant could classify the user as lower risk than a generic user with no restrictions on his keys.

The advantage of doing everything on the card would be that you wouldn't need to rely on any third party for each payment (or there could be multiple third parties / certification authorities, each with its own smartcard type/software, certifying various public keys for 0-confirmation payments). Larger merchants could become their own CAs and issue their own wallets/smartcards that could be used both as "secure wallets" (for sites that accept their certification) and regular Bitcoin wallets (for sites that do not know how to handle the additional information).

LATER EDIT: a third party in a multi-sig scenario doesn't prevent the user from sending one transaction through that third party and immediately doing a double-spend to another destination without going through them. As long as the user has access to his private key, he/she cannot be forced to perform a particular type of transaction (multi-sig, etc). Doing this in the wallet prevents the user from executing any transactions without anti-double-spend verification (they have no choice, the smartcard doesn't sign unless it's satisfied that all the security conditions are met).

[fpgaminer]

Regarding A, the third party is just a signing authority, it cannot spend any funds, it has no access to the private keys.

In A, I point out that a trusted third party can double spend; I didn't say they can access your private keys   Anyone working at the trusted third party with access to the signing key can perform double spend attacks.

a third party in a multi-sig scenario doesn't prevent the user from sending one transaction through that third party and immediately doing a double-spend to another destination without going through them. As long as the user has access to his private key, he/she cannot be forced to perform a particular type of transaction (multi-sig, etc).

The user would send their money, long before any purchases are made, to a multi-sig address to which they have only one of the key-pairs.  The trusted third party has the other key-pair.  When it comes time to send money to a merchant, the user signs the transaction with their key, and then gives the transaction to the third party for the final signature.  The third party will refuse to sign a double spend transaction (this can be determined in a multitude of ways).

Yes, this does require that the third party be constantly involved in transactions.  As I mentioned, though, it allows for user backups, and it makes it less likely that the third party will have its signing key stolen.

[falschgeld]

Here in Germany, we already got an electronic payment system that uses exactly this approach.

You can move funds from your bank account to your Geldkarte. The Geldkarte is a smart card to store money (Euros) on. When you add funds, this transaction will be stored on your Geldkarte. Then, you can go to an OFFLINE vending machine to spend the money. Just insert the card, push a button, wait a second while the Geldkarte creates and signs a transaction that transfers money to the merchant's card. When that's done, you can leave with your product and remove your card. The merchant would later take their merchant's card and move the funds to their bank account.

This system is protected against double-spending by not allowing the user to read the keys from their smart card. So basically, the merchant has to trust the customer's bank not to issue cards that can be used for double-spending. In addittion to that, there are a few more safeguards:
- all cards will expire eventually. If someone manages to hack one card, they can only double-spend with it until it expires.
- the Federal Central Bank maintains shadow accounts for all cards in order to detect any double-spending attempts, even though they should be impossible.
- Funds cannot move freely within the system. They can move from a bank account (or cash) to a Geldkarte. From there, they can only be moved to a merchant's card and from the merchant's card, they can only go to the merchant's bank account. Instead of spending funds, users can also request a refund.

Even though pretty close to everybody here in Germany has a Geldkarte, only few people actually use this system because:
- Nobody bothers to move funds to their Geldkarte
- There are always other payment methods available
- There are only few places that accept Geldkarte payments; Even though it would be possible to accept the Geldkarte in stores and on web sites (card reader and some software required), I have only seen vending machines to accept them.

The Geldkarte has a pretty clear pro - it prevents double-spending without requiring an internet connection. Yet most merchants don't accept it. A large number of merchants uses to process payments by any other payment method, most notably "wild direct debit" - i. e. you authorize your POS payment by signature and it will be processed as a chargeback-prone card-not-present direct debit.

Note that those mechants whom I am talking about always use payment processors and card terminals that would support an online balance check as well as chip&pin. However, they would have to pay surcharges for that which are sometimes just considered to be a bit too expensive; It's cheaper for them to risk a chargeback and transfer the matter to a debt-collection agency when neccessary.

There are also merchants who make a differnece between small and large transactions - small  ones are processed by wild direct debit (it's called "wild" because all banks dislike this payment method because they can't make much money from it - yet all banks offer it to their business customers) while large ones may be processed with chip&pin.

[falschgeld]

You may also want to look at this thread [1] where I suggested to prevent double-spending by requiring several (at least two) signatures on a tranaction. The first would be from the paying party, the others would be from 3rd parties who would just confirm that the transaction is not part of a double-spending scam.

[1] https://bitcointalk.org/index.php?topic=189697.msg196627

[drazvan]

As you said, the problem with involving a third party with each payment is that they could eventually go out of business (or simply have an outage at a certain point in time). If all they do is publish a list of Bitcoin addresses that have double-spend-proof smartcards behind their private keys, they can't lock you out of your own money (by refusing or being unable to sign the transaction when requested). This removes them from a position of power (they can't block your funds or refuse to allow you to spend them for political or legal reasons).

Also, if they ever go out of business, you can still use your smartcard-backed wallet as a regular wallet (it would still sign transactions and they can still be verified as double-spend-proof by anyone that still has the list of public keys they've published). New Bitcoin keys could be added to the wallet (or rather generated by the wallet) and it would then function as a standard Bitcoin wallet since there would be no one to update the public key list (vendor went out of business).

So you don't entrust a third party with your funds and give them the ability to block your transactions. You still have complete control over where and when you pay, you just don't get access to your keys. I suspect that most non-technical users will not care much - as long as they can quickly and easily pay for their transactions. Just like most of them don't memorize credit card numbers or account numbers, all they care is that the transactions go through quickly and without much involvement from their end.

[falschgeld]

If all they do is publish a list of Bitcoin addresses that have double-spend-proof smartcards behind their private keys, they can't lock you out of your own money [...]. This removes them from a position of power [...].

YOu're right about that as long as the smartcard behaves. Did you look at the approach that I suggested in the other thread? I'm proposing an approach that removes the 3rd party out of their position of power without requiring a smartcard.

[drazvan]

I've just read it, sorry. It's a very nice idea and you're right, it doesn't lock your funds (or it does, but for a limited time). I wonder if "lock times" (see https://en.bitcoin.it/wiki/Contracts ) could be used to make your idea work (without requiring a change in the Bitcoin protocol).

The problem I see with all these solutions is that most simpler clients (such as the Android-based wallets) do not understand anything other than simple payments / scripts. I may be wrong but I think even desktop clients may (and currently do) choose to not forward certain transactions if they do not understand the scripts attached to the inputs and outputs. I don't know enough about the current clients to confirm this though.

[Mike Hearn]

Yes, this sort of thing has come up before. It's a great idea but obviously, a fair bit of work to make it happen. Perhaps one day the Trezor or a Trezor-like device could be configured such that it's useful for that kind of thing. The device has to be able to remotely attest that it's not been tampered with and the hardware has to be secure. I believe Trezor is not designe to be physically tamperproof currently ... maybe in a v2, or a competitor.