• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Zranitelnost čipových platebních karet jako příklad on-line hrozby - Tomáš Rosa (bezpečnostní specialista, Raiffeisenbank)

Zranitelnost čipových platebních karet jako příklad on-line hrozby - Tomáš Rosa (bezpečnostní specialista, Raiffeisenbank)






Total Views
Views on SlideShare
Embed Views



2 Embeds 12

http://www.slideshare.net 10
http://tuesday.cz 2



Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment

    Zranitelnost čipových platebních karet jako příklad on-line hrozby - Tomáš Rosa (bezpečnostní specialista, Raiffeisenbank) Zranitelnost čipových platebních karet jako příklad on-line hrozby - Tomáš Rosa (bezpečnostní specialista, Raiffeisenbank) Presentation Transcript

    • On the „Chip & PIN Broken“ Attack Experience Gained in Raiffeisenbank Tomáš Rosa tomas.rosa@rb.cz April 14th 2010, Prague
    • Foreword I In February 11th 2010, Steven J. Murdoch (a member of the prof. Anderson’s team at Cambridge) published a draft of his paper “Chip and PIN is Broken” [5]. The paper shows on how to make a PIN-based transaction with the chip payment card without knowing the correct value of the PIN at all. Side / 2
    • Foreword II The objective of the attack is the EMV protocol implementation, mainly in the Point of Sale (POS) terminals. It is a Man-in-the-Middle (MITM) attack assuming the attacker is controlling the ISO 7816 communication in between the terminal device (e.g. the POS) and the chip payment card. Actually, it focuses on certain risky part of the EMV protocol which is likely to be implemented in a wrong way. Side / 3
    • Part One Attack Recapitulation Side / 4
    • ISO 7816 in EMV There is a weak protection of the ISO 7816 interface in between the payment card and the terminal (e.g. the POS). Only certain parts of certain APDU messages are cryptographically protected. The attacker can spy/modify/insert messages in this channel relatively easily, provided she has a suitable HW equipment allowing her to play the role of MITM. Side / 5
    • The VERIFY(PIN) Command This is the EMV core command used for off-line PIN verification. The terminal (e.g. the POS) provides a PIN value to the chip card. The card returns OK/FAIL message basing on whether the value presented is correct or not. The PIN value being sent to the card can be encrypted (DDA/CDA type cards), but the card response is neither encrypted nor integrity protected. Side / 6
    • Attack Core Illustration of [5] In the best faith taken from [5]. Side / 7
    • VERIFY(PIN) Workaround What the terminal could do, is to cross-verify the VERIFY(PIN) result with the value of the usually available CVR (Card Verification Result). CVR is a cryptographically protected vector which the card (usually) returns in response to the GENERATE AC command. Among others, CVR recaps whether the card “saw” the PIN and whether it was correct or not. Well, generally, the CVR can be missing or even not protected by AC. This (rare) case, is NOT a reason of omitting the cross-check in general. Unfortunately, this obvious(!) workaround is probably seldom implemented in practice. Side / 8
    • Attack Assumptions The attack can be used whenever off-line PIN verification occurs. It is necessary to distinguish in between the off-line PIN verification and off-line transaction authorization. Regarding POS terminal, even on-line authorized transactions often rely on the PIN being verified off-line! Side / 9
    • Typical Situations The attack typically applies to: POS terminal with either off-line as well as on-line authorization. The attack typically does not apply to: ATM terminal, since it often performs on-line PIN verification. CAP/DPA, since it relies on explicit CVR cross-check. Anyway, the particular situations must be verified case-by-case. The indication is the off-line PIN verification (not to be confused with off-line authorization!). Side / 10
    • Part Two eKit MITM Testing Device Side / 11
    • MITM Device – eKit To verify the attack, we first needed to get a device allowing MITM scenario attack for the ISO 7816 interface card protocol. Commercially available laboratory devices cost thousands of Euros. Academic devices assume cooperation of several students during their term projects. Since our budget and time is very limited, we decided to build our own (limited) device. It is a „less than100 EUR/less than 2 weeks“ breadboard construction called eKit. Side / 12
    • eKit Internals The main parts of the eKit are: HW Rx/Tx core module Redirects the ISO 7816 communication flow through the PC connected via two full speed USB ports. One USB port serves the terminal side, the other one serves the payment chip card. PC running Win32 API console application written in C++ Monitors the communication and performs the MITM (Man-in-the- Middle) action when trigger condition occurs. Side / 13
    • eKit - Rx/Tx Core Module The HW core module consists of: I/O line amplifiers/decouplers for a smooth attachment to the communication traffic with analog bypass multiplexer (to allow monitoring in a purely passive way), bus conversion logic in between the single-wire protocol of ISO 7816 and Rx/Tx serial line, programmable USB interface based on FT232R providing, among others, excellent etu timing accuracy due to its rational clock divider, fast ATR reply circuit based on the FT232R natural handshake procedures; it allows us to e.g. disable boosting the communication speed over 14 kbps. Side / 14
    • The MITM C++ Application Implements the original attack of [5] with just a few extensions. These are necessary, mostly since we are operating on the link rather than the application layer of the ISO 7816 protocol. We have to solve, for instance, resynchronization of T=1 protocol packet stream, etc. Another extension is the GET DATA(9F17) forgery described bellow in the part discussing the off-line PIN verification being blocked case. Side / 15
    • eKit in Action During the Test MITM original card inverse card connector eKit HW core board Side / 16
    • Note on Miniaturization of eKit At first, miniaturization was not a design criterion. Actually, there is no such requirement regarding cooperation with a collusive merchant at all. Regarding placing a fraudulent transaction in a common place, the whole setup can be redesigned to fit into an adult palm easily. Instead of PC, the MITM role will be played by a single chip microcontroller. The AT91SAM7Sx family of ARMs seems to be the right choice, since, among others, they provide the rational clock divider necessary for the smooth adoption to the frequency dictated by the POS terminal. Of course, there is also a reliable GNU development tool chain for them. Side / 17
    • eKit Micro Edition Preview pure contact fields with the former chip stripped off hidden – thin enameled wire connection original payment chip driven by a microcontroller (mounted bellow the SIM clips) interfaced to the hidden wire This is just a foto preview, not a real device! Yet… However, this kind of device should be achievable rather easily. It should be much easier than building an ATM/POS skimming device. The original payment chip card is prepared in the GSM SIM-style and then housed in the standard SIM connector. This can be done in just a few seconds. Side / 18
    • Part Three RBCZ Internal Penetration Tests Side / 19
    • Foreword The tests we are referring to in the next slides were done more than one month ago. Since that time, the banks in CZ have been informed and started preparing their internal countermeasures accordingly. Although these cannot be derived directly from the EMV standard, there already are several possibilities on how to detect/stop this attack even at the issuer’s side. Therefore, it is reasonable to expect the attack is not such an acute threat in the time of reading these slides. Side / 20
    • Test Results of RBCZ Since March 10th 2010, we have used the eKit to test several real-life payment card systems. We have tried to make a fraudulent transaction using certain POS terminal with several different chip payment cards issued by banks in CZ, SK, and AT. We have always used a faked incorrect value of PIN “1234”. Except one card, all these transactions were 100 percent successful. The exceptional card (MC/Maestro) had some countermeasure applied on the issuer’s side. Side / 21
    • Example: POS Terminal Bills signature signature unnecessary unnecessary merchant’s bill customer’s bill Side / 22
    • SDA vs. DDA Scheme In general, DDA scheme should offer higher protection than SDA scheme. DDA stands for Dynamic Data Authentication SDA stands for Static Data Authentication However, in this case, DDA does not prevent this attack in any way! Recall that the PIN being sent to the card is encrypted in DDA, but the response of the card is still NOT protected in any way. We have already made fraudulent transactions with DDA cards without any problem. Side / 23
    • Note on CDA CDA stands for Combined DDA and Application Cryptogram Generation. It offers even higher protection than DDA. It, for instance, allows the terminal to check the integrity of CVR locally without online cooperation with the issuer. Regarding this attack, however, it still does not introduce any direct implicit countermeasure. Therefore, the attack still applies, provided the terminal developer failed to foresee the attack and apply the CVR cross-check accordingly. Side / 24
    • Attack Extension Off- The Case of Off-line PIN Blocked I During ongoing tests, we have also met a payment cards with PIN Try Counter set to 0. This actually means, that off-line PIN verification was blocked. Note it seems to be the only “legal” way on how to block offline PIN, since for a majority of cards the associations require offline PIN to be in the CVM list. We have been informed, that the cards: support the PIN-change functionality, are working correctly in POS transactions. Side / 25
    • Off- The Case of Off-line PIN Blocked II We have tried the following: We extended the former MITM attack to forge the value of the PIN Try Counter, too. In particular, we have also faked the reply to the GET DATA(9F17) command. We pretended PIN Try Counter = 3 to the POS. Under such an extension, we were able to make a successful fraudulent transaction again! Side / 26
    • Further Attack Extensions The weak protection of the ISO 7816 communication in between the terminal and the chip payment card can have much broader impact on security in the future. For instance, a vulnerability similar to the VERIFY(PIN) command case can be also observed in the EXTERNAL AUTHENTICATE command. This can, in theory, allow an attacker to break the issuer authentication procedure. Side / 27
    • Final Remarks I Is it an attack on the whole EMV protocol? Well, the missing protection of VERIFY(PIN) is such obvious, so it can hardly be assumed as a surprising, yet undetected vulnerability. On the other hand, the EMV standard documentation is horrible reading. It often leaves a notion that “this and that is for sure solved somewhere else in the standard” while giving absolutely no idea of how exactly those things work. In this viewpoint, it is an attack on the whole EMV, since EMV failed to provide clear and concise description of the card management and operation processes resulting e.g. into omitting cross-checks of the VERIFY(PIN) status. Side / 28
    • Final Remarks II We emphasize that even the contactless smartcards according to ISO 14443 rely on the same ISO 7816 APDU framework. It is, therefore, an interesting open question on how far does the weak APDU protection affect the security of emerging RFID payment cards. Obviously, the relevant protocol procedures need to be checked very carefully… Side / 29
    • Conclusion The “Chip & PIN Broken” attack is there and it is highly dangerous. Despite many “experts” not understanding it and the payment card associations even downplaying it. It must be taken as seriously as e.g. the skimming attacks. Our contribution: We have verified the attack can be mounted with a moderate skills in electrical engineering. The effort is much less than what can be estimated basing on the rather complex setup used by the researchers in Cambridge. We have successfully extended the attack for certain “off-line PIN blocked” situations. We warn about the EXTERNAL AUTHENTICATE command. We argue to check the RFID payment cards as well. Side / 30
    • Thank You… Dr. Tomáš Rosa Raiffeisenbank, a.s. tomas.rosa@rb.cz Side / 31
    • Acknowledgement Tomáš Hajm, Card Operations of RBCZ Tomáš Jabůrek, Head of IT Delivery and Support of RBCZ Radek Komanický, Head of Information Security of RBCZ Petr Novák, Card Operations of RBCZ Ondřej Pokorný, Security Department of RBCZ Side / 32
    • References 1. EMV Integrated Circuit Card Specification for Payment Systems, Book 1 – Application Independent ICC to Terminal Interface Requirements, version 4.1, May 2004 2. EMV Integrated Circuit Card Specification for Payment Systems, Book 2 – Security and Key Management, version 4.1, May 2004 3. EMV Integrated Circuit Card Specification for Payment Systems, Book 3 – Application Specification, version 4.1, May 2004 4. EMV Integrated Circuit Card Specification for Payment Systems, Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements, version 4.1, May 2004 5. Murdoch S.-J., Drimer, S., Anderson, R., and Bond, M.: Chip and PIN is Broken, to appear at the 2010 IEEE Symposium on Security and Privacy, draft available at http://www.cl.cam.ac.uk/~sjm217/papers/oakland10chipbroken.pdf 6. Detecting Potential Fraud, VISA Member Letter VE 13/10, March 9th 2010 Side / 33