Verified EMV Software with reviews

Basic concepts

The ECV Testing suite (EMV Card Verification) is designed for testing EMV applications on smart cards. ECV allows you to check the completeness of the data on the card and the performance of the card when servicing transactions, perform cryptographic functions of the EMV application, identify the causes of failures in the operation of already issued cards, and much more.

ECV is a point-of-sale (POS) terminal emulator with a number of additional features that are not available in the POS terminal. The EMV application tested by ECV can be placed either on a contact card (meeting the ISO/IEC 7816 specifications), or on a contactless card or mobile device (interacting with which is based on the protocols described in ISO 14443). The payment application selects the transaction processing mode (contact or contactless) automatically, depending on the method of using the media. Therefore, the payment applet can be placed on a card with two types of interfaces – contact and contactless (dual interface card). The mobile device always communicates with the POS terminal via NFC and emulates the operation of a contactless card.

Although ECV emulates transaction processing in contact and contactless modes, there is a big difference between these modes. In contact mode, any EMV application works according to the specifications defined in EMV. Integrated Circuit Card Specifications for Payment Systems. This is due to the fact that in contactless mode, due to certain restrictions, it is impossible to fully support the same transaction processing algorithm as in contact mode.
There is no single specification for contactless mode. Each payment system (for example, Visa, MasterCard, …) has implemented its own algorithm for processing in contactless mode, and the EMV Contactless Specifications for Payment Systems are nothing more than a set of general provisions for processing a contactless transaction in a POS terminal. For each the concept of the core (Kernel), which is responsible for processing a contactless transaction for this (and only this) system, is introduced. The information provided in the EMV Contactless Specifications is usually not sufficient to implement the contactless transaction processing core in the terminal. In addition to the open EMV Contactless Specifications, we also need specifications for the operation of the payment application in contactless mode for a specific payment system. And these specifications are provided only to the partners of the payment system (in other words, they are bought for a lot of money).

In this regard, the main difference between the processing of a contact and contactless transaction in ECV is as follows.
The processing of a contact transaction is regulated by strict EMV specifications. Integrated Circuit Card Specifications for Payment Systems, in connection with which this process is fully defined and can be performed by the terminal emulator for the EMV application of any payment system.
The processing of a contactless transaction is described by the general EMV Contactless Specifications and depends on the payment system. The terminal emulator does not process contactless transactions for everyone, but only for some payment systems.

Before you start using the ECV testing package, it is recommended to familiarize yourself with the following concepts:
the format of data objects exchanged between the card and the terminal
the main stages of performing a transaction in contact mode
features of performing a transaction in contactless mode.
A brief explanation of these entities is given in the following sections of the chapter. If you are familiar with the subject, you can skip to the next chapter.

Data elements and objects

Any EMV application uses some set of data elements. Data elements are logical structures that, if necessary (for example, when transmitting data to a terminal), are card to data objects. There are different ways to card data items to data objects. The EMV specifications use the BER-TLV encoding formalized in the ISO/IEC 8825 standard. According to ISO / IEC 8825, any data object is defined by two or three fields: Tag, Length, and Value. The value field must be omitted if the length is 0. The tag field consists of one or more bytes (in EMV specifications, one or two bytes). The structure of the tag field is shown in the following tables.
The structure of the first byte of the tag field. In EMV specifications, a composite data object is called a template (for example, an FCI Template).

The data object length field defines the number of bytes in the object value field. In the EMV standard, the length field is set to one, two, or three bytes. If the highest bit of the leftmost byte of the length field is 0, then the length field takes up one byte and defines the length of the value from 0 to 127. If the highest bit is 1, then the subsequent bits determine the number of additional bytes used to represent the length field.

The BER-TLV data encoding method described above allows you to uniquely determine its ID, size, and value for a specific data object. Thus, the BER-TLV encoding is a universal means of representing data.

Lists of data objects

To execute a number of commands, the card requires transaction parameters and terminal capabilities. For most EMV applications, this data is required for the first and second GENERATE AC commands, as well as for the GET PROCESSING OPTIONS command. The list of data objects required to execute the command is generally called the Data Object List (DOL). For specific teams, the names of the lists are specified. For example:

• Card Risk Management Data Object List 1 (CDOL1) – list of data objects for the first GENERATE AC command
• Card Risk Management Data Object List 2 (CDOL2) – list of data objects for the second GENERATE AC command
• Processing Options Data Object List (PDOL) – a list of data objects for the GET PROCESSING OPTIONS command

Any list of data objects is a list of tags and lengths of data objects that should be passed to the card. All lists are written to the card during its personalization and are read by the terminal using the READ RECORD command. The terminal sends only the values of the objects listed in the lists in the corresponding commands.

Transaction in contact mode

General scheme of transaction processing in contact mode. The diagram below does not show all the features of the card operation in the terminal, but it allows you to understand how the card (payment application) participates in this operation. In addition, the following description of transaction processing in contact mode lacks important details, which are omitted, since the purpose of the document is not to define the transaction processing process, but to describe the process of interaction between the terminal and the card.

The payment operation begins with the terminal selecting the payment application on the card. To perform a transaction, the terminal must support the payment application that is located on the card. At the stage of selecting an application, the terminal checks whether there is such an application (if there are several applications supported by the terminal on the card, then the terminal and, possibly, the cardholder choose which of them should be used to perform the current transaction).

There are two ways to select an application: selection via PSE (Payment System Environment) and direct selection. PSE is a list with the ID 1PAY. SYS.DDF01, which lists all the payment applications on the card. But PSE is not mandatory. Therefore, the terminal can find all the applications that it processes on the card and make its own list of candidates for processing. In any case, to select the application to be processed, the SELECT command is used, as a result of which some data about the selected payment application is transmitted to the terminal. 1
After the application is selected, the terminal initiates the transaction. To do this, use the GET PROCESSING OPTIONS command, which the terminal uses to tell the card the data it needs in order to determine the specifics of the operation being performed.2 In response to the GET PROCESSING OPTIONS command, the card informs the terminal of its transaction execution capabilities and terminal requirements (via Application Interchange Profile – AIP) and provides links to the data that the terminal must read in order to successfully complete the transaction (defined in Application File Locator-AFL).

1 This data is called File Control Information (FCI) and contains the application ID
(AID), the application label, and the preferred languages of communication between the terminal and the cardholder.
2 The data required by the card to initiate a transaction is defined in the Processing Options Data Object List (PDOL) provided in response to the SELECT command. If no data is needed from the terminal, then there is no PDOL list, and no data is transmitted with the GET PROCESSING OPTIONS command.

The terminal reads all the records specified by the card using the READ RECORD commands and proceeds to perform offline authentication of the data provided by the card. At this point, only SDA or DDA authentication can be fully performed. Data authentication using the CDA method (due to the implementation features) is performed completely only after receiving a response from the first GENERATE AC command.

• The terminal then proceeds to perform the procedures for checking the restrictions on the use of the application (checking the version numbers, checking the validity of the card, etc.) and checking the stop lists.
• The terminal looks through the list of cardholder verification methods provided by the card, selects the appropriate method, and verifies the cardholder.
• The terminal, at the direction of the card, can also perform risk management procedures that control the amount and number of consecutive transactions performed offline.

Next, the terminal analyzes the results of the checks performed by it using the criteria formulated to the terminal by the servicing bank and the card issuer. As a result, the terminal makes one of three decisions about processing the transaction:

• Approve the transaction offline.
• Transfer the transaction for authorization to the card issuer.
• Reject the transaction in offline mode.

The terminal informs the card about its decision using the first GENERATE AC command. Together with the GENERATE AC command, the transaction data, the results of the terminal’s risk management procedure, and the terminal’s banking details are transmitted to the card. Based on the data obtained, the card performs its own risk management procedures and analyzes the results of its audits using the criteria formulated by the card issuer. As a result, the card makes its own decision to process the transaction – one of the three decisions described above, but the rank of the card’s decision is always not lower than the rank of the terminal’s decision (for example, if the terminal has decided to reject the transaction, the card has no right to change this decision). In EMV, this dependency is fundamental and is controlled by both the card and the terminal.
If the card decides that the transaction should be sent to the issuer for authorization, the card forms a special cryptogram, which is a signature of the transaction details, the card and the terminal. In all other cases,cryptograms are generated that inform about the completion of the transaction (approval or rejection of the transaction in offline mode). In addition, in the case of using the CDA authentication method, the cryptogram is entered in a special data packet, which is encrypted on the card key and serves for offline data authentication by the terminal.

The terminal, having received data from the card by the GENERATE AC command, authenticates the card if the CDA authentication method is used (decrypts the data packet with a cryptogram and makes sure that the data in the packet is correct). The terminal then checks which cryptogram the card returned. If the cryptogram of approval or rejection of the transaction in offline mode is returned, then the processing is completed. When a transaction is to be sent for authorization to the issuer, the terminal sends (via the host of the servicing bank) the cryptogram and other transaction-related data to the issuer.

After receiving the data, the issuer authorizes the transaction (checks the cryptogram and some other parameters). Based on the results of these checks, the issuer decides whether to reject or approve the transaction, and, in turn, generates a cryptogram that is used by the card to authenticate the issuer. The issuer’s response is sent to the servicing bank, which sends it to the terminal.

The issuer’s response may contain script processing commands intended for the card. With these commands, the issuer can change the parameters of the payment application, unlock or change the PIN code, and block the card application. The issuer can assign each script processing command the status of critical (the command is sent to the card immediately after receiving it by the terminal before checking the issuer’s response) or non-critical (the command is passed to the card after checking the issuer’s response).
After receiving the issuer’s response, the terminal sends the card the issuer’s decision, the issuer’s cryptogram, and the updated data of its checks in the second GENERATE AC command (or the EXTERNAL AUTHENTICATE command, if the payment application uses this command to verify the issuer’s response). The card authenticates the issuer by verifying the cryptogram. If the issuer’s authentication is successful, the card fulfills the issuer’s decision to complete the transaction and generates a cryptogram of approval or rejection of the transaction. When the issuer’s authentication fails, the transaction is usually rejected.
Below is a more detailed description of the individual stages of transaction processing and the data objects exchanged between the terminal and the card.

Data on the card

The data that is required to complete the transaction is read by the terminal from the records of the payment application files using the READ RECORD command. But not all the data that the terminal may need is located in the file entries. Some data is stored as separate objects and, if necessary, the terminal extracts it from the card using the GET DATA command.
Security issues
The most important feature of a payment application is the use of cryptographic functions to improve the security of financial transactions. The main tasks for improving the security of financial transactions, solved by the application, are as follows.

Providing authentication of the application on the card (or authentication of the card). Card authentication refers to the process of proving its authenticity, i.e. the fact that the card was issued by a bank authorized to issue cards. In the case of an offline transaction, the issuer fully delegates to the card the function of making a decision on the result of the operation. Obviously, you can only trust the decisions of the card, the authenticity of which is proven. That’s why its reliable authentication is so important. The card is authenticated by the terminal and / or the issuer. In offline operations, the card is authenticated only by the terminal and is called offline authentication. In the case of an online transaction, the card can be authenticated by both the terminal and the issuer. The card authentication performed by the issuer is called online.
Ensuring the issuer’s authentication and verifying the integrity of the data sent to them by verifying the signatures of the data generated by the issuer.

Guarantee to the issuer that the cardholder cannot refuse the result of the performed operation. This is ensured by the fact that for each completed transaction, the issuer receives an application cryptogram from the card, which is a signature of the most critical transaction data. The correspondence of the cryptogram to the transaction data confirms the fact of its execution.

Checking the integrity of the critical data exchange between the card and the terminal. Ensuring the confidentiality of data in the information exchange between the card and the issuer, the card and the terminal. Providing a mechanism for reliable verification of the cardholder through offline PIN verification.

The payment application implements transaction security functions based on the RSA asymmetric encryption algorithm and the DES symmetric encryption algorithm used in the EMV standard.

First, consider the RSA encryption algorithm. Apart from the RSA terminology, which can sometimes be confusing, asymmetric encryption is based on the fact that there are two keys – a public key and a secret key. If the data is encrypted on the public key, it can be decrypted on the private key and vice versa. The need to use asymmetric encryption algorithms in security procedures is caused by the fact that the terminal should not have the secrets of the card (symmetric encryption always implies that the participants in the information exchange know the general secret).
In order for the terminal to use the asymmetric keys of the card to implement security functions, it is necessary to create a PKI infrastructure (PKI – Public Key Infrastructure). The PKI infrastructure of the payment system in accordance with the EMV standard

The root of the PKI infrastructure is the Certification Authority (CA) of the payment system. The certification authority generates RSA key pairs (public and secret) and sends the public keys to the servicing banks for uploading them to the payment system terminals. At the second level of the PKI infrastructure tree, there are certification centers for issuers participating in the payment system. These centers also generate RSA key pairs and receive public key certificates from the CA. A public key certificate represents the details of the public key (including the public key itself), its validity period, issuer ID, etc., signed on the secret key of the payment system certification authority.

Finally, at the lower level of the infrastructure, the public and private keys of the issuer’s cards are located. The public keys of the cards are signed in the issuer’s certification authority on the secret key of the issuer’s certification authority.

In the process of personalization of the payment application, the issuer’s public key certificates and the card’s public key, as well as the card’s secret key, are written to the card.

In order to obtain the card’s public key, the terminal reads the issuer’s and the card’s public key certificates from the card. Then, using the CA public key stored in the terminal, the terminal verifies the validity of the issuer’s public key certificate.

After proving the validity of the issuer’s public key certificate, the terminal uses the restored issuer’s public key to verify the validity of the card’s public key certificate. If the certificate is correct, the terminal gets access to the card’s public key. The public key of the card is used by the terminal to authenticate the application on the card and encrypt confidential data sent to the application (for example, the PIN code). The application is authenticated by verifying the signature of certain data generated by the card on the card’s secret key. If the card signature is correct, it means that it was made by the card’s secret key corresponding to its public key certified by the issuer. This in turn means that the card was issued by the issuing bank, whose public key was certified by the payment system certification authority. Thus, the fact of issuing the card by the bank authorized to issue the payment system cards is proved.
To generate application cryptograms, signatures of data transmitted between the issuer and the card, as well as to encrypt the exchange

1 In EMV terminology, the Sign function on the secret key is used to generate certificates. This function encrypts the certificate on the secret key and it can only be decrypted on the public key corresponding to the secret key.
2 The certificate is decrypted on the public key. In EMV terminology, this function is called Recover. As a result of decrypting the certificate, the terminal gets access to the issuer’s public key, which is stored in the certificate. But the certificate may not store the entire public key of the issuer, but only a part of it. The other part of the key is extracted from a data object called the Issuer Public Key Remainder.

To be fair, the set of secret keys in the payment application is determined by the developer. Therefore, it is not necessary to talk about any standards. For example, you can see which keys are used in an application created according to the EMV CCD (Common Core Definitions) specifications:
Ka key (Application Cryptogram Key) – used to calculate application cryptograms
Ki key (MAC Key) – used to calculate the data signature
(Message Authentication Code-MAC) in script processing commands
Kc key (Encryption Key) – used to encrypt confidential data in script processing commands

The issuer stores only the master keys of the symmetric cryptographic algorithm, which are transformed (diversified) into unique keys of the payment application during the card personalization process (the issuer’s master key can be diversified in several ways using Application PAN and Application PAN Sequence Number). Thus, each payment application uses a set of unique keys for cryptographic operations. Moreover, the payment application’s unique key is diversified for each transaction into a session key. To get the session key, use the Application Transaction Counter – ATC) – a counter that increases with each transaction.
As a result, for each transaction, the card and the issuer use a unique key of a symmetric cryptographic algorithm, which significantly increases security.

Verification of the cardholder

Verification of the cardholder is performed in order to establish the identity of the person who received the card from its issuer (the bank’s client) with the person performing the card transaction. The key data object for cardholder verification is the Cardholder Verification Method (CVM) List object, which is stored on the card. This object defines a list of methods and conditions for verifying the cardholder.

One of the main methods of cardholder verification is the PIN verification procedure. PIN verification, although it is only one of the possible verification methods, has become widespread due to its reliability and efficiency.

There are two different methods of offline PIN verification:
– verification of the PIN code transmitted to the card in clear text
– verification of the PIN code transmitted to the card in encrypted form
Offline PIN verification always starts with the terminal issuing the GET DATA command to get the PIN Try Counter data object. The value of this object is the number of remaining attempts to enter the PIN code. If the cardholder still has attempts to enter the PIN code, the terminal receives from the cardholder the value of his PIN code (from 4 to 12 digits) and forms a PIN block from the PIN code in ISO Format 2

If the CVM specifies that the PIN code must be presented in unencrypted form, the terminal sends the VERIFY command to the card, the data field of which contains the value of the PIN block in ISO Format 2. When the PIN code must be presented in encrypted form, the terminal first receives a random number from the card using the GET CHALLENGE command, then generates a PIN certificate that contains the PIN block and the received random number, and encrypts the certificate on the card’s public key. The encrypted PIN certificate is sent to the card as the data of the VERIFY command. The card compares the received PIN value with the value stored on the card (by first decrypting the PIN certificate on the card’s secret key and verifying the certificate when necessary). If they match, the PIN verification is considered successful. Each time an incorrect PIN code is presented, the number of remaining attempts to enter the PIN code is reduced by 1 (when zero is reached, the PIN code will be blocked).
Online PIN verification has nothing to do with the card. The PIN input device requests the PIN code from the cardholder and encrypts it using a special algorithm, usually using the DUKPT (Derived Unique Key Per Transaction) algorithm. Verification of the cardholder by the terminal is completed at this point, since the PIN code value is checked by the issuer, not the card.