PCI Watch

Tracking changes across the Payment Card Industry

SB nº SU-6 : Modification to Combined Dynamic Data Authentication and Application Cryptogram Generation (Spec Change)

v1.0 Specification Bulletins

EMVCo Bulletins Specification Update: Bulletin no. 6, December 14th, 2001 The contents of this bulletin have immediate effect. Modification to Combined Dynamic Data Authentication and Application Cryptogram Generation

Introduction

This bulletin specifies the announced (see EMVCo Bulletin no. 10) enhancements to the Combined Dynamic Data Authentication and Application Cryptogram Generation (CDA) mechanism as described in section 6.6 of Book 2: Security and Key Management of EMV2000 (version 4.0). The main aspects of the enhancements can be summarised as follows: 1. The addition of a hash-code computed on the transaction data to the ICC Dynamic Data, which is signed by the ICC during the dynamic authentication process. 2. Extending the possibility of applying CDA not only to the first GENERATE AC command, but also to the second GENERATE AC command. The remainder of this bulletin specifies the changes to the books 2, 3 and 4 of EMV2000 (version 4.0) to support the enhancements to CDA. Modifications to Book 2 Section 6.6 of Book 2 is to be replaced by the following text:

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

  • The terminal has successfully retrieved the ICC Public Key as described above. 1 This document contains proprietary and confidential information of EMVCo. LLC. Copyright 2001  EMVCo. LLC.. All rights reserved.
  • Both the ICC and the terminal support combined dynamic data authentication/AC generation and the ICC will respond as such to the GENERATE AC command according to Book 3 of these specifications. The generation of the combined dynamic signature and Application Cryptogram takes place in the following steps. 1. The terminal issues a GENERATE AC command according to Book 3 of these specifications. It is mandatory that the Card Risk Management Data Object List (CDOL1 for the first GENERATE AC, CDOL2 for the second GENERATE AC) contains the Unpredictable Number generated by the terminal (tag ‘9F37’, 4 bytes binary). If this is not the case, then combined dynamic data authentication/AC generation will have failed. 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 command1. ¾ 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 command1. ¾ 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 command1. ¾ 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 command1. ¾ 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. 1 At the time of issuance of the command, the terminal is required to store the values of these data elements to later perform the signature verification process as specified in section 6.6.2. 2 This document contains proprietary and confidential information of EMVCo. LLC. Copyright 2001  EMVCo. LLC.. All rights reserved. ¾ 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 1 1 LDD NIC – LDD – 25 4

Description

Hex. Value ‘05’ Identifies the hash algorithm used to produce the Transaction Data Hash Code and the Hash Result in the digital signature scheme 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’ 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) The length LDD of the ICC Dynamic Data satisfies 0 ≤ LDD ≤ NIC − 25. The 32-38 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 3 This document contains proprietary and confidential information of EMVCo. LLC. Copyright 2001  EMVCo. LLC.. All rights reserved.

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. 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 the Response of the GENERATE AC Command in the Case of Combined Dynamic Data Authentication/AC generation. 3. If the ICC responds with an AAC, 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 Application Authentication Cryptogram Issuer Application Data Presence M M M O Table 17 – Data Elements Contained in the Response to the GENERATE AC Command if a AAC is Generated 6.6.2 Dynamic Signature Verification If the ICC has responded with an AAC, then combined dynamic data authentication/AC generation has failed. If the ICC has responded with a TC or ARQC, the terminal retrieves from the response the first 4 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 dynamic data authentication/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 dynamic data authentication/AC generation has failed. 4 This document contains proprietary and confidential information of EMVCo. LLC. Copyright 2001  EMVCo. LLC.. All rights reserved.

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 1 1 1 LDD NIC – LDD – 25 20 1 Description Hex. Value ‘6A’ Hex. Value ‘05’ Identifies the hash algorithm used to produce the Transaction Data Hash Code and 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’ 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 dynamic data authentication/AC generation has failed. 4. Check the Signed Data Format. If it is not ‘05’, combined dynamic data authentication/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 dynamic data authentication/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 dynamic data authentication/AC generation has failed. 10. Concatenate from left to right the values of the following data elements: 5 This document contains proprietary and confidential information of EMVCo. LLC. Copyright 2001  EMVCo. LLC.. All rights reserved.

  • 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 dynamic data authentication/AC generation has failed. If all the above steps were executed successfully, combined dynamic data authentication/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. Modifications to Book 3 Section 5.3, after the last paragraph, add the following paragraph: "If the ICC response is an approval (TC) or online authorisation request (ARQC) and the Combined DDA/AC Generation Requested bit in the GENERATE AC command is '1', 6 This document contains proprietary and confidential information of EMVCo. LLC. Copyright 2001  EMVCo. LLC.. All rights reserved. the ICC shall return the GENERATE AC response in a public key envelope as specified in Book 2 Section 6.6." Section 6.7, delete "and the ICC's CDOL1 does not include the tag for the Terminal Capability Profile" and replace the deleted text with "as described in Section 6.3." Section 6.8.2, delete entire section. The deleted text has been moved to section 5.3. Section 6.11, add the following paragraph after the first paragraph in the Description section: “If the terminal is to perform Combined DDA/AC Generation as described in Section 6.3, the terminal shall set the Combined DDA/AC Generation Requested bit in the GENERATE AC command to ‘1’.” Modifications to Book 4 At the end of Section 2.3.2, add the following paragraphs: "After a GENERATE AC response is received if Combined DDA/AC Generation failed as shown in section 6.6.2 of Book 2 Security and Key Management, the terminal shall set the Combined DDA/AC Generation Failed bit in the TVR to '1'. After the first GENERATE AC, ƒ If the card has returned a TC as indicated in the CID bit, the terminal shall decline the transaction. ƒ If the card has returned an ARQC as indicated in the CID bit, the terminal shall complete the transaction processing by performing an immediate second GENERATE AC command requesting an AAC. After the second GENERATE AC, the terminal shall decline the transaction." Delete the final bullet at the end of Section 2.3.7. This is the paragraph that begins "If Combined DDA/AC generation failed". 7 This document contains proprietary and confidential information of EMVCo. LLC. Copyright 2001  EMVCo. LLC.. All rights reserved.