6.8 Terminal action analysis

In the terminal action analysis stage, the terminal evaluates the results of the processing performed during the current EMV ¢ transaction and decides whether the transaction should be approved off-line, transmitted on-line to be authorized by the issuer, or declined off-line.

This evaluation is performed after the terminal risk management has been completed, after the transaction data is entered by the cardholder/merchant, and prior to the first use of the GENERATE AC command. However, if the processing in any EMV ¢ stage results in the setting of 1 bit in the TVR, the terminal can immediately trigger the terminal action analysis to determine whether the transaction should be rejected off-line based upon the issuer's and/or the acquirer's security policies. This can spare subsequent computational effort of the terminal, since the transaction would finally be rejected.

6.8.1 Action codes and security policies

The evaluation of the terminal processing consists of interpreting the content of the TVR against two sets of registers, which are referred to as the Issuer Action Codes and the terminal action codes. Each set contains three registers, which are referred to with the set name and one of the following suffixes: denial, on-line, and default. Each set of registers encodes the security policies considered by the issuer and by the acquirer in case 1 bit in the TVR is 1, determining the action to be performed by the terminal.

The set of registers that encodes the security policies of the issuer is as follows :

Issuer Action Code-Denial (tag 9F0E in the card): This register specifies the issuer's conditions that cause the denial of a transaction without attempting to go on-line. If this register is not personalized in the card, the terminal considers, by default, that all the bits are set to 0.
Issuer Action Code-On-line (tag 9F0F): This register specifies the issuer's conditions that cause a transaction to be transmitted on-line. If this register is not personalized, the terminal considers by default that all the bits are set to 1.
Issuer Action Code-Default (tag 9F0D): This register specifies the issuer's conditions that cause a transaction to be rejected if it might have been approved on-line but the terminal is unable to transmit the transaction on-line. If this register is not personalized, the terminal considers, by default, that all the bits are set to 1.

The bits in these registers are set according to the security policies established by the issuer concerning the action to be taken in case a failure appears during the EMV ¢ processing. Let us discuss the following examples.

Example 1: Assume that the security policy of the issuer states that:

If off-line SDA fails (which is reflected in bit 7 of byte 1 of the TVR set to 1), the transaction should be transmitted on-line to the issuer .

If the terminal is off-line only or the on-line connection with the issuer cannot be established, then the transaction must be declined .

In this case, bit 7 of byte 1 in the three action code registers of the issuer should be encoded as follows:

0 in the Issuer Action Code-Denial, which means that the transaction should not be declined off-line when off-line SDA fails;
1 in the Issuer Action Code-On-line, which means that the transaction should be directed on-line when off-line SDA fails;
1 in the Issuer Action Code-Default, which means that in case the transaction cannot be directed on-line to the issuer, the terminal should decline the transaction.

Example 2: Assume that the security policy of the issuer states that:

If cardholder verification was not successful (which is reflected in bit 8 of byte 3 of the TVR set to 1), the transaction should be declined off-line without attempting to transmit the transaction on-line to the issuer .

In this case bit 8 of byte 3 in the Issuer Action Code-Denial should be set to 1, while the value of the same bit in the other two registers does not matter.

The set of registers that encodes the security policies of the acquirer is as follows:

Terminal Action Code-Denial: This register specifies the acquirer's conditions that cause the denial of a transaction without attempting to go on-line. If the acquirer specifies no value for this register, the terminal considers by default that all the bits are set to 0.
Terminal Action Code-On-Line: This register specifies the acquirer's conditions that cause a transaction to be transmitted on-line.
Terminal Action Code-Default: This register specifies the acquirer's conditions that cause a transaction to be rejected if it might have been approved on-line, but the terminal is unable to transmit the transaction on-line.

If the last two registers are not personalized, the terminal considers, by default, that all their bits are set to 0. It is strongly recommended, however, that at least the following bits in the first byte of the last two registers be set to 1 by the acquirer:

Bit 8: Off-line data authentication was not performed.
Bit 7: Off-line SDA failed.
Bit 4: Off-line DDA failed.

6.8.2 The terminal proposes and the card disposes

The evaluation of the processing performed during the current EMV ¢ transaction, according to the content of the TVR and of the issuer/terminal action codes sets, leads the terminal to make a decision concerning the finalization of the EMV ¢ transaction. The terminal may propose one of the following actions through the first issuance of the GENERATE AC command:

Transaction approved: The card is required to produce a transaction certificate (TC) when the terminal appreciates that there are no risks (according to the security policies adopted by the issuer/acquirer) and recommends the approval of the EMV ¢ transaction off-line.
On-line authorization requested : The card is required to produce an authorization request cryptogram (ARQC) when the terminal recommends that the intervention of the issuer is necessary to decide upon the approval or denial of the EMV ¢ transaction.
Transaction declined: The card is required to produce an application authentication cryptogram (AAC) when the terminal decides that the business risks are unacceptable and the transaction must be declined off-line.

After the first GENERATE AC command is received by the card with a proposal of finalization from the terminal, the card risk management may accept the terminal's recommendation or may override the terminal's decision to a lower decision level. The hierarchy of the decision levels (from highest to lowest ) is TC, ARQC, AAC. In addition to these three levels known to the terminal, the card knows a supplementary decision level, according to which a referral is requested by the card for the finalization of the EMV ¢ transaction through an application authorization referral (AAR) cryptogram. This decision level is situated between the ARQC and the AAC.

Note that Application Cryptogram (AC) generically refers to any of the four types of cryptograms: TC, ARQC, AAR, or AAC.

The following three situations may appear:

If the terminal proposes the highest decision level (i.e., TC), the card risk management may either accept it or require a lower decision level, namely ARQC, AAR, or AAC.
If the terminal proposes an ARQC, the card may either accept it or request for a lower decision level, which can be either AAR or AAC.
If the terminal proposes an AAC, the card accepts it because there is no lower decision level that can override the AAC.

If the card responds with a decision level higher than that proposed by the terminal, this indicates a logic error in the card. When this error appears after the first issuance of the GENERATE AC command, the terminal shall terminate the EMV ¢ transaction.

6.8.3 Off-line denial of a transaction

For each bit in the TVR with value 1, the terminal checks the corresponding bit in the Issuer Action Code “Denial and Terminal Action Code “Denial. Together, these two registers specify the conditions that determine the denial of a transaction without attempting to go on-line. If the corresponding bit in either of the two action code registers is set to 1, the terminal decides to reject the transaction according to the indication of either the issuer or the acquirer. The transaction is declined off-line.

In this case the terminal issues a GENERATE AC command, requiring the card to produce an AAC on the data related to the transaction at the point of service. To this end, the reference control parameter, which is P1 in the C-APDU, is set to 00h (see Section 6.8.6 for the significance of the C-APDU of the GENERATE AC ).

After receiving this command, the card produces the requested AAC, since this is the lowest decision level. Consequently, bits 8 and 7 are set to 0 in the Cryptogram Information Data, returned in the R-APDU of the GENERATE AC command, encoding the AAC.

The AAC returned by the card indicates:

A rejection of the transaction due to unacceptable business risks;
A restriction that disallows the use of the card in certain business environments. This is the case when the use of a card is not compatible with certain merchant categories, or there is an incompatibility resulting from processing restrictions related to the AUC (see Section 6.5.2).

The card may optionally distinguish between these cases and may return appropriate codes in the least significant 3 bits (bit 3, bit 2, and bit 1), referred to as reason/advice/referral code of the Cryptogram Information Data:

000 ”no information given;
001 ”service not allowed;
010 ”PIN try limit exceeded;
011 ”issuer authentication failed (available for the second GENERATE AC );
XXX ”other values RFU.

Correspondingly, the terminal application may choose adequate messages to inform the cardholder about the rejection of the transaction.

In certain exceptional cases, like the situation when the PIN try limit is exceeded, the issuer may wish that the card asks the terminal to form and send an advice request message (1220 in the ISO 8583 notation; see Section 2.8.2). This advice request message is sent separately from either an authorization request or a clearing message. In this case the card positions bit 4 in the Cryptogram Information Data to 1, which means "advice (message) required".

When the AAC is forwarded to the issuer, it proves that the card was present during the denied transaction.

6.8.4 On-line transmission of a transaction

If the terminal is "off-line-only" (with Terminal Type in the set of values 13, 23, 16, 26, 36), the analysis described in this section is meaningless.

For "on-line-only" or "off-line with on-line capability" terminals, if the terminal does not reject the transaction off-line, the terminal action analysis continues with the evaluation of the bits in the TVR with respect to the pair of registers Issuer Action Code “On-line and Terminal Action Code “On-line. Together, these two registers specify the conditions that cause a transaction to be completed on-line.

For each bit in the TVR with value 1, the terminal checks the corresponding bits in the Issuer Action Code “On-line and Terminal Action Code “ On-line. If the corresponding bit in either of these two action code registers is set to 1, the terminal shall require the on-line completion of the transaction processing.

In this case the terminal issues a GENERATE AC command, requiring the card to produce an ARQC on the data related to the transaction at the point of service. To this end the reference control parameter, P1 in the C-APDU, has bit 8 and bit 7 set to 1 and 0, respectively (see Section 6.8.6). The terminal may explicitly ask for a combined DDA/AC generation, in case the combined off-line DDA and GENERATE AC is indicated in bit 2 of the AIP and the terminal also supports combined DDA/AC generation (Section 6.4.1). In this case, bit 6 in the reference control parameter, P1 in the C-APDU, is set to 1. In case CDOL1 includes the tag 9F33, corresponding to the terminal capabilities, the card can determine by itself whether the combined DDA/AC generation should be performed, indifferent of the value of bit 6 in the reference control parameter (see also Section 6.8.6.1).

After receiving this command, the card risk management decides whether the terminal's ARQC decision is acceptable or this decision should be overridden with one of the lower decision levels, either AAR (referral) or AAC (rejection).

First, if the card risk management decides to reject the transaction, then the AAC is returned. Consequently, the Cryptogram Information Data in the R-APDU encodes the AAC as detailed in Section 6.8.3. This concludes the EMV ¢ processing.

Second, if the card decides to ask for a referral, then the AAR is returned. Consequently, the Cryptogram Information Data in the R-APDU encodes the AAR as follows: bit 8 = 1, bit 7 = 1, bit 4 = 0 (no advice request message is required). Bit 3 through bit 1 indicate the reason why the referral was required.

The terminal application chooses, based on some proprietary policies of the payment system, how to further process the AAR.

After receiving the AAR, the terminal could provide by itself an Authorization Response Code (tag 8A), based, for example, on the referral reason of the card. According to Annex A6 in Book 4 [3], this code can have one of the following meanings:

Off-line approved (Y1)/Off-line declined (Z1);
Approval (after card-initiated referral) (Y2)/Decline (after cardinitiated referral) (Z2);
Unable to go on-line, off-line approved (Y3)/Unable to go on-line, offline decline (Z3).

The terminal proceeds to the issuance of a second GENERATE AC , requiring either TC (codes Y1, Y2, or Y3) or AAC (codes Z1, Z2, or Z3), which will conclude the transaction. Note that the Authorization Response Code is a data item included in the CDOL2 (see Section 6.8.6.1).

Otherwise, the terminal could use the AAR as an ARQC and go on-line to get further advice from the issuer on whether to authorize the transaction.

Third, if the card agrees with the terminal's decision level, then the ARQC is returned. Consequently, the Cryptogram Information Data in the R-APDU encodes the ARQC as 80h (bit 8, bit 7 = 10, bit 6 = 0, bit 5 “bit 1 = 0). The on-line processing of the ARQC is described in Section 6.9.

6.8.5 Default action in a transaction

The terminal action analysis uses the registers Issuer Action Code-Default and Terminal Action Code-default to determine whether to reject or approve off-line an EMV ¢ transaction as follows:

If the bit in the Issuer Action Code-Default or the terminal action code-default and the corresponding bit in the TVR are both set to 1, the transaction shall be denied.
Otherwise, the transaction shall be approved.

This processing is performed in the following two cases:

The terminal is an off-line terminal and the transaction was not already rejected based on the content of the Issuer Action Code-Denial and Terminal Action Code-Denial registers (Section 6.8.3). In this case the contents of the Issuer Action Code “On-line and Terminal Action Code “On-line are meaningless. Consequently, the Terminal issues a first GENERATE AC asking for either TC (in case the analysis above indicated approval) or AAC (in case the analysis above indicated denial). This will conclude the EMV ¢ transaction.
The terminal has decided to transmit the transaction for on-line authorization, but the terminal was unable to go on-line (e.g., after sending the authorization request message 1100 to the issuer, the terminal does not receive the authorization response message 1110 in due time). In this case the terminal has already issued a first GENERATE AC with ARQC, and it obtained the ARQC from the card. Consequently, the terminal issues a second GENERATE AC asking for either TC (approval) or AAC (denial). In the former case, the terminal sets the Authorization Response Code to the value "Unable to go on-line, off-line approved" (Y3), while in the latter case, the terminal sets the Authorization Response Code to "Unable to go on-line, off-line decline" (Z3). Note that the Authorization Response Code is included in the CDOL2 (see Section 6.8.6.1). This shall conclude the EMV ¢ transaction.

In case the terminal recommends approval (TC), the Cryptogram Information Data returned in the R-APDU may be either the TC (approval) or AAC (denial). The choice depends on whether the card risk management agrees with the proposal of the terminal or overrides it with the only lower decision level acceptable in this case, which is AAC. Note that ARQC or AAR decision levels are ruled out since either the terminal is off-line or the R-APDU corresponds to a second GENERATE AC , for which the only acceptable decision levels can be TC or AAC.

In case the terminal recommends denial (AAC), the Cryptogram Information Data returned in the R-APDU must be AAC.

6.8.6 Compute Application Cryptogram with GENERATE AC

The C-APDU of the GENERATE AC command is given in Table 6.8.

Table 6.8: C-APDU of the `GENERATE AC` Command
Code	Value
CLA	80 (EMV ¢ specific command)
INS	AE
P1	Reference control parameter : Bit 8 and bit 7: 00 ”AAC, 01 ”TC, 10 ”ARQC, 11 ”RFU Bit 6: 0 ”combined DDA/AC generation not explicitly requested 1 ”combined DDA/AC generation requested Bit 5 to bit 1: RFU
P2	00
Lc	Variable: equal to the length of the data field
Data	Transaction related data: byte string formed with the value fields of the data objects listed in the CDOL1 (in the first issuance) or CDOL2 (in the second issuance)
Le	00

6.8.6.1 Transaction related data according to CDOL1/CDOL2

The card specifies in the Card Risk Management Data Object List 1 (CDOL1) the set of data objects from the business environment of the terminal that it needs for processing the first GENERATE AC . CDOL1 is mandatory in the card and is stored with the tag 8C. The card also specifies in the Card Risk Management Data Object List 2 (CDOL2) the set of data objects it needs from the terminal for processing the second GENERATE AC . CDOL2 is mandatory in the card and is stored with the tag 8D (see Section 6.3.2).

The data field of the C-APDU contains the data related to the transaction, which is formed as a raw byte string (which is not TLV encoded) concatenating the value fields of the data objects mentioned either in CDOL1 or in CDOL2. The card uses the data related to the transaction for the following purposes:

Performing the card risk management processing;
Determining whether the combined DDA/AC should be performed, even when not explicitly required in bit 6 of the reference control parameter, P1 of the C-APDU;
Serving as input data for generating the appropriate cryptogram (TC, ARQC, AAR, or AAC) that serves as evidence of a card's participation in a particular EMV ¢ transaction.

The terminal shall build the data related to the transaction immediately before calling the GENERATE AC command, guaranteeing that the value fields of the data objects in the terminal represent the current values. Note also that even when the same data object is listed both in the CDOL1 and CDOL2, its value field included in the data related to the transaction could be different for the first and second GENERATE AC , since the terminal has continued its processing. This continuation of the processing could have changed the value of certain data objects (e.g., the TVR).

The list of data objects in the CDOL1/CDOL2 must include the tag-length reference of a random number generated by the terminal ”Unpredictable Number (tag 9F37') ”which guarantees that the evidence produced by the card cannot be replied by an attacker.

If the CDOL1 includes the tag 9F33 corresponding to the Terminal Capabilities, the card can determine by itself whether the combined DDA/AC generation should be performed or not, indifferent of the value of bit 6 in the reference control parameter, P1 in the C-APDU. Otherwise, the terminal must explicitly require the combined DDA/AC generation, setting bit 6 to 1 in the reference control parameter.

The tag-length references of some data objects are included in both the CDOL1 and CDOL2. These data objects indicate the business conditions of the transaction at the point of service:

Amount, Authorized (Numeric) (tag 9F02);
Amount, Other (Numeric) (tag 9F03);
Transaction Currency Code (tag 5F2A);
Transaction Date (tag 9A);
Transaction Type (tag 9C);
Terminal Country Code (tag 9F1A);
Terminal Type (tag 9F35).

There could exist data objects in the terminal's business environment that are not directly involved in the card risk management but which must be considered for generating the application cryptogram. If this is the case, the issuer specifies their tag-length references in the Transaction Certificate Data Object List (TDOL), with tag 97 in the card. The terminal forms a byte string concatenating the value fields of the objects referenced in the TDOL and computes the hash code of this string (see Appendix D, Section D.2.1). This hash code is stored in the value field of the TC Hash Value data object with tag 98 in the terminal. In order to consider the computed hash code in the generation of the application cryptogram, the ICC must include the tag-length reference of the TC Hash Value among the items listed in the CDOL1/CDOL2.

The CDOL1/CDOL2 also include the tag-length references of the data objects that keep the results of the processing performed by the terminal:

Terminal Verification Results (tag 95);
Data Authentication Code (tag 9F4C), proving the completion by the terminal of the SDA (see stage 4 in Section 6.4.2);
ICC Dynamic Number (tag 9F45), proving the completion by the terminal of the DDA (see Section 6.4.3.4)

The tag-length references of some other data objects are included only in the CDOL1, if these objects have a specific interest for the issuer. They include the data objects Amount in Reference Currency (tag 9F3A), and Transaction Reference Currency Code (tag 9F3C), which are used in a currency conversion procedure, if supported by the terminal.

The Issuer Authentication Data (tag 91) is received from the issuer in the authorization response message 1110. The issuer sends this message after receiving and processing an on-line authorization with ARQC in an authorization request message 1100 (Section 6.9.2). The CDOL2 may include the tag-length reference of the Issuer Authentication Data. The CDOL2 may also include the tag-length reference of the data object with tag 8A, Authorization Response Code. This code can be generated by the issuer, in case an ARQC was successfully sent on-line for authorization to the issuer and the corresponding response came back to the terminal, or by the terminal, in case the transaction is not authorized on-line (see also Section 6.8.4).

6.8.6.2 Application Cryptogram computation

After receiving the C-APDU of the GENERATE AC command, the card performs the card risk management procedure (see Section 7.10) to determine whether it agrees with the decision level proposed by the terminal. As a result, the card establishes the type of Application Cryptogram that it will generate (i.e., TC, ARQC, AAR, or AAC). The card sets the Cryptogram Information Data, which is the object in the card with tag 9F27, according to the type of Application Cryptogram it decides to compute.

In the next step the card generates the application cryptogram, which is the result of a cryptographic transformation performed with a cryptographic parameter that is uniquely linked to the ATC and/or the Application PAN of the card. This transformation is performed on a byte string referred to as a transaction claim, which includes the data objects related to the transaction at the point of service and a random number generated by the terminal. This Application Cryptogram can be regarded as the evidence produced by the card concerning its participation, as a delegate of the issuer, in the current transaction. One can recognize that this security mechanism corresponds to a dynamic authentication of the card (see Appendix D, Section D.7). Implicitly, this means that when producing the application cryptogram, the card dynamically authenticates itself, allowing a verifier to assess whether this is a genuine card or a counterfeit card. In other words, someone can say that there is an indissoluble link between the generation of the Application Cryptogram by the card and its dynamic authentication. The question is to whom the card dynamically authenticates. Or, in other words, which is the entity that can verify the validity of the dynamic authentication performed by the card, through assessing the correctness of the application cryptogram?

Case 1: When the transformation used by the card is a symmetric cryptographic algorithm, the Application Cryptogram is computed as a MAC with a session secret key SK _AC . In this case the dynamic authentication of the card is performed with a MAC-based DDA (see Appendix D, Section D.7.1). The issuer of the card is the only entity that can verify the application cryptogram.
Case 2: When the transformation used by the card is an asymmetric cryptographic algorithm, the Application Cryptogram is computed as a digital signature with the ICC private key (see Section 6.4.3). In this case the dynamic authentication of the card is performed with a digital signature “based DDA (see Appendix D, Section D.7.2). Anyone with an authentic copy of the ICC public key, and in particular the terminal at the point of service, can verify the application cryptogram. In Section 6.6 of Book 2 [2] of the EMV 2000 specifications, this is called the combined dynamic data authentication/Application Cryptogram generation. This can be performed only during the first issuance of the GENERATE AC command and only when the card was requested for a TC or an ARQC.

In the remainder of this section, we describe the processing performed by the card for the computation of the Application Cryptogram in each of the two cases identified above.

Case 1 First, we explain the personalization of the appropriate keys in the card for the computation of the application cryptogram. The IH uses a tamper-resistant cryptographic module containing the issuer master key for Application Cryptogram (IMK _AC ). The state of the art in cryptography requires that this master key be at least a double-length triple DES key (see Appendix E, Section E.3). When a card is issued, the IH uses the account identification data linked to this card as a diversification information to derive a unique key per card (see Appendix E, Section E.5). The account identification data consists of the Application PAN and the Application PAN Sequence Number, which identifies the current card among several cards that may be linked to the same PAN (see Annex A1.4 in Book 2 [2]). This derived key is referred to as the ICC Application Cryptogram master key (MK _AC ), which is also a double-length triple DES key (see Section 8.1.2 in Book 2 [2]). The issuer stores MK _AC in the ICC.

When the card receives the GENERATE AC command during its utilization stage, it derives an Application Cryptogram session key (SSK _AC ) asa double-length triple DES key from the MK _AC , using the ATC as diversification information (see Annex A1.3 in Book 2 [2]). This session key is used to produce the Application Cryptogram with a MAC based on a 64 bitlength block cipher (see Appendix E, Section E.4) applied on the transaction claim.

The transaction claim is a byte string formed as the concatenation of the following data items:

The value fields of some data objects received from the terminal in the transaction-related data field included in the C-APDU of the GENERATE AC command: Amount Authorized, Amount Other, Transaction Currency Code, transaction date, transaction type, Terminal Country Code, TVR, and unpredictable number;
The value fields of some data objects in the card, describing the context of the EMV ¢ transaction from the viewpoint of the card: the AIP, the ATC, and the card risk management verification results (see Section 7.10).

The Application Cryptogram consists of 8 bytes if it is produced with a DES-based MAC with the symmetric session key SSK _AC .

The data field of the R-APDU returned by the GENERATE AC command consists of a BER-TLV data object. The encoding of this data object shall be according to one of the following two formats.

Format 1 The data object can be a primitive data object with a tag equal to 80. Its value field consists of the concatenation without delimiters (tag and length) of the value fields of the following data objects:

Cryptogram Information Data ”mandatory. The meaning of the bits in this data elements was explained in Sections 6.8.3 to 6.8.5;
Application Transaction Counter (ATC) ”mandatory;
Application Cryptogram (AC) ”mandatory;
Issuer Application Data (IAD) ”optional, formed according to the issuer preferences. It may include a key indicator and an algorithm version number to uniquely specify a certain version of the IMK _AC ,if there are different key versions for time-variant key values, and a certain version of the MAC/derivation algorithms used 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). In order to motivate certain decisions taken by the card, the issuer may decide to include the card risk management verification results in the IAD.

This format is suitable if the answer of the GENERATE AC has a preestablished format known in advance to the terminal application.

Format 2 The data object that is returned in the response message is a constructed data object with a tag equal to 77. Its value field may contain several BER-TLV encoded objects, but shall always include the Cryptogram Information Data (tag 9F27), the ATC (tag 9F36), and the Application Cryptogram computed by the ICC (tag 9F26).

This format is suitable if the answer of the GENERATE AC has no preestablished format.

Case 2 When the card receives the GENERATE AC command, it uses the ICC private key ( n _IC , d _IC ) to produce the signed dynamic application data. The procedure used to compute this signature is the same as that described in Section 6.4.3.3, with the following modifications:

The leftmost 12 to 18 bytes of field 4, ICC dynamic data, in the M _R part of the dynamic application data to be signed, contains the following data items:
- ICC Dynamic Number length ”1 byte;
- ICC Dynamic Number ”2 to 8 bytes;
- Cryptogram Information Data ”1 byte (supplementary item compared with the simple DDA);
- TC or ARQC ”8 bytes (supplementary item compared with the simple DDA).
The part M ² of the dynamic application data to be signed consists only of the Unpredictable Number generated by the terminal (in the framework of the simple DDA, the part M ² consists of the whole terminal dynamic data byte string, which includes the unpredictable number).

As one can see, the TC or ARQC is part of field 4. This means that the ICC must first compute the Application Cryptogram on the transaction claim. To this end the ICC computes the MAC based on a 64 bit-length block cipher with the symmetric session key SSK _AC , as explained in Case 1.

The data field of the R-APDU returned by the GENERATE AC command consists of a BER-TLV data object encoded according to format 2 in case the card risk management of the card decides to return a TC or ARQC.

Format 2 The data object that is returned in the response message is a constructed data object with a tag equal to 77. The value field may contain several BER-TLV coded objects, but shall always include the Cryptogram Information Data (tag 9F27), the ATC (tag 9F36), and the Signed Dynamic Application Data computed by the ICC (tag 9F4B).

If the card risk management of the card decides to answer with an AAC (rejection) to the combined DDA/AC request, the R-APDU is a BER-TLV data object, encoded either according to format 1 or 2. In either case the R-APDU includes at least the following data objects: Cryptogram Information Data, ATC, and the AAC.

6.8.6.3 Application Cryptogram verification

We have stated that the Application Cryptogram produced by the ICC can serve as evidence of a card's participation in an EMV ¢ transaction.

If the GENERATE AC returns an ARQC, this is sent in an authorization request message 1100 to the IH. If the verification of the ARQC passes , the IH has proof that the card used at the point of service is genuine. Thus, the ARQC serves as the on-line card authentication, which guarantees that no fake card is authorized in the system. This is a significant advance when compared to the debit/credit cards implemented with magnetic stripe.
If the GENERATE AC returns a TC, this enters in a clearing message 1240, based on which the acquirer claims the Amount, Authorized in the EMV ¢ transaction from the issuer (see Section 2.10). If the verification of the TC received in the clearing message passes, the issuer knows that its card produced the TC that participated in the transaction. The issuer agrees to pay back the money to the acquirer. However, if the cardholder denies his or her participation in a transaction, the issuer cannot legally prove that the TC evidence is correct, since only the tamper-resistant cryptographic module of the IH can verify this evidence.
In case the GENERATE AC returns an AAC with the reason code 010, "PIN try limit exceed", in bits 3 to bit 1 of the Cryptogram Information Data, the ICC may require the terminal to generate an advice message 1220 (bit 4 = 1 in the Cryptogram Information Data). This advice message informs the IH about the exceeding of the PIN try limit in the card, and the AAC serves as evidence to this fact.

The IH uses a tamper resistant cryptographic module containing the IMK _AC (see Section 6.8.6.2, Case 1). Based on the account identification data of the ICC, the cryptographic module derives the MK _AC corresponding to the ICC according to Annex A1.4 in Book 2 [2]. Using this key specific to each card, the cryptographic module computes the session key SSK _AC as a leaf in a keys-tree built starting from the MK _AC at the root of this tree and using the ATC, which uniquely identifies the EMV ¢ transaction. This session key is used to produce a MAC based on a 64 bit-length block cipher like DES applied on the transaction claim. This verification MAC is compared against the received application cryptogram, and if the two values are equal, the Application Cryptogram is accepted as valid evidence.

The verification algorithm explained above can be executed in the cryptographic module of the IH provided that the 1100, 1240, 1340, and 1220 messages include the following data items:

Application Cryptogram (ARQC, TC, or AAC);
Account identification data of the card (PAN and PAN Sequence Number);
ATC and the Unpredictable Number;
All the data objects necessary to reproduce the transaction claim.

If the ICC performs a combined DDA/AC generation, the terminal can verify off-line that the card is genuine by verifying the correctness of the Signed Dynamic Application Data returned in the R-APDU of the GENERATE AC command.

To this end the terminal first obtains an authentic copy of the ICC public key ( n _IC , e _IC ), applying the procedure described in Section 6.4.3.2. Using this key, the terminal verifies the Signed Dynamic Application Data by applying a slightly modified version of the processing described in Section 6.4.3.4. The entire procedure can be found in Section 6.6.2 of Book 2 [2]. If the verification passes, the terminal accepts the fact that the card is genuine. If, however, the Signed Dynamic Application Data is stored (e.g., by the payment system operator), the issuer would have a supplementary possibility to prove in a court of law the participation of an EMV ¢ card in a certain transaction. This facility, however, has significant costs in terms of storage space, and should be utilized only for transactions involving important values of the parameter Amount, Authorized.