BY: Anuradha Gupta Manasi Sachdeva

1. CHIP AND PIN IS BROKEN BY: Anuradha Gupta Manasi Sachdeva

2. From the Previous Discussion • Why Cryptosystems Fail …. • Use of wrong threat model. • Unable to deal with the various insider attacks • Lack of public feedback about the cryptosystems and the failures • Reluctance of bureaucrats to admit their failures and learn from them. • Problems with encryption mechanisms.

3. Thinking Inside the Box: System-Level Failures of Tamper Proofing • Smartcard payments depend on the anti-tampering measures in PIN entry devices but it’s not enough to concentrate on the design of anti-tampering features. • Complex systems should have a security architecture document to inform all the participants in the design and evaluation process. • Claims that terminals are ‘Common Criteria Evaluated’ turn out to be almost meaningless; the devices should be ‘Common Criteria Certified’. • Technology alone won’t help in preventing attacks, effective regulatory reforms are also required.

4. E(Europay) M(Mastercard) V(Visa) Protocol • EMV is a protocol used in “Chip and Pin” system like smart card , credit card and debit card. • Began in 1993 and as of 2010, there are more than 730 million EMV compliant chip-based payment cards in use worldwide and 14.5 million EMV point-of-sale terminals have been deployed. • It authenticates both card and cardholder by the combination of cryptographic message authentication code (MAC), digital signature and PIN entry. • The microprocessor chip contains the information needed to use the card for payment, and is protected by various security features. • Chip cards are said to be more secure alternative to traditional magnetic stripe payment cards.

5. Scope of the paper • EMV protocol • Authentication mechanism • Attacks Demonstration • Causes • Solution and Non Solutions • Evidence Problem • Related work • Response of the paper • Conclusion

6. Need of EMV- Flaws in magnetic stripe In magnetic stripe card customer hands their card to the clerk at the point of sale, who "swipes" the card through a magnetic reader which verify the account detail and generate a slip for customer signature, clerk verify the signature with the signature made on the back of the card and transaction take place. Flaws in Magnetic Stripe card • Lost and stolen card • Counterfeit • Duplicate Signature

7. Stolen card. Without the correct PIN being entered, the card will not produce the correct response, and so cannot be used in an on-line Chip & PIN transaction. • Observed PIN. Without the card, a fraudster who knows the PIN will find it difficult to produce a fake card which will compute the correct response. • Stolen card and its PIN observed. Now the fraudster can use the card and PIN to produce a valid response and use it as though he is the rightful owner. The account holder, however, will eventually notice the fraudulent transactions and promptly contact his bank, causing the card to be cancelled. • Observed response. If the fraudster knows the PIN (or persuades the customer to enter it) and gets temporary access to the card, the card will produce correct responses. These response, however, cannot be used later as the challenges from legitimate terminals are meant to be unpredictable.

8. Phases of EMV • Card authentication: The terminal confirms that the card is legitimate through Static Data Authentication (SDA), Dynamic Data Authentication (DDA) and/or Combined Data Authentication (CDA) • Cardholder verification: The terminal confirms that the person presenting the card is the legitimate cardholder (e.g. by PIN) • Transaction authorization: The terminal confirms that the card’s account has adequate funds for the transaction

9. Static Data Authentication • SDA does not require the chip card to be capable of public key cryptographic processing because there is a static cryptogram (called signed static application data) placed onto the chip at the time the card is produced. • This cryptogram is generated using selected Issuer information from the chip and provides a way to ensure that this information is not changed after the card has been provided to the customer. • During a payment transaction, the card provides the signed static application data to the terminal that then performs a public key authentication of the cryptogram. If this is successful, this means the card, and the information on the card, has not been altered since having been issued to the customer.

10. Dynamic Data Authentication • DDA requires the chip card to be capable of public key cryptographic processing because it needs to be able to dynamically generate a unique cryptogram for each transaction. • During a payment transaction, the chip card uses a private key to generate a one time cryptogram that is unique to the transaction for validation at the terminal. • The terminal performs a public key authentication of the dynamic cryptogram, and if this is successful, this means the card, and the information on the card, has not been altered since being issued to the customer, and significantly - that the card is not a copy of the original chip card issued.

11. DDA is better than SDA, then why SDA is still being used???

12. Combined Data Authentication • CDA is similar to DDA with the additional functionality of verifying the authenticity of the card’s application cryptogram, which ensures that the cryptogram has not been corrupted. • As CDA cards are more expensive than comparable DDA cards and provide a level of security that exceeds the requirements of most applications, few issuers have chosen to deploy CDA technology.

13. Card holder verification • Card and terminal decide what CVM they will use for egPIN entry, Digital Signature. Discretion Pin entry Digital Signature No Verification No action Card Terminal Decide method on the basis of the transaction Value like (purchase Cash)

14. Procedure 2. Sending Pin to card Terminal Card If match, send 0x9000 If fail, send 0x63Cx 1. Customer has entered the pin 3.Compare Received Pin with its own Store pin

15. CVM list specifies a set of rules for how terminals should select a cardholder verification method based on: • Terminal capabilities • Attended or unattended terminal • Type (cash, purchase, cashback) Cardholder verification methods are: • PIN •Signature (generally if cardholder cannot remember/enter a PIN) • Nothing (generally for unattended terminals) For PIN verification, the entered PIN is sent to the card encrypted under its public key (DDA) or in the clear (SDA). The card reports success or failure (and decrements the PIN retry counter).

16. Transaction Verification Generate AC Command Card Terminal Issuer Request for ARQC If transaction permit send ARQC(ATC,IAD,MAC) Else AAC Send ARQC MAC (ARC +ARPC) External Command (MAC) Validate received MAC Update its internal state with that issuer authorized transaction Generate AC Command TC TC

17. But do this transition to EMV reallySECURE & RELIABLE???

18. ATTACKMan-in-the-middle attack

19. Central flaw • The PIN verification is never explicitly authenticated. • The authenticated data sent to the bank contains two fields which incorporate information about the result of the cardholder verification – the Terminal Verification Results (TVR) and the Issuer Application Data (IAD). • Essentially what the attack does is to exploit a flaw in the chip and pin system. It makes the terminal think the correct pin has been entered, and the card think the transaction was authorised with a signature. • At the end the receipt says 'verified by pin' by responding with 0x9000 to Verify, without actually sending the PIN to the card. So the bank is going to think the pin is entered directly, but the criminal actually did not know the pin.

20. TERMINAL VERIFICATION RESULTS (TVR) BYTE 3. IAD FORMAT, BYTE 5 Bit Meaning when bit is set 8 Cardholder verification was not successful 7 Unrecognized CVM 6 PIN Try Limit exceeded 5 PIN entry required and PIN pad not present or not working 4 PIN entry required, PIN pad present, but PIN was not entered 3 Online PIN entered 2 Reserved for future use 1 Reserved for future use Bit Meaning when bit is set 4 Issuer Authentication performed and failed 3 Offline PIN performed 2 Offline PIN verification failed 1 Unable to go online

21. The IAD does often indicate whether PIN verification was attempted. However, it is in an issuer-specific proprietary format, and not specified in EMV. • Therefore the terminal, which knows the cardholder verification method chosen, cannot decode it. • The issuer, which can decode the IAD, does not know which cardholder verification method was used, and so cannot use it to prevent the attack. • Because of the ambiguity in the TVR encoding, neither party can identify the inconsistency between the cardholder verification methods they each believe were used. • The issuer will thus believe that the terminal was incapable of soliciting a PIN – an entirely plausible yet inaccurate conclusion.

22. ATTACK DEMONSTRATION • The attack was carried out the attack in one of the cafeterias of University of Cambridge with due permissions. • The team tried out four common cards - two credit cards, issued by HSBC and John Lewis, and two debit cards, issued by Barclays and the Co-operative Bank. • The hardware for the attack was made of cheap off-the-shelf components and required only elementary programming and engineering skills.

23. Hardware Required

24. The man-in-the-middle circuit connects to the terminal through a fake card. This card has thin wires embedded in the plastic substrate, which connect the card’s contact pads to an interface chip for voltage level-shifting. • This is connected to a general-purpose FPGA board that drives the card and converts between the card and PC interfaces. • Through a serial link, the FPGA is connected to a laptop, which is in turn connected to a standard smart card reader from Alcor Micro into which the genuine card is inserted.

26. A stolen card sits in an off-the-shelf card reader, inside a backpack. • This allows it to communicate with a chip, running software written by the team and controlled from a laptop. • All of this is hooked up to a fake card, which slots into the actual shop terminal. The kit would not have to be big - the Cambridge team is already working on miniaturising it all into a unit the size of a remote control. • A Python script running on the laptop relays the transaction while waiting for the • Verify command being sent by the terminal; it then suppresses it to the card, and responds with 0x9000: • if VERIFY_PRE and command[0:4] == "0020": • debug("Spoofing VERIFY response") • return binascii.a2b_hex("9000") • The rest of the communication is unaltered.

27. It is called a "man in the middle" attack because the software is tricking the terminal into thinking the pin has been verified. • At the end the receipt says 'verified by pin' so the bank is going to think the pin is entered directly, but the criminal actually did not know the pin.

28. VIDEO

29. Causes • Protocol design error: it compartmentalizes the issuer specific MAC protocol too distinctly from the negotiation of the cardholder verification method • Misconception of designers: TVR and card verification results primarily as separate lists of possible failures represented by a bit mask, rather than as a report of the authentication protocol run. • There was a closed design process, with no open external review of the architecture and its supporting protocols. • There are also mismatches between acquirer and issuer banks; between banks and suppliers; and between banks and the facilities management firms • The size and complexity of the specification, and its poor structure.

30. “…. Although they have raised a clear security concern with regards to Chip and Pin which we are taking very seriously, the problem highlighted is relevant to all card issuers and not just HSBC.”

31. “…whilst the prevention and detection of course a major priority for Barclays, this is an industry issue and is not specific to any card, provider or bank”

32. “.....this is an industry issue, which is not specific to The Co-operative Bank….. Our chip and pin debit and credit cards are no different to that of any other provider….”

33. What Now?? • Core protocol failures are difficult to fix • None of the already planned security improvements by the bank will help: • Moving from SDA to DDA • Both occur before cardholder verification stage • Further enhancement to CDA

34. Possible Solutions & limitations • Parsing of IAD • Effective for offline and online transactions where CDA is used. • IAD is intended only for issuer and has various different formats, without any reliable method to establish which format was used. • For this bank and terminal vendor has to act together • Look for alternatives that require changes only to the customer cards or to the issuer’s back end systems. • Card can change its CDOL to request that the CMVR be included in the Generate AC command. • This will allow the issuer and the card to identify the inconsistency. • Established design principles for robust security protocols • Industry standard transport layer confidentiality and authenticity standard, such as TLS, could be wrapped around the existing command set. • Regulators should insist that a threat model, security policy and protocol specifications should be published for open review.

35. EMV has discovered flaws which allow criminals to make transaction by using stolen cards without knowing the correct PIN. Issuer refused to refund the customer money on the basis that their records showed the PIN was used. Evidences

36. In 1999 Herreweghan and Wille identified the problem to how to determine if the genuine Verify Command is executed. They suggested that ARQC should only be generated if the Verify Command has been successful. But they neither provide the information that the result of PIN verification should be included in IAD or not nor that the Verify message could be tamper with by that man in middle attack. Related Work

37. In 2005 Anderson showed that how Bank customer phased difficulties in obtaining refund once transaction authorized by PIN. He also demonstrated that how fraud can occur through SDA card use for Offline transaction. The survey showed that 14% of consumers have suffered some kind of financial loss which they believe is through fraud. Relay attack Tamper the Terminal

38. This paper suggested that EMV consortium should publish its plans for fixing the framework. Will they fix the technical issue? 2. Will the high level of consumer protection so far enjoyed by US cardholders be preserved? 3. Will the introduction of the remediated system introduce any systemic risks, because of moral hazard effects?

39. Response of the paper is very positive, respondent agreed that attack works. There is a discord regarding that “Chip and Pin Broken” because some respondent measure the success. Some of them agreed that Chip and Pin Successful because Its reduced the deployment cost. Prevent counterfeit card frauds using the chip. Prevent lost and stolen card frauds by using PIN. Some of respondent argued that attack would not be practically possible because it required bulk of equipment and card can be cancel after found it is stolen. Some of the argued that problem is not significant because system performed various cross check measure. Response

40. Some of the respondent favor EMV protocol as it performs various system checks like : Checking the correspondence between CVMR and IAD. Checking the capabilities of terminals and POS data entry mode against IAD. Some of respondent agreed with the problem but they argued that it was not the fault of EMV or the card scheme specification, but the issuing bank are responsible for frauds.

41. CONCLUSION • Moving from magnetic stripe to Chip and Pin system was premature. • The PIN verification feature of the EMV protocol is flawed. • A lack of authentication on the PIN verification response, coupled with an ambiguity in the encoding of the result of cardholder verification as included in the TVR, allows an attacker with a man-in-the-middle to use a card without the correct PIN. • Many similar related work have been done resulting in similar flaws (on the part of design). Even then no effort has been made in this regard. • Both of the parties who rely on transaction authentication – the merchant and the issuing bank – need to have a full and trustworthy view of the method used to verify the cardholder.

43. GLOSSARY • AAC – (Application Authentication Cryptogram) A cryptogram generated by the card at the end of offline and online declined transactions. It can be used to validate the risk management activities for a given transaction. • ARQC – (Authorization Request Cryptogram) A cryptogram used for a process called Online Card Authentication. This cryptogram is generated by the card for transactions requiring online authorization. It is the result of card, terminal, and transaction data encrypted by a DES key. It is sent to the issuer in the authorization or full financial request. The issuer validates the ARQC to ensure that the card is authentic and card data was not copied from a skimmed card. • ARPC – (Authorization Response Cryptogram) A cryptogram used for a process called Online Issuer Authentication. This cryptogram is the result of the Authorization Request Cryptogram (ARQC) and the issuer’s authorization response encrypted by a DES key. It is sent to the card in the authorization response. The card validates the ARPC to ensure that it is communicating with the valid issuer.

44. CAM – (Card Authentication Method) Validation of the card by the issuer to protect against data manipulation and skimming. Also referred to as Online Card Authentication. See also Authorization Request Cryptogram (ARQC). • CVM – (Cardholder Verification Method) A method used to confirm the identity of a cardholder and to signify cardholder acceptance of a transaction, such as signature, Offline PIN and Online PIN. • DDA – (Dynamic Data Authentication) A type of Offline Data Authentication in which the card uses public key technology to generate a cryptographic value, which includes transaction-specific data elements, that is validated by the terminal to protect against skimming. • EMV – (Europay, MasterCard, Visa Specifications) (EMV) Technical specifications developed jointly by Europay International, MasterCard International and Visa International outlining the interaction between chip cards and terminals/CADs to ensure global interoperability. • MAC – (Message Authentication Code) A digital code generated by passing data through a cryptographic algorithm. A MAC ensures that a message has not been altered during transmission.

45. SDA – (Static Data Authentication) A type of Offline Data Authentication in which the terminal validates a cryptographic value placed on the card during personalization. This validation is similar to CVV and protects against some types of counterfeit fraud, but does not protect against skimming. • TC – (Transaction Certificate) A cryptogram generated by the card at the end of all offline and online approved transactions. The cryptogram is the result of card, terminal, and transaction data encrypted by a DES key. The TC provides information about the actual steps and processes executed by the card, terminal, and merchant during a given transaction and can be used during dispute processing. • TVR- The CVR (Card Verification Results) and TVR (Terminal Verification Results) data elements are two structures which contain a list of checks carried out during the offline authentication stage by the card, in case of the CVR, and by the terminal in case of the TVR.

46. References • EMVCo, “About EMV,” November 2009. [Online]. Available: http://www.emvco.com/about emv.aspx • S. Drimer, S. J. Murdoch, and R. Anderson, “Thinking nside the box: system-level failures of tamper proofing,” in IEEE Symposium on Security and Privacy (Oakland), May 2008, pp. 281–295. [Online]. Available: http://www.cl.cam. ac.uk/∼sd410/papers/ped attacks.pdf • http://www.zdnet.co.uk • http://www.telegraph.co.uk • http://www.bbc.co.uk • http://www.cl.cam.ac.uk • http://cotignac.co.nz • http://www.visa-asia.com