The transaction

After the optional card authentication and card holder verification, the actual trans-action is performed. Transtrans-actions can be either offline or online. The terminal chooses which it wants to use, but the card may refuse to do a transaction offline and force the terminal to do an online transaction instead.

For a transaction the card generates one or two cryptograms: one in the case of an offline transaction, and two in the case of an online transaction.

• In an offline transaction the card provides a proof to the terminal that a transac-tion took place by means of a Transactransac-tion Certificate (TC), which the terminal sends to the issuer later.

• In an online transaction the card first provides an Authorisation Request Cryp-togram (ARQC) which the terminal forwards to the issuer for approval. If the card receives approval, the card then provides a TC as proof that the transaction has been completed.

In both on- and offline transactions the card can also choose to refuse or abort the transaction, in which case an Application Authentication Cryptogram (AAC) is pro-vided instead of a TC or ARQC.

Below we first discuss how exceptions that occur can influence the type of cryp-togram that is requested and the different types of crypcryp-tograms in more detail, before we describe the protocol steps for off- and online transactions.

Terminal action analysis

During the terminal action analysis, the terminal decided whether a transaction should be performed online or be aborted in case of the occurrence of an excep-tion. When an exception occurs at the side of the terminal, such as, for example, a failed data authentication or unsuccessful cardholder verification, this is stored in the Terminal Verification Results (TVR). The TVR is a bit-string, where every ex-ception corresponds to a particular bit. When an exex-ception occurs the corresponding bit in the TVR is set to 1 by the terminal. To specify what the terminal should do in case of exceptions EMV makes use of so-called Action Codes. An Action Code is a bit-string similar to the TVR. Both the issuer and the acquirer can indicate their preferred actions specified in the Issuer Action Codes (IACs) and Terminal Action Codes (TACs) respectively. We can distinguish three different types of action codes:

Denial, Online and Default. If no TACs are present, they have a default value of all bits set to 0. The default value for IAC - Denial is all 0s, whereas the IAC - Online and IAC - Default are all 1s by default. The Action Codes are processed in pairs by the terminal in the following order:

• Denial, if an exception occurred and the corresponding bit is 1 in either the TAC - Denial or IAC - Denial, the terminal will abort the transaction by requesting an AAC.

• Online, if the terminal supports online transaction and an exception occurred for which the corresponding bit is 1 in either the TAC - Online or IAC - Online, the terminal will force the transaction to be performed online by requesting an ARQC.

• Default, if the terminal does not support online transaction or it was unable to go online, and an exception occurs for which the corresponding bit is 1 in either

3.2. An EMV protocol session 23

the TAC - Default or IAC - Default, the transaction will be aborted by the terminal by requesting an AAC. If the transaction is not aborted, the terminal will try to complete an offline transaction by requesting a TC.

Cryptograms

Using the GENERATE AC command, the terminal can ask the card to compute one of the types of cryptograms mentioned above, i.e. TC, ARQC or AAC.

Arguments of the GENERATE AC command tell the card which type of cryptograms to produce and whether CDA has to be used. Additional arguments that have to be supplied by the terminal are specified by CDOL1 and CDOL2. CDA is only performed on TC or ARQC messages, and not on AAC messages.

The response always contains

• the Cryptogram Information Data (CID), indicating the Application Cryp-togram (AC) type in the response,

• the Application Transaction Counter (ATC) and

• an Application Cryptogram (AC) or proprietary cryptogram.

Optionally, the response may contain

• the Issuer Application Data (IAD),

• other proprietary data,

• the Signed Dynamic Application Data (SDAD), namely if CDA is requested and the type of the response cryptogram is not AAC.

The cryptogram returned by the card can either be in the format specified in the EMV standard, or in a proprietary format. Additionally, if CDA is used, the card also returns the SDAD over the response using its private key SKICC so that the terminal can check the authenticity of the complete message. If no CDA is performed, the response to a GENERATE AC command consists of the CID, the ATC, the AC and optionally the IAD. When performing CDA, the AC is replaced by the SDAD.

Both the CDOL1 and CDOL2 are required to always include the UN. A Card Risk Management Data Object List (CDOL) might request a Transaction Certificate Hash, which is a hash on the elements in the Transaction Certificate Data Object List (TDOL). The TDOL might be provided by the card, or a default can be used that is specified by the payment system.

The GENERATE AC command starts with a parameter indicating the type of AC that is requested. The boolean parameter cda requested specifies whether a CDA signature is requested. This results in the protocol step given in Figure 3.6. For an offline transaction this is the only step to confirm the transaction by requesting a TC.

T → C: GENERATE AC, (ac type, cda requested, data specified by the CDOL1) C → T: (CID, ATC, AC, [IAD])

Figure 3.6: Protocol step for a single GENERATE AC command

T → C: GENERATE AC, (ARQC, cda requested, data specified by the CDOL1) C → T: (CID, ATC, AC, [IAD])

T: Communication with issuer to retrieve issuer authentication data T → C: EXTERNAL AUTHENTICATE, (issuer authentication data)

C → T: Success/ Failed

T → C: GENERATE AC, (TC, cda requested, data specified by the CDOL2) C → T: (CID, ATC, AC, [IAD])

Figure 3.7: Protocol steps for an online transaction using the EXTERNAL AUTHENTICATEcommand

After forwarding the ARQC in an online transaction, the terminal might receive the Issuer Authentication Data in response from the issuer. If supported by the card, this data is sent to the card using the EXTERNAL AUTHENTICATE command to which the card responds whether the issuer authentication was successful (see Figure 3.7).

If the EXTERNAL AUTHENTICATE command is not supported by the card, the Issuer Authentication Data can still be included in the CDOL2 for the card to authenticate the issuer. How the issuer is exactly authenticated is out of scope of the EMV spec-ifications. After the card returns a TC the transaction is confirmed (and the money or goods handed over to the customer), even though the TC might not have been forwarded to the bank yet.