ICC Debit and Credit – EMV

So, an EMV application was selected on terminal …

A selection of an EMV application in an Integrated Circuit chip (ICC) returns a File Control Information (FCI) template to a terminal.

The terminal by its turn, extracts a Processing Options Data Object List (PDOL) from that FCI template. The PDOL contains a list of tag-length identifiers that the EMV application would need to obtain from the terminal. So, the terminal interprets the PDOL and builds the GET PROCESSING OPTIONS (GPO) command sending it back to the ICC.

The ICC application checks the GPO command received and it decides if this transaction can keeps being performed.

If it decides the transaction is not able to be processed in this environment, it notifies the terminal and the processing of this application is finalized. Therefore, the terminal returns the application selection to select another application in this chip. If there is no other application available, the terminal ends the transaction of the chip.

If the chip application decides to continue with a transaction it sends to the terminal an Application File Locator (AFL) and an Application Interchange Profile (AIP).

The terminal in this case, cleans tables as Terminal Verification Result (TVR) and Transaction Status Information (TSI). The terminals use these tables to builds a historical of commands and results that will be performed on this transaction.

Evaluating the information contained in the AFL, the terminal can perform reading of all public information from an EMV debit/credit application. So, after this reading the terminal decides if the selected application has all necessary data objects to continue this transaction.

Evaluating the information contained in the AIP, the terminal decides if off-line data authentication must be performed to enforce the card authentication security service. This process also is described as Card Authentication Method (CAM).

There are three sorts of CAM that can be performed:

  1. Static Data Authentication (SDA);
  2. Dynamic Data Authentication (DDA);
  3. Combined Dynamic Data Authentication-Application Cryptogram Generation (CDA).

Furthermore, the terminal performs some Processing Restrictions Functions, which evaluates:

  • The EMV version that will be used on this transaction.
  • The application expiration date.
  • If the ICC can ask for certain financial service at the point of service (as cash withdrawal for example).
  • Also, will be checked, If the card is eligible for international transaction interchange.

The terminal also performs the cardholder verification stage if the ICC has proposed this function in the AIP. If this function is supported by the card application, the terminal determines a cardholder verification method that is mutually supported by the ICC and the terminal. Then, using this method, the terminal and the card establish the link between the user of the card and the legitimate cardholder.

Some different Cardholder Verification Method (CVM) that exists are:

  • just tap the card
  • PIN off-line in clear text
  • Encrypted PIN off-line available only for DDA and CDA cards
  • PIN on-line

When the process of Terminal Restrictions Functions is finalized, the terminal performs some Terminal Risk Management Functions. These functions allow the terminal to establish (from the point of view of the acquirer) whether the amount involved in the transaction is between some acceptable lower and upper floors. The terminal may also decide whether the transaction should be forwarded on-line to prevent some sort of attacks.

At this stage of the processing, the terminal has a set of results accumulated in the tables TVR and TSI. Therefore, the terminal starts a process known as Terminal Action Analysis. In this process, the terminal compares the results stored in tables TVR and TSI with some fixed tables stored in terminal known as Issuer Action Codes and Terminal Action Codes.

The result of these Analysis is an Application Cryptogram to be suggested to the ICC in the Application Cryptogram Request command that will be sent to the ICC.

This command that is built by the terminal merges some data from Card Disk Management Data Object List 1 (CDOL1) with some other static data such as AIP, Application Transaction Count (ATC) and Cardholder Verification Result (CVR). The possible Applications Cryptograms to be suggestions are:

  • Application Authentication Cryptogram    AAC         Suggesting to decline the Transaction
  • Authorization Request Cryptogram            ARQC      Suggesting to process the Transaction Online
  • Transaction Certificate                                  TC            Suggesting to approve the Transaction Offline

When the ICC receive the Generate AC request. It starts a first Card Action Analysis. This analysis compares tables as Application Decisions Results and Card Issuer Action Codes with the Application Cryptogram suggested by the terminal. This analysis can agree with the terminal suggestion or change to another type of Application Cryptogram.

When the ICC receives the GENERATE AC request command, it derives a Session Key Application Cryptogram (SKAC) as a double-length triple DES key from a Master Key Application Cryptogram (MKAC) stored in ICC in advance, using the ATC as diversification information. This session key is used to calculate the Application Cryptogram.

With the Application Cryptogram calculated the ICC builds a response APDU and send it back to the terminal.

The terminal evaluates the response received and can follows with three different sorts of processing:

  1. If it received an AAC, a log might be generated, the transaction is denied and the EMV processing finishes.
  2. If it received a TC the transaction is approved off-line, it is generated a clearing message to be processed by the acquirer following acquirer rules and the EMV processing is finishes.
  3. If it received an ARQC it must to go to on-line processing, therefore, the terminal generates an authorization request message (message 1100 from ISO/IEC 8583) contenting the ARQC and the terminal sends it to an Issuer Host (IH).

If the processing was not finalized and the IH received a 1100 message, it must check and validate the authorization request message received. This process can be summarized on the four steps below:

  1. The IH starts a derivation process using a Issuer Master Key Application Cryptogram (IMKAC) known in advance and some data objects from 1100 message to recovery what is the MKAC stored in the ICC involved in process.
  2. With the MKAC calculated and some other object data from 1100 message, the IH can recover the SKAC used to produce the ARQC present on the 1100 message received.
  3. With the SKAC calculated and some object data from 1100 message, the IH can produce its own ARQC.
  4. The IH can check now if its ARQC is the same in comparison with the ARQC received on 1100 message, it validate the 1100 message received.

After this processing, the IH creates the authorization response message 1110 that can content some Issuer Authentication Data Objects, an Authorization Response Cryptogram (ARPC) and some Issuer Scripts Templates. This message is sent back to the terminal.

At this stage, the terminal can proceed with some different rules:

  • 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 being unable to go online making this register in TSI table.
  • If the terminal received an ARPC with an Issuer Authentication Data it is also registered in TSI table.

Thus, the terminal starts a second Terminal Action Analysis. In this process, the terminal compares again the results stored in the tables TVR and TSI with the fixed tables Issuer Action Codes and Terminal Action Code producing a second Generate Application Cryptogram request command carrying a second suggestion of Cryptogram to be generated by the ICC.

This second suggestion can be an AAC (suggesting to decline the Transaction) or a TC (suggesting to approve the Transaction Offline). If this transaction was previously processed on-line, the second generate AC command also will load the ARPC cryptogram created by the IH.

The terminal also checks if Issuer Authentication is supported, it is described on the AIP and it is used to produce an EXTERNAL AUTHENTICATE command.

In this stage, the ICC receives the second Generate Application Cryptogram request that might be combined with the EXTERNAL AUTHENTICATE command.

Therefore, the ICC starts a second Card Action Analysis processing the EXTERNAL AUTHENTICATE if it is present, this process use the same Symmetric Session Key previously computed in this transaction and some data objects from Card Disk Management Data Object List 2 (CDOL2) that were sent by the terminal.

The ICC decrypts and verifies the cryptograms ARPC and ARQC. It also checks the terminal AC suggestion and the result of the EXTERNAL AUTHENTICATE process to produce the final cryptogram to be sent back to the terminal.

How mentioned, the response message 1110 received from the IH can also include some Issuer Scripts Templates to be delivered to the ICC via terminal. These scripts take changes to be applied in ICC credit/debit card applications. Sometimes these scripts are performed by the ICC before the second Card Action Analysis and sometimes after this Analysis be evaluated.

The terminal by this turn, receive the response created by the ICC. It decrypts and verifies the cryptograms loaded on the response and follows with two different sorts of processing to finalize the transaction:

  • If it received an AAC, a log might be generated, the transaction is denied and the EMV processing finishes.
  • If it received a TC the transaction is approved off-line, it is generated a clearing message to be processed by the acquirer following acquirer rules and the EMV processing finishes.