The ARQC and ARPC cryptograms

Data to be signed by the Issuer when generating the ICC RE Public Key certificate

Name of the Length field,
byte Description Format
Certificate
Format 1 ‘ 04’h b
PAN 10 the pan card Number, supplemented on the right by the characters ‘F’h’ 20
Certificate
Expiration
Date 2 the date (month and year) after which the certificate is invalid P4
Certificate
Serial
Number 3 a Binary number unique to this certificate assigned by the Issuer
Hash
Algorithm
Indicator 1 Identifies the hashing algorithm; in the current implementation, EMV takes the value ‘ 01’h, corresponding to the SHA-1 algorithm
ICC PE
Public Key Algorithm Indicator 1 Identifies the digital signature algorithm; in the current implementation, EMV takes the value ‘ 01’h, corresponding to the RSA algorithm.
ICC PE
Public Key Length 1 Length of the card public key module in bytes – Nn
ICC PE Public Key Exponent Length 1 The length of the card’s public key exponent in bytes
ICC PE
Public Key or its leftmost digits Nr 42 If NptSfl is 42, this field must contain the entire card public key module, supplemented on the right with bytes with the value ‘ BB’h.
If Npe>N-A2, this field contains N-42 of the most significant bytes of the card’s public key
CS RE
Public Key Reminder 0 or Npe-N,+A 2 this field is present if NIf>N-A2 and consists of NK-Nj+42 least significant bytes of the card’s public key
ICC PE
Public Key Exponent 1 or 3 Value 3 or 216+1

Before encrypting the PIN code, the terminal sequentially verifies certificates and restores the Issuer’s public keys and the card (or the PIN Encryption Public Key) from them.
In addition, the terminal sends the GET CHALLENGE command to the card and receives a random 8-byte ICC Unpredictable Number from the card in the response data field.
After that, the terminal generates the data shown in the table. 3.23, and signs them using the public key of PIN encryption.

PIN block data encrypted for transfer to the card
Data Header 1 ‘ 7’H b
PIN block 8 PIN block b
ICC Unpredictable Number 8 Random number generated by the card
Random Pad
Pattern 17 Random sequence generated by the terminal

N = NPE or N = Nkb depending on which key is used to encrypt the PIN code.
Encrypted data is transmitted from the terminal to the card in the data field of the VERIFY command.
To extract the PIN value from the signed data received in the VERIFY command, the card applies an RSA algorithm to the encrypted data using the card’s secret key and obtains the PIN block value.
In order to make sure that the received data is really a card, the card compares the value of a random number generated by the card in response to the GET CHALLENGE command with a random number. If they are equal, PIN verification continues, if not, it stops, and the card in the corresponding bit of the Card Verification Results register (the Offline PIN Failed bit) sets the value to 1.
In addition, the card verifies that the value of the Data Header obtained from the encrypted PIN data is correct, and that the length of the encrypted data is equal to the length of the card’s public key module used to encrypt the PIN block.
The card compares the PIN code obtained from the pin block of encrypted data field with the PIN code stored in the protected area of the card’s memory. If they are equal, the check was successful. Otherwise, the Offline PIN Failed bit of the Card Verification Results object is set to 1.
It follows from the above that using the ICC Unpredictable Number mechanism helps to solve several problems.
First, the card uses this element to verify the integrity of encrypted data received from the terminal.
Second, the ICC Unpredictable Number data element helps fight fraud when a card is stolen or lost. Let’s assume that the fraudster conspired with the store’s cashier and made it possible to store on the terminal the values of encrypted PIN blocks corresponding to the PIN codes used by cardholders when performing operations through the cashier’s terminal. If later fraudsters manage to steal one of the cards with the PIN value saved for it, then if the ICC Unpredictable Number was not applied, the fraudster would have the opportunity to commit fraud. To do this, it needs to perform an operation on the stolen card in the terminal, which would send the previously stored value of the encrypted PIN block to the card in the data field of the VERIFY command. Such a terminal could be a” modernized ” cashier’s terminal or a fraudster’s terminal (a fraudster’s terminal could also be used to remember the values of encrypted PIN blocks). In any case, the PIN code check (as well as other checks— the card is authentic!) would have been completed successfully and the cashier would have had all the necessary data necessary to justify the fraudulent operation (applied cryptogram, random number, etc.).
Finally, the ICC Unpredictable Number element allows you to deal with PIN theft on some terminals. Indeed, the EMV specifications only state that the encrypted data containing the PIN block must contain a random sequence generated by the terminal. Whether this sequence should change from transaction to transaction is not specified by the standard. Let’s assume that the terminal once generated a random sequence and does not change it again, using PIN Offline in all operations performed on it. Then, knowing the values of the encrypted PIN block and the public key of the card, in the case when the ICC Unpredictable Number is not used, it is possible to determine the PIN code of the cardholder by searching only 10,000 possible PIN values.
The raised issue of ensuring the security of the PIN code when it is transferred to the card imposes requirements on the procedure for generating a random sequence generated by the terminal.
Application Cryptogram and Issuer authentication
The EMV standard distinguishes four types of application cryptograms generated by the card depending on the decision it makes to further process the transaction:
Transaction Certificate — when the card decides to approve the transaction;
ARQC (Authorization Request Cryptogram) — when the card decides to perform an operation in real time;
AAR (Application Authorization Referral) — when the card is applied to the Issuer for authorization confirmation using alternative methods (for example, phone call, telex, etc.); this method may be relevant for the “offline only” type of terminal, when it is not possible to apply to the Issuer using a normal authorization request of the Huo;
AAC (Application Authentication Cryptogram) in the case when the card takes the decision to reject the transaction.

In addition, the standard uses a cryptogram generated by the Issuer and used by the card to authenticate the Issuer. This cryptogram is called ARPC (Authorization Response Cryptogram).
Cryptograms of the TS and AAS cards are formed upon completion of the transaction and are used by the Issuer to ensure that the cardholder cannot refuse the result of the operation. In fact, the TS and AAS are signatures of critical transaction parameters performed using a symmetric encryption algorithm.
The ARQC and ARPC cryptograms are used for mutual authentication of the card and the Issuer (online mutual authentication).
The card generates a cryptogram using the MAC calculation algorithm (Algorithm 3 IS0/IEC 9797-1), described in clause 3.11.3, over a set of data generated by the terminal (CD0L1 and CD0L2 data transmitted in the generate AC command, PD0L data transmitted in the GET PROCESSING OPTIONS command) and the card. The minimum set of data recommended by the EMV 4.1 standard (section 8.1 of Book 2) for calculating a cryptogram is shown in table. 3.24. This data set is completely determined by the card Issuer.

The minimum dataset is recommended to compute the cryptogram

The value of the data Source
Amount, Authorized (Numeric) Terminal
Amount, Other (Numeric) Terminal
Terminal Country Code TerminaL
Terminal Verification Results Terminal
Transaction Currency Code Terminal
Transaction Date Terminal
Transaction Type Terminal
Unpredictable Number Terminal
Application Interchange Profile ICC
Application Transaction Counter ICC

In practice, the terminal verification results (TVR) and Card Verification Results (CVR) data elements are often added to the minimum data set.
The application cryptogram is calculated in two steps. At the first step, a 1B-byte session key (the key for the current operation) Application Cryptogram Session Key SK^is generated using the 16-byte key of the card to generate the ICLS cryptogram. The algorithm for calculating the session key is chosen by the Issuer (of course, taking into account the list of symmetric encryption algorithms supported by IPC manufacturers). The key management procedures and, in particular, the procedures for displaying session keys will be described in section 3.16.2.
In the second step, using the MAC calculation algorithm and the 16-byte SK^ key, the 8-6-byte value of the applied cryptogram is calculated.
Let’s now focus on algorithms for calculating the ARPC cryptogram. The EMV 4.1 standard covers two methods for calculating ARPC.
Method 1. The ARPC cryptogram is calculated by the Issuer using the 3DES algorithm using the 16-byte session key SK, f, as well as the values ARQC and Authorization Response Data (ARD, 2 bytes).
As an ARD in the VIS 1.4 specifications.x uses the Authorization Response Code (ARC) element, and the m/Chip 4 specification uses ARPC Response Code. The ARC element is an authorization code that must, at a minimum, indicate the result of transaction authorization:
the transaction is approved, denied or the Issuer requesting an alternative authorization;
whether to capture the card in the terminal.
To approve a transaction in the VIS 1.4 specifications.x uses ARC codes with the values ‘ 00’h, ’10’h, ‘ll’h, and the m/Chip 4 specifications use the values Wh,’ Ol’h, y08’h.
The ARPC Response Code element is present only in the m/Chip 4 specifications. in addition to the authorization result, it determines the setting of offline card counters, the need to perform the next card operation online, and synchronization of PIN Try Counter values on the card and the Issuer host.