Control the security of the EMV standard

Additional check

A group of control elements that define additional checks that are performed during the card analysis process allows you to perform the following checks:
▪ checking the PSE (Payment System Environment)
▪ analysis of the PPSE (Proximity Payment System Environment)
▪ display information from the payment application’s transaction log, if supported
▪ getting and analyzing objects using the GET DATA command

The following is a brief description of these additional features for checking the payment application and its environment. PSE verification in contact mode, you can use PSE (Payment System Environment) to select a payment application, and the test Suite allows you to verify it. In terminology, EMV is a directory, but it is actually an application with the 1pay ID.SYS.DDF01. The terminal emulator first selects the PSE application on the card, which returns the SFI of the file with the list of applications on the card. Then, sequentially, using the READ RECORD command, it reads the entries in this file and extracts information about the payment applications present on the card from them. PSE analysis is never performed in non-contact processing mode.

PPSE analysis
In contactless mode, the procedure for selecting a payment application is based on using the PPSE (Proximity Payment System Environment) application, which has a 2PAY ID.SYS.DDF0. In response to the SELECT command, the PPSE application returns an FCI object containing information about contactless applications on the card. Using this information, the terminal emulator checks the list of contactless payment applications defined in PPSE. PPSE analysis is never performed in contact processing mode. Displaying information from the transaction log a Number of payment applications may have a transaction log – a special file where transactions are registered. The terminal emulator allows you to read transaction log entries and display information from these entries. Keep in mind that the transaction log for any payment application is optional.

Getting objects using the GET DATA command But not all payment application data is located in file records (file records are read using the READ RECORD command). Some data is stored as separate objects, and if necessary, the terminal extracts them from the card using the GET DATA command. For example, offline PIN verification always starts with the terminal issuing the GET DATA command to get the PIN Try Counter object. The value of this object is the number of remaining attempts to enter the PIN code. Most of the payment application data objects that are read using the GET DATA command are not needed to complete the transaction. The terminal emulator can read certain objects to inform the user about why the card made a decision to process a transaction that differs from the terminal’s decision. However, the terminal emulator never reads additional objects that it doesn’t need, unless the “Get objects using the GET DATA command”switch is enabled. Setting this switch causes the terminal emulator to read all known objects of the analyzed payment application. Information from the read objects is checked and explained. If the “Get objects using the GET DATA command” switch is enabled, then the “Search for unknown objects” switch can also be set, informing you that you need to search for all objects of the payment application (even those that are not defined in the specifications) that can be obtained using the GET DATA command. When the switch is set, all objects are read sequentially by tags that are not defined in the specifications of the analyzed payment application. If the payment application type is not defined, the availability of all objects except standard EMV objects is checked. There are many such objects (more than 1000), so it is not recommended to use this feature unnecessarily (searching for objects can take several tens of seconds). When performing a transaction in contactless mode, in most cases, setting this switch is ignored.

Event log
The log of events recorded during the operation of the test Suite is the main source of information about the operating environment, the results of card verification, data analysis, and so on. the event Log (Protocol) is displayed in a separate window of the program and can be viewed at any time when working with the test Suite. In addition, the Protocol is always saved in the current directory (the directory from which the program is launched) in a file named Card Verification Log.x.y, where x is the date and y is the time when the Protocol file was created. Usually, the log contains a lot of data. To make it easier to navigate and find the information you need, there are log management buttons

Two arrow buttons allow you to go to the beginning of the card research with the payment application in the Protocol window. For example, suppose that the window displays a fragment of card study 3. Then pressing the up arrow button will set the Protocol to the beginning of the card study 3, pressing it again will set it to the beginning of the card study 2, and so on. Similarly, clicking the down arrow button will set the Protocol to the beginning of the card study 4, and clicking again will set it to the beginning of the card study 5… the Last button is used to save the Protocol to a file and simultaneously clear the Protocol window. You should immediately say that the Protocol is saved in a file in any case, and this is usually done automatically. Clicking the save Protocol button leads to the following.
▪ All lines presented in the Protocol window are written to a file named Card Verification Log.x.y. this file is created when you run the test Suite, and it is always the same (a new file will only be created the next time you run the test Suite).
▪ All lines are deleted from the Protocol window (the window is cleared). Thus, the save Protocol button allows you to withdraw information from consideration if it is no longer needed now. Of course, this information is not lost and can be analyzed later.

Control button
To manage the ECV test Suite, use the buttons to control the test Suite.

When you click on these buttons, the test Suite informs you that the user wants to perform a specific action related to determining the operation parameters, checking the card, or viewing the parameters of the payment application. The following explains in detail what actions are performed when the control buttons are pressed. Options the “Options” Button allows you to configure the options for the operation of the test Suite, shown in Fig. 13 in the “operation Options” window. Among the customizable options, there are service features (for example, deleting outdated protocols and banning sounds when certain events occur) that allow you to adapt the testing package to the user’s requirements and do not affect the verification of payment applications in any way. There is also a rather strange option “incomplete compliance with EMV specifications is allowed”. At first glance, this is a” harmful ” feature, but it allows you to continue checking the application even if errors have already been detected (for example, this is useful when checking key certificates). This feature is not recommended for inexperienced users, as it can be quite difficult to assess how much this or that discrepancy affects the further course of testing. The two remaining features are often required when checking a payment application. First, you can determine that a full trace of the cryptographic operations being performed is required. Second, the entire exchange of the test Suite with the card can be recorded. If these features are frequently used, why are they optional? The answer to this question is quite simple. Both the tracing of cryptographic operations performed and the tracing of data exchange with the card leads to the fact that the verification Protocol of the payment application becomes very large. This is why the Protocol shown in the document was created without using these options. In many cases, additional data about card exchanges and cryptographic operations is not needed. Once the user decides that they need this additional data, they can always enable additional trace options. When it is determined that the execution of cryptographic operations should be recorded in the Protocol, the log will generate an explanation of how the test Suite implements cryptographic checks. Above is a fragment of the Protocol that performs a cryptographic operation to verify the Issuer’s public key certificate. For any cryptographic operation, the source data, intermediate results, and execution (verification) results are always provided.