Flaws in EMV (Chip and Pin) Card Security
Steven J. Murdoch and Ross Anderson have a fascinating paper entitled “Security Protocols and Evidence: Where Many Payment Systems Fail” (h/t Bruce Schenier). The paper proposes five principles to guide the design of good security protocols:
Principle 1: Retention and disclosure. Protocols designed for evidence should allow all protocol data and the keys needed to authenticate them to be publicly disclosed, together with full documentation and a chain of custody.
...
Principle 2: Test and debug evidential functionality. When a protocol is designed for use in evidence, the designers should also specify, test and debug the procedures to be followed by police officers, defence lawyers and expert witnesses.
...
Principle 3: Open description of TCB [trusted computing base]. Systems designed to produce evidence must have an open specification, including a concept of operations, a threat model, a security policy, a reference implementation and protection profiles for the evaluation of other implementations.
...
Principle 4: Failure-evidentness. Transaction systems designed to produce evidence must be failure-evident. Thus they must not be designed so that any defeat of the system entails the defeat of the evidence mechanism.
...
Principle 5: Governance of forensic procedures. The forensic procedures for investigating disputed payments must be repeatable and be reviewed regu- larly by independent experts appointed by the regulator. They must have access to all security breach notifications and vulnerability disclosures.
EMV cards violate several of these principles and the authors propose several ideas to improve the evidential characteristics of the system. One idea is a cryptographic audit log of all transactions to be maintained by the card. A forward secure Message Authentication Code (MAC) would prevent a forger from inserting fake transactions in the past even with possession of the current audit key. Similarly, committing a hash chain over all past transactions would mean that a forger with knowledge of the audit key (but not the card itself) cannot insert fake transactions without inducing a discrepancy between the bank server log and the audit log on the genuine card. By putting the card into a forensic mode to retrieve the audit log, a customer would thus be able to demonstrate that the card was not present in a disputed transaction – presumably, the merchant and the bank will be left to figure out how to share the loss.
One of the comments (by mike~acke) on Bruce Schneier’s blog points out that in today’s system, the card holder has to trust the merchant completely: “when you use your card: you are NOT authorizing ONE transaction: you are giving the merchant INDEFINITE UNRESTRICTED access to your account.”. His solution is a very simple though radical idea which simply removes the merchant from the trusted chain. (mike~acke’s comment below is probably easier to understand if you interpret POST to mean merchant and PCI to mean bank though neither identification is completely correct.)
When the customer presents the card it DOES NOT send the customer’s card number to the POST. Instead, the POST will submit an INVOICE to the customer’s card. On customer approval the customer’s card will encrypt the invoice together with authorization for payment to the PCI (Payment Card Industry Card Service Center) for processing and forward the cipher text to the POST. Neither the POST nor the merchant’s computer can read the authorizing message because it is PGP encrypted for the PCI service. Therefore the merchant’s POST must forward the authorizing message cipher text to the PCI service center. On approval the PCI Service Center will return an approval note to the POST and an EFT from the customer’s account to the merchant’s account. The POST will then print the PAID invoice. The customer picks up the merchandise and the transaction is complete. The merchant never knows who the customer was: the merchant never has ANY of the customer’s PII data.
I like this idea and would like to extend the idea even to ATM cards. That way, we will never have to worry about inserting a card into a fake or compromised ATM, because our ATM card would not trust the ATM machine – it would talk directly to the bank server in encrypted messages that the ATM cannot understand. At the end of it all, the bank server would simply send a message to the ATM to dispense the cash.
Updated February 11, 2014 to insert block quotes and ellipses in quote from Murdoch-Anderson paper.
Posted at 10:47 am IST on Tue, 11 Feb 2014 permanent link
Comments