EMV-Cryptogram-ARQC-Explained

An Introduction to Cryptogram

When a magnetic stripe card is swiped at the terminal, terminal would read the track data that is embossed on the card. Track data contains, name of the card holder, expiry date and few other details Including discretionary data such as CVC1 / CVV1. As this data is static in nature, in case of counterfeit fraud, it becomes difficult to identify a fraudulent transaction performed on the stolen card.

In case of a chip card, generation and verification of a dynamic cryptogram reduces the risk of counterfeit transactions.

When a Cryptogram is generated?

Before dwelling further on what is cryptogram, let us quickly understand what happens when a chip card is dipped at the terminal.

When the card is dipped at the terminal, terminal performs few validations, such as the type of the product (debit / credit etc.,) , card holder verification method (offline / online, encrypted pin / plain PIN etc.,), offline transaction limit.

After the validations, terminal takes a decision on whether to decline the transaction or to take offline approval or to go online. Based on the decision, the terminal requests one of the following ‘cryptograms’ from the card:

• Transaction certificate (TC) — Offline approval
• Authorization Request Cryptogram (ARQC) — Online authorization
• Application Authentication Cryptogram (AAC) — Offline decline

Card will either accept the terminal’s action analysis or decline a transaction or force a transaction on-line.

TC, ARQC & AAC are all cryptograms but the elements which are used for generating each of these cryptograms is different.

We will only be talking about online authorization scenario (ARQC) from hereon.

What is Cryptogram & What does it contain

As the name suggests it is the “cryptic” format of collection of certain data.

EMV guidelines do not mandate which fields are to be present in the cryptogram. It is application dependent.

However, EMV recommends below set of data elements to be included in generation of the cryptogram:

• Transaction amount
• Terminal country code
• Terminal Verification Results
• Transaction currency code
• Transaction date
• Transaction type
• Unpredictable Number
• Application Interchange Profile
• Application Transaction Counter

In these data elements, Application interchange profile and Application transaction counter are generated / maintained at chip level whereas all other data elements are sourced in from terminal to chip.

Below is high level explanation of some of the fields:

Application Interchange profile (AIP) indicates the application functions supported by the chip. Functions include –

• Static Data Authentication (SDA) is supported or not
• Dynamic Data Authentication (DDA) is supported or not
• Which cardholder verification method is supported?
• Whether terminal risk management is to be performed
• Issuer authentication is supported or not
• Combined Dynamic Data Authentication (CDA) is supported or not

Application Transaction Counter is a two-byte value which is incremented for each transaction.

Unpredictable Number is a unique 4-byte field generated by the terminal and passed to Chip to help in generating a unique cryptogram

MasterCard mandates all above fields except terminal country code to be present in DE 55 for Full EMV transactions along with Application Cryptogram, Cryptogram Information Data & Issuer Application Data.

Visa also accepts / identifies all above mentioned fields along with few other fields like Terminal capability profile and Issuer Script Results.

How is Cryptogram generated

Upon receiving cryptogram generation request along with the data from the terminal, Chip (ICC) generates 8-byte Application Cryptogram using Application Cryptogram Master Key (MKAC). Chip performs below actions in-order to generate Application Cryptogram (AC).

1) A session key (SKAC) is generated Using MKAC & ATC**. Session key is unique for each transaction.

2) Generates Application Cryptogram using the session key and the data by applying 3DES or AES.

** Using of ATC in session key generation is subjected to the method / algorithm used for generation of session key.

In case of an online transaction, this authorization cryptogram is called as ARQC. Chip sends the ARQC to terminal, which in-turn sends ARQC in the authorization message to the issuer host for authorization.

Cryptogram Response

Upon receiving the ARQC in the authorization request, issuer system, validates the ARQC and generates response cryptogram (ARPC) using security modules like HSM.

If the ARQC verification is successful, then ARPC is generated using ARQC as one of the inputs.

If the ARQC verification is not successful, then ARQC should not be used as input for ARPC generation.

There are two methods using which ARPC can be generated.

Method 1 generates an 8-byte ARPC using an 8-byte ARQC and a 2-byte Authorization Response code (ARC) as input.

Method 2 generates a 4-byte ARPC using an 8-byte ARQC, a 4-byte Card Status Update (CSU) and a 0–8 byte Proprietary Authentication Data as input.

ARPC is sent in authorization response message from the issuer to the terminal via acquirer.