Tracing cryptographic of EMV operations.

Tracing cryptographic operations.

If you set a trace for data exchange with the card, the Protocol will contain information about commands sent to the card and the response received from the card. For rice. 15 shows a fragment of the Protocol with the enabled trace of data exchange with the card (the lines explaining how to work with the card are highlighted in red). For any command, its encoding, data transmitted with the command, as well as data received from the card, and status bytes (the card return code) are displayed. Keep in mind that the card activity trace does not depend on any other trace. Therefore, redundant data may appear in the Protocol (for example, in Fig. 15 the card’s response to the GET PROCESSING OPTIONS command is shown in two places).

Trace data exchange with the card.
Personalization. The “Personalization” button is used to start the process by which you can check the correct personalization of the payment application for the card issue task (a file with data for personalization of the EMV application) generated by the personalization data preparation subsystem from the input data of the issuing Bank’s back office. The use of this function is limited primarily by the fact that to verify the correct personalization of the payment application, an XML File prepared by the OpenWay personalization subsystem (Way4 Smart card Perso) for an external person Bureau is required. The test Suite does not work with personalization subsystems of other personal solution providers. In addition, the full personalization check is performed only for the PayCORN payment app. For other types of payment applications, only partial verification can be performed.

When you click the “Information” button, a window with summary information about the last checked card is displayed on the screen. For rice. 16 shows a fragment of this information. The following data is provided:
▪ general information about the card and payment application
▪ result of executing the GET PROCESSING OPTIONS command
▪ data read from the payment application files
▪ data read using the GET DATA command
▪ some additional information about the payment app.

Summary information about the last checked card can be viewed and saved in the current program directory in a file named Card Info.x.y, where x is the date and y is the time the file was created. You need to pay attention to the fact that the generalized information is just a sample of the data that is presented in the Protocol, the results of the verification of the payment application. If no payment application has been processed yet, no information is displayed. The “Research” Button initiates the verification process for the specified payment application located on the installed card. Before you start analyzing the payment application, you need to do the following:

  1. Determine how the payment application will be searched on the card. It is possible to set the application type.
  2. Set the payment application verification environment (set terminal, transaction, and online processing emulation parameters).
  3. Select the smart card reader to install the card with the application being checked.
  4. Install the card with the application being checked in the selected device. After clicking the “Research” button, the verification of the payment application is performed automatically and no further actions are required from the user.

This Chapter contains background information that can help you understand the capabilities of the ECV testing Suite and avoid certain errors when checking payment applications. References to this information are present in other chapters of the document, but only in this Chapter are they presented and explained in full. This Chapter describes some of the cryptographic algorithms used by the card, terminal, and Issuer. All these algorithms are described in detail in the EMV specifications. The algorithms are listed here because they were mentioned in the text of the document and are common to all payment applications. The description of the algorithms can only be used for reference and should not be used for other purposes. When describing cryptographic methods, the following conventions are used.

  1. To determine the operation of data encryption using the Triple DES algorithm, the following designation is used: 3DESECB (Data, K) – data encryption on the key K in ECB mode.
  2. The following symbols are used to define data encryption and decryption operations using the RSA algorithm:
  • RSARPUB (Sign, Kp) – recovering data from the Sign signature on the open Kp key (i.e. decrypting data on the open key)
  • RSASPRV (Data, Ks) – getting a data signature on the KS secret key (i.e. encrypting data on the secret key)

Diversification of the master key
When entering payment application keys (see the section “Defining keys”), there are three methods for converting the entered keys into payment application keys:
▪ diversification (conversion) of keys is not performed

▪ diversification of keys by option A

▪ diversification of keys by option B

In the last two cases, it is considered that the Issuer’s master keys are defined as keys, which should be diversified into payment application keys. This section describes the algorithm for diversifying the Issuer’s master key (IMK) using PAN (Primary Account Number) and PAN Sequence Number. As a result of this diversification, the CMK key, which is unique for the payment application, is calculated. According to the document ” EMV. Integrated Circuit Card Specifications for Payment Systems. Book 2. Security and Key Management. Version 4.2. June 2008 ” the Issuer can use two options to diversify the master key-option A and option B.

The diversification process includes the following steps.

  1. If the PAN contains more than 16 decimal digits and the B – key option is used, then the step is passed
  2. Otherwise, the digits PAN Sequence Number are placed behind the decimal digits PAN (if PAN Sequence Number is not specified, then a null byte is used instead).

If the result X contains less than 16 digits, it is padded with zeros on the left to get the 8-byte number Y. When the result X contains at least 16 digits, the 8-byte number Y represents the 16 rightmost digits of the result X. the step is passed. If the PAN contains an odd number of digits, it is padded with a zero on the left. Then, after the decimal digits of the PAN, the digits of the PAN Sequence Number are placed (if the PAN Sequence Number is not specified, a null byte is used instead). Calculates the hash value obtained by SHA-1 algorithm, which obtained a 20-byte result X. Then selects the first 16 decimal digits of X to result to get an 8-byte number Y. If the number Y is not enough decimal digits, hex digits of X are converted to decimal by subtracting 10. For example, if X = ‘1230ABCD567842D4B179F2CA345D6789A17B64BB’, then the value Y = ‘1230567842417923’ (the first 16 decimal digits of the result X).

If X = ‘1B3CABCDD6E8FAD4B1CDF2CAD4FDC78FA17B6EBB’, then the value Y = ‘1368412478176’.
These decimal digits are then added to the result of converting the hexadecimal digits ‘120’ (derived from ‘B’, ‘C’, and ‘A’) and the number Y = ‘1368412478176120’.
The CMK key is calculated as the result of the following operations: Z1 = 3DESECB (Y, IMK) Z2 = 3DESECB (Y ⊕ 0xffffffffffffff, IMK) CMK = Z1 || Z2
Thus, option A of the master key diversification is a subset of option B. the Issuer can use any of the options, since they are absolutely equivalent.
Of course, option A is easier to implement, and option B is more advanced.