Verified EMV Software with reviews

The working place of the ECV testing complex is a special smart card reader with a license card installed and a payment card verification program that can only function if it detects a connected special device a smart card reader. Other smart card readers can also be connected to the workplace of the testing complex, but the presence of a special device with a license card installed is mandatory. This is only due to the fact that ScanTek licenses the use of the ECV testing suite using a license card.

All smart card readers that the ECV testing suite works with are PCSC devices. PCSC (correctly PC/SC) is an abbreviated name (Personal Computer/ Smart Card) of the Microsoft specification for integrating smart cards into the environment of personal computers. Microsoft implemented PCSC in Windows 200x/XP (and even made PCSC available in Windows NT/9x!). Interestingly, a free implementation (free software) exists even for Linux (as well as other Unixes) in the form of PC/SC Lite, and a not-quite-legal version of PC/SC Lite exists even for Mac OS X.

All this reasoning is interesting, but the payment card verification program only functions under the Windows operating system. The Windows 10 version is recommended, but in any case, the operating system version must be at least Windows 2000 / XP. Any versions of the program running Linux (and other Unix), as well as Mac OS, are not planned, and are unlikely to ever be implemented.

After starting the payment card verification program, a program window appears on the display screen of a personal computer running Windows. Of course, the window doesn’t look quite like that (or even quite like that). Because the figure shows groups of control elements that are used to regulate the process of studying the EMV application and monitor the progress of its implementation.

Further, the program features are discussed in detail in accordance with the selected groups of control elements. This is necessary so that the user can understand what features are available when analyzing an EMV application. Although the payment card verification program is thoroughly “documented” (when you hover the mouse over any control element, a hint is displayed, which serves as an additional means of training the user), but this does not mean that all the features will be transparent to the user and he will understand the logic of the developer.

Choosing a payment app

One of the main problems that arise when analyzing a card is to determine which payment applications are on the card. As mentioned earlier, there are two methods for selecting an application for a POS terminal: direct selection and selection from a list (PSE or PPSE). The terminal emulator allows you to do the same, but with some additional features. The definition of parameters for selecting the analyzed payment application.
But first you need to select the PCSC device in which the card will be installed. To do this, use combo-box1, which contains a list of all smart card readers connected to the computer. The list of devices is created when you run the payment card verification program. If a new PCSC device is connected dynamically during operation, it is enough to build the list of devices again.

A combo-box is a control that is a combination of a list of items and an edit line. In the future, such a control will be called a combo-box, because for IT specialists, translation can lead to a misinterpretation of the term.

The method used to select the analyzed payment application is specified by the parameters that are determined using the remaining control elements.

First, you can explicitly specify that an application with the specified ID (AID) should be selected on the card. To do this, in the combo-box “Application”, select a line with one of the standard AIDS corresponding to the payment application.

Secondly, you can specify that a list of candidate applications should be built and the analyzed application should be selected from this list. The list of candidate applications is constructed as follows:
an attempt is made to find on the card all applications whose AID begins with RID1 of the payment systems listed in the combo-box list. Any found application is checked and established whether it is a payment application, if the application is a payment application, it is entered in the list of candidate applications

1 RID is the first five bytes of the AID that are assigned to the payment system and uniquely identify it. For example, for MasterCard, a RID is assigned in the form A000000004 and the AID of all MasterCard card products must start with this RID.
2 Not all applications on the card with the payment system’s RID are necessarily payment applications. There may be special service applications on the card that relate to the payment system, but can not be used by the terminal to conduct a transaction.

Third, the application of interest can be defined explicitly. To do this, select the line “Explicit application definition” in the combo-box list, and then enter the application’s AID in the “AID” edit element. In this case, you may need to select the application type from the combo-box “Type” list.»

Finally, the app can be selected from the PSE list (for contact mode) or the PPSE list (for contactless mode), if they are on the card. In this case, the final choice of the application is left to the user. It should select the analyzed application from the list that will be displayed on the screen

Defining terminal parameters

To perform a transaction, the terminal emulator must be configured accordingly. The fact is that the execution of the transaction depends on the type and capabilities of the terminal, the acquirer’s policy in the field of security of payment transactions, and many other parameters that the servicing bank usually uploads to the real terminal. For the terminal emulator, all these parameters can be changed dynamically before executing a transaction, which allows you to check different behaviors of payment applications.

The user can define the following.
The type of terminal, its capabilities, as well as additional features that determine the physical features of the POS terminal and the types of transactions allowed.
Conditions for making a decision about processing a transaction, which are set for the terminal in the form of Terminal Action Codes (TACs).
The country where the terminal is located (the payment application can be configured to make a decision about processing a transaction, depending on whether the transaction is domestic or international).
Terminal risk management parameters for contact transactions.
Risk management parameters for contactless transactions, which usually depend on the payment system.

Defining keys

Let’s analyze why the terminal needs public keys of payment systems (more precisely, the keys of payment system certification authorities) to perform a transaction. As described earlier (see the section “Security Issues”), in order to gain access to the card’s public RSA key, the terminal must first recover the issuer’s public key from the certificate of this key signed on the Certificate Authority’s secret key (CA). And why does the terminal need a public RSA key of the card? First, to perform offline data authentication. Secondly, to encrypt the PIN code, if the cardholder verification method “Presenting the encrypted PIN code to the card” is used. And the absence of a payment system certificate authority key can affect (and very significantly) the progress of the transaction.
In this regard, the ECV testing complex has a database with all known public keys of payment systems. But even if some payment system is not in the database, or the necessary key is missing for it, it is easy to fix it. You can create a new payment system with a specific RID, or block all the keys of a particular payment system (the blocked keys are not deleted from the database, but become inaccessible to the terminal emulator). In addition, a new key can be created for any payment system or an existing one can be deleted.

With the keys of the payment application, everything is not as simple as with the public keys of payment systems. To complete the transaction does not need them, but in some cases may require the terminal to perform the following functions:

• check the transaction cryptogram (AAC, TC or ARQC) generated by the card
• generate a cryptogram of the Issuer in response to the authorization request in the case of an emulation of online processing
• create script commands, the processing used by the Issuer to modify the information on the card (again, in the case of an emulation of online processing)

Although it is tempting to use payment application keys in the terminal emulator, it is not always possible – there are a number of restrictions. First, the emulator implements only algorithms for the application created according to the EMV CCD (Common Core Definitions) specifications. Secondly, the process of key diversification, generating session keys and calculating cryptograms, and forming script processing commands is so multi-stage and complex that a lot of preparation is needed to use the payment application keys in the terminal emulator. Of course, the final decision is left to the user of the test suite.

Transaction Parameters

The group of control elements for entering payment transaction parameters includes the following objects:

• combo-box for determining the type of payment operation (transaction)
• payment transaction
• amount cashback amount (used only for purchases with cashback – cashback; in all other cases, it must be equal to 0)
• combo-box for determining the currency of the payment operation

In addition, this group of controls also includes an edit line for entering the PIN code of the cardholder. The value specified as the PIN code is used only if, as a result of analyzing the list of verification methods for the cardholder, it is established that the PIN code is required to be presented to the card. If the PIN code is not specified and it is required to be presented to the card, it is considered that the cardholder refused to enter the PIN code.

For online verification, the PIN value is not used, since the terminal emulator does not generate data for the issuer. It is always assumed that the correct PIN code is presented.

Be careful and do not forget that the PIN code that is suitable for the current card will most likely be incorrect for the next card. Therefore, do not forget to change the PIN code value for each analyzed card. It is recommended that after checking the next card, delete the value in the edit line for entering the PIN code.

Online Processing Emulation parameters

It should be said right away that online processing is modeled only for contact mode, since in contactless mode, the terminal emulator always performs a transaction in one touch to the terminal. After working with the card and receiving all the data from it, the emulator considers that the processing is complete. In the real terminal, the issuer’s response is analyzed, and a decision is made to approve or reject the transaction. These actions are never performed in the terminal emulator, because they will not provide anything new for checking the payment application.