and do you realize that my attack simply involves making a second transaction, which for all intents and purposes is identical to a normal transaction? until there's a way to prevent the attack, i don't see any point in discussing merchant adoption of an insecure system.
grue, I understand that your attack has relevance to standard smart cards. How much relevance, I'm not sure, since those basically require you to trust the POS terminal regardless.
But I want you to look again at the hardware I'm proposing be used, and to think about the process flow:
- The terminal sends the transaction amount to the smart card.
- The transaction amount is displayed on the smart card.
- The user presses the button on the smart card to verify the amount.
- The smart card creates and signs the transaction.
There is no way to create multiple transactions without consent. There is no way to create transactions with the wrong amount without consent. No sensitive information is transferred to the terminal. All transactions are created on the card itself using Bitcoin keys that never leave the card.
This is a good model for a hardware wallet. It is essentially the same model as the "box with serial port" model that has been discussed in many other threads.
My only objection is that I think that smartcards are a lousy choice for this model. But, in parts of the world where smart card terminals are common, the network effect may very well be more important.