Clone a contactless card using a mobile application

It was always interesting to see what happens on a bank card under the “hood”. How the communication protocol of a bank card and a POS terminal is implemented, how it works and how safe it is. Such an opportunity appeared before me when I was doing an internship at Digital Security. As a result, when parsing one known vulnerability of EMV cards in MagStripe mode, it was decided to implement a mobile application that is able to communicate with the terminal via a contactless interface, using its own commands and a detailed analysis of requests and responses. And also try to implement the method of cloning MasterCard cards in MagStripe mode.

In this article I will try to describe what an EMV card is, how it works and how using Android you can try to clone your MasterCard card.

“There are some things money can’t buy. For everything else, there’s MasterCard »

What is an EMV card?

EMV is the international standard for bank cards with a chip. Europay + MasterCard + VISA took part in the development of this standard, hence the name. Let’s try to figure out how the card communicates with the POS terminal via a contactless interface.

Let’s start with the basics.

A non-contact EMV card at the physical level works almost the same as an RFID tag. If it is basic, the chip enters the electromagnetic field, and in the closed conducting circuit (in our case it will be an antenna located around the perimeter), placed in an alternating magnetic field, an alternating electric current is generated. This current charges a special capacitor connected in parallel to the resonant circuit of the card. The energy stored in the capacitor is used to perform the chip card various operations. When the reader changes the electromagnetic field, the changes will immediately be noticeable on the chip. Using signal modulation, we can transmit information in binary form. If you connect the load resistance on the card and or change the capacitance of the capacitor, you can change the current strength in the circuit of the card, which will lead to a change in the electromagnetic field created by it in the area of ​​the reader circuit, thus the card transmits data. The reader will have to detect these changes. Such physical interaction is regulated by the standard ISO / IEC 14443 “Identification Cards – Contactless integrated circuit (s) cards – Proximity cards”.

The card chip itself is a smart card that runs JavaCard, a separate version of Java for platforms with low computing resources and support for cryptographic algorithms. JavaCard downloads applets, which are applications. There is also a GlobalPlatform is a certain standard for JavaCard, which provides the ability to safely manage data on the map and allows you to download, modify and delete applications on the map. In this article, we will not consider the security mechanisms of the smart card itself. It is enough to know that the protected data, for example, the private key and the secret master key of the card, are in a secure place and it is impossible to remove them using standard means.

I also recall a little terminology for those who are not familiar.

POS-terminal (Point of Sale) – a seller’s device that reads a card and initiates a payment. Further we will call this device simply a terminal.
The issuing bank is the bank that issued your card.
Acquirer Bank – a bank that issues POS-terminals to sellers and processes payments from them.
The payment system is the central link between the acquirer bank and the issuing bank, absolutely all payments go through it, and it knows which bank should transfer money to how much. There are many payment systems in the world, besides the well-known Visa and MasterCard, there are also American Express, China UnionPay and the Russian payment system MIR.

A standard EMV transaction takes place in several stages, I will describe the full interaction algorithm in the case of a contact interface, for a contactless interface the algorithm is somewhat shortened:

     Application selection;
     Initialization of application processing;
     Reading application data
     Offline authentication
     Processing restrictions;
     Cardholder check;
     Risk management on the side of the terminal;
     Analysis of terminal actions;
     Risk management on the card side;
     Analysis of the actions of the card;
     Online processing;
     The completion of the operation.

We briefly consider each operation.

Application selection. It often happens that there can be several applications on one card. For example, a bank card and a travel ticket. And the terminal somehow needs to figure out where and which algorithm to use. The so-called Application Identifier (AID) is used to select an application. To understand this, the terminal sends a SELECT command. For example, the Visa Classic card’s AID will look like this: A0000000031010. If several such codes come in response and the terminal can work with several applications, the terminal will display a list and offer to select the application we need. If the terminal does not support any of the application codes, then the operation will be rejected by the terminal.

Initializing application processing. Here, the geographical location is first checked. For example, Maestro Momentum cards can work for payment only in Russia. This stage is done in order to provide issuers with the opportunity to apply existing online risk management methods when conducting offline operations. At this stage, an EMV transaction can be canceled at the initiative of the card itself if this type of transaction is prohibited by the issuer in a given country in the world. Further, the card transmits to the terminal a set of specially structured information containing a description of the functionality of the card and the application.

Read application data. Various card data necessary for the transaction are transmitted to the terminal, for example, card number, expiration date, transaction counter and many other data. Some of them will be discussed later.

A certificate of the public key of the issuing bank and the card itself is also transmitted. In order for the terminal to be able to verify the digital signature of some card data, the PKI infrastructure (Public Key Infrastructure) is used. In short, the payment system has a pair of keys – public and private, and the payment system is for all participants of the CA (Center Authority). In fact, the payment system for each bank of the issuer issues a new key pair, and at the same time generates a certificate of the public key of the issuer’s bank, signing it with the private key CA. Further, when the bank issues a new card, it accordingly generates a pair of keys for the card, and also generates a certificate of the public key of the card, signing it using the bank’s private key. In terminals, a public key certificate for various payment systems is usually wired. Thus, when the card transmits the issuer’s bank’s public key certificate and the card’s certificate itself, the terminal can easily check the entire chain using the public key of the payment system. The terminal, using the public key of the payment system, first verifies the authenticity of the issuer’s bank certificate, if it is genuine, then it can be trusted and now using the issuer’s bank certificate you can verify the certificate of the card itself. More details in the article about EMV security.

Offline authentication. The terminal determines the type of supported offline authentication method. There is static (Static Data Authentication – SDA), dynamic (Dynamic Data Authentication – DDA) and combined (Combined Data Authentication – CDA). These methods are also based on PKI. SDA is just signed data on the issuer’s bank’s private key, DDA – the terminal sends some random number and the card must sign it using its private key, and the terminal will verify this signature using the previously received card certificate, so the terminal will make sure that the card really has a private key – hence it is genuine. CDA is just a combination of both.

Processing constraints. Here, the terminal checks the previously received data from the card for the suitability condition for this operation. For example, it checks the start / end dates of the application Application Expiration Date (Tag ‘5F24’) and Application Effective Date (Tag ‘5F25’). It also checks the version of the application. The results of operations carried out at this stage are also recorded in the TVR report (Terminal verification results). Based on the results of this stage, the transaction cannot be canceled, even if, for example, the application has expired.

Card holder check. Cardholder verification is carried out in order to authenticate the person who provided the card and verify whether he is the true owner of the card. The EMV standard provides various Cardholder Verification Methods. Verification methods are defined both on the terminal and on the map. They are contained in the so-called CVM lists. In the process of execution, the terminal and the card compare the received CVM lists and select the general verification method.

List of supported verification methods:

    No CVM required (‘011111’b);
    Fail CVM processing (‘000000’b);
    Signature (‘011110’b);
    Enciphered PIN verified online (‘000010’b);
    Plaintext PIN verification performed by ICC (‘000001’b);
    Plaintext PIN verification performed by ICC and signature (‘000011’b);
    Enciphered PIN verification performed by ICC (‘000100’b);
    Enciphered PIN verifi cation performed by ICC and signature (‘000101’b).

Here there is also interesting information on this subject.

Risk management on the side of the terminal. At this stage, the terminal carries out an internal verification of transaction parameters, based on the risk management settings of the acquiring bank. Risk management procedures can be performed by the terminal at any time between the completion of the process of reading card data and the formation of the first GENERATE AC command by the terminal. Risk management on the terminal side includes three mechanisms:

    control of the size of operations performed on the card (Floor Limit Checking);
    random transaction selection for online authorization of this transaction by the issuer (Random Transaction Selection);
    checking offline activity of using the card (Velocity Checking).

Analysis of terminal actions. At this stage, the terminal analyzes the results of the previous steps of the transaction. Based on the results of the analysis, the terminal makes a decision on whether to conduct the operation online, allow it to be carried out offline or reject the operation.

Risk management on the card side. The card, having received from the GENERATE AC command data about the transaction, the terminal and the results of terminal checks, in turn performs its own risk management procedures and makes its own decision on how to complete the operation.

Analysis of the actions of the card. At this stage, the card completes the risk management procedures and generates a response cryptogram to the terminal. If the card decides to approve the transaction, a Transaction Certificate is generated. If the card decides to perform the operation in real time, then it generates an ARQC (Authorization Request Cryptogram). If the card uses alternative authorization methods, then the Application Authorization Referral is used. In case the card rejects the transaction, then Application Authentication Cryptogram.

Another ARPC (Authorization Response Cryptogram) cryptogram is needed to authenticate the issuer. The issuer generates a cryptogram ARPC and sends the cryptogram to the card, if the card confirms the cryptogram, then the issuer is authenticated by the card.

A little about the security of keys and mutual authentication of the card and the issuer from the book of I. M. Goldovsky:

    The meaning of mutual authentication is that the card and the terminal authenticate each other using the authentication of ARQC and ARPC cryptograms. Cryptograms are data generated using a secret key (which is known to the card and the bank to the issuer), transaction number, random number generated by the terminal, as well as some details of the transaction, terminal and card. In the case of ARPC, the authorization response code of the issuer is still added to the listed data. Without knowing the secret key of the card for generating a cryptogram, it is impossible to calculate the ARQC / ARPC values ​​in the foreseeable time with the current level of technology, and therefore the fact of their successful verification indicates the authenticity of the card and the issuer. Online authentication is the most reliable way to authenticate a card. This is due to the fact that it is carried out directly by the issuer, without an intermediary in the form of a terminal. In addition, 3DES algorithm with a 112-bit temporary key is used for online authentication, the cryptographic strength of which corresponds to the cryptographic strength of the RSA algorithm with the asymmetric key module length used for offline authentication of the card application exceeding 1700 bits. Using asymmetric keys of this length on the card is still quite rare. Typically, keys with a module length of 1024, 1152, or 1408 bits are used.