SB nº SU-20 : Combined DDA/AC Generation (Spec Change)

2004-01-01T00:00:00+00:00 v1.0 Specification Bulletins

Specification Update Bulletin no. 20 First Edition December 2003 Combined DDA/AC Generation This bulletin clarifies details of Combined DDA/AC Generation and applies to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0 Books 2, 3, and 4 as updated by Specification Update Bulletins 6 and 9. The main aspects of these Combined DDA/AC Generation clarifications can be summarized as follows: 1. The addition of the required card and terminal behaviour when the card response to the first GENERATE AC is an AAR. 2. The addition of the required terminal behaviour when the applicable CDOL does not include the tag for the Unpredictable Number. 3. The clarification that in the case that Combined DDA/AC Generation has failed the terminal shall determine the cryptogram type using the version of Cryptogram Information Data recovered from the GENERATE AC response, not the cleartext version. 4. The clarification that the terminal should not request Combined DDA/AC Generation when the terminal is requesting an AAC in the GENERATE AC command. 5. The clarification that the TVR Bit for Combined DDA/AC Generation failed shall be set when the offline data authentication input list cannot be built. 6. The clarification that the ICC Public Key need not be retrieved until it is needed for dynamic signature verification. A flowchart with an example of Combined DDA/AC Generation processing has been added to the revised text. Combined DDA/AC Generation for AAR Card Responses In order to clarify the response format during Combined DDA/AC Generation when the card response is an AAR, it is necessary to add that an AAR card response should not be contained within an RSA envelope. Please make the following changes to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 2, Section 6.6.1 Dynamic Signature Generation Step 3 below Table 16: Change "If the ICC responds with an AAC" to "If the ICC responds with an AAC or an AAR".

Change Table 17 third line Value entry from "Application Authentication Cryptogram" to "AAC or AAR." Please replace the first paragraph of EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 2, Section 6.6.2 Dynamic Signature Verification with the following three paragraphs: On receiving the GENERATE AC response, the terminal determines the type of Application Cryptogram by inspecting the cleartext CID in the response. If the ICC has responded with an AAC, then Combined DDA/AC Generation has failed, the terminal shall set the TVR bit for Combined DDA/AC Generation failed to '1', and the transaction is declined. If the ICC has responded with an AAR, then the response should not contain a dynamic signature and the terminal should not attempt recovery of a dynamic signature from the response. If this response does contain a dynamic signature, Combined DDA/AC Generation has failed, the terminal should set the TVR bit for Combined DDA/AC Generation failed to '1' and complete the transaction as a decline. Combined DDA/AC Generation when CDOL does not contain the tag for Unpredictable Number In order to clarify the terminal behaviour when Combined DDA/AC Generation is to be performed and CDOL1 or CDOL2 does not contain the tag for Unpredictable Number, it is necessary to add that the TVR bit for Combined DDA/AC Generation failed is set to '1' and an AAC is requested. Please replace Step 1 of EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 2, Section 6.6.1 Dynamic Signature Generation with the following: 1. The terminal issues a first or second GENERATE AC command according to Book 3 of these specifications. It is mandatory that the Card Risk Management Data Object List 1 (CDOL1) for the first GENERATE AC and the Card Risk Management Data Object List 2 (CDOL2) for the second GENERATE AC contain the Unpredictable Number generated by the terminal (tag '9F37', 4 bytes binary). If this is not the case, then Combined DDA/AC Generation has failed and the terminal shall set the TVR bit for Combined DDA/AC Generation failed to '1' and shall request an AAC from the ICC." Combined DDA/AC Generation usage of Cryptogram Information Data In order to clarify whether the cleartext Cryptogram Information Data (CID) or the CID recovered from the dynamic signature shall be used to determine the terminal action in the case that Combined DDA/AC Generation has failed, it is necessary to add that the recovered CID is used when available.

Please make the following change to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 4, Section 2.3.2 Data Authentication as shown in EMV Specification Update Bulletin 6: After the bulleted items add a non-bulleted sentence saying “If as part of dynamic signature verification the CID was retrieved from the ICC Dynamic Data (as recovered from the Signed Dynamic Application Data), then it is this value that shall be used to determine the cryptogram type. Otherwise the cleartext CID in the GENERATE AC response shall be used.” Combined DDA/AC Generation when an AAC is requested In order to clarify that the terminal should not request Combined DDA/AC Generation when the terminal is requesting an AAC in the GENERATE AC command, it is necessary to add that the CDA-requested bit in the GENERATE AC command should not be set under these circumstances. Please make the following changes to EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 2, Section 6.6.1 Dynamic Signature Generation: In the first paragraph after the first two bullets, add the following bullet:

The cryptogram to be requested is not an AAC. Clarification of Setting of TVR Bit when Offline Data Authentication Input List cannot be Built In order to clarify that the terminal shall set Combined DDA/AC Generation failed in the TVR during Combined DDA/AC Generation when the input list for offline data authentication cannot be built, please make the following change to the seventh paragraph under "Description:" in EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 3, Section 6.3 Offline Data Authentication: Replace "and the appropriate 'Offline static data authentication failed' or 'Offline dynamic authentication failed' bit shall be set in the TVR." with "and the appropriate 'Offline static data authentication failed' or 'Offline dynamic data authentication failed' or 'Combined DDA/AC Generation failed' bit shall be set in the TVR." Clarification that the ICC Public Key need not be Retrieved until it is needed for Dynamic Signature Recovery In order to clarify that the terminal need not retrieve the ICC Public Key from the ICC Public Key Certificate, please make the following change in EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 2, Section 6.6.1 Dynamic Signature Generation: Delete the first bullet after "In this section it assumed that" For the same reason, please make the following change in EMV 2000 Integrated Circuit Card Specifications for Payment Systems Version 4.0, Book 2, Section 6.6.2 Dynamic Signature Verification: Add a sentence to the beginning of the section saying "In this section it is assumed that the terminal has successfully retrieved the ICC Public Key as described above. " Revised Section 6.6 of EMV Book 2 The following is Section 6.6 of EMV 2000 Integrated Circuit Card Specifications for Payment Systems Book 2 Security and Key Management with incorporation of the changes and clarifications from this bulletin and from EMV Specification Update Bulletin 6 published in December 2001. Text changing with this bulletin is marked with change bars. These bulletins listed above and Specification Update Bulletin 9 published in March 2003 contains additional changes and clarifications to Books 3 and 4 that are not shown below.

6.6 Combined Dynamic Data Authentication/Application Cryptogram Generation 6.6.1 Dynamic Signature Generation In this section it is assumed that

Both the ICC and the terminal support Combined DDA/AC Generation and the ICC will respond as such to the first generate AC command according to Book 3 of these specifications.
The cryptogram to be requested is not an AAC. 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 according to Book 3 of these specifications. It is mandatory that the Card Risk Management Data Object List 1 (CDOL1) for the first GENERATE AC and the Card Risk Management Data Object List 2 (CDOL2) for the second GENERATE AC contain the Unpredictable Number generated by the terminal (tag '9F37', 4 bytes binary). If this is not the case, then Combined DDA/AC Generation has failed and the terminal shall set the TVR bit for Combined DDA/AC Generation failed to '1' and shall request an AAC from the ICC. 2. If the ICC is to respond with a TC or ARQC, the ICC performs the following steps: 1) The ICC generates the TC or ARQC. 2) The ICC applies the hash algorithm specified by the Hash Algorithm Indicator to the concatenation from left to right of the following data elements: In the case of the first GENERATE AC command: The values of the data elements specified by, and in the order they appear in the PDOL, and sent by the terminal in the GET PROCESSING OPTIONS command. The values of the data elements specified by, and in the order they appear in the CDOL1, and sent by the terminal in the first GENERATE AC command. The tags, lengths and values of the data elements returned by the ICC in the response to the GENERATE AC command in the order they are returned, with the exception of the Signed Dynamic Application Data. In the case of the second GENERATE AC command: The values of the data elements specified by, and in the order they appear in the PDOL, and sent by the terminal in the GET PROCESSING OPTIONS command. The values of the data elements specified by, and in the order they appear in the CDOL1, and sent by the terminal in the first GENERATE AC command. The values of the data elements specified by, and in the order they appear in the CDOL2, and sent by the terminal in the second GENERATE AC command. The tags, lengths and values of the data elements returned in the response to the GENERATE AC command in the order they are returned, with the exception of the Signed Dynamic Application Data. The 20-byte result is called the Transaction Data Hash Code 3) The ICC applies the digital signature scheme specified in Annex A2.1 to the data specified in Table 14 using its ICC Private Key SIC in conjunction with the corresponding algorithm. The result is called the Signed Dynamic Application Data. Field Name Signed Data Format Hash Algorithm Indicator ICC Dynamic Data Length ICC Dynamic Data Pad Pattern Unpredictable Number Length 1

Description

Hex. Value ‘05’ 1 1 LDD NIC – LDD – 25 4 Identifies the hash algorithm used to produce the Hash Result1 Identifies the length LDD of the ICC dynamic data in bytes Dynamic data generated by and/or stored in the ICC (NIC – LDD – 25) padding bytes of value ‘BB’7 Unpredictable Number generated by the terminal Format b b b b b Table 14 - Dynamic Application Data to be Signed (i.e., input to the hash algorithm in Annex A2.1.2) The length LDD of the ICC Dynamic Data satisfies 0 ≤ LDD ≤ NIC − 25. The 3238 leftmost bytes of the ICC Dynamic Data shall consist of the concatenation of the data specified in Table 15. Length 1 2-8 1 8 20 Value ICC Dynamic Number Length ICC Dynamic Number Cryptogram Information Data TC or ARQC Transaction Data Hash Code Format b b b b b Table 15 – 32-38 Leftmost Bytes of the ICC Dynamic Data The ICC Dynamic Number is a time-variant parameter generated by the ICC (it can for example be an unpredictable number or a counter incremented each time the ICC receives a GENERATE AC command during a transaction). The ICC response to the GENERATE AC command shall be coded according to format 2 as specified in Part I of Book 3 of these specifications (constructed data object with tag ‘77’) and shall contain at least the three mandatory data objects (TLV coded in the response) specified in Table 16, and optionally the Issuer Application Data. 7 As can be seen in Annex A2.1, NI − 22 bytes of the data signed is recovered from the signature. Since the length of the first three data elements in Table 11 is three bytes, there are NI − 22 − 3 = NI − 25 bytes remaining for the data to be stored in the signature.

Tag ‘9F27’ ‘9F36’ ‘9F4B’ ‘9F10’ Length 1 2 NIC Var. up to 32 Value Cryptogram Information Data Application Transaction Counter Signed Dynamic Application Data Issuer Application Data Presence M M M O Table 16 - Data Objects Included in Response to GENERATE AC if a TC or ARQC Requested 3. If the ICC responds with an AAC or an AAR, the ICC response shall be coded according to either format 1 or format 2 as specified in Part I of Book 3 of these specifications and shall contain at least the three mandatory data elements specified in Table 17, and optionally the Issuer Application Data. Tag ‘9F27’ ‘9F36’ ‘9F26’ ‘9F10’ Length 1 2 8 Var. up to 32 Value Cryptogram Information Data Application Transaction Counter AAC or AAR Issuer Application Data Presence M M M O Table 17 - Data Objects Included in Response to GENERATE AC if an AAC or AAR Requested 6.6.2 Dynamic Signature Verification In this section it is assumed that the terminal has successfully retrieved the ICC Public Key as described above. On receiving the GENERATE AC response, the terminal determines the type of Application Cryptogram by inspecting the cleartext CID in the response. If the ICC has responded with an AAC, then Combined DDA/AC Generation has failed, the terminal shall set the TVR bit for Combined DDA/AC Generation failed to '1', and the transaction is declined. If the ICC has responded with an AAR, then the response should not contain a dynamic signature so the terminal should not attempt recovery of a dynamic signature from the response. If the response does contain a dynamic signature, then Combined DDA/AC Generation has failed, the terminal should set the TVR bit for Combined DDA/AC Generation failed to '1' and complete the transaction as a decline If the ICC has responded with a TC or ARQC, the terminal retrieves from the response the first four data objects specified in Table 16 and executes the following steps. 1. If the Signed Dynamic Application Data has a length different from the length of the ICC Public Key Modulus, Combined DDA/AC Generation has failed.

2. To obtain the recovered data specified in Table 18, apply the recovery function specified in Annex A2.1 on the Signed Dynamic Application Data using the ICC Public Key in conjunction with the corresponding algorithm. If the Recovered Data Trailer is not equal to ‘BC’, Combined DDA/AC Generation has failed. Field Name Recovered Data Header Signed Data Format Hash Algorithm Indicator ICC Dynamic Data Length ICC Dynamic Data Pad Pattern Hash Result Recovered Data Trailer Length 1 Description Hex. Value ‘6A’ 1 Hex. Value ‘05’ 1 1 LDD NIC – LDD – 25 20 1 Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme Identifies the length of the ICC dynamic data in bytes Dynamic data generated by and/or stored in the ICC (NIC – LDD – 25) padding bytes of value ‘BB’6 Hash of the Dynamic Application Data and its related information Hex. Value ‘BC’ Format b b b b b b b Table 18 - Format of the Data Recovered from the Signed Dynamic Application Data 3. Check the Recovered Data Header. If it is not ‘6A’, Combined DDA/AC Generation has failed. 4. Check the Signed Data Format. If it is not ‘05’, Combined DDA/AC Generation has failed. 5. Retrieve from the ICC Dynamic Data the data specified in Table 15. 6. Check that the Cryptogram Information Data retrieved from the ICC Dynamic Data is equal to the Cryptogram Information Data obtained from the response to the GENERATE AC command. If this is not the case, Combined DDA/AC Generation has failed. 7. Concatenate from left to right the second to the sixth data elements in Table 18 (that is, Signed Data Format through Pad Pattern), followed by the Unpredictable Number. 8. Apply the indicated hash algorithm (derived from the Hash Algorithm Indicator) to the result of the concatenation of the previous step to produce the hash result. 9. Compare the calculated hash result from the previous step with the recovered Hash Result. If they are not the same, Combined DDA/AC Generation has failed.

10. Concatenate from left to right the values of the following data elements: In the case of the first GENERATE AC command:

The values of the data elements specified by, and in the order they appear in the PDOL, and sent by the terminal in the GET PROCESSING OPTIONS command.
The values of the data elements specified by, and in the order they appear in the CDOL1, and sent by the terminal in the first GENERATE AC command.
The tags, lengths, and values of the data elements returned by the ICC in the response to the GENERATE AC command in the order they are returned, with the exception of the Signed Dynamic Application Data. In the case of the second GENERATE AC command:
The values of the data elements specified by, and in the order they appear in the PDOL, and sent by the terminal in the GET PROCESSING OPTIONS command.
The values of the data elements specified by, and in the order they appear in the CDOL1, and sent by the terminal in the first GENERATE AC command.
The values of the data elements specified by, and in the order they appear in the CDOL2, and sent by the terminal in the second GENERATE AC command.
The tags, lengths, and values of the data elements returned in the response to the GENERATE AC command in the order they are returned, with the exception of the Signed Dynamic Application Data. 11. Apply the indicated hash algorithm (derived from the Hash Algorithm Indicator) to the result of the concatenation of the previous step to produce the Transaction Data Hash Code. 12. Compare the calculated Transaction Data Hash Code from the previous step with the Transaction Data Hash Code retrieved from the ICC Dynamic Data in Step 5. If they are not the same, Combined DDA/AC Generation has failed. If all the above steps were executed successfully, Combined DDA/AC Generation was successful. The ICC Dynamic Number and the ARQC or TC contained in the ICC Dynamic Data recovered in Table 15 shall be stored in Tag ‘9F4C’ and in Tag ‘9F26’, respectively. The following three figures provide an example of the processing for Combined DDA/AC Generation. If any discrepancies are found between the text and flow, the text shall be followed. Offline Data Authentication Processing Terminal & card support CDA? YES Terminal recovers CA, Issuer, and ICC Public Keys from certificates NO Check other Offline Data Authentication methods Any certificate recovery errors? NO Term. Action Analysis result is AAC? NO, TC or ARQC CDOL1 contains Unpred. Number? YES YES, AAC NO Set CDA Failure in TVR YES Issue 1st GEN AC for TC or ARQC with P1 requesting CDA Set ODA Performed in TSI Issue 1st GEN AC for an AAC. Do not request CDA in P1. Card GEN AC Processing CDA requested in P1 of GEN AC? NO YES ICC response = TC or ARQC? NO, AAC or AAR YES Return GEN AC response with Signed Dynamic Applic. Data Return GEN AC response without Signed Dynamic Applic. Data Figure 1 of CDA Processing Flow 1st GEN AC Response Processing P1 of 1st GEN AC requested CDA? YES GEN AC response = AAC or AAR? NO, TC or ARQC Recover Signed Dynamic Applic. Data Recovery is YES successful? GEN AC response = TC? NO, ARQC YES Perform approval processing NO Perform non-CDA processing GEN AC YES response = AAC? YES YES NO Set CDA Failure in TVR. Set ODA Performed in TSI NO, AAR Signed Dyn. Applic. Data in response? NO Set ODA Performed in TSI Perform referral processing Perform Online Processing GEN AC response = NO ARQC? Unpred. Number in CDOL2? YES Issue 2nd GEN AC with P1 requesting CDA NO Set CDA Failure in TVR. Set ODA Performed in TSI YES, ARQC Issue 2nd GEN AC for an AAC. Do not request CDA in P1. Perform decline processing Figure 2 of CDA Processing Flow 2nd GEN AC Response Processing C Receive response to 2nd GEN AC CDA requested in P1 of 2nd GEN AC? Complete transaction NO processing according to non-CDA rules. YES GEN AC response = AAC? NO, YES, TC AAC Recover Signed Dynamic Applic. Data Recovery successful? YES Perform approval processing NO Set CDA Failure in TVR Perform decline processing Set ODA Performed in TSI Complete transaction processing Figure 3 of CDA Processing Flow