EMV Cryptography – Common Core Definitions

Let’s analyze why the terminal needs public keys of payment systems (more precisely, keys of payment system certification centers) to perform a transaction. As described earlier (see the section “security Issues”), in order to get access to the public RSA key of the card, the terminal must first restore the Issuer’s public key from the certificate of this key signed on the secret key of the certification Authority (CA). Why does the terminal need a public RSA card key? First, to perform offline data authentication. Second, to encrypt the PIN code, if the verification method of the cardholder “Presenting the encrypted PIN code to the card”is used. And the absence of a payment system certification authority key can affect (and very significantly) the progress of the transaction. In this regard, there is a database with all known public keys of payment systems in the ECV testing complex. 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 keys of a particular payment system (blocked keys are not deleted from the database, but become unavailable to the terminal emulator). In addition, a new key can be created for any payment system or an existing one can be deleted. Payment application keys are not as simple as public keys of payment systems. They are not required to perform a transaction, but in certain cases the terminal emulator may need them to perform the following functions:
▪ verification of the transaction cryptogram (AAC, TC, or ARQC) generated by the card
▪ generating the Issuer’s cryptogram in response to an authorization request in case of online processing emulation
▪ creating script processing commands used by the Issuer to modify information on the card (again, in the case of emulating 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 an application created using EMV CCD (Common Core Definitions) specifications. Secondly, the process of diversifying keys, generating session keys, calculating cryptograms, and forming script processing commands is so multi-stage and complex that a lot of preparation is needed to use 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 transaction (transaction)
▪ the amount of the payment transaction
▪ cash refund amount (used only for cashback purchases – in all other cases, it must be equal to 0)
▪ combo-box for determining the currency of a payment transaction

In addition, this group of controls also includes the edit line for entering the cardholder’s PIN code. The value specified as the PIN code is used only if the analysis of the list of verification methods for the cardholder determines that the PIN code must be presented to the card. If the PIN code is not specified and it is required to present it to the card, it is considered that the cardholder refused to enter the PIN code. You should pay attention to the following features of using the pin code by the terminal emulator.

1. For online verification, the PIN code 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.

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

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 payment transaction security, 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 performing a transaction, which allows you to check various behaviors of payment applications. The user can define the following:
▪ The type of terminal, its capabilities, and additional features that define 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.

The “AID” editing element is only used when the application is explicitly defined. In all other cases, it is not available for input and its contents can be ignored.