SB nº SU-44 : CDA Modified Terminal Behaviour (Spec Change)

2007-02-01T00:00:00+00:00 v1.0 Specification Bulletins

Specification Update Bulletin No. 44 First Edition February 2007 CDA Modified Terminal Behaviour This bulletin modifies terminal behaviour for CDA in order to allow improved CDA transaction performance. This bulletin also modifies terminal behaviour for CDA failures based upon when in the transaction sequence the terminal detects the failure. It requires a terminal to use the results of Terminal Action Analysis when CDA failures are detected prior to Terminal Action Analysis. CDA failures detected after Terminal Action Analysis always result in an offline decline. This bulletin also clarifies other aspects relating to CDA processing.

Applicability

This Specification Update Bulletin applies to:

EMV Integrated Circuit Card Specifications for Payment Systems Version 4.1 Book 2 Security and Key Management
EMV Integrated Circuit Card Specifications for Payment Systems Version 4.1 Book 3 Application Specification
EMV Integrated Circuit Card Specifications for Payment Systems Version 4.1 Book 4 Cardholder, Attendant, and Acquirer Interface Requirements

Description

This bulletin

modifies terminal behaviour for CDA to allow improved transaction performance by reducing the occurrences of CDA during some transactions;
modifies terminal behaviour for CDA failures based upon when in the transaction sequence the terminal detects the failure;
modifies terminal behaviour for when the card responds with an AAC;
modifies terminal behaviour with respect to Unpredictable Numbers in CDOLs;
clarifies other aspects relating to CDA processing. An annex to this bulletin provides an updated version of Book 2 incorporating the changes identified in this bulletin. Transaction Performance This bulletin defines a modification to terminal behaviour such that even though the card and terminal both support CDA (as indicated in the AIP and Terminal Capabilities), the terminal need not request CDA for online authorisations. Similarly, following successful online authorisation the terminal need not request a CDA signature on a TC in the second GENERATE AC command1. However if the terminal is unable to go online and requests a TC in the second GENERATE AC command, then the terminal shall request a CDA signature on this TC. If CDA is not performed because the terminal has requested an ARQC without CDA, then the terminal shall set the TVR bit to indicate that Offline Data Authentication was not performed on the transaction. A CDA-capable card is still expected to reply with a CDA signature if (and only if) so requested by the terminal, except when responding with an AAC. CDA Failures This bulletin defines terminal behaviour in the event of a CDA failure. This behaviour depends on when in the transaction sequence the terminal detects the failure. It requires that a terminal uses the results of Terminal Action Analysis if CDA failures are detected prior to Terminal Action Analysis. CDA failures detected after Terminal Action Analysis always result in an offline decline. Please note that EMV Book 3 Section 10.7 recommends that as a minimum the TAC - Online and TAC - Default bits for ‘CDA failed’ be set to 1 so that transactions where CDA fails prior to Terminal Action Analysis will not be approved offline. Please note also that if the Issuer and ICC Public Keys are recovered after the final Terminal Action Analysis, then any recovery failures will result in an offline decline. 1 Such a request would not normally be expected because the transaction will have been approved online but a CDA signature might be deemed useful for business reasons. AAC responses This bulletin modifies terminal behaviour so that when the terminal requests an ARQC or TC with a CDA signature the terminal will not consider CDA to have failed on account of the card responding with an AAC. Unpredictable Numbers This bulletin modifies terminal behaviour so that the terminal does not check that CDOL1 and CDOL2 identify the Unpredictable Number. Issuers are advised that CDA cards must still identify the Unpredictable Number in both CDOL1 and CDOL2. Clarifications This bulletin
clarifies that when CDA fails after the card has responded with a TC to the first GENERATE AC command, then the decline processing does not require that the terminal issue a second GENERATE AC for an AAC;
clarifies the reference to the description of the retrieval of the ICC Private Key;
corrects an omission in EMV Specification Update Bulletin 20 and thereby in EMV 4.1 Book 3, where the Terminal Action Analysis processing fails to mention that CDA is not requested when the cryptogram being requested is an AAC;
clarifies that in the case of CDA the process of offline data authentication continues beyond the first GENERATE AC command. Specification Change Notice Please modify Book 2 Section 6.6 with the following text inserted immediately before Section 6.6.1. “In the case of the first GENERATE AC command:
When requesting an ARQC, the terminal may request it with or without a CDA signature. When an ARQC is requested without a CDA signature, then the terminal shall set the TVR bit for 'Offline data authentication was not performed' to 12 prior to issuance of the GENERATE AC command. When an ARQC is requested without a CDA signature, the processes described in sections 6.6.1 and 6.6.2 are not performed.
When requesting a TC, the terminal shall request it with a CDA signature.
When requesting an AAC, the terminal shall request it without a CDA signature. In the case of the second GENERATE AC command:
The terminal shall set the TVR bit for 'Offline data authentication was not performed' to 03 prior to issuance of the GENERATE AC command. If the terminal is processing the transaction as ‘unable to go online’ then the TVR bit setting shall be done before the associated terminal action analysis.
When requesting a TC:
If the terminal is processing the transaction as ‘unable to go online’ (and the result of terminal action analysis is to request a TC), then the terminal shall request a TC with a CDA signature. 2 This updated TVR is used if requested in CDOL1. 3 This updated TVR is used if requested in CDOL2.
If the terminal is not processing the transaction as ‘unable to go online’, then the terminal may request the TC with or without a CDA signature.
When requesting an AAC, the terminal shall request it without a CDA signature. ” Please append the following text to the first sentence of the first step of Section 6.6.1: “ with the ‘CDA signature requested’ bit in the GENERATE AC command set to 1.” Please change the last paragraph of EMV Book 3 Section 10.7 to the following: "If CDA is to be performed (as described in section 10.3 of this book and Section 6.6 of Book 2), the terminal shall set the bit for ‘CDA signature Requested’ in the GENERATE AC command to 1.” Note that Specification Update Bulletin 20 and its incorporation into EMV – in version 4.1 - clarified that the terminal should not request CDA when the terminal requests an AAC in the GENERATE AC command. This clarification was erroneously omitted in one location in the specification but is correct above. Clarification to actions taken on CDA failure Please replace the text between the second paragraph and final paragraph of EMV Book 4 Section 6.3.2 with the following: "When the selected form of offline data authentication is CDA and CDA fails prior to the final Terminal Action Analysis (for example, Issuer Public Key recovery fails prior to Terminal Action Analysis) preceding the issuance of a first GENERATE AC command, or second GENERATE AC command in the case ‘unable to go online’, the terminal shall set the TVR bit for ‘CDA failed’ to 1 and request the cryptogram type determined by Terminal Action Analysis. In this case, the GENERATE AC command shall not request a CDA signature and no further CDA processing is performed. When the selected form of offline data authentication is CDA and a CDA failure is detected after the final Terminal Action Analysis preceding the issuance of a first or second GENERATE AC command, the terminal shall set the ‘CDA failed’ bit in the TVR to 1 and the following rules apply: If CDA fails in conjunction with the first GENERATE AC:
If the Cryptogram Information Data (CID) bit indicates that the card has returned a TC, the terminal shall decline the transaction and not perform a second GENERATE AC command.
If the CID bit indicates that the card has returned an ARQC, the terminal shall complete the transaction processing by performing an immediate second GENERATE AC command requesting an AAC. If CDA fails in conjunction with the second GENERATE AC, the terminal shall decline the transaction.” Please replace the beginning of Book 2 Section 6.6 with the following text (where the use of underscore denotes new text inserted and the use of strikethrough denotes old text deleted): "6.6 Combined DDA/Application Cryptogram Generation (CDA) CDA consists of a dynamic signature generated by the ICC (similar to DDA but including Application Cryptogram (AC) generation) followed by verification of the signature by the terminal. It is applicable to both the first and second GENERATE AC commands and requires the retrieval of the relevant public keys as described in Sections 6.2, 6.3 and 6.4. Since the public keys are not required until the CDA signature is verified as part of processing the response to the first GENERATE AC, retrieval of the public keys may happen any time before verifying the CDA signature. During retrieval of the public keys, errors may result in CDA failure (TVR bit for ‘CDA failed’ is set to 1). These errors include but are not limited to failure of public key retrieval and invalid format of records to be authenticated (see Book 3 Section 10.3). For the first GENERATE AC command, and for the second GENERATE AC command in the case ‘unable to go online’, the cryptogram type requested by the terminal is always determined by the final Terminal Action Analysis preceding the GENERATE AC command. If any of the above errors are detected prior to the final Terminal Action Analysis, then the terminal shall not request CDA in the GENERATE AC command. When the GENERATE AC command is issued with a CDA request, then if any of the above errors are detected subsequently, the eventual result will be an offline decline in accordance with the paragraphs beginning "If CDA fails in conjunction" in Book 4 Section 6.3.2. In this section In sections 6.6.1 and 6.6.2 it is assumed that:
Both the ICC and the terminal support CDA.
The cryptogram to be requested is not an Application Authentication Cryptogram (AAC), i.e. Terminal Action Analysis has not resulted in offline decline.
The TVR bit for ‘CDA failed’ is not set to 1 prior to final Terminal Action Analysis.
Except when returning an AAC, the ICC always replies with a CDA signature when requested by the terminal.” AAC Responses Please modify the 3rd paragraph of Section 6.6.2 as follows: “If the ICC has responded with an AAC, then CDA has failed, and the terminal shall decline the transaction.” Unpredictable Numbers Please delete all but the first sentence in Step 1 of Section 6.6.1. At the beginning of Section 6 on , please replace the end of the second bullet “..and identified by Card Risk Management Data Object List 1 (CDOL1) or Card Risk Management Data Object List 2 (CDOL2).” with the following footnote “In order to ensure that the ICC uses the correct value for the Unpredictable Number the Issuer must ensure that both CDOL1 and CDOL2 contain tag ‘9F37’”. Sample CDA Flows In order to synchronize the CDA flows with the specification changes and clarifications described above, please replace Figures 3, 4, and 5 with the flows on the following pages: Figure 3: CDA Sample Flow Part 1 of 3 Offline Data Authentication Processing Terminal & card support CDA? Check other NO Offline Data Authentication methods YES Any CDA errors detected yet? Terminal recovers CA, Issuer, and ICC Public Keys from certificates. YES Note: Key recovery may be done at any time before 1st GEN AC response processing. Recovery failures are acted on either during Terminal Action Analysis or in 1st GEN AC response processing. NO Approve Offine (TC) YES Issue GEN AC for TC/ARQC requesting CDA A Terminal Action Analysis result... Go Online (ARQC) Terminal requests CDA for ARQC? NO Set ‘Offline Data Auth. Not Performed’ to ‘1’ in TVR. Issue GEN AC for ARQC without requesting CDA. Decline Offline (AAC) Set ‘Offline Data Auth. Not Performed’ to ‘1’ in TVR. Issue GEN AC for AAC without requesting CDA. Continue with nonCDA processing. Set CDA Failure in TVR Complete Terminal Action Analysis and GEN AC processing without CDA according to Book 3 Figure 7. A Card 1st GENERATE AC Processing CDA requested in P1 of GEN AC? YES TC or ARQC ICC response... Card returns GEN AC response with Signed Dynamic Applic. Data NO AAC Card returns GEN AC response without Signed Dynamic Applic. Data Figure 4: CDA Sample Flow Part 2 of 3 A 1st GENERATE AC Response Processing GEN AC response... O AAC ARQC/TC TC Perform approval processing. Do not issue 2nd GEN AC. Unable to Go Online - Approval YES Set ‘Offline Data Auth. Not Performed’ to ‘0’ in TVR. Issue 2nd GEN AC for a TC requesting CDA. B GEN AC response... CDA NO requested in GEN AC? YES Recover Signed Dynamic Application Data ARQC O Perform online authorization Online processing result... Online Approval Terminal requests CDA for online approvals? Online Decline or Unable to Go Online - Decline NO Issue 2nd GEN AC for a TC without requesting CDA. Continue with nonCDA processing. NO Any CDA errors detected? YES Set CDA Failure in TVR GEN AC response... ARQC TC/ AAC Perform decline processing. Do not issue 2nd GEN AC. Issue 2nd GEN AC for an AAC without requesting CDA. Continue with nonCDA processing. Figure 5: CDA Sample Part 3 of 3 B 2nd GENERATE AC Response Processing GEN AC response... TC Recover Signed Dynamic Applic. Data AAC Recovery successful? NO Set CDA Failure in TVR YES Perform approval processing Perform decline processing Complete transaction processing Clarification of Retrieval of ICC Private Key To clarify the reference to the process of retrieving the ICC Private Key, in EMV Book 2 Section 6.6.2 first sentence, please replace "as described above" with "as described in Section 6.2, 6.3, and 6.4." Clarification that in the case of CDA the process of offline data authentication continues beyond the first GENERATE AC command The EMV specifications define three types of offline data authentication: SDA, DDA and CDA. When performing SDA or DDA the terminal completes the offline data authentication process prior to issuing the first GENERATE AC command. This means that the Terminal Action Analysis can always be informed of the results of SDA or DDA. When performing CDA the terminal will normally not complete the offline data authentication process until after receiving the response to the first GENERATE AC command4 and in this case the results of CDA cannot be used in the Terminal Action Analysis. This bulletin clarifies this scenario by adding a note to Section 10.3 of the EMV Integrated Circuit Card Specifications for Payment Systems Version 4.1 Book 3. When performing CDA it is permitted that the terminal commence the processing of the Public Key Certificates before or after issuing the first GENERATE AC command. If processing before and this processing fails, then the ‘CDA failed’ bit in the TVR is set to 1 and this result can be used in Terminal Action Analysis. Insert the following note in Section 10.3 of EMV Integrated Circuit Card Specifications for Payment Systems Version 4.1 Book 3 at the end of the ‘Sequence of Execution’ clause: “Note: Although the terminal shall commence performing CDA before completion of Terminal Action Analysis, the terminal will not normally finish performing CDA until after it has received the response to the GENERATE AC command. (This is a necessary consequence of the design of CDA.)” 4 Or even the second GENERATE AC command Updated Book 2 After the changes in this bulletin are applied, of Book 2 can be replaced with the following text:

6.6 Combined DDA/Application Cryptogram Generation (CDA) CDA consists of a dynamic signature generated by the ICC (similar to DDA but including Application Cryptogram (AC) generation) followed by verification of the signature by the terminal. It is applicable to both the first and second GENERATE AC commands and requires the retrieval of the relevant public keys as described in Sections 6.2, 6.3 and 6.4. Since the public keys are not required until the CDA signature is verified as part of processing the response to the first GENERATE AC, retrieval of the public keys may happen any time before verifying the CDA signature. During retrieval of the public keys, errors may result in CDA failure (TVR bit for ‘CDA failed’ is set to 1). These errors include but are not limited to failure of public key retrieval and invalid format of records to be authenticated (see Book 3 Section 10.3). For the first GENERATE AC command, and for the second GENERATE AC command in the case ‘unable to go online’, the cryptogram type requested by the terminal is always determined by the final Terminal Action Analysis preceding the GENERATE AC command. If any of the above errors are detected prior to the final Terminal Action Analysis, then the terminal shall not request CDA in the GENERATE AC command. When the GENERATE AC command is issued with a CDA request, then if any of the above errors are detected subsequently, the eventual result will be an offline decline in accordance with the paragraphs beginning "If CDA fails in conjunction" in Book 4 Section 6.3.2. In sections 6.6.1 and 6.6.2 it is assumed that:

Both the ICC and the terminal support CDA.
The cryptogram to be requested is not an Application Authentication Cryptogram (AAC), i.e. Terminal Action Analysis has not resulted in offline decline.
The TVR bit for ‘CDA failed’ is not set to 1 prior to final Terminal Action Analysis.
Except when returning an AAC, the ICC always replies with a CDA signature when requested by the terminal. In the case of the first GENERATE AC command:
When requesting an ARQC, the terminal may request it with or without a CDA signature. When an ARQC is requested without a CDA signature, then the terminal shall set the TVR bit for 'Offline data authentication was not performed' to 15 prior to issuance of the GENERATE AC command. When an ARQC is requested without a CDA signature, the processes described in sections 6.6.1 and 6.6.2 are not performed. 5 This updated TVR is used if requested in CDOL1.
When requesting a TC, the terminal shall request it with a CDA signature.
When requesting an AAC, the terminal shall request it without a CDA signature. In the case of the second GENERATE AC command:
The terminal shall set the TVR bit for 'Offline data authentication was not performed' to 06 prior to issuance of the GENERATE AC command. If the terminal is processing the transaction as ‘unable to go online’ then the TVR bit setting shall be done before the associated terminal action analysis.
When requesting a TC:
If the terminal is processing the transaction as ‘unable to go online’ (and the result of terminal action analysis is to request a TC), then the terminal shall request a TC with a CDA signature.
If the terminal is not processing the transaction as ‘unable to go online’, then the terminal may request the TC with or without a CDA signature.
When requesting an AAC, the terminal shall request it without a CDA signature.

6.6.1 Dynamic Signature Generation The generation of the combined dynamic signature and Application Cryptogram takes place in the following steps. 1. The terminal issues a first or second GENERATE AC command with the ‘CDA signature requested’ bit in the GENERATE AC command set to 1 according to sections 6.5.5.4 and 9.3 of Book 3. 2. If the ICC is to respond with a TC or ARQC, the ICC performs the following steps: a. The ICC generates the TC or ARQC. b. The ICC applies the hash algorithm specified by the Hash Algorithm Indicator to the concatenation from left to right of the following data elements: 6 This updated TVR is used if requested in CDOL2.

Applicability

Related Documents

Description