Security Analysis of EMV Protocol and Approaches for Strengthening It

  • Khedkar Shrikrishna
  • N. V. Narendra Kumar
  • R. K. Shyamasundar
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 10722)


Reliance on smart cards for our daily lives makes their security essential. Credit card fraud has been a major hassle for electronic commerce over the past few years. A worldwide standard for payment has been introduced by Europay, Mastercard, and Visa (EMV) with the objective of limiting the card payment frauds. The EMV standard has two main pillars, card authentication (chip) - counters skimming and counterfeiting frauds, and cardholder verification (PIN) - counters stolen or lost cards fraud. Today EMV (aka Chip-and-PIN) is the leading system for the card payments worldwide with more than 4.8 billion cards. Although EMV cards are widely adopted around the world, it is still amenable to attacks as our analysis reveals.

In this paper, we present an approach for analyzing the security of the EMV protocol using a novel information security model called the Readers-Writers Flow Model (RWFM) that explicitly captures the intentions of the protocol designer. An assessment of security of the EMV protocol by the approach automatically reveals several attacks on the EMV protocol presented in the literature, and provides implementation guidelines for realizing a secure EMV protocol w.r.t different threat models. It is experimentally illustrated that most of these attacks are overcome by using a RWFM wrapper in a prototype implementation following the guidelines. Efficacy of the approach is demonstrated by successfully preventing the software simulation of the “No-PIN” attack.


EMV Chip-and-PIN cards Secure information-flow Payment protocols 

1 Introduction

For quite some time, we had been using the magnetic stripe card. Whenever the magnetic stripe cards is swiped in the terminal, it captures all the data contained in the card for processing. However, by inserting simple hardware between the card and the terminal, one can easily clone the magnetic stripe card by copying its data. Thus, magnetic stripe cards are unsafe. To overcome these problems, cards containing microprocessors capable of performing simple computations have been introduced.

EMV1 or chip-and-PIN is a standard for communication between chip supported cards and terminals. EMV contact cards have been introduced to reduce the damages due to exponential growth in skimming attacks on the magnetic stripe cards. Chip cards use fixed commands to communicate with the terminal. In EMV, chip prevents the attacker from card counterfeiting, and PIN prevents him from using lost or stolen cards. EMV card contains a chip as well as a magnetic stripe for backward compatibility.

EMV chip cards are considered more secure than the magnetic stripe cards. However, the chip cards are proven to be vulnerable to some attacks, such as transaction can be performed without the knowledge of the PIN [14], cloning the card with pre-play attack [5], the relay attack [8] etc. Further, in the EMV protocol, most of the data exchanged between the card and the terminal is in plaintext, which enables an attacker to easily collect data for performing online-usage attacks, or cloning magnetic stripe cards. Recently in October 2015, an organised hacker group from France realized the no-PIN attack with almost invisible hardware [13].

Several researchers have formally analyzed the EMV protocol [1, 5, 8, 14, 20, 21] and demonstrated that it is prone to attacks. Some of these researchers have also suggested modifications to the protocol for overcoming the specific attacks they have identified. Our goal has been to assess the possibility of protecting the chip card based transactions without deviating from the protocol structure very much. Towards this end, we labelled (using RWFM model [15, 17]) the initial data involved in the transaction, and used the RWFM model for automatically deriving the labels of the messages being exchanged between the various parties in the transaction.

This labelled protocol clearly identifies the owner, permissible readers and influencers of information, thus, enabling us to analyze its security w.r.t different threat models by tracking the confidentiality, integrity as well as subject authorities. For example, the label of the PDOL data sent by card to the terminal is \((C,\{C,B,T\},\{C,B,T\})\), clearly suggesting that the card has created it, and only the card, bank and the terminal can read it. Our analysis immediately identifies that exchanging data in plain text (this is the case as per the EMV protocol) ensures security only in the case where the terminal is trusted to be free of malware (software and/or hardware like skimmers). From another perspective, the terminal also needs to authenticate the card involved in the transaction. Thus, our approach presents a practical model which provides implementations tuned to different threat models. Further, the labelled transaction thus derived also adheres to several principles for good protocol design like the principle of full information [22] and canonical intensional specification [19].

Main contributions of the paper include:
  • a novel general approach to analyze the security of the EMV protocol,

  • implementation of EMV protocol through our approach that prevents the “No-PIN” attack, and

  • general recommendations to be followed for realizing secure EMV transactions w.r.t different threat models, since the EMV protocol is here to stay. Note that our approach is general and applies to other protocols also equally well.

The rest of the paper is organized as follows: Sect. 2 presents an overview of the EMV and the RWFM model. In Sects. 3 and 4, we present our approach, its advantages and an implementation. Section 5 discusses the comparison of our approach with some relevant literature, and Sect. 6 provides concluding remarks.

2 Background

In this section, we present an overview of the EMV transaction2 and the information security model Readers-Writers Flow Model (RWFM).

2.1 Flow of EMV Transaction

Each successful transaction of EMV contact card has four phases: initialization, card authentication, cardholder verification and transaction authorization.

Initialization phase. The goal of this phase is that the right application is selected and that all mandatory information is exchanged from card to terminal to determine how to proceed with the further steps.

The protocol starts by selecting the payment applications supported by cards such as credit or debit or ATM. The card provides the supported payment applications to the terminal and optionally provides Processing Options Data Object list (PDOL), that specifies the data which card wants from the terminal for subsequent phases.

The card then also provides its Application Interchange Profile (AIP) and the Application File Locator (AFL) [21]. AIP indicates the card supported features for card authentication and cardholder verification. AFL is a list of files which are used for currently selected application.

Card Authentication Methods (CAM). The goal of this phase is that the card authenticates its genuineness and which bank issued the card to the terminal. EMV has three different card authentication methods: Static Data Authentication (SDA), Dynamic Data Authentication (DDA), and Combined Data Authentication (CDA). CDA always has the highest priority, followed DDA and finally SDA. The method that is supported by both the terminal and the card with the highest priority is selected. In this phase, only the card is authenticated to the terminal but the terminal is not authenticated to the card.

Cardholder Verification Methods (CVM). The goal of this phase is to verify the identity of the cardholder, so that stolen or lost cards cannot be easily used. The terminal chooses which CVM to use based on the CVM rules provided by the card. Cardholder verification methods supported by EMV are:
  1. 1.

    Online PIN: bank checks the PIN.

  2. 2.

    Offline plaintext PIN: chip card checks the PIN transmitted in clear.

  3. 3.

    Offline encrypted PIN: chip card checks the PIN sent in encrypted form.

  4. 4.

    Handwritten signature.

  5. 5.


Transaction Authorization. For a transaction, the card generates one or two cryptograms, one in the case of an offline transaction and two in the case of an online transaction.
  1. 1.

    In an offline transaction the card provides a proof (Transaction Certificate (TC)) to the terminal that a transaction took place, which the terminal sends to the issuer later.

  2. 2.

    In an online transaction the card first provides an Authorisation Request Cryptogram (ARQC) which the terminal forwards to the issuer for approval. If the card receives approval, the card then provides a Transaction Certificate (TC) as a proof that the transaction has been completed.


Complete details on the EMV standard and its transaction flow can be found in [9, 10, 11, 12].

2.2 Readers-Writers Flow Model (RWFM)

The Readers-Writers Flow Model (RWFM) proposed in [15, 16] is a novel model for information flow control. RWFM is obtained by recasting the Denning’s label model [7], and has a label structure that: (i) explicitly captures the readers and writers of information, (ii) makes the semantics of labels explicit, and (iii) immediately provides an intuition for its position in the lattice flow policy.

Recasting Procedure. Given a Denning’s lattice model \(DFM = (S,O,SC,\oplus ,\leqslant )\) with flow policy \(\lambda : S \cup O \rightarrow SC\), we recast the labels in terms of the readers and writers to obtain an equivalent flow policy defined by \(DFM_1 = (S,O,SC_1,\oplus _1,\leqslant _1)\) and \(\lambda _1: S \cup O \rightarrow SC_1\), where: (i) \(SC_1 = 2^S\times 2^S\), (ii) \(\oplus _1 = (\cap ,\cup )\), (iii) \(\leqslant _1 = (\supseteq ,\subseteq )\), and (iv) \(\lambda _1(e) = (\{s \in S\) | \(\lambda (e)\leqslant \lambda (s)\},\{s \in S\) | \(\lambda (s)\leqslant \lambda (e)\})\), where e is a subject or object.

RWFM is obtained by generalizing the above recasting procedure, and is defined as follows:

Definition 1

(Readers-Writers Flow Model (RWFM)). Readers-writers flow model is defined as the eight tuple \((S,O,SC,\leqslant ,\oplus ,\otimes ,\top ,\bot )\), where
  • S and O are the set of subjects and objects in the system,

  • \(SC=S\times 2^S\times 2^S\) is the set of labels,

  • \(\leqslant =(-,\supseteq ,\subseteq )\) is the permissible flows ordering,

  • \(\oplus =(-,\cap ,\cup )\) and \(\otimes =(-,\cup ,\cap )\) are the join and meet operators respectively, and

  • \(\top =(-,\emptyset ,S)\) and \(\bot =(-,S,\emptyset )\) are respectively the maximum and minimum elements in the lattice.

The first component of a security label in RWFM is to be interpreted as the owner of information, the second component as the set of readers, and the third component as the set of influencers. Note that RWFM is fully defined in terms of S, the set of subjects in the information system.

Note that the first component in the label is introduced only to facilitate limited discretionary flows (downgrades), and has no impact on the permissible information flows, or joins and meets. Therefore, we have abused notation in the above definition for simplicity, by uniformly blanking out the first component of the label.

Note that in RWFM information flows upwards in the lattice as readers decrease and writers increase.

Property of the recasting procedure: RWFM is a complete model, w.r.t Denning’s lattice model, for studying information flows in a system.

The recasting procedure presented at the beginning of this section actually constructs such an equivalent RWFM policy for a given Denning’s policy.

RWFM Semantics of Secure Information Flow. RWFM provides a state transition semantics of secure information flow, which presents significant advantages and preserves useful invariants that aid in establishing that the system is secure or not misusing information. In the following, we present the RWFM semantics.

Let S denote the set of all the subjects in the system. RWFM follows a floating-label approach for subjects, with labels \((s,S, \{s\})\) and \((s,\{s\},S)\) denoting the “default label” - the label below which a subject cannot write, and “clearance” - the label above which a subject cannot read, for a subject s respectively. Object labels are fixed and are provided by the desired policy at the time of their creation.

Definition 2

(State of Information System). State of an information system is defined as the set of current subjects and objects in the system together with their current labels.

Next, we describe the permissible state transitions of an information system, considering the primitive operations that cause information flows. The operations that are of interest are: (i) subject reads an object, (ii) subject writes an object, (iii) subject downgrades an object, and (iv) subject creates a new object. We believe that these operations are complete for studying information flows in a system. Note that we consider the set of subjects as fixed, and hence no operations for creation of new subjects.

For each of the above operations, we describe the conditions under which it is safe (causes only permissible information flows) and hence can be permitted. Note that when a subject s requests a new session, system assigns \((s,S,\{s\})\) as its label.

Intuitively, downgrading is allowed only by the owner at the same label as the information being downgraded, and (i) unrestricted addition of readers if he is the only influencer of information, or (ii) additional readers restricted to the set of stakeholders that contributed to the computation.

CREATE Rule Subject s labelled \((s_1,R_1,W_1)\) requests to create an object o.

Create a new object o, label it as \((s_1,R_1,W_1)\) and add it to the set of objects O.

Given an initial set of objects on a lattice, the above transition system accurately computes the labels for the newly created information at various stages of the transaction/workflow.

The transition system above satisfies the following invariants that are handy to establish flow security:
  1. 1.

    subject and object labels float upwards only,

  2. 2.

    for a subject s, \(A(s)=s\), \(s\in R(s)\), and \(s\in W(s)\),

  3. 3.

    the set of writers of information is always accurately maintained (exactly the set of subjects that influenced the information content), this plays a vital role in forensics and audit,

  4. 4.

    label of newly created objects precisely reflects the circumstances under which they are created, and

  5. 5.

    downgrade rule is within the boundaries of the flows permissible under a given transaction.


3 RWFM Dynamic Labelling for EMV Transactions

In this section, we describe the EMV protocol for a specific choice of parameters, label the initial data in the protocol, derive the complete labelled protocol using the initial labels, and discuss the security properties implied by the labels.

3.1 EMV Protocol

We describe the EMV protocol where static data authentication (SDA), offline plaintext PIN verification, and online transaction authorization are the chosen methods. Note that, in SDA the terminal authenticates the card using the data received in the initialization phase. Therefore, in the protocol given below, there will not be any messages in the card authentication phase.


\(M_1\)       T \(\rightarrow \) C : Select application

\(M_2\)       C \(\rightarrow \) T : PDOL

\(M_3\)       T \(\rightarrow \) C : Get Processing Options

\(M_4\)       C \(\rightarrow \) T : AIP, AFL

Cardholder verification

\(M_5\)       T \(\rightarrow \) U : Get PIN

\(M_6\)       U \(\rightarrow \) T : Enters PIN

\(M_7\)       T \(\rightarrow \) C : PIN verify

\(M_8\)       C \(\rightarrow \) T : PIN correct

Transaction authorization

\(M_9\)       T \(\rightarrow \) C : N\(_t\)

\(M_{10}\)      C \(\rightarrow \) T : ARQC=(ATC,IAD,MAC(N\(_t\),ATC,IAD))

\(M_{11}\)      T \(\rightarrow \) B : N\(_t\), ARQC

\(M_{12}\)      B \(\rightarrow \) T : ARC, ARPC

\(M_{13}\)      T \(\rightarrow \) C : ARC, ARPC

\(M_{14}\)      C \(\rightarrow \) T : TC=(ATC,IAD,MAC(ARC,N\(_t\),ATC,IAD))

\(M_{15}\)      T \(\rightarrow \) B : TC

For simplicity, we assume that all the records needed by the terminal are included in \(M_4\) itself. In particular, the CVM list is a part of \(M_4\).

3.2 Labelled EMV Protocol

Generally, in any protocol, when a step of the form “\(X\rightarrow Y : M\)” is specified, it intends to capture the following:
  • Initial data and their intended usage i.e., which principals can access/modify which data.

  • Principal X constructed the message M from his current knowledge, for the purpose of sharing it with Y.

  • It is intended that M can be read by Y only.

  • If a component of M appears in a subsequent step in the protocol, it is intended that it is also readable by the receiver in the step.

  • When Y receives the message, he must be able to authenticate that the message is indeed constructed and sent by the intended party (X), and is in the form specified by the protocol.

  • Y should not use the message M or its components, in the current session or in any other session, in ways other than those specified by the protocol.

Based on the discussion above, intentions for the EMV protocol can be derived systematically. For example, \(M_4\) is to be interpreted as saying: when the card sends processing options to the terminal, it is for the use of the terminal only and it is to be used in this session only. The terminal is not supposed to retain these details and use them later.

Now, we derive labels for EMV protocol described in the previous section, to capture the protocol designers’ intentions automatically from the initial set of subjects and objects together with their respective labels. In the EMV protocol, there are 4 subjects, namely, the bank (B), user (U), card (C) and the terminal (T). Initial objects in the EMV protocol are: PDOL, AIP, AFL, PIN, ATC, IAD, and the shared key (SK) between the card and the bank.

Initial state of the system

PDOL\(^{(B,\{B,C\},\{B\})}\), AIP\(^{(B,\{B,C\},\{B\})}\), AFL\(^{(B,\{B,C\},\{B\})}\), PIN\(^{(C,\{B,C\}, \{B,C,U\})}\), ATC\(^{(C,\{C\},\{C,U\})}\), IAD\(^{(C,\{C\},\{C\})}\), SK\(^{(B,\{B,C\},\{B\})}\), C\(^{(C,\{B,C,T,U\},\{C\})}\), B\(^{(B,\{B,C,T,U\},\{B\})}\), T\(^{(T,\{B,C,T,U\},\{T\})}\), U\(^{(U,\{B,C,T,U\},\{U\})}\).

PDOL, AIP, AFL, and SK are created by the bank and stored on the card at the time of its’ issue. Therefore, they have the label \((B,\{B,C\},\{B\})\) indicating that they have been created by the bank, readable only by the bank and the card, and influenced only by the bank. PIN is readable only by the bank and the card, and has been influenced by bank, card and the user. Note that this is so because when a user changes his PIN, he influences the PIN, also because the bank has to authenticate the user before a PIN change, it would have influenced, and finally the card stores the PIN in an encrypted form, so it also influences the PIN. Similarly, the labels for the other initial objects can be understood.

In addition to the EMV protocol described above, we consider a message \(M_0\) at the very beginning, where the user inserts the card into the terminal. Labelled EMV protocol is depicted in Fig. 1.
Fig. 1.

Labelled EMV protocol

Information-flow diagrams (IFD) provide a visual representation of the state transitions in the labelled protocol, and serve as simple yet fully formal models of the labelled protocol. IFD for a portion of the EMV transaction where the terminal gets the PIN verified by the card is depicted in Fig. 2.
Fig. 2.

Information-flow diagram for a portion of the EMV protocol

In Fig. 2, we have only represented those subjects and objects in the initial state that are of relevance to the portion of the transaction for which the IFD is provided. Changes to the state after each transition are highlighted in bold. In the last state, T is highlighted in the readers set of \(M_8\) to depict that the object has been successfully downgraded.

The labelled EMV protocol and the IFD derived above explicitly specify the security requirements of each of the messages exchanged in the protocol.

Security Properties Implied by the Labelling. Consider the message \(M_4\) in which the card provides its preferences to the terminal. Label of \(M_4\) specifies the following security requirements: (i) authenticity: it is generated by the card, (ii) confidentiality: it can only be read by the bank, and the card, and (iii) integrity: it has been influenced only by the stakeholders of the computation. However, note that the terminal should also be able to read this message for the proper working of the protocol. Therefore the card downgrades the message and adds T as a reader - this is allowed in RWFM because T has influenced the message.

Similar interpretations also hold for the other messages of the protocol like cardholder verification (\(M_8\)) and transaction authorization (\(M_{10}\)). A security assessment of the EMV protocol based on the security properties specified by the labels reveals several potential security issues in it.

Security Interpretation/Assessment of EMV Protocol based on the Labelling
  • [Cloning] In the EMV protocol most of the messages are exchanged in plain text - no constraint on readers. Therefore, any subject in the system can read these messages, not only the intended recipient. This leads to the possibility of cloning the card if an attacker captures the necessary information. This attack has been demonstrated in [2].

  • [Replay/Modifications] Since the messages exchanged are in plaintext, the recipient has no guarantee that the message has been generated and sent by the intended sender. This leads to the possibility of an attacker either modifying certain contents of a message or replaying an old message that he had captured. Replay attack has been demonstrated in [6]. CVM downgrade attack [2] where the terminal is forced to choose offline PIN verification, the Chip-and-PIN is broken attack [14] where the PIN correct command is sent by the attacker, and the relay attack [8] where the attacker is relaying messages from a fake terminal are examples of attacks realized by modifying the transmitted message. The Chip-and-skim attack [5] in which an attacker captures a transaction certificate (TC) for a pre-selected random number and uses it for authorizing another transaction involves both replaying the TC, and modifying the random number in the message.

This information in combination with the threat model and trust specifications aids in identifying suitable mechanisms for realizing the desired security.

Implementation Guidelines
  • If the terminal cannot be fully trusted (could be infected with malware and/or contains skimmers), then the labels immediately suggest that messages need to be encrypted for preserving security.

  • When the messages are decrypted by the terminal for processing, temporary data stored on its RAM also needs to be protected from unwanted access and modifications. This can be easily ensured by implementing an RWFM monitor because the intermediate data gets labelled automatically.

  • The decision of whether (and how) to respond to a message received is very much dependant on the current state of the receiver. Labels provide a coarse-grained notion of state, which becomes important in deciding further actions.

Thus, our approach provides a general unified technique to specify, analyze/assess, and derive implementations tuned to different threat models assuring truly end-to-end security for the EMV protocol.

4 Implementation of EMV via RWFM and Assessment of Its’ Security

To validate our approach, we have implemented a RWFM wrapper on the software implementation3 of EMV terminal. In this section, we discuss the software simulation of the Chip-and-PIN is broken attack [14], and its prevention.

4.1 Simulation of the “Chip-and-PIN Is Definitely Broken” Attack

Murdoch et al. [14] have shown that it is possible to use a stolen or lost smart card without the knowledge of its PIN ( The attack assumes that the card is configured with offline PIN verification method as its highest priority. Subsequently, most issuers have changed the default to online PIN verification. However, a man-in-the-middle can still force the terminal to choose offline PIN verification by modifying the CVM list sent by the card as it is in plaintext. This attack has also been practically demonstrated by Barisani et al. [2].

Since the main objective of this paper is to demonstrate how our approach prevents attacks on the EMV protocol by labelling it, we have worked with a software simulation instead of on the actual hardware. We illustrate this with a simulation of the Chip-and-PIN is definitely broken attack [2] which combines the Chip-and-PIN is broken attack [14] with CVM downgrade attack [2].

Experimental Setup. The following main hardware and software components are needed to perform this attack:
  • Hardware: Chip card, Smart card reader, and Laptop/PC.

  • Software: Terminal, and man-in-the-middle (MitM).

For the terminal, we have used the software implementation by Jean-Pierre Szikora and Philippe Teuwen (available from, and we have implemented our own program for MitM. In line with the practical considerations, our experimental setup is such that all the communication between the card and the terminal goes via the MitM. The MitM just acts as a proxy for all the messages exchanged other than CVM list and PIN verify.

Experiment steps
  1. 1.

    Insert the chip card into the smart card reader and connect it to the PC through a USB port.

  2. 2.

    [CMV downgrading] When the card sends the CVM list to the terminal, the MitM changes the CVM list and forces the terminal to perform offline PIN verification.

  3. 3.

    [PIN spoofing] When the terminal sends the PIN verify command to the card, MitM suppresses it and replies with the PIN correct command.


Since these attacks are widely discussed in the literature, and on various forums on the web, we do not provide much more details and refer the interested reader to [2, 14].

4.2 Experimental Evaluation of Our Approach

To realize the labelled protocol derived in Sect. 3.2, we have implemented the following:
  • a library for RWFM functionality including managing and manipulating labels, and providing access decisions,

  • a program for simulating the actions of the card - this is needed because we do not have control over the actual card for labelling it, and

  • modified terminal and MitM programs integrated with the appropriate RWFM function calls.

In this setup, RWFM library monitors the actions of all the stakeholders in the system and permits data accesses only as per the labels. Initially, RWFM library is loaded with the list of initial objects and their labels. Subsequently, as each operation is performed, RWFM library automatically labels the subjects and the messages being exchanged.

When we retried the simulation of the Chip-and-PIN is definitely broken attack on the labelled protocol, it provides several layers of defence. For exploring all the possible defences provided by our approach, the implementation only displays error messages whenever an unauthorized access is about to happen, but does not prevent it.

  1. 1.

    The CVM list (\(M_4\)) sent from the card to the terminal is labelled \((C,\{B,C,T\},\) \(\{B,C,T,U\})\). When the MitM tries to read this message, RWFM library logs an error because MitM is not a valid reader of the message as per its label.

  2. 2.

    MitM modifies the CVM list for sending to the terminal, which will be labelled \((M,\{B,C,T\},\{B,C,M,T,U\})\). When the terminal receives this message, RWFM library identifies that the message is created by MitM (M) and is also influenced by it, and since this is not the expected label for this message, RWFM logs an error message. Notice that in this step we actually have two defences - one based on the owner and the other based on the set of influencers.

  3. 3.

    PIN verify command (\(M_7\)) sent from the terminal to the card is labelled \((T,\{B,C,T\},\) \(\{B,C,T,U\})\). When the MitM tries to read this message, RWFM library logs an error because MitM is not a valid reader of the message as per its label.

  4. 4.

    MitM sends PIN correct command to the terminal, which will be labelled \((M,\{B,C,\) \(T\},\{B,C,M,T,U\})\). When the terminal receives this message, RWFM library identifies that the message is created by MitM (M) and is also influenced by it, and since this is not the expected label for this message, RWFM logs an error message. In this step we actually have two defences - one based on the owner and the other based on the set of influencers.


Having demonstrated how our approach prevents the Chip-and-PIN is definitely broken attack, we now discuss how it overcomes several other attacks discovered in the literature.

  1. 1.

    Skimming attacks [2] and the Chip-and-skim attack [5] are prevented for the same reasons as discussed in the above example.

  2. 2.

    PoS RAM scraper attacks [18] are prevented because RWFM also labels the temporary data in the RAM and provides access controls to it.

  3. 3.

    Relay attacks [8] can be prevented by forcing the stakeholders to interact only with others that are RWFM enabled (can be verified by a simple certificate - provides a root of trust).

  4. 4.

    Replay attacks are prevented to an extent by RWFM because the messages captured can only be replayed in another session between the same parties.

The above discussion is summarized in the table below:


RWFM\(^{\text {a}}\)

Suggestion given in the literature

Chip-and-PIN is broken [14]

Open image in new window

CVM Downgrade [2]

Open image in new window

Replay [6]


Skimming [2]

Open image in new window

Chip-and-skim [5]

Open image in new window

Random number generator algorithm

PoS RAM Scraper [18]

Open image in new window

Relay [8]

Open image in new window

Distance bounding

\(^{\text {a}}\)In the table above, by RWFM we mean an apt implementation of RWFM labels that realizes the security implied by the labels.

We have demonstrated that our approach based on the dynamic labelling using RWFM provides a uniform solution to many of the attacks discovered on the EMV protocol. Further, the labelled protocol also keeps track of the transaction history (coarse-grained), thus conforming to well-established principles for secure protocol design such as:
  • The principle of full information [22]: in every outgoing message, participants must include all of the information they have gathered so far in the exchange,

  • Canonical intensional specification [19]: no participant can believe a protocol run has completed unless a correct series of messages has occurred up to and including the last message the given participant communicates.

5 Related Work

Literature on the EMV protocol has three types of research: (i) attacks on EMV, (ii) analysis of the EMV protocol (high-level), and (iii) analysis of the cryptographic primitives of EMV protocol. We present a brief overview of only the first two types of research since they are directly connected to the paper.

No-PIN attack [14]: A man in the middle device which intercepts and modifies the communications between the card and the terminal, tricks the terminal into believing that PIN verification succeeded. The card believes that the terminal has either skipped cardholder verification or used a signature instead.

Chip and Skim [5]: The attacker records an ARQC for a transaction with nonce N, and presents it to a terminal that actually generated the nonce N1. The terminal sends the ARQC along with N1 (plain text) to the bank. The attacker changes N1 to N and the transaction succeeds.

CVM downgrade attack [2]: CVM list is sent by the smart card to the terminal which chooses the highest priority method that is supported by both of them. But the CVM list is sent in plaintext, thereby allowing an attacker to modify it to force the terminal to choose offline PIN verification method. Further, most of the data exchanged between the smart card and the terminal is in plaintext including the card number, expiry date, cardholder name etc. This data is enough to perform online attacks. It has been established that after the introduction of EMV, attackers moved towards the card not present transactions.

Some of the other attacks presented in literature include [6, 8, 18].

A formal analysis of the EMV protocol is presented in [20, 21]. The authors modelled the EMV protocol in F#, and presented its analysis using ProVerif [4] and FS2PV [3]. The formalisation covers all the major options of the EMV protocol suite. The following are the verification results using their formal model: (i) the private asymmetric keys and the shared symmetric keys remain confidential, (ii) if the terminal successfully performs a card authentication, it should be the highest card authentication method supported by both the card and the terminal, (iii) in the case of DDA, if a terminal completes an authentication, the corresponding card is in fact involved, (iv) in the case of SDA, a terminal may complete an authentication without the corresponding card being involved, (v) if the customer is authenticated using his PIN, the terminal and card need not agree on whether the PIN was accepted, (vi) using SDA or DDA, if a transaction is successfully completed by the terminal, the corresponding card need not agree on having the transaction completed successfully, and (vii) using DDA, the card and terminal should agree on the result of the transaction.

Our observations on the related work are summarized as follows:

Realistically speaking, very few protocols, get formally verified w.r.t their specifications. Even assuming that the protocol is verified, it is essentially a verification of the model and not that of the actual protocol. In the context of financial protocols such as EMV, the added disadvantage is that the threat models and attackers evolve rapidly. Thus, it is imperative to derive an analysis technique parameterized on threat models relative to the designers’ intentions. We can say that our approach realizes the following characteristics that would benefit a security analysis of the EMV protocol:
  • [Attacks] The attacks are usually discovered accidentally; or possibly during the testing phase by extensive trial and error with deep intuitions for a possible issue (that arises in similar cases). Thus, it is desirable to provide an analysis based on the protocol designers’ intentions that can be effectively used under different resource constraints or underlying threat models. Our analysis using the RWFM does exactly this by generating the underlying IFD that highlights the constraints that need to be observed for a secure realization. In a sense, our analysis is incremental, and allows different implementations under different threat models.

  • [Formal Modelling and Analysis] The IFD generated by our approach is quite small compared to the analysis reported in [20, 21] – that consists of five pages of F# model. Furthermore, how one integrates the security requirements with F# model is not clear. Our approach essentially provides a complete transition system clearly highlighting the capabilities of the subjects and objects and hence, any formal model can be used to check for the properties in the transition system.

6 Conclusions

In this paper, we have analyzed the EMV protocol from a security perspective, keeping in view the intentions of the designer. Our analysis not only brings to light the attacks that have been found in the literature, but also demonstrates that while implementing the protocol if one keeps track of the functional requirements of read and write by the stakeholders, it brings out the constraints that should be satisfied for realization in a given threat model. Thus, if the architecture of implementation does not satisfy these constraints then the implementation will not guarantee the expected security. Further, it was also demonstrated how the design can be realized using the RWFM security model to avoid “No-PIN” attack. In summary, the work brings to light the need of analysis techniques that keep track of the constraints for satisfying the functionality of the protocol, and the constraints that needs to be satisfied for realizing security policy. Such an explicit bookkeeping aids in possible realizations for different threat models and architectures. In particular, our approach leads to a general implementation that works even if the regular card was replaced by another payment mechanism such as a mobile or e-wallet. We further demonstrated how the RWFM security model leads to analysis techniques that satisfy these criteria. Further, work on linking the system with automatic tools for establishing higher level properties is in progress.


  1. 1.

    The EMV standard is designed by Europay, MasterCard, and Visa.

  2. 2.
  3. 3.



The work was done as part of Information Security Research and Development Centre (ISRDC) at IIT Bombay, funded by MEITY, Government of India.


  1. 1.
    Adida, B., Bond, M., Clulow, J., Lin, A., Murdoch, S., Anderson, R., Rivest, R.: Phish and chips. In: Christianson, B., Crispo, B., Malcolm, J.A., Roe, M. (eds.) Security Protocols 2006. LNCS, vol. 5087, pp. 40–48. Springer, Heidelberg (2009). CrossRefGoogle Scholar
  2. 2.
    Barisani, A., Bianco, D.: Practical EMV PIN interception and fraud detection. In: 31th Chaos Communication Congress [31c3] of the Chaos Computer Club [CCC] (2014)Google Scholar
  3. 3.
    Bhargavan, K., Fournet, C., Gordon, A.D., Tse, S.: Verified interoperable implementations of security protocols. In: 19th IEEE CSFW, pp. 139–152 (2006)Google Scholar
  4. 4.
    Blanchet, B.: An efficient cryptographic protocol verifier based on prolog rules. In: 14th IEEE CSFW, pp. 82–96 (2001)Google Scholar
  5. 5.
    Bond, M., Choudary, O., Murdoch, S.J., Skorobogatov, S.P., Anderson, R.J.: Chip and skim: cloning EMV cards with the pre-play attack. CoRR abs/1209.2531 (2012)Google Scholar
  6. 6.
    Degabriele, J.P., Lehmann, A., Paterson, K.G., Smart, N.P., Strefler, M.: On the joint security of encryption and signature in EMV. In: Dunkelman, O. (ed.) CT-RSA 2012. LNCS, vol. 7178, pp. 116–135. Springer, Heidelberg (2012). CrossRefGoogle Scholar
  7. 7.
    Denning, D.E.: A lattice model of secure information flow. Commun. ACM 19(5), 236–243 (1976).
  8. 8.
    Drimer, S., Murdoch, S.J.: Keep your enemies close: Distance bounding against smartcard relay attacks. In: Provos, N. (ed.) 16th USENIX Security Symposium. USENIX Association (2007)Google Scholar
  9. 9.
    EMVCo: Book 1: Application independent ICC to terminal interface requirements v4.3 (2011).
  10. 10.
    EMVCo: Book 2: Security and key management v4.3 (2011).
  11. 11.
    EMVCo: Book 3: Application specification v4.3 (2011).
  12. 12.
    EMVCo: Book 4: Cardholder, attendant, and acquirer interface requirements v4.3 (2011).
  13. 13.
    Ferradi, H., Géraud, R., Naccache, D., Tria, A.: When organized crime applies academic results: a forensic analysis of an in-card listening device. J. Crypt. Eng. 6(1), 49–59 (2016)CrossRefGoogle Scholar
  14. 14.
    Murdoch, S.J., Drimer, S., Anderson, R.J., Bond, M.: Chip and PIN is broken. In: 31st IEEE S&P, pp. 433–446. IEEE Computer Society (2010)Google Scholar
  15. 15.
    Narendra Kumar, N.V., Shyamasundar, R.K.: Realizing purpose-based privacy policies succinctly via information-flow labels. In: 4th IEEE BDCloud, pp. 753–760. IEEE (2014)Google Scholar
  16. 16.
    Narendra Kumar, N.V., Shyamasundar, R.K.: POSTER: dynamic labelling for analyzing security protocols. In: 22nd ACM CCS, pp. 1665–1667 (2015)Google Scholar
  17. 17.
    Narendra Kumar, N.V., Shyamasundar, R.K.: Analyzing protocol security through information-flow control. In: Krishnan, P., Radha Krishna, P., Parida, L. (eds.) ICDCIT 2017. LNCS, vol. 10109, pp. 159–171. Springer, Cham (2017). CrossRefGoogle Scholar
  18. 18.
    Rodríguez, R.J.: Evolution and characterization of point-of-sale RAM scraping malware. J. Comput. Virol. Hacking Tech. 13(3), 179–192 (2017). CrossRefGoogle Scholar
  19. 19.
    Roscoe, A.W.: Intensional specifications of security protocols. In: 9th IEEE CSF, pp. 28–38 (1996)Google Scholar
  20. 20.
    de Ruiter, J.: Lessons learned in the analysis of the EMV and TLS security protocols. Ph.D. thesis, Radboud University Nijmegen, August 2015Google Scholar
  21. 21.
    de Ruiter, J., Poll, E.: Formal analysis of the EMV protocol suite. In: Mödersheim, S., Palamidessi, C. (eds.) TOSCA 2011. LNCS, vol. 6993, pp. 113–129. Springer, Heidelberg (2012). CrossRefGoogle Scholar
  22. 22.
    Woo, T.Y.C., Lam, S.S.: A lesson on authentication protocol design. SIGOPS Oper. Syst. Rev. 28(3), 24–37 (1994)CrossRefGoogle Scholar

Copyright information

© Springer International Publishing AG 2018

Authors and Affiliations

  • Khedkar Shrikrishna
    • 1
  • N. V. Narendra Kumar
    • 2
  • R. K. Shyamasundar
    • 1
  1. 1.Department of Computer Science and EngineeringIndian Institute of Technology BombayMumbaiIndia
  2. 2.Centre for Payment SystemsIDRBTHyderabadIndia

Personalised recommendations