Researchers from Cambridge found a vulnerability in IC cards using EMV, which is used worldwide (with over 730 million cards in circulation) in chip and pin credit/debit cards. Note that the authors claimed that “the protocol is broken”. The details will be published at IEEE Security and Privacy Symposium in May this year, and a working draft is available now.
With this vulnerability, criminals are able to launch Man-In-The-Middle (MITM) attacks easily and use stolen cards without knowing the correct PIN. The attack works for both online and offline transactions on terminals. Fortunately, it can’t work for ATM transactions.
Let’s see how it works. The EMV protocol can be split into three steps:
1 Card authentication – assure which bank issued the card and the data hasn’t been tampered.
1.1 The terminal requests the list of available applications (e.g. card use at shops, ATM functionality, etc.), and selects one of them.
1.2 The terminal reads the information of the card-holder, including card details (e.g. primary account number, start and expiry date), backwards compatibility data, and control parameters for the protocol. Some information is signed by RSA, and the certificate chain is also included in the information.
2 Card-holder verification – assure the PIN entered matches the one stored on the card.
2.1 The terminal sends the inputed PIN to the card for verification.
2.2 If the inputed PIN matches the one stored on the card, 0×9000 is returned to the terminal. Otherwise, 0×63Cx is returned, where ‘x’ is the number of further PIN verification attempts the card allows. Note that the response is NOT directly authenticated.
3 Transaction authorization – assure the bank authorizes the transaction.
3.1 The terminal asks the card to generate a cryptographic MAC over the transaction details, including e.g. the transaction amount, currency, type, a random nonce generated by the terminal, and the terminal verification result. Note that the terminal verification result merely enumerates possible failure conditions, and doesn’t indicate which particular method is used in case of success.
3.2 The card sends back also a sequence counter identifying the transaction, a variable length field containing data generated by the card, and the MAC. The MAC is usually generated using 3DES with a symmetric key shared between the card and the issuer.
3.3 The terminal sends the response to the bank for transaction authorization.
3.4 If the check passes, the bank sends back a two byte long response code, and a MAC over the message sent from the card and the response code.
3.5 The response is forwarded by the terminal to the card. If the card verifies the response from the bank, it updates some internal states to note that the bank authorizes the transaction.
3.6 The terminal asks the card to generate a transaction certification, signifying that it’s authorizing the transaction to proceed. It will be sent to the bank and stored locally for further use.
Due to the above two flaws, the bad boy is able to launch the MITM attack like this:
1) It hijacks the communication in step 2, sending 0×9000 to the terminal to fool it into believing the PIN verification succeeds.
2) As the PIN is never sent to the card, it will be fooled into believing the terminal doesn’t support PIN verification, and the PIN retry counter is not modified.
3) As the terminal verification result doesn’t tell the particular method used, the terminal believes the PIN verification succeeds and the card believes the PIN verification is not attempted.
4) The variable length field containing data generated by the card generated in step 3.2 is issuer-specific, and not specified in EMV. Therefore, the terminal can’t decode it, and the issuing bank doesn’t know which card-holder verification scheme is used.
Also, the researchers found that EMV failed to provide adequate evidence to produce in dispute resolution and litigation, among other issues. And we should be aware that this vulnerability is not implementation-specific, but the fundamental protocol is broken!
21.2.10
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment