Implementing Electronic Card Payment Systems (Artech House Computer Security Series)

6.9 On-line processing and issuer authentication

During the EMV ¢ transaction processing, the terminal may send an authorization request message (1100) to the acquirer because of at least one of the following reasons:

• The terminal is an "on-line-only" type, which requires always the authorization of the issuer.

• The attendant explicitly triggers the authorization request message, since there are some suspicions about the cardholder at the point of service.

• The terminal risk management stage has chosen the current transaction at random for on-line authorization. The terminal could reach the same decision following the velocity checking, which revealed a high number of transactions that were performed off-line.

• The terminal requires on-line authorization following the terminal action analysis stage, when the TVR was compared against the terminal/Issuer Action Code “On-line. The terminal issues the first GENERATE AC command with the reference control parameter (P1) set up to ARQC. The card analyzes the proposal of the terminal according to its own card risk management procedure, which reflects the security and availability policies of the issuer, and agrees with an on-line authorization by the issuer.

• The terminal requires off-line completion following the terminal action analysis. The terminal issues the first GENERATE AC command with the reference control parameter (P1) set up to TC. The card analyzes the proposal of the terminal according to its own card risk management procedure and decreases the decision level proposed by the terminal from TC to ARQC.

Whenever the card answers with an ARQC in the Cryptogram Information Data, the terminal starts up the on-line processing function. This means that the card and the terminal judged the current transaction outside the limits of risk for an off-line completion, as defined by the issuer, payment system, and acquirer. Therefore, the issuer is required to analyze the actual EMV ¢ transaction at the point of service, based on the information it receives from the terminal and the account information it stores in the IH in connection with the card. This guarantees that the issuer can review the conditions of the transaction and can approve or reject it.

6.9.1 Authorization request and response with chip data

The terminal generates an authorization request message 1100. The data fields included in this message are those explained in Section 2.9 for the processing of transactions using magnetic stripe cards. In addition, the authorization request message includes the field ICC system- related data, corresponding to bit 55 in the bitmap (see Section 2.8.1) of the data elements present in the 1100 message, according to ISO 8583:1993. This field contains all the data objects from the point of service, which allows the IH to verify the correctness of the ARQC produced by the card. Among these data objects one can mention:

• Application Cryptogram (ARQC);

• Account identification data of the card (PAN and PAN Sequence Number);

• ATC and the unpredictable number;

• Issuer Application Data (IAD), which may include the key indicator and the algorithm version number to uniquely specify a certain version of the IMK _AC and of the MAC algorithm used to compute the ARQC in the card. The IAD may also include the witness values of the SDA or DDA processing by the terminal (i.e., the Data Authentication Code or the ICC Dynamic Number, respectively). In addition, the card risk management verification results can also be included in the IAD.

• All the data objects necessary to reproduce the transaction claim.

After receiving the authorization request message 1100, the IH first verifies that the card at the point of service is genuine . To this end, the cryptographic module of the IH must verify the correctness of the ARQC, according to the following steps:

• Use the key indicator present in the IAD to retrieve the correct version of the IMK _AC .

• Use the account identification data to derive the key MK _AC corresponding to the card participating in the transaction.

• Derive the actual session key SSK _AC from MK _AC , using the ATC as diversifier information in the keys-tree.

• Use the algorithm version number in the IAD to call the same algorithm for the computation of the MAC as that used in the card.

• Use SSK _AC to produce a MAC on the same data objects that were considered by the card in the transaction claim.

• Compare the computed MAC against the ARQC received in the authorization request message 1100. If the two values are equal, the ARQC is accepted as valid evidence that the card at the point of service is authentic and genuine.

The IH identifies the cardholder's account using the account identification data received in the authorization request message. The account information kept in connection with the card, including the history of the most recent transactions, allows the issuer to run an improved risk management procedure. The IH can perform additional verifications that are not possible at the point of service. Thus, the issuer can identify transactions performed with cards that were reported stolen, or that have already spent the limit of the account balance. Correspondingly, the issuer may approve or reject the transaction, indicating also the reason of the rejection .

The issuer prepares the Issuer Authentication Data with tag 91, which consists of two items: the authorization response cryptogram (ARPC) on 8 bytes, and the Authorization Response Code (ARC) on 2 bytes.

The cryptographic module of the IH computes the ARPC as a triple DES cryptogram in ECB mode on the result of an XOR operation between the ARQC and the ARC padded at right with 6 bytes 00h. The ARQC is the value received in the 1100 message and serves as a challenge for countering replay attacks. This cryptogram is produced with the same session key SSK _AC , which was already produced by the cryptographic module of the IH, since the verification of the ARQC. The ARPC allows the card to authenticate the issuer and to check that the Authorization Response Code represents the decision of the issuer concerning the finalization of the current EMV ¢ transaction.

The issuer may also consider the status of the EMV ¢ transaction, as the terminal reports it in the TVR and as the card reports it in the card risk management verification results, which was a data object included in the IAD. These two data objects are recommended for inclusion in the authorization request message. Interpreting this status information of the EMV ¢ transaction or considering some other post-issuance management operations, the issuer may decide whether it is necessary to correct the operation of the card. Examples of such corrections include:

• The extension of an expiration date, which would allow a cardholder who forgot to renew his or her card to operate , for a limited period of time, with an expired card;

• The unblocking of an application, following a PIN try limit exceeded;

• The modification of some parameters of the card risk management, like amount spending limits per day, per week, or per month, depending on the cardholder's availability of funds in the corresponding account;

• The updating of some cryptographic parameters, which are periodically changed for security reasons.

All of these corrections decided by the IH are translated in a sequence of post-issuance commands, which are encapsulated in the so-called Issuer Script Template 1 with tag 71 or in the Issuer Script Template 2 with tag 72.

After all this processing, the IH creates the authorization response message 1110. This message includes the data fields already mentioned in Section 2.9, in connection with the processing of transactions carried out with magnetic stripe cards. In addition, the authorization response message optionally includes the ICC system-related data field, corresponding to bit 55 in the bitmap of the data elements present in the 1110 message [4]. When the issuer authentication is performed, this field contains the Issuer Authentication Data, which consists of the ARPC and the ARC. When postissuance management of the ICC is needed, the issuer includes in this field the Issuer Script Template 1 or the Issuer Script Template 2.

If the terminal does not receive the authorization response message, or it receives it too late, or with an invalid syntax, then the terminal shall process the transaction as being unable to go on-line (see Section 6.8.5).

If the authorization response message is received by the terminal but it does not contain the Issuer Authentication Data, the terminal shall not execute the EXTERNAL AUTHENTICATE command and shall set bit 5, "Issuer authentication was performed", in the TSI to 0. Otherwise, the card performs the issuer authentication as explained below.

6.9.2 Issuer Authentication

If the Issuer Authentication Data (tag 91) is received in the authorization response message 1110, the terminal checks the content of bit 3, "Issuer Authentication is supported", in the AIP.

When this bit is set to 1, the card supports issuer authentication through the EXTERNAL AUTHENTICATE command. In this case, the terminal prepares the C-APDU corresponding to this command according to Table 6.9.

The terminal may send this command only once in a transaction. The ICC should return the SW1SW2 = 6985 in the R-APDU, if this restriction is not respected. Regardless of the status words in the R-APDU, the terminal shall set to 1 bit 5, "Issuer authentication was performed", in the TSI. In case the SW1SW2 are different than 9000, the terminal shall set bit 7, "Issuer authentication was unsuccessful ", in byte 5 of the TVR.

When bit 3, "Issuer Authentication is supported", in the AIP is set to 0, the card may combine the issuer authentication with the second GENERATE AC command. In this case, the issuer should have listed the data object Issuer Authentication Data (tag 91) in the CDOL2.

Regardless of whether EXTERNAL AUTHENTICATE or GENERATE AC is used to perform issuer authentication, the processing performed by the card is the same. The ICC decrypts the ARPC with the session key SSK _AC , which was previously derived for the computation of the ARQC. After performing the XOR operation with the value of the ARQC, the ARC can be obtained from the leftmost 2 bytes of the result. This computed value of the ARC is compared against the value received in the Issuer Authentication Data. If the two values are identical, the issuer authentication has passed.