The Standard of EMV Entry Point Specification

As noted earlier, EMVCo has taken over the rights to support and develop the EMV Contactless Communication Protocol Specification developed by MasterCard. The issue of creating a single contactless application EMV Contactless Application — an analog of the Common Payment Application for contact cards-is on the agenda of EMVCo. This issue is actively raised by major European banks. However, EMVCo is in no hurry to develop a standard for EMV Contactless Application. The reason given by EMVCo is the lack of experience in using contactless cards, which is necessary for generalization and implementation in the future standard for a single contactless application. EMVCo conducts internal discussions every year on whether to start developing this standard, and has not yet made a positive decision.
At the same time, the appearance of a standard for a single contactless application in the future is obvious. Therefore, EMVCo, anticipating the appearance of such a standard, developed the EMV Contactless Specifications for Payment Systems — Entry Point Specification (in the future we will call it Entry Point Specification for short), which solves a number of issues related to the implementation of the EMV Contactless Application. In particular, the Entry Point Specification standard defines the procedure for selecting a contactless application on the card by the terminal when the contactless application of a payment system can be implemented on the card either as a native application of this payment system (for example, MasterCard PayPass, VISA Contactless, JCB QUICPay, American Express ExpressPay), or as a future unified application EMV Contactless Application.
However, the scope of the Entry Point Specification standard is not limited to the contactless application selection procedure. The standard defines the General scheme of processing a contactless card transaction on the terminal side (Entry Point) and describes in sufficient detail the procedures that precede the application selection. But about everything in order.

According to the Entry Point Specification, processing an operation performed via the contactless interface consists of the following steps:
defining operation processing parameters (pre-conditions);
pre-treatment of the transaction (preliminary transaction processing);
activating the contactless interface;
the terminal selects the application on the card and the core of the terminal application that works with a contactless card;
activating the terminal application core (granting the application core the right to process a transaction);
transaction processing;
deactivating the contactless interface.
Figure 7.10 below illustrates the steps involved in processing a contactless transaction.
Let’s look at these stages in more detail. At the first stage, the terminal’s task is to determine / generate operation parameters that are significant for transaction processing. Among these parameters, two are required for support by any terminal that meets the Entry Point Specification standard. These include the transaction size (Amount, Authorized) and a random terminal number (Unpredictable Number).
In addition, at this stage, the terminal must have access to a set of data and flags from the list below for each application ID (AID) it supports:
Terminal Floor Limit (transactions that exceed or equal the Terminal Floor Limit must be processed online);
Terminal Contactless Floor Limit (contactless transactions that exceed or equal the Terminal Contactless Floor Limit must be processed online);
Terminal Contactless Transaction Limit (transactions that exceed or equal the Terminal Contactless Transaction Limit cannot be processed via the contactless interface);
Terminal CVM Required Limit (transactions that exceed or equal the Terminal CVM Required Limit must be processed with cardholder verification);
Status Check Support Flag;
Zero Amount Allowed Flag.

Finally, if the terminal supports VISA applications, the terminal must have access to the Terminal Transaction Qualifiers object for the corresponding AID IDs of THESE applications, which is modified at the next stage — the pre-processing stage of the transaction.
At the second stage (pre-processing of the transaction), the terminal sets the values of the following internal flags of the terminal application for each supported application ID based on the data received at the previous stage:
Terminal Contactless Floor Limit Exceeded (this flag is set in two cases:
if the Terminal Contactless Floor Limit parameter is present in the terminal configuration data for this AID and the size of the contactless transaction is greater than or equal to its value;
or if the Terminal Contactless Floor Limit parameter is not present in the configuration for this AID, but the Terminal Floor Limit parameter is present and the contactless transaction size is greater than or equal to its value);
Terminal Contactless Transaction Limit Exceeded (this flag is set if the Terminal Contactless Transaction Limit parameter is present in the terminal configuration data for this AID and the transaction size is greater than or equal to the Terminal Contactless Transaction Limit value);
Terminal CVM Required Limit Exceeded (this flag is set if the CVM required Limit parameter is present in the terminal configuration data for this AID and the transaction size is greater than or equal to the CVM Required Limit value);
Status Check Requested (this flag is set if the Status Check Support Flag is present in the terminal configuration data for this AID, and the value of the transaction size is equal to one in the transaction currency);
Zero Amount (this flag is set if the transaction size is 0).
Next, the application terminal performs the setting of the flag Contactless Application Not Allowed. For MasterCard PayPass M/Chip and JCB applications, the Contactless Application Not Allowed flag is set if and only if the Terminal Contactless Transaction Limit Exceeded flag is set.
For VISA contactless applications, the Contactless Application Not Allowed flag is set in any of the following cases:
if the terminal is able to perform an operation in online mode (online-capable), the Zero Amount flag is set, but the Zero Amount Allowed Flag is not set;
if the Zero Amount flag is set, and the terminal can only process transactions offline;
if the Terminal Contactless Transaction Limit Exceeded flag is set.
In addition, during the pre-processing stage of a contactless transaction, the value of the object’s data field is generated for AID IDs that support the Terminal Transaction Qualifiers object. However, the Entry Point application “insists” on installing only two bits of this object-bits 7 and 8 of byte 2. The values of these bits are as follows:
if bit 8 of byte 2 is equal to 1, the terminal requires performing the operation in online mode (Online cryptogram required);
if bit 8 of byte 2 is 0, the terminal does not require performing the operation in online mode (Online cryptogram not required);
if bit 7 of byte 2 is equal to 1, the terminal requires performing a cardholder verification operation (CVM required);
if bit 7 of byte 2 is 0, the terminal does not require verification of the cardholder when performing the operation (CVM not required).
The remaining bits are set by the terminal according to the specification of the selected application. The following rules apply to bits 7 and 8 of byte 2 of Terminal Transaction Qualifiers:
if the Terminal Contactless Transaction Limit Exceeded flag is set, the entry Point terminal application sets the value of bit 8 of byte 2 to 1 (Online cryptogram required);
if the Status Check Requested flag is set, the Entry Point terminal application sets the value of bit 8 of byte 2 to 1 (Online cryptogram required). Thus, the purpose of the Status Check Requested flag is to provide the terminal with a mechanism to force it to process the operation online;
if the Zero Amount Allowed Flag and Zero Amount flags are set, the Entry Point terminal application sets the value of bit 8 of byte 2 to 1 (Online cryptogram required);
if the Terminal CVM Required Limit Exceeded flag is set, the entry Point terminal application sets the value of bit 7 of byte 2 to 1 (CVM required).
This completes the second stage of transaction processing (pre-processing). If there is at least one AID application ID for which the Contactless Application Not Allowed flag is not set, the terminal offers to place the card in the working area of the terminal reader. The card is placed in the reader’s work area, activated, the terminal establishes communication interaction with it, and proceeds to the fourth stage — selecting the application on the card and the core of the terminal application that works with the contactless card.
We have already described the procedures for selecting The MasterCard PayPass and VISA Contactless applications by the terminal. Below you will find information about choosing an app when the EMV Contactless Application can be found on your card along with native contactless payment system applications. In this case, if the EMV Contactless application

The Application is recognized by the payment system as its alternative application, then the terminal served by the Bank of this payment system must support both native applications (for example, MasterCard PayPass or VISA Contactless) and EMV Contactless Application. At the same time, the core of the terminal application that supports the native application of the payment system on the card is called Legacy Kernel, and the core of the terminal application that provides the EMV Contactless Application is called EMV Contactless Kernel.
Then the task of selecting the application is set as follows: what is the name of the card application directory (ADF Name) and the core of the terminal application for processing the card application should be selected to process the operation of the contactless card holder? The card (or rather its Issuer via the data stored on the card) and the terminal participate in getting an answer to this question.
To answer this question, we remind you that the app is selected using the PPSE directory, which is mandatory for contactless cards. If the terminal supports more than two AIDS, the application selection starts with the SELECT command specifying the DDF name of the PPSE directory (2PAY.SYS.DDF01). The FCI Template object (Tag ‘ 6F’) of this directory, returned to the terminal in response to the SELECT command, has the form specified in table 7.2. as can be easily seen in table. 7.2, a composite Directory Entry object can contain a Contactless Application Capabilities Type data object (Tag ‘9F28’), whose data field has the structure shown in table. 7.7 and 7.8.
After receiving the FCI Template object in response to the SELECT command, the terminal starts analyzing all the Directory Entry objects present in it in order to build a list of combinations “card application AID — terminal application core name”. A combination is included in the list of terminal combinations if:
The ADF Name of the next Directory Entry object matches one of the AID IDs supported by the terminal;
the card application can be processed by some terminal application core (terminal kernel);
the Contactless Application Not Allowed flag is not set for the card application AID.
It is easy to see that as a result of analyzing a single Directory Entry object, 0, 1, or two combinations can be added to the list of terminal combinations. Two combinations will be included in the list of combinations if bits 7 and 8 of byte 1 of the Contactless Application Capabilities type object data field are equal to 1 and the terminal supports both applications.

b8 b7 b6 b5 b4 b3 b2 b1 bit Value
x x whether the app is present
0 0 the App is not being used
1 0 EMV Contactless Application is present
0 1 the native payment system application is Present
1 1 the native payment system application and EMV Contactless Application are Present
x application selection preference indicator (Processing Preference Indicator)
1 EMV Contactless Kernel terminal Application is preferred
0 a terminal Application that supports the system’s native application is preferred
x x x x x Bits are reserved for future use
b8 b7 b6 b5 b4 b3 b2 b1 bit Value
x x x x x x x x Name of the terminal application associated with this application
0 0 0 0 0 0 0 0 Reserved for use
0 0 0 0 0 0 1 terminal Application that works with the native JCB application on the card
0 0 0 0 0 0 1 0 terminal Application that works with MasterCard PayPass
0 0 0 0 0 0 1 1 terminal Application that works with VISA Contactless
0 0 0 0 0 1 0 0 4-e terminal application
— – – – – – – – Another terminal application
1 1 1 1 1 1 1 0 254-e terminal application
1 1 1 1 1 1 1 1 Reserved for future use

The combination that appears in the list of combinations contains the following parameters:
ADF Name of the card application (AID).
name of the terminal kernel that can process an application with the AID identifier;
Application Priority Indicator (if present);
Processing Preference Indicator (if present).

Without stopping at the details, let’s consider the process of final selection of the combination. First, the terminal selects the name of the ADF Name directory that corresponds to the card application with the highest priority (Application Priority Indicator) among all the names of the ADF Name directories that are present in the combinations of the list of combinations. If two combinations from the list of combinations correspond to the selected ADF Name, the terminal analyzes bit 6 of byte 1 of the Contactless Application Capabilities Type data object. If it is equal to 1, then a combination is selected that has terminal kernel=EMV Contactless Kernel. If bit 6 of byte 1 of the Contactless Application Capabilities Type data object is 0, then a combination is selected that has terminal kernel=Legacy Kernel.
After selecting a combination, the corresponding combination of the terminal application core is activated, which the Entry Point application passes control to. The first command of the selected application core is SELECT AID, where AID is the ID of the card application from the selected combination.

EMVCo pays attention to the implementation of the Entry Point Specification. Type Approval procedures have been prepared for certifying terminals that support this specification.

NFC Protocol and its use in cell phones
Today, the cell phone is the most common electronic device in the hands of the population of our planet. The number of mobile phones in the world is more than 2.5 times the number of Internet users and about 3 times the number of television devices.

In addition, the cell phone is a universal network (mobile) computing tool. It has its own processor, memory, display, keyboard, and supports a variety of communications (various variations of GSM/UMTS protocols, as well as Wi-Fi, IrDA, Bluetooth, and others). The phone may contain other chips (SIM/UICC card, memory card, and other SE (Secure Elements) elements) that use the phone’s capabilities to perform various useful functions.
The computing and communication capabilities of the phone, clearly superior to those of a modern microprocessor card, led to the idea of using the phone as a payment card. Thanks to the keyboard and display, the phone adds an element of interactivity and visualization to the properties of an ordinary plastic card (selecting an application/service, entering the details necessary for making a payment, displaying the results of the operation, logos and brands of issuers/payment systems, etc.). The client’s phone can be used as a universal electronic wallet for storing applications from various issuers and even various payment systems, which is convenient for the client. Finally, when using the phone as a payment card, the app Issuer can remotely manage its app hosted on the phone or in the phone’s SIM/UICC card.
The idea of using a phone as a payment card has gained concrete meaning due to the emergence and spread of NFC (Near Field Communication) technology. NFC technology is formalized in the framework of the ISO 18092 standard (ECMA 340, NFCIP-1), which describes the Protocol for interaction between two devices via a radio interface. The main characteristics of the NFC Protocol are listed below.
The Protocol allows two devices located at a distance of no more than 10 cm from each other to exchange data via a radio interface using the same carrier frequency of 13.56 MHz ± 7 KHz, as in the case of the ISO 14443 Protocol discussed above. Data is exchanged at speeds of 106 Kbit / s, 212 Kbit / s, and 424 Kbit / s. As an option, higher data transfer rates are allowed (for example, 848 Kbit/s).
When transmitting data at a speed of 106 Kbit/s, the already familiar ISO 14443 type a Protocol is used. At higher data exchange rates, the FeliCa Protocol developed by Sony specialists is used. The forward and reverse channels of the FeliCa Protocol use 10% amplitude modulation, and the Manchester code is used to encode bits of information. The subcarrier is not used to modulate the signal in the reverse channel. Figure 7.12 shows the appearance of signals in the forward and reverse channels of the FeliCa Protocol.
The ISO 10373-6 Protocol has been developed for certification of radio devices for compliance with the ISO 18092 standard.
A distinctive feature of the FeliCa Protocol is the existence of a symmetrical mode of interaction between two radio devices. When using this mode, both devices are sources of a magnetic field (or are said to be active) and therefore can initiate a data exchange dialog, and also do not need the magnetic field of the second participant of the dialog to transmit their data to it. Therefore, when using a symmetrical mode, after data transmission is complete, the active device disables the generation of its magnetic field and starts working only for receiving information.
The NFC Protocol as a means of communication is becoming more common in cell phones, PDAs, laptops, and digital cameras. According to the latest forecasts of ABI Research, the critical mass of phones (half a billion devices) that support the NFC standard will be reached by 2012.
The key issue for turning a cellular NFC phone into a plastic card is where the payment app should be stored on the phone. An obvious candidate for the role of a payment application Keeper is a SIM / UICC card. Of course, the app can also be stored on other secure card elements (such as a memory card). However, not all phones have such elements. In addition, the variety of SE elements and ways to use them in the phone makes this choice more difficult to implement, and therefore less attractive.
In this regard, the largest Association of mobile operators GSMA (GSM Association), which has more than 700 mobile operators in its ranks, adopted the so-called SIM-centric model, according to which the SIM/UICC card should play a Central role (the role of application Keeper) when using NFC for protected applications. In addition, the model assumes the presence of a separate NFC chip on the card, which acts as a communication processor (establishes an NFC Connection with an external device) and supports the SWP/HCI interface between the SIM/UICC card and the NFC chip, as well as the HCI interface with all other secure elements of the phone.
The SWP (Single Wire Protocol, ETSI TS 102 613) standard was approved by ETSI (European Telecommunications Standards Institute) in October 2007. It defines the OSI physical and channel layer protocols for high-speed full-duplex connections organized using the C6 pin (ISO 7816) of the SIM/UICC card. The standard was created based on the HDLC standard (ISO 13239), which describes the link layer Protocol (used in the X. 25 Protocol).
The HCI Protocol (Host Controller Interface, ETSI TS 102 622) was approved by ETSI in late February 2008. It is a transport layer Protocol between various elements of the SE phone and the NFC chip. The approval of the ETSI TS 102 622 standard has raised a storm of passions in the community of mobile operators and phone manufacturers. This was due to the fact that the standard allows you to organize the interaction of external systems with the elements of the se phone, so that as a result of communication for uploading data to the SE, the SIM card is controlled. This state of Affairs did not suit some phone manufacturers who want to download their own software to the phone without the control of the mobile operator.
As a result of the introduction of SWP and HCI standards, all technical issues related to the introduction of NFC on the phone were considered resolved. Currently, from a technical point of view, everything is ready to start mass production of NFC devices.
Obviously, the Issuer of the SIM / UICC card is a mobile operator (Mobile Network Operator, or MNO). Therefore, when using the SIM-centric model, there is immediately a conflict between mobile operators and issuers of applications from other service providers. Indeed, it is usually the mobile operators who manage the content of the SIM / UICC card. Obviously, for security reasons, this state of Affairs is not satisfied with the issuers of other apps (for example banks). Banks want to make sure that the payment application uploaded to the SIM/UICC card was not modified during the download process, was correctly installed, activated, or, on the contrary, was deleted during the download process. In addition, there is a question about the privacy and integrity of app personalization data.
In this regard, the GSMA Association, meeting the needs of the banking community, adopted the GSMA Pay-Bye-Mobile initiative, according to which a new participant-Trusted Service Manager (TSM) — appears in the NFC infrastructure designed to use a cell phone to implement secure applications.
The following players (managers) participate in the NFC ecosystem:
mobile operators (MNO)
service providers (Service Provider, or SP), such as banks, transport companies, retail and service companies, and so on.
trusted representative of TSM service providers;
Confidential Key Loading Authority (CKLA) — the authority responsible for loading the initial initialization keys of certain privileged applications to the SIM/UICC card.

The main function of TSM is to organize communication with mobile operators on behalf of numerous service providers. If there is a TSM, the operator (MNO) does not have to work with each service provider separately, but only interacts with their trusted representative, the TSM. Optionally, TSM can perform a number of commercial functions on behalf of SP, such as being a commercial agent of SP.
The variation of TSM technical functions is great. To the maximum extent, TSM functions include key management, downloading, installing, deleting, personalization of service provider applications, and quality control of services provided by the mobile operator.
To perform the functions of secure content management of a SIM/ UICC card, the GlobalPlatform platform that we discussed earlier is most suitable (see clause 2.7). Today, we recommend using the GlobalPlatform Card Specification V. 2.2 and GlobalPlatform UICC Configuration specifications to implement SIM/UICC content management
The latest specification is a guide to implementing the GlobalPlatform Card Specification V. 2. 2 in mobile communications and managing the secure delivery of new services. It defines each participant in the process of implementing a SIM / UICC card, and describes the roles and responsibilities of each player for various business models of card implementation.
The GlobalPlatform Card Specification V. 2. 2 offers a new business model for managing card content, in which service providers have the ability to fully control the card content in their allocated memory area of the card (the so-called Authorized Mode).
GlobalPlatform Confidential Card Content Management – Card Specification V. 2. 2 — Amendment A V. 1. 0 provides standard mechanisms for managing card content, including:
secure loading of the initial security domain keys by a third party.
secure download of app code;
secure transfer of APDU command scripts to a security domain in order to personalize the application associated with that domain or manage card content.