Acquiring: EMV Transaction Flow. Part 1: Interfaces and Bases of the APDU

Intro

In this series of articles, we will try to tell as simply and clearly as possible what happens between the card and the device when a purchase is made through a POS terminal or when an ATM is used. Let us consider one by one all the steps of the exchange between a chip card and a device. I.e., we will tell you about the thing that is commonly called «EMV Transaction flow». The first part deals with the review of the exchange interfaces and the basic principles of operation of the APDU format.

Exchange interfaces

«Interface» is a common name of one or another way of exchange between a card and a device. Speaking of POS or ATM, we should list the three main interfaces:

1. MS/MStripe, or a Magnetic Stripe, is the earliest exchange interface, gradually «falling into oblivion». It is basically for the reasons of technical imperfection and the security issues logically deriving therefrom. Since it lacks prospects (and because it is simple), let us limit ourselves to only a brief review of the implementation mechanisms. The MStripe is based on a set of data consisting of two or three objects (so-called «tracks»). These include the card number, its validity term, surname/name of the cardholder as well as the service code and a certain set of data for card validity verification (so-called CVV, Card Verification Value). The service code, in turn, contains the parameters controlling the card usage within a region (transactions within a country, international transactions, etc.), online requests sent to the issuer as well as the permissible services (POS/ATM) and the terms of PIN code request. As noted above, since the structure of the data is simple enough, and their size is limited, a magnetic stripe card can be easily copied by the fraudsters. That is the main reason why such an interface is currently getting out of use.

2. ICC Contact (Integrated Circuit Card, Contact). It is also known as the «smart card», «EMV card» or «chip card». The classic contact chip card is well-known. Compared to MStripe, its technological capabilities and security level are incomparably higher (especially if the issuer observes all the requirements and recommendations of the PS.) Curiously enough, in comparison with the more up-to-date «contactless» chip, the classical contact chip has some capabilities that are hard to implement in a «contactless» chip due to the special features of the latter. Those are, for example, the issuer’s capability to remotely send the control commands to the card (so-called Issuer Scripts), the online functionality flexible control capability (various limits, fee calculations and/or discounts) and some others.

Arguably the only significant downside of the contact chip card is a low rate of the data exchange between the devices. As many have observed that the time that a purchase using a contact chip card can take is quite substantial. However, this happens not because a POS terminal «runs slow» or «freezes» at all. It is caused by the architectural features of the exchange interface design (we will talk about such features in this series of articles.) Besides, some POS To HOST protocols imply the existence of additional communication sessions between the device and the PC for the contact chip-based exchange - so-called EMV Final Advice (EFA). These are usually the MTI 0220-0230 messages, where a terminal transmits to the host the results of the issuer’s response processing by the card and some other data necessary for the generation of the clearing messages. I.e., a POS terminal initiates the connection twice: the first time for the exchange with the issuer and reception of the response from the issuer, and the second time for the EFA. Naturally, this downside is well known to the Payment systems, which is why several ways to optimize the exchange between the device and the card have been developed during the evolution of the «chip». They are aimed at reduction of the transaction time and involve changing the general logic of its processing (amount, type of cryptogram, etc.) in comparison with the «classical» scheme described in EMVBook. As a rule, such specifications have the respective prefixes («Fast» or «Quick») in their names. For example, Mastercard M/Chip Fast, Visa Quick Chip or American Express Quick Chip. Such specification data and, consequently, such exchange schemes, are not widely spread in our region. It is basically thanks to a relatively high general technical level of the regional infrastructure which allowed to provide, in a very short time, support of the contactless cards that have no issues with the rate of the data exchange.

3. ICC Contactless (Integrated Circuit card, Contactless). Another card not less widely spread in our region is the card equipped with a built-in antenna for the exchange through the contactless interface. Unlike the contact EMV cards, it is based on the ISO 14443 protocol. It has no such downside as the rate of the data exchange, which was and is clearly highlighted by the Payment systems. For example, the famous motto of Mastercard Contactless«Just Tap & Go». The characteristic feature of a contactless card is a significant distinction in terms of the exchange design from the perspective of one or another PS. In other words, while the contact chip card exchange is very similar for the cards of all PS’s (which, undoubtedly, is good to ensure support of one or another PS’s card by a Participant), the «contactless» card has some modifications, and in some cases they are fundamental. For example, while the contactless core of MasterCard did not undergo such significant changes, the Contactless Visa has some characteristic features that are fundamental in terms of the information exchange. This implies that even if the IDs of a certain card are described in the configuration of the POS or ATM, the device will not necessarily be able to support them when exchanging through the contactless interface.

Another characteristic feature logically deriving from the above-said, is some «reduction» of the contactless cores’ technical functionality regarding the contact chip, mainly in terms of the rate of the data exchange and the security. Those include the exception of the offline PIN codes from the list of CVM methods, the exception of the cardholder’s name/surname storage in the contactless card profile and some other things inherent in each specific PS.

It should be noted that a contactless card can be a «chip» as well as a «magnetic» card. I.e., usually, a contactless card includes two profiles that can operate either in emulation or chip mode (EMV-Mode), or a magnetic stripe (MStripe-Mode). However, the EMV-Mode is the preferred mode, and the support of the MStripe-Mode in our region is nowadays being gradually removed from the devices in accordance with the regulations of the PSs. Surely, in this case, the «magnetic stripe contactless cards» have a sufficient security level in comparison with the physical «magnetic stripe cards», because they have enhanced capabilities of the data storage and the algorithms for verification of the card authenticity.

APDU

It is necessary to touch upon the APDU format in broad strokes because it is the basic format of exchange both through the contact chip and for operation through the contactless interface.

APDU (Application Protocol Data Unit) is a format of exchange between the card and the device (POS, ATM, etc.). In this case, the device sends an APDU-Command (APDU-C), and the card returns APDU-Response (APDU-R). This alone makes it clear that the device initiates the entire exchange process.

1. APDU-C including the so-called «Header» and «Body» command.

In general, the Header has the following structure:

  • CLA (Class Byte) — class of the command.
  • Ins (Instruction Byte) — instruction code.
  • P1 — First parameter of the command. If there is none, its value will be always = 0.
  • P2 — Second parameter of the command. If there is none, its value will be always = 0.

Body of the command has the following structure:

  • Lc Send is the length of the data to be sent (i.e., the length of the «Data» field).
  • Data is the command data themselves.
  • Le Reciever is the expected response length in APDU-R.

For example:

00A4040007A000000004101000, where:

  • Class of the command: 00
  • Instruction code: A4
  • Parameter 1: 04
  • Parameter 2: 00
  • Field length: 07
  • Data: A0000000041010
  • Expected response length: 00

2. The structure of APDU-R includes «Body», i.e., the body of the response itself, and so-called «Trailer» with the status bytes (or «Words») SW1 (Status Word-1) and SW2 (Status Word-2). Trailer is a certain equivalent of the Response code (RC), and it communicates the result of the exchange. However, should the exchange result in an error, the «Body» element will be missing in the APDU-C.

For example:

Select response (Error: File not found)
Response: 6A82
SW1 SW2: 6A82

The persons interested in the SW1/SW2 list can familiarize themselves with it, here, for example.

«Inside» APDU, the exchange is based on either the ISO 7816 protocol (contact chip) or the ISO 14443 protocol (contactless chip), which, as it was said above, is in fact the specific design of exchange through the cards of one or another PS. The commands between the device and the card imply the exchange of the data organized based on TLV (Tag, Length, Value) format.

For example:

8407A0000000041010, where:

  • Tag: 84
  • Length: 07 байт
  • Value: A0000000041010.

This is the minimum information that gives a basis for the understanding of exchange between the card and the device at its main stages. The next part of the EMV Transaction Flow overview will deal with the matters of the Candidate list organization and Choice of application.