On the „Chip & PIN Broken“ AttackOn the „Chip & PIN Broken“ AttackOn the „Chip & PIN Broken“ AttackOn the „Chip & PIN Broken“ Attack

Experience Gained in RaiffeisenbankExperience Gained in RaiffeisenbankExperience Gained in RaiffeisenbankExperience Gained in Raiffeisenbank

April 14th 2010, Prague

Tomáš RosaTomáš RosaTomáš RosaTomáš Rosa

tomas.rosa@rb.cztomas.rosa@rb.cztomas.rosa@rb.cztomas.rosa@rb.cz

ForewordForewordForewordForeword IIII

� 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

Side / 2

transaction with the chip payment card without knowing

the correct value of the PIN at all.

ForewordForewordForewordForeword IIIIIIII

� 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.

Side / 3

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.

Part OnePart OnePart OnePart One

Side / 4

Part OnePart OnePart OnePart One

Attack RecapitulationAttack RecapitulationAttack RecapitulationAttack Recapitulation

ISO 7816 in EMVISO 7816 in EMVISO 7816 in EMVISO 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

Side / 5

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.

The VERIFY(PIN) CommandThe VERIFY(PIN) CommandThe VERIFY(PIN) CommandThe 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.

Side / 6

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.

Attack Core Illustration of [5]Attack Core Illustration of [5]Attack Core Illustration of [5]Attack Core Illustration of [5]

Side / 7

In the best faith taken from [5].

VERIFY(PIN) WorkaroundVERIFY(PIN) WorkaroundVERIFY(PIN) WorkaroundVERIFY(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

Side / 8

� 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.

Attack AssumptionsAttack AssumptionsAttack AssumptionsAttack 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.

�

Side / 9

� Regarding POS terminal, even on-line authorized

transactions often rely on the PIN being verified off-line!

Typical SituationsTypical SituationsTypical SituationsTypical 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.

Side / 10

� 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!).

Part TwoPart TwoPart TwoPart Two

Side / 11

Part TwoPart TwoPart TwoPart Two

eKit MITM Testing DeviceeKit MITM Testing DeviceeKit MITM Testing DeviceeKit MITM Testing Device

MITM Device MITM Device MITM Device MITM Device –––– eKiteKiteKiteKit

� 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.

Side / 12

� 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.

eKit InternalseKit InternalseKit InternalseKit 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

Side / 13

� 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.

eKit eKit eKit eKit ---- Rx/Tx Core ModuleRx/Tx Core ModuleRx/Tx Core ModuleRx/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,

Side / 14

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.

The MITM C++ ApplicationThe MITM C++ ApplicationThe MITM C++ ApplicationThe 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.

Side / 15

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.

eKit in Action During the TesteKit in Action During the TesteKit in Action During the TesteKit in Action During the Test

original card

MITMMITMMITMMITM

Side / 16

inverse card connector eKit HW core board

original card

Note on Miniaturization of eKitNote on Miniaturization of eKitNote on Miniaturization of eKitNote 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.

Side / 17

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.

eKit Micro Edition PrevieweKit Micro Edition PrevieweKit Micro Edition PrevieweKit 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

Side / 18

� This is just a foto preview, not a real device!This is just a foto preview, not a real device!This is just a foto preview, not a real device!This is just a foto preview, not a real device! Yet…Yet…Yet…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.

SIM clips) interfaced to the hidden

wire

Part ThreePart ThreePart ThreePart Three

Side / 19

Part ThreePart ThreePart ThreePart Three

RBCZ Internal Penetration TestsRBCZ Internal Penetration TestsRBCZ Internal Penetration TestsRBCZ Internal Penetration Tests

ForewordForewordForewordForeword

� 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

Side / 20

� 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.

Test Results of RBCZTest Results of RBCZTest Results of RBCZTest 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.

�

Side / 21

� 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.

Example: POS Terminal BillsExample: POS Terminal BillsExample: POS Terminal BillsExample: POS Terminal Bills

signature

signature

unnecessary

Side / 22

merchant’s billmerchant’s billmerchant’s billmerchant’s bill

signature

unnecessary

customer’s billcustomer’s billcustomer’s billcustomer’s bill

unnecessary

SDA vs. DDA SchemeSDA vs. DDA SchemeSDA vs. DDA SchemeSDA 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

Side / 23

� 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.

Note on CDANote on CDANote on CDANote 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.

Side / 24

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.

Attack ExtensionAttack ExtensionAttack ExtensionAttack Extension

The Case of OffThe Case of OffThe Case of OffThe Case of Off----line PIN Blockedline PIN Blockedline PIN Blockedline PIN Blocked IIII

� 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

Side / 25

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.

The Case of OffThe Case of OffThe Case of OffThe Case of Off----line PIN Blockedline PIN Blockedline PIN Blockedline PIN Blocked IIIIIIII

� 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

Side / 26

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!

Further Attack ExtensionsFurther Attack ExtensionsFurther Attack ExtensionsFurther 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)

Side / 27

command case can be also observed in the EXTERNAL

AUTHENTICATE command.

� This can, in theory, allow an attacker to break the issuer

authentication procedure.

Final RemarksFinal RemarksFinal RemarksFinal Remarks IIII

� 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

Side / 28

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.

Final RemarksFinal RemarksFinal RemarksFinal Remarks IIIIIIII

� 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

Side / 29

does the weak APDU protection affect the security of

emerging RFID payment cards.

� Obviously, the relevant protocol procedures need to be

checked very carefully…

ConclusionConclusionConclusionConclusion

� 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

Side / 30

� 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.

Thank You…Thank You…Thank You…Thank You…

Side / 31

Dr. Tomáš Rosa

Raiffeisenbank, a.s.

tomas.rosa@rb.cz

AcknowledgementAcknowledgementAcknowledgementAcknowledgement

� 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

Side / 32

� Ondřej Pokorný, Security Department of RBCZ

ReferencesReferencesReferencesReferences

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

Side / 33

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