EMV Software - Chip Writer

For the contact mode, emulation of the online mode makes sense, since work with the card after receiving all the data from it to form an authorization request to the issuer has not yet been completed. In real life, the terminal sends a message to the host of the servicing bank, which contains information about the transaction. Based on this data, the host of the servicing bank generates an authorization request (message x100 of the ISO 8583 standard).

But the terminal emulator is not intended for communication with the servicing bank and the issuer. No messages to the host of the servicing bank or authorization requests to the issuer are generated. Instead, the emulator can simulate various options for receiving the issuer’s response (or its absence).

The main parameter for emulating online processing is the simulated situation, selected from the list of options defined by the combo-box “Type GAC2” 1. From the list defined by this element, one of the following terminal actions is selected when executing the second GENERATE AC command:
the AAC cryptogram (transaction rejection) must be
requested the TC cryptogram with the simulation of the “Unable to go Online”situation is requested

• the TC cryptogram is requested (the situation “The issuer’s data is not provided” is simulated)

• the TC cryptogram is requested (the “Issuer authentication failed” situation is simulated for the payment application)

• in the second GENERATE AC command, the TC cryptogram is requested and the issuer’s data is provided, which allows the payment application to successfully authenticate the issuer (a full-fledged issuer response is simulated for the application)

Further discussion of the features of the above options is still to be done, but in the meantime, we need to discuss other parameters for emulating the online mode. It should be said right away that the online mode emulation was developed for applications that meet the EMV CCD (Common Core Definitions) specifications. And for a number of payment applications, the online mode parameters (data objects) are not used (not applicable).
One of these data objects is the Card Status Update (CSU), which indicates whether the transaction was approved or rejected by the issuer, and also determines the actions that, from the issuer’s point of view, should be performed by the card. Feature detection in the CSU is ignored if the issuer’s host does not need to use the CSU to manage the payment application. This refers to the type of the requested cryptogram in the second GENERATE AC command. From the following it will be clear that the list determines not only the type of cryptogram requested, but also various options for online processing.

But the script processing commands are formed in accordance with the EMV CCD specifications. The fact is that the issuer uses the Secure Messaging algorithm when creating script processing commands. The main goals of Secure Messaging are to ensure data integrity, provide the ability to authenticate the data source and guarantee the confidentiality of secret data. The Secure Messaging algorithm for the EMV CCD application is implemented in accordance with Secure Messaging Format 1, which is described in the document “EMV. Integrated Circuit Card Specifications for Payment Systems. Book 2. Security and Key Management. Version 4.2. June 2008».

Two important conclusions follow from this. First, if the script-processing commands for the analyzed payment application are not formed in accordance with Secure Messaging Format 1, then the tool for determining script-processing commands provided in the testing package cannot be used. Secondly, as you can easily guess, to create script processing commands, the terminal emulator requires the keys of the payment application (see the section “Defining keys”).
And now we return to the discussion of the options for the actions of the terminal emulator when executing the second GENERATE AC command. As described above, to emulate online processing, the user can choose one of five options. The actions of the terminal emulator depend on the selected option. But in any case, the emulator performs the following:

• before executing the second command, GENERATE AC passes critical script processing commands to the card, if they are defined

• after executing the second command, GENERATE AC sends critical script processing commands to the payment application, if it is used

The rest of the actions of the terminal emulator depend on the selected scenario.

Rejection of the transaction.

In this case, the actions of the terminal emulator are not at all interesting, since the payment application ignores the data provided in the second GENERATE AC command and always returns the AAC cryptogram (transaction rejection)

Approving a transaction in a “Unable to go Online”situation
The terminal emulator informs the payment application about this situation in the second GENERATE AC command, requesting approval of the transaction. Zeros are usually passed instead of the issuer’s data.

The approval of a transaction in the situation “The issuer’s data is not provided”
is not much different from the situation “Unable to go Online”. But there are differences in the data transmitted to the payment application in the second GENERATE AC command, and therefore the behavior of the payment application may differ.

Transaction approval and simulation of the “Issuer authentication failed”situation
The terminal emulator requests approval of the transaction in the second GENERATE AC command, passing a random number as the issuer’s cryptogram (it is assumed that it will never match the cryptogram that the issuer should form in response to the authorization request).

Approval of the transaction with full emulation of the issuer’s response
The second GENERATE AC command requires approval of the transaction with the provision of data that allows the payment application to successfully authenticate the issuer and perform the actions requested by the issuer. For this option, the terminal emulator requires the keys of the payment application (see the section “Defining keys”).
It remains only to describe two switches. The “CDA” switch allows you to request a Signed Dynamic Application Data certificate from the payment application (used for the CDA offline authentication method), not only in the first, but also in the second GENERATE AC command. Although at first glance this possibility seems superfluous, but obtaining a certificate of the CDA method in the second GENERATE AC command is defined by the EMV specifications for special cases. Thus, the “CDA” switch allows you to check whether the payment application is able to provide a Signed Dynamic Application Data certificate in the second GENERATE AC command.

The “Reject in case of Unable to go Online” switch reflects the possibility that is available to the servicing bank to configure a terminal that works only in online mode. For such terminals, it can be determined that in the situation of Unable to go Online, the transaction should be rejected without a TAC/IAC analysis.

Additional checks

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)

• PPSE (Proximity Payment System Environment) analysis
• displaying information from the transaction log of the payment application, if it is supported getting and analyzing objects using the GET DATA command.

Checking the PSE

In contact mode, PSE (Payment System Environment) can be used to select a payment application, and the testing package allows you to check it. In terminology, EMV is a directory, but in fact it is an application with the identifier 1PAY.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 records of this file and extracts information about 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 the identifier 2PAY.SYS.DDF0. In response to the SELECT command, the PPSE application returns an FCI object containing information about contactless applications on the card. Using the received information, the terminal emulator checks the list of contactless payment applications defined in the 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 in which transactions are recorded. The terminal emulator allows you to read transaction log entries and display information from these records. It should be borne in mind that the transaction log for any payment application is optional.

Getting objects using the GET DATA command

But not all the data of the payment application is located in the file records (file records are read by 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 data objects of the payment application that are read using the GET DATA command are not needed to perform a transaction. The terminal emulator can read certain objects to inform the user about why the card made a decision to process the transaction that differs from the terminal’s decision. But the terminal emulator never reads additional objects that it does not need, unless the “Getting objects by the GET DATA command”switch is enabled. Setting this switch causes the terminal emulator to read all the objects of the analyzed payment application known to it. The information from the read objects is checked and explained.

If the “Getting objects by the GET DATA command” switch is enabled, then the “Search for unknown objects” switch can also be set, informing that a search is required for all objects of the payment application (even those 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 type of payment application is not defined, the availability of all objects is checked, except for standard EMV objects. There are a lot of 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, the setting of this switch is ignored.

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 a particular discrepancy affects the further course of testing.

The two remaining features are very often required when checking a payment application. First, you can determine that a complete trace of the cryptographic operations being performed is required. Secondly, the entire exchange of the testing complex with the card can be recorded.

If these features are often 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. That is why the protocol given in the document (see the chapter “Applications”) was created without using these options. In many cases, additional data about the exchange with the card and cryptographic operations are not needed. As soon as the user decides that he will need this additional data, he can always enable the options for additional traces.
When it is determined that the execution of cryptographic operations should be recorded in the protocol, an explanation of how the testing complex implements cryptographic checks will be formed in the log. For example, a fragment of the protocol is shown with the execution of a cryptographic operation to verify the issuer’s public key certificate. For any cryptographic operation, the initial data, intermediate results and the results of execution (verification) are always given.

Tracing cryptographic operations.

If the data exchange trace with the card is set, the protocol will contain information about the commands transmitted to the card and the response received from the card. A fragment of the protocol with data exchange tracing enabled with the card (the lines explaining how to work with the card are highlighted in red). For any command, its encoding, the data transmitted with the command, as well as the data received from the card and the status bytes (the card return code) are displayed. It should be borne in mind that the tracing of actions with the card does not depend on any other tracing. Therefore, redundant data may appear in the protocol (for example, the card’s response to the GET PROCESSING OPTIONS command is given in two places).