PCI Watch

Tracking changes across the Payment Card Industry

SB CPA Specification v1 Plus Bulletins

v1.0 Specification Bulletins
Contact Card

Application Note Bulletin No. 39 First Edition February 2008 CPA Transaction Logging Controls in Application Control This Application Note Bulletin clarifies the EMV Common Payment Application (CPA) Specification to indicate that issuers should not modify the transaction logging controls in the Application Control data element after issuance of the card.

Applicability

This Application Note Bulletin applies to:

  • EMV Common Payment Application Specification Version 1.0 December 2005

Related Documents

  • Specification Update bulletin 56 – CPA Corrections and Changes

Description

This Application Note Bulletin clarifies the EMV Common Payment Application Specification to state that issuers should not modify post-issuance the setting of the bits in Application Control that indicate whether to log internal CPA application data as part of Transaction Logging. The format of the Transaction Log is personalised in Log Format, and cannot be modified by postissuance commands (not supported by CPA). The personalisation of Log Format must be consistent with the setting of the following bits in the Application Control data element for CPA:

  • Log the ATC
  • Log the CID
  • Log the CVR
  • Log the Profile ID If an update to the Application Control data element changes the setting of any of the bits listed above from the values set during personalisation to correspond with the Log Format, then transaction information logged in the transaction log could be misinterpreted. Specification Clarification Notice Please make the following clarification to EMV Common Payment Application Version 1.0. Add the following note in Annex L, page L-18, in the Meaning column of Table L-10: Application Control, Byte 3 for the bits ‘Log the ATC’, ‘Log the CID’, ‘Log the CVR’, and ‘Log the Profile ID’: “Because updates to Log Format are not supported by CPA, issuers should not change the setting of this bit post-issuance. Otherwise the contents of the transaction log may be misinterpreted because the setting in Application Control is not consistent with the contents personalised in Log Format.” Page 2Application Note Bulletin No. 40 First Edition February 2008 CPA Personalisation of Duplicate Record Data This Application Note Bulletin clarifies where to personalise duplicate record data when personalising CPA using EMV CPS. Applicability This Application Note Bulletin applies to:
  • EMV Common Payment Application Specification Version 1.0 December 2005 Related Documents
  • None. Description This Application Note Bulletin clarifies where to personalise duplicate record data, when personalising CPA using EMV CPS. If the application uses different record data in different profiles (for example, different CVM Lists are used in different profiles), the application may need to store duplicate record data in different records. The duplicate data should be personalised in additional records in the same file as the first instance of the record data. For example, if the first instance is in SFI 3, record 1, then the duplicate data should be in another record in SFI 3. This bulletin adds DGI '030n' for the duplicate data in SFI 3, and simplifies the description of DGI '020n' used for duplicate data in SFI 2. Specification Clarification Notice Please make the following clarifications to EMV Common Payment Application Version 1.0. In CPA Table 21-12 on -21, change the row for DGI '020n' to the following: '020n' SFI 2 Record n: Duplicate of any of DGIs '0201' through '0205' – No CPA In CPA Table 21-12 on -21, add the following row below the row for SFI 3 Record 3: '030n' SFI 3 Record n: Duplicate of any of DGIs '0301' through '0303' – No CPA Copyright Replace Table 21-20 on pages 21-25 and 21-26 with the following: Additional DGIs '020n' may be used to personalise duplicates of any of the DGIs in the range from '0201' to '0205'; for example, if multiple certificates are to be personalised for offline data authentication in different profiles. Below CPA Table 21-23 on -28, add the following: Additional DGIs '030n' may be used to personalise duplicates of any of the DGIs in the range from '0301' to '0303'; for example, if different CDOL 1, CDOL 2, or CVM lists are used in different profiles. Copyright © 2011 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of these Specifications is subject to the terms and conditions of the EMVCo Terms of Use agreement available at www.emvco.com. These Specifications are provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON-INFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of these Specifications may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of these Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement these Specifications is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with these Specifications EMV Integrated Circuit Card Specifications for Payment Systems Common Payment Application Specification Version 1.0 December 2005 EMV Integrated Circuit Card Specifications for Payment Systems Common Payment Application Specification Version 1.0 December 2005 © 2005 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of the EMV Specifications (“Materials”) shall be permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo found at http://www.emvco.com/specifications.cfm. Common Payment Application Specification December 2005 Common Payment Application Specification Contents Part I – General 1 Scope 1.1 Underlying Standards 1.2 Audience 1.3 Contents 2 Normative References 2.1 EMV Documents 3 Definitions 4 Abbreviations, Notations, Conventions, Terminology, and Symbols 4.1 Abbreviations 4.2 Notations 4.3 Data Element Format Conventions 4.4 Terminology 4.5

Requirement

Notation 4.6 Flow Chart Symbols 1-1 1-1 1-1 1-2 2-1 2-1 3-1 4-1 4-1 4-5 4-6 4-8 4-10 4-11 Part II – Introduction to Processing 5 Overview 5.1 Implementer-Options 5.2 Functional Overview 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5 5.2.6 5.2.7 5.2.8 5.2.9 5.2.10 5.2.11 5.2.12 Application Selection (mandatory) Initiate Application Processing (mandatory) Read Application Data (mandatory) Offline Data Authentication (optional) Processing Restrictions (performed by the terminal) Cardholder Verification (mandatory) Terminal Risk Management (performed by the terminal) Terminal Action Analysis (performed by the terminal) First Card Action Analysis (mandatory) Online Processing (conditional – if first AC type was ARQC) Second Card Action Analysis (conditional – if first AC type was ARQC) Issuer Script Command Processing (optional) 5.3 Sample Transaction Flow 5-1 5-2 5-3 5-3 5-4 5-4 5-5 5-6 5-6 5-7 5-7 5-8 5-9 5-10 5-11 5-12 December 2005

Common Payment Application Specification 5.4 Minimum Functionality 5.4.1 5.4.2 Card Functional Requirements Command Support Requirements 6 General Command Information 6.1 Implementation of the CPA Specifications 6.2 State Machine 6.2.1 6.2.2 States Sequence of Commands and Transition Between States 6.3 Command Validation 6.4 Exception Handling 6.4.1 6.4.2 Status Words Missing or Invalid Resources Part III - Function Processing 7 Application Selection 7.1 Purpose 7.2 Sequence of Execution 7.2.1 Subsequent Related Processing 7.3 Processing 7.3.1 7.3.2 Building the Candidate List Identifying and Selecting the Application 8 Initiate Application Processing 8.1 Purpose 8.2 Sequence of Execution 8.2.1 8.2.2 Prior Related Processing Subsequent Related Processing 8.3 Card Data 8.4 Terminal Data 8.5 GET PROCESSING OPTIONS Command 8.5.1 8.5.2 8.5.3 8.5.4 8.5.5 Command Coding Processing Profile Selection Profile Behaviour Respond to GET PROCESSING OPTIONS Command 8.6 Function Flow Charts 5-14 5-14 5-16 6-1 6-1 6-2 6-2 6-4 6-6 6-6 6-6 6-6 7-1 7-1 7-1 7-1 7-2 7-2 7-3 8-1 8-1 8-2 8-2 8-2 8-4 8-8 8-9 8-10 8-12 8-13 8-16 8-17 8-17

December 2005

Common Payment Application Specification 9 Read Application Data 9.1 Purpose 9.2 Sequence of Execution 9.2.1 9.2.2 Prior Related Processing Subsequent Related Processing 9.3 Card Data 9.4 Terminal Data 9.5 READ RECORD Command 9.5.1 9.5.2 9.5.3 Command Coding Processing Respond to READ RECORD Command 9.6 Function Flow Charts 9.7 Additional File Requirements 9.7.1 9.7.2 9.7.3 VLP Data File Transaction Log File File Containing the Profile Selection Entries 10 Offline Data Authentication 10.1 Purpose 10.2 Sequence of Execution 10.2.1 Prior Related Processing 10.2.2 Subsequent Related Processing 10.3 Card Data 10.4 Terminal Data 10.5 Determining Whether to Perform SDA, DDA, or CDA 10.6 Static Data Authentication (SDA) 10.6.1 Commands 10.6.2 Processing 10.7 Offline Dynamic Data Authentication 10.7.1 10.7.2 INTERNAL AUTHENTICATE Command GENERATE APPLICATION CRYPTOGRAM (AC) Command 11 Processing Restrictions 11.1 Purpose 11.2 Sequence of Execution 11.2.1 Prior Related Processing 11.2.2 Subsequent Related Processing 11.3 Card Data 11.4 Terminal Data 9-1 9-1 9-2 9-2 9-2 9-3 9-3 9-4 9-4 9-5 9-6 9-7 9-8 9-8 9-9 9-10 10-1 10-1 10-2 10-2 10-3 10-5 10-9 10-10 10-11 10-11 10-11 10-12 10-12 10-15 11-1 11-1 11-2 11-2 11-2 11-3 11-4 December 2005 Page v

Common Payment Application Specification 11.5 Processing 11.5.1 11.5.2 11.5.3 11.5.4 Application Version Number Application Usage Control Application

Effective Date

Application Expiration Date 12 Cardholder Verification 12.1 Purpose 12.2 Sequence of Execution 12.2.1 Prior Related Processing 12.2.2 Subsequent Related Processing 12.3 Card Data 12.4 Terminal Data 12.5 GET DATA Command 12.5.1 12.5.2 12.5.3 Command Coding Processing GET DATA Flow Chart 12.6 GET CHALLENGE Command 12.6.1 12.6.2 12.6.3 12.6.4 Command Coding Processing GET CHALLENGE Response GET CHALLENGE Flow Chart 12.7 VERIFY Command 12.7.1 12.7.2 12.7.3 Command Coding Processing VERIFY Flow Chart 13 Terminal Risk Management 13.1 Purpose 13.2 Sequence of Execution 13.2.1 Prior Related Processing 13.2.2 Subsequent Related Processing 13.3 Card Data 13.4 Terminal Data 13.5 Processing 13.5.1 13.5.2 13.5.3 13.5.4 13.5.5 Terminal Exception File Merchant Forced Transaction Online Floor Limits Random Transaction Selection Terminal Velocity Checking 11-5 11-5 11-5 11-6 11-6 12-1 12-1 12-2 12-2 12-2 12-4 12-7 12-8 12-8 12-8 12-10 12-12 12-12 12-12 12-13 12-13 12-14 12-15 12-17 12-21 13-1 13-1 13-2 13-2 13-2 13-2 13-2 13-3 13-3 13-3 13-3 13-3 13-3

December 2005

Common Payment Application Specification 14 Terminal Action Analysis 14.1 Purpose 14.2 Sequence of Execution 14.2.1 Prior Related Processing 14.2.2 Subsequent Related Processing 14.3 Card Data 14.4 Terminal Data 14.5 Processing 14.5.1 Review Offline Processing Results 14.5.2 Request Cryptogram Processing 15 First Card Action Analysis 15.1 Purpose 15.2 Sequence of Execution 15.2.1 Prior Related Processing 15.2.2 Subsequent Related Processing 15.3 Card Data 15.4 Terminal Data 15.5 First GENERATE AC Command 15.5.1 15.5.2 15.5.3 15.5.4 15.5.5 15.5.6 15.5.7 15.5.8 Command Coding Profile Behaviour Card Risk Management Processing Determine Response Application Cryptogram Type Application Approves Transaction Offline Application Requests Online Processing Application Declines Transaction Offline Respond to GENERATE AC Command 15.6 Function Flow Charts 16 Online Processing 16.1 Purpose 16.2 Sequence of Execution 16.2.1 Prior Related Processing 16.2.2 Subsequent Related Processing 16.3 Card Data 16.4 Terminal Data 16.5 Commands 16.6 Processing 16.6.1 16.6.2 16.6.3 Online Request Online Response No Online Response 16.7 Function Flow Chart December 2005 14-1 14-1 14-2 14-2 14-2 14-3 14-4 14-5 14-5 14-6 15-1 15-1 15-2 15-2 15-2 15-3 15-13 15-14 15-16 15-19 15-23 15-57 15-60 15-64 15-65 15-68 15-74 16-1 16-2 16-3 16-3 16-3 16-4 16-5 16-5 16-6 16-6 16-6 16-7 16-8

Common Payment Application Specification 17 Second Card Action Analysis 17.1 Purpose 17.2 Sequence of Execution 17.2.1 Prior Related Processing 17.2.2 Subsequent Related Processing 17.3 Card Data 17.4 Terminal Data 17.5 Second GENERATE AC Command 17.5.1 17.5.2 17.5.3 17.5.4 17.5.5 17.5.6 17.5.7 17.5.8 Command Coding Configure Second Card Action Analysis Online Authorisation Completed Online Processing requested, Online Authorisation Not Completed Application Approves Transaction (TC) Application Declines Transaction (AAC) CVR Updates Respond to GENERATE AC Command 17.6 Function Flow Charts 18 Issuer Script Command Processing 18.1 Purpose 18.2 Sequence of Execution 18.2.1 Prior Related Processing 18.2.2 Subsequent Related Processing 18.3 Card Data 18.4 Terminal Data 18.4.1 Authorisation Response Data 18.5 Overview 18.5.1 18.5.2 18.5.3 18.5.4 18.5.5 Authorisation Response Message Issuer-to-Card Script Processing Card Secure Messaging Resulting Indicators Script Commands Supported 18.6 APPLICATION UNBLOCK Command 18.6.1 18.6.2 18.6.3 APPLICATION UNBLOCK Command Coding APPLICATION UNBLOCK Command Processing APPLICATION UNBLOCK Flow 18.7 PIN CHANGE/UNBLOCK Command 18.7.1 18.7.2 18.7.3 PIN CHANGE/UNBLOCK Command Coding PIN CHANGE/UNBLOCK Processing PIN CHANGE/UNBLOCK Flow 17-1 17-2 17-3 17-3 17-3 17-4 17-13 17-15 17-17 17-20 17-24 17-45 17-62 17-63 17-64 17-66 17-71 18-1 18-2 18-2 18-2 18-3 18-4 18-6 18-7 18-8 18-8 18-8 18-9 18-10 18-11 18-12 18-13 18-13 18-14 18-17 18-18 18-19 18-23

December 2005

Common Payment Application Specification 18.8 PUT DATA Command 18.8.1 18.8.2 18.8.3 PUT DATA Command Coding PUT DATA Processing PUT DATA Flow 18.9 UPDATE RECORD Command 18.9.1 18.9.2 18.9.3 UPDATE RECORD Command Coding UPDATE RECORD Processing UPDATE RECORD Flow 18-29 18-29 18-31 18-34 18-39 18-39 18-41 18-44 Part IV

  • Additional Topics 19 Additional Functions 19-1 19.1 Overview 19.2 Requirements for Additional Functionality 19.3 Examples of Additional Functionality 19.3.1 19.3.2 19.3.3 19.3.4 19.3.5 19.3.6 19.3.7 Additional Accumulators, Counters, and Cyclic Accumulators Issuer-Discretionary Bits – CVR, ADR, and CIACs Issuer-Discretionary Bits – Internal Application Data Issuer-Discretionary Bytes – Issuer Application Data Issuer-Discretionary Bytes – Issuer Authentication Data Additional Issuer Script Commands Support for Other MAC Lengths 19-1 19-2 19-3 19-3 19-4 19-4 19-4 19-5 19-5 19-6 20 Security and Key Management 20-1 20.1 Reference PIN Protection 20.2 Key Protection 20.3 Secure Messaging 20.4 Security Counters 20.5 Other Data Requirements 20-2 20-3 20-3 20-4 20-6 21 Personalisation 21-1 21.1 Data Elements to be Personalised 21.1.1 21.1.2 21.1.3 EMV Data in Records with SFI 1 through 10 CPA Data Elements Requiring Personalisation CPA Default Implementation 21.2 EMV CPS 21.2.1 21.2.2 21.2.3 21.2.4 21.2.5 21.2.6 Personalisation Commands Data Grouping Rules Data Grouping Order Grouped Data Groupings DGIs for Record Data Files with SFI between 1 and 10 21-2 21-2 21-3 21-12 21-15 21-15 21-17 21-17 21-18 21-19 21-19 December 2005 Common Payment Application Specification 21.2.7 21.2.8 21.2.9 21.2.10 21.2.11 21.2.12 Files with SFI between 11 and 30 CPA Recommended Data Group Indicators for Records DGIs for Internal Application Data DGIs for Command Response Data DGIs for PIN and Key Related Data RFU DGIs 21.3 Requirements for Data Element Values 21.3.1 21.3.2 21.3.3 21.3.4 21.3.5 21.3.6 21.3.7 21.3.8 21.3.9 21.3.10 21.3.11 21.3.12 21.3.13 Profile Selection Entries AIP AFL VLP Profile Data Token Authentication Profile Data Offline Counters CIACs Signed Static Data EMV Record Data CDOLs Keys Previous Transaction History (PTH) Log Entry 21.4 Missing Data Elements Part V
  • Annexes Annex A Profile Selection File Processing A1 Profile Selection Entry A2 Processing A3 Examples Annex B Additional Check Table Functionality B1 Additional Check Table Content B2 Processing Additional Check Table x B3 Examples of Additional Check Table x Value Annex C Currency Conversion Functionality C1 Currency Conversion Table Data Element C2 Example Annex D Transaction Logging D1 Transaction Log Entry Description D2 Issuer Options for Transaction Logging D3 Log Data Tables 21-20 21-21 21-31 21-33 21-33 21-34 21-34 21-34 21-34 21-34 21-35 21-36 21-37 21-37 21-38 21-40 21-41 21-42 21-42 21-42 21-43 A-1 A-1 A-5 A-8 B-1 B-1 B-3 B-5 C-1 C-2 C-3 D-1 D-1 D-3 D-4 Page x December 2005 Common Payment Application Specification D4 Processing Transaction Logging D5 Example Annex E Management of Dates in Days E1 Date Conversion E2 Computation of Reference Day Annex F Security Counters F1 Symmetric Keys F2 PIN Encipherment Key Annex G Management of Profile Data G1 Profile Resources G2 Structure of Profile Resource Templates G3 Profile Resource Templates for PUT DATA and GET DATA G4 PUT DATA Command Applied to Templates G5 GET DATA Command Applied to Templates Annex H Issuer Profile Options Specification and Processing H1 Profile Selection H2 Configuring Profile Resources H3 Profile-specific Issuer Options Profile Control H4 Profile-specific AIP and AFL H5 Profile-specific CIACs H6 Profile-specific Configuration of MTA Check H7 Profile-specific Configuration of Offline Counters H8 Profile-specific Configuration of Accumulators H9 Profile-specific Configuration of Cyclic Accumulators H10 Pre-defined Issuer profiles H11 Example – Simple CCD-Compliant Profile Annex I Understanding Cyclic Accumulators I1 Cyclic Accumulators I2 Management of Cyclic Accumulators I3 Management of Erroneous Transaction Dates I4 Cyclic Accumulator Usage Scenarios Annex J GET DATA and PUT DATA Data Elements Annex K Data Element Tags Annex L Data Dictionary D-7 D-9 E-1 E-1 E-2 F-1 F-1 F-3 G-1 G-1 G-2 G-3 G-5 G-9 H-1 H-1 H-3 H-8 H-10 H-11 H-12 H-14 H-16 H-19 H-21 H-23 I-1 I-1 I-7 I-9 I-12 J-1 K-1 L-1 December 2005 Common Payment Application Specification December 2005 Common Payment Application Specification Tables Table 4-1: Terminology for Required and Optional Functionality 4-9 Table 5-1: Implementer-options 5-2 Table 5-2: Card Functional Requirements 5-14 Table 5-3: Command Support Requirements 5-16 Table 6-1: Application States 6-2 Table 6-2: Sequence of Commands and State Transitions for Commands 6-5 Table 8-1: Initiate Application Processing – Card Data 8-4 Table 8-2: Initiate Application Processing – Terminal Data 8-8 Table 8-3: GET PROCESSING OPTIONS Command Message 8-10 Table 8-4: PDOL Related Data 8-10 Table 9-1: Read Application Data – Card Data 9-3 Table 9-2: READ RECORD Command Message 9-4 Table 9-3: Reference Control Parameter Coding for READ RECORD Command 9-4 Table 9-4: Profile Selection File Entry 9-10 Table 10-1: Offline Data Authentication – Card Data 10-5 Table 10-2: Offline Data Authentication – Terminal Data 10-9 Table 10-3: INTERNAL AUTHENTICATE Command Message 10-13 Table 11-1: Processing Restrictions – Card Data 11-3 Table 11-2: Processing Restrictions – Terminal Data 11-4 Table 12-1: Cardholder Verification – Card Data 12-4 Table 12-2: PIN Processing – Terminal Data 12-7 Table 12-3: GET DATA Command Message 12-8 Table 12-4: GET CHALLENGE Command Message 12-12 Table 12-5: VERIFY Command Message 12-15 Table 13-1: Terminal Risk Management – Card Data 13-2 Table 14-1: Terminal Action Analysis – Card Data 14-3 Table 14-2: Review Offline Processing Results—Terminal Data 14-4 Table 15-1: First Card Action Analysis – Card Data 15-3 Table 15-2: First Card Action Analysis – Terminal Data 15-13 Table 15-3: First GENERATE AC Command Message 15-16 Table 15-4: Reference Control Parameter Coding for First GENERATE AC 15-16 Table 15-5: First GENERATE AC Command Data 15-17 Table 15-6: Card Risk Management Checks 15-24 Table 15-7: Conditions for Accumulating Transaction in Accumulator y 15-45 Table 15-8: Card’s Response to First GENERATE AC Command 15-58 Table 15-9: Issuer Application Data for Profile '7E' (Authentication Token) 15-68 Table 15-10: Issuer Application Data for Profile Not '7E' 15-70 Table 15-11: Data Appended to Transaction Log 15-74 Table 16-1: Online Processing – Card Data 16-4 December 2005 Common Payment Application Specification Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table 17-1: Second Card Action Analysis – Card Data 17-4 17-2: Second Card Action Analysis – Terminal Data 17-13 17-3: SECOND GENERATE AC Command Message 17-17 17-4: Reference Control Parameter Coding for SECOND GENERATE AC 17-17 17-5: SECOND GENERATE AC Command Data: Amounts in CDOL2 17-18 17-6: SECOND GENERATE AC Command Data: No Amounts in CDOL2 17-18 17-7: Bits to Reset if Non-required Issuer Authentication Fails 17-26 17-8: Bits to Reset if Issuer Authentication Passes 17-30 17-9: Conditions for Accumulating Transaction using CSU Approval 17-35 17-10: Bits to Reset if Issuer Authentication Data Not Present 17-41 17-11: Card Risk Management Checks 17-46 17-12: Conditions for Accumulating Offline Approved Transaction 17-52 17-13: Issuer Application Data for SECOND GENERATE AC 17-67 17-14: Data Elements to Log 17-70 18-1: Issuer-to-Card Script Processing – Card Data 18-4 18-2: Issuer-to-Card Script Processing – Terminal Data 18-6 18-3: Issuer-to-Card Script Processing – Authorisation Response Data 18-7 18-4: APPLICATION UNBLOCK Command Message 18-13 18-5: PIN CHANGE / UNBLOCK Command Message 18-18 18-6: PUT DATA Command Message 18-29 18-7: UPDATE RECORD Command Message 18-39 18-8: Reference Control Parameter coding for UPDATE RECORD 18-39 21-1: SELECT Command Response Data Elements – Mandatory 21-3 21-2: Unique CPA Persistent Data Elements – Mandatory 21-4 21-3: Unique CPA Persistent Data Elements – Issuer-optional 21-5 21-4: Unique CPA Persistent Data Elements – Dynamic RSA Option Elements 21-6 21-5: Unique CPA Persistent Data Elements – Issuer-optional Transaction Logging Elements 21-6 21-6: Unique CPA Persistent Data Elements – Optional Security Limit Elements 21-6 21-7: Unique CPA Persistent Data Elements – Conditional VLP Elements 21-7 21-8: Unique CPA Persistent Data Elements – Issuer-Optional VLP Elements 21-7 21-9: CPA Persistent Data Elements – Data Sets 21-8 21-10: Currency Conversion Parameter 21-11 21-11: Number of Each Type of Profile Resource in CPA 21-13 21-12: DGI Summary for Record Data 21-21 21-13: Data Content for DGI '0101' 21-22 21-14: Data Content for DGI '0102' 21-22 21-15: Data Content for DGI '0201' 21-22 21-16: Data Content for DGI '0202' 21-23 21-17: Data Content for DGI '0203' 21-24 21-18: Data Content for DGI '0204' 21-24 December 2005 Common Payment Application Specification Table 21-19: Data Content for DGI '0205' 21-24 Table 21-20: Data Content for DGI '020n' 21-25 Table 21-21: Data Content for DGI '0301' 21-27 Table 21-22: Data Content for DGI '0302' 21-28 Table 21-23: Data Content for DGI '0303' 21-28 Table 21-24: Data Content for DGI '0B01' 21-29 Table 21-25: Data Content for DGI 'ssrr' 21-30 Table 21-26: DGI Summary for Internal Application Data 21-31 Table 21-27: Data Content for DGI '3000' 21-32 Table 21-28: DGI Summary for Command Response Data 21-33 Table 21-29: Data Content for DGI '8301' through '8305' 21-33 Table 21-30: VLP Record Data (SFI 11) 21-35 Table 21-31: PDOL Data to Support VLP Transaction 21-36 Table 21-32: PDOL Data to Support Token Authentication 21-36 Table 21-33: Static Data to be Authenticated 21-39 Table A-1: Data Elements in Profile Selection Entry A-2 Table A-2: Profile Selection File – Simple Example A-8 Table A-3: Profiles for Complex Profile Selection File A-9 Table A-4: Profile Selection File – Complex Example A-10 Table A-5: PDOL Contents – Complex Example A-11 Table A-6: Profile Selection Entries – Complex Example A-11 Table B-1: Additional Check Table x B-2 Table B-2: Example of Additional Check Table x Value B-5 Table B-3: Example of Additional Check Table x Value B-6 Table C-1: Currency Conversion Parameter C-2 Table C-2: Example Currency Conversion Parameters C-3 Table D-1: Structure of Log Format data element D-2 Table D-2: Transaction Logging Options in Application Control byte 3 D-3 Table D-3: Log Data Table Format D-4 Table D-4: Example of GEN AC Log Data Table D-5 Table D-5: Data Logged at First GENERATE AC for a TC or ACC D-7 Table D-6: Data Saved for Second GENERATE AC after an ARQC D-8 Table D-7: Data Logged at Second GENERATE AC D-8 Table D-8: Example – Transaction Logging Settings in Application Control D-9 Table D-9: Example – First GENERATE AC Command Data D-10 Table D-10: Example – Second GENERATE AC Command Data D-10 Table D-11: Example – Data Referenced in First GEN AC Unchanging Log Data Table D-11 Table D-12: Example – Data Referenced in First GEN AC Log Data Table D-11 Table D-13: Example – Data Saved if First GENERATE AC Response is an ARQC D-12 Table D-14: Example – Data Logged at First GENERATE AC for a TC or AAC D-12 Table D-15: Example – Data Extracted from Second GENERATE AC Command Data D-13 Table D-16: Example – Transaction Data Logged at Second GENERATE AC D-13 December 2005 Common Payment Application Specification Table G-1: Profile Resource Templates for PUT DATA and GET DATA Table G-2: Counter Controls Contents before PUT DATA Command Table G-3: Coding of Received PUT DATA Command Table G-4: Counter Controls Contents after PUT DATA Command Table G-5: Accumulator Profile Controls Contents before PUT DATA Command Table G-6: Coding of Received PUT DATA Command Table G-7: Accumulator Controls Contents after the PUT DATA Command Table G-8: Coding of the Received PUT DATA Command Table I-1: Cyclic Accumulator x Data Table I-2: Cyclic Accumulator x Control Table I-3: Cyclic Accumulator Profile Control y for Cyclic Accumulator x Table I-4: Management of Erroneous Transaction Dates Table I-5: Parameters for Cyclic Accumulator Usage Example 1 Table I-6: Parameters for Cyclic Accumulator Usage Example 2 Table I-7: Parameters for Cyclic Accumulator Usage Example 3 Table I-8: Parameters for Cyclic Accumulator Usage Example 4 Table I-9: Parameters for Cyclic Accumulator Usage Example 5 Table J-1: GET DATA Command Data Elements Table K-1: Data Element Tags G-3 G-5 G-6 G-6 G-8 G-8 G-9 G-10 I-2 I-3 I-4 I-10 I-12 I-14 I-16 I-18 I-20 J-1 K-1 December 2005 Common Payment Application Specification Figures Figure 4-1: Flow Chart Symbols Figure 5-1: Sample Transaction Flow Figure 8-1: Initiate Application Processing Flow Figure 9-1: READ RECORD Command Processing Flow Figure 10-1: INTERNAL AUTHENTICATE Flow Figure 12-1: GET DATA Flow Figure 12-2: GET CHALLENGE Flow Figure 12-3: VERIFY Flow Figure 15-1: First Card Action Analysis Processing Flow Figure 15-2: Examples – Building the IAD 4-11 5-13 8-18 9-7 10-14 12-11 12-13 12-22 15-15 15-72 ** First Card Action Analysis Flow Charts ** see Figure 16-1: Online Processing Flow for Online Response Figure 16-2: Online Processing Flow for No Online Response Figure 17-1: Second Card Action Analysis Processing Flow 16-8 16-9 17-16 ** Second Card Action Analysis Flow Charts ** see Figure 18-1: Command Data Format if Only MAC Data is Present Figure 18-2: APPLICATION UNBLOCK Flow Figure 18-3: Recovering New PIN Block from PIN CHANGE/UNBLOCK Command Data Figure 18-4: PIN CHANGE/UNBLOCK Flow Figure 18-5: Command Data Format for PUT DATA Figure 18-6: PUT DATA Flow Figure 18-7: Command Data Format for UPDATE RECORD Figure 18-8: UPDATE RECORD Flow Figure A-1: Profile Selection Entry Format Figure A-2: Profile Selection Algorithm Figure A-3: Profile Selection Using Card Data Figure B-1: Additional Check Table x Figure B-2: Additional Check Table Usage Figure D-1: Processing First GEN AC Log Data Table Figure G-1: Profile Resource Template Figure G-2: Counter Controls before PUT DATA Command Figure G-3: Counter Controls Coding after PUT DATA Command Figure G-4: Profile Resource Template Coding after Personalisation Figure G-5: Accumulator Profile Controls before PUT DATA Command Figure G-6: Accumulator Profile Controls Template Contents after PUT DATA Command Figure G-7: Card Response to the GET DATA Command Figure H-1: Profile Selection Process Figure H-2: Profile Control Figure H-3: Profile-specific Controls Figure H-4: Issuer Options Profile Control 18-13 18-15 18-21 18-24 18-31 18-35 18-41 18-45 A-1 A-5 A-7 B-1 B-4 D-6 G-2 G-5 G-6 G-7 G-8 G-9 G-10 H-2 H-3 H-6 H-9 December 2005 Common Payment Application Specification Figure Figure Figure Figure Figure Figure Figure Figure Figure H-5: AIP/AFL Entry H-6: CIACs Entry H-7: MTA Profile Control H-8: Counter Profile Control for Counter n – Example H-9: Accumulator Profile Control for Accumulator n – Example (n=2) H-10: Cyclic Accumulator Control I-1: Cyclic Accumulator I-2: Cyclic Accumulator Behaviour I-3: Management of Erroneous Transaction Dates (n=3) H-10 H-11 H-13 H-15 H-17 H-20 I-6 I-8 I-11 December 2005 Common Payment Application Specification Card Action Analysis Flow Charts Flow 15-1 Flow 15-2 Flow 15-3 Flow 15-4 Flow 15-5 Flow 15-6 Flow 15-7 Flow 15-8 Flow 15-9 Flow 15-10 Flow 15-11 Flow 15-12 Flow 15-13 Flow 15-14 Flow 15-15 Flow 15-16 Flow 15-17 Flow 15-18 Flow 15-19 Flow 15-20 Flow 15-21 Flow 15-22 First GENERATE AC Initial Flow ARQC Requested TC Requested TC Checks ARQC Checks AAC Checks Authentication Token AAC Accumulator Check AAC Counter Check Accumulator Cumulating Accumulator x Non-cumulating Check Additional Check Table Processing Build Issuer Application Data Counter x Cumulating Check Counter Non-cumulating Check Currency Conversion 15-118 Cyclic Accumulator Cumulating Cyclic Accumulator Non-cumulating Check Maximum Number of Days Offline Check Maximum Transaction Amount Check First GENERATE AC Transaction Logging Verify/Reset Cyclic Period 15-75 15-82 15-86 15-91 15-95 15-98 15-103 15-104 15-105 15-106 15-109 15-110 15-112 15-115 15-117 15-120 15-122 15-123 15-124 15-126 15-130 December 2005 Common Payment Application Specification Second Card Action Analysis Flow Charts Flow 17-1 Flow 17-2 Flow 17-3 Flow 17-4 Flow 17-5 Flow 17-6 Flow 17-7 Flow 17-8 Flow 17-9 Flow 17-10 Flow 17-11 Flow 17-12 Flow 17-13 Flow 17-14 Flow 17-15 Flow 17-16 Flow 17-17 Flow 17-18 Flow 17-19 Flow 17-20 Flow 17-21 Flow 17-22 Flow 17-23 Flow 17-24 Flow 17-25 Flow 17-26 Flow 17-27 Flow 17-28 Flow 17-29 Flow 17-30 Flow 17-31 Second GENERATE AC Initial Flow Transaction Authorization Online Issuer Authentication Present Issuer Authentication Not Present Issuer Authentication Failed Issuer Authentication Okay Transaction Approved after Issuer Authentication Failed Online TC Unable To Go Online AAC Unable To Go Online TC AAC Add to Accumulator x Add to Counter x Add to Cyclic Accumulator x Build Issuer Application Data Check Cyclic Reference Date Currency Conversion CVR Updates Cyclic Accumulator Check with Cumulating Cyclic Accumulator Check Without Cumulating Maximum Transaction Amount Check Offline TC Accumulator Check with Cumulating Offline TC Accumulator Check Without Cumulating Offline TC Counter Check with Cumulating Offline TC Counter Check Without Cumulating Reset Maximum Number of Days Offline Reset Non-velocity Checking Indicators Reset Velocity Checking Indicators Transaction Logging Second GENERATE AC Verify/Reset Cyclic Period 17-72 17-74 17-75 17-76 17-77 17-78 17-84 17-85 17-86 17-93 17-94 17-97 17-99 17-101 17-102 17-104 17-107 17-109 17-111 17-116 17-119 17-120 17-122 17-124 17-125 17-127 17-128 17-129 17-130 17-131 17-133 December 2005 Common Payment Application Specification Part I General December 2005 Common Payment Application Specification December 2005 Common Payment Application Specification 1

Scope

This document, the Common Payment Application Specification (CPA), defines the data elements and functionality for an application that complies with the EMV Common Core Definitions (CCD). It focuses on the functions performed by the integrated circuit card (ICC) and the interaction between the ICC and terminal at the point of transaction. The objectives of the Common Payment Application Specification are to:

  • Describe the functionality of a CCD-compliant implementation of EMV to ease vendor development efforts
  • Specify a core set of functionalities that issuers can rely on having available in every implementation of CPA
  • Specify an implementation that can be personalised with the same data elements to meet the business requirements of multiple payment systems Because CPA is based on EMV and CCD, the specifications should be used together for reference and development purposes.

1.1 Underlying Standards This specification is based on the EMV standards and should be read in conjunction with those standards. However, if any of the provisions or definitions in this specification differs from those standards, the provisions herein shall take precedence.

1.2 Audience This specification is intended for use by ICC application developers, manufacturers of ICCs, system designers in payment systems, and financial institution staff responsible for implementing financial applications in ICCs. December 2005

-1

1 Scope 1.3 Contents Common Payment Application Specification 1.3 Contents This section provides an overview of each section of the Common Payment Application Specification. To provide clarity, requirements from EMV (including CCD) may be restated or replicated in this specification to provide a comprehensive application specification. This specification is divided into the following sections: Part I – General

  • Section 1, Scope
  • Section 2, Normative References – Lists standards and specifications referenced by this document.
  • Section 3, Definitions – Provides a glossary of terms used in this document.
  • Section 4, Abbreviations, Notations, Conventions, Terminology, and Symbols – Lists the acronyms and describes the formats used throughout this document. Part II – Introduction to Processing
  • Section 5, Overview – This section provides an overview of each function in transaction processing. The Processing Overview is structured into the functional processes described in EMV, and has the following sub-sections: ƒ Section 5.1, Implementer-Options – Identifies functionality that is optional for the application vendor to implement. ƒ Section 5.2, Functional Overview General Description – Provides a high-level overview of the function in transaction processing. Condition of Execution – Defines the conditions under which this process is executed. ƒ Section 5.3, Sample Transaction Flow – Illustrates a sample flow for a CPA transaction at an EMV-compliant terminal. ƒ Section 5.4, Minimum Functionality – Provides a high-level overview of the functionalities that are mandatory for all card implementations to support.
  • Section 6, General Command Information – Provides general requirements for processing commands during an EMV transaction. General command processing includes the application state machine, command validation, and exception handling. -2 December 2005 Common Payment Application Specification 1 Scope 1.3 Contents Part III - Function Processing For ease of use, each function processing section (sections 7 through 18) is structured as follows: ƒ Purpose – Defines the functionality of the process. ƒ Sequence of Execution – Outlines prior processing to aid in understanding previous activities related to this function, and subsequent processing to aid in understanding future activities related to this function. ƒ Card Data – Provides a brief description of the data from the card used to support the function. ƒ Terminal Data – Provides a brief description of the data from the terminal used to support the function. ƒ Command Processing – Provides a brief description of the commands used to support the function, and the functionality of the functional process. If there are several commands or functions within a process, they may be listed separately. ƒ Function Flow Chart – Where appropriate, provides a sample flow to illustrate how the functionality might be implemented. NOTE: Flow charts are representative of processing and may not include all steps that may be performed. Other processing flows with the same results are allowed.
  • Section 7, Application Selection – This function determines which of the applications, supported by both the card and terminal, will be used to conduct the transaction.
  • Section 8, Initiate Application Processing – During this function, the card receives any terminal data which the card requested during Application Selection and sends the terminal a list of the data to be read and functions to be supported for the transaction.
  • Section 9, Read Application Data – During this function, the terminal reads the card data records necessary for the transaction.
  • Section 10, Offline Data Authentication – During this function, the terminal authenticates data from the card using RSA public key technology.
  • Section 11, Processing Restrictions – During this function, application version checks, effective and expiration date checks, and other checks are performed by the terminal.
  • Section 12, Cardholder Verification – During this function, the terminal determines the cardholder verification method (CVM) to be used and performs the selected CVM. December 2005 -3 1 Scope 1.3 Contents Common Payment Application Specification
  • Section 13, Terminal Risk Management – During this function, the terminal ensures that higher-value transactions are sent online and that chip transactions go online periodically.
  • Section 14, Terminal Action Analysis – During this function, the terminal applies rules set by the issuer in the card and by the acquirer in the terminal to the results of offline processing. This analysis determines whether the transaction should be approved offline, declined offline, or sent online for an authorisation.
  • Section 15, First Card Action Analysis – During this function, velocity checking and other risk management, internal to the card, is performed. The application then determines whether to send the transaction online for authorisation or to approve or decline the transaction offline, and generates the response cryptogram.
  • Section 16, Online Processing – During this function, the issuer’s host computer (or a proxy for the issuer) reviews and authorises or declines transactions using the issuer’s host-based risk parameters.
  • Section 17, Second Card Action Analysis – During this function, additional card risk management is performed, and the card processes the results of the attempt to send the transaction online. The application then generates the second response cryptogram.
  • Section 18, Issuer-to-Card Script Processing – During this function, the card applies post-issuance changes sent from the issuer. Part IV – Additional Topics
  • Section 19, Additional Functions – Discusses optional extensions to the application, including examples of how to support additional counters or incorporate additional functionality using issuer-discretionary bits in application data elements.
  • Section 20, Security and Key Management – Provides requirements related to security and key management for a CPA implementation that are in addition to the specifications for CCD-compliant applications, as specified in EMV 4.1.
  • Section 21, Personalisation – Describes the personalisation requirements for a CPA implementation. Part V – Annexes
  • Annex A, Profile Selection File Processing – Describes how the Profile Selection File can be used during Application Initiation to customise application behaviour based on transaction characteristics as specified by the issuer at the time of personalisation. Includes an example illustrating how the data element might be personalised to provide this functionality. -4 December 2005 Common Payment Application Specification 1 Scope 1.3 Contents
  • Annex B, Additional Check Table Functionality – Describes how the Additional Check Tables can be used during Card Action Analysis to provide a card risk management test that can be customised by the issuer at the time of personalisation. Includes an example illustrating how the data element might be personalised to provide this functionality.
  • Annex C, Currency Conversion Functionality – Describes how the Currency Conversion Table can be used to estimate the domestic currency value of a non-domestic currency transaction using Currency Conversion Parameters specified by the issuer at the time of personalisation. Includes an example illustrating how the data element might be personalised to provide this functionality.
  • Annex D, Transaction Logging – Describes how the card can be configured to support flexible transaction logging specified at the time of personalisation. Includes an example illustrating how the data elements might be personalised to provide this functionality.
  • Annex E, Management of Dates in Days – Describes how a date in the format YYMMDD can be converted to a count of days since a reference date, so that the application can perform card risk management based on number of days elapsed.
  • Annex F, Security Counters – Describes an implementation of security counters for CPA if the security counters described in section 20 are implemented in the application.
  • Annex G, Management of Profile Data – Explains the management of application resource data for the PUT DATA and GET DATA commands using a single template tag for each type of resource.
  • Annex H, Issuer Profile Options Specification and Processing – Describes how the application processes Issuer-defined profile options and configures card behaviour based on these options.
  • Annex I, Understanding Cyclic Accumulators – Explains the behaviour and management of Cyclic Accumulators in the application.
  • Annex J: GET DATA and PUT DATA Data Elements – Lists the data elements that are supported for the GET DATA and PUT DATA commands.
  • Annex K, Data Element Tags – Lists the data element tags and template tags used in the application and terminal.
  • Annex L, Data Dictionary – Defines the data elements used in processing the application from a card and issuer perspective. December 2005 -5 1 Scope 1.3 Contents Common Payment Application Specification -6 December 2005 Common Payment Application Specification 2 Normative

References

The following standards contain provisions that are referenced in this specification. The latest version shall apply unless a publication date is explicitly stated.

2.1 EMV Documents EMV documents are available on the EMVCo Website: http://www.emvco.com/specifications.cfm. EMV Book 1 EMV Book 2 EMV Book 3 EMV Book 4 EMV CPS EMV Integrated Circuit Card Specifications for Payment Systems, version 4.1, Book 1, Application Independent ICC to Terminal Interface Requirements, May 2004. EMV Integrated Circuit Card Specifications for Payment Systems, version 4.1, Book 2, Security and Key Management, May 2004. EMV Integrated Circuit Card Specifications for Payment Systems, version 4.1, Book 3, Application Specification, May 2004. EMV Integrated Circuit Card Specifications for Payment Systems, version 4.1, Book 4, Cardholder, Attendant, and Acquirer Interface Requirements, May 2004. EMV Card Personalization Specification, version 1.0, June 2003. December 2005

-1

2 Normative References Common Payment Application Specification

-2 December 2005

Common Payment Application Specification 3

Definitions

This section provides a glossary of terms used in this specification; it is not intended as a data dictionary. For descriptions of specific card and issuer data elements, refer to Annex L: Data Dictionary. Acquirer Application Application Authentication Cryptogram (AAC) Application Block Application Cryptogram Asymmetric Cryptographic Technique ATM Authentication A Payment System member that has a contractual relationship with a merchant or that disburses currency to a cardholder in a cash disbursement, and directly or indirectly enters the resulting transaction into interchange. A program and associated data that reside on an integrated circuit chip and satisfy a business function. Examples of applications include payment, stored value, and loyalty. An Application Cryptogram generated by the card for offline and online declined transactions. Instructions sent to the card by the issuer, to shut down the selected application on a card to prevent further use of that application. This process does not preclude the use of other applications on the card. A blocked application may be unblocked by the issuer. A cryptogram generated by the card in response to a GENERATE AC command. See also:

  • Application Authentication Cryptogram (AAC)
  • Authorisation Request Cryptogram (ARQC)
  • Transaction Certificate (TC) A cryptographic technique that uses two related transformations: a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is computationally infeasible to derive the private transformation. An unattended terminal that has electronic capability, accepts PINs, and disburses currency or cheques. A cryptographic process that validates the claimed origin of data or identity of an entity. December 2005 -1 3 Definitions Common Payment Application Specification Authorisation Authorisation Request Authorisation Request Cryptogram (ARQC) Authorisation Response Authorisation Response Cryptogram (ARPC) Byte Card Card Block Cardholder Cardholder Confirmation Cardholder Selection Cardholder Verification Cardholder Verification Method (CVM) Cash Disbursement A process whereby an issuer or a representative of the issuer approves a transaction. A merchant’s or acquirer’s request for authorisation of a transaction. The Application Cryptogram generated by the card when requesting online authorisation for a transaction. It is sent to the issuer in the authorisation request. The issuer may validate the ARQC during the Online Processing function to ensure that the card is authentic. The issuer’s reply to an authorisation request. A cryptogram that may be generated by the issuer and may be sent to the card in the authorisation response. This cryptogram is the result of the Authorisation Request Cryptogram (ARQC) and the Card Status Update enciphered with a session key. It is validated by the card during Issuer Authentication to ensure that the response came from a valid issuer. 8 bits of data. A payment card as defined by a payment system. Instructions, sent to the card by the Issuer, which shut down all proprietary and non-proprietary applications that reside on a card, to prevent further use of the card. A card that has been blocked cannot be unblocked. An individual to whom a card is issued or who is authorised to use that card. Confirmation by the cardholder that the application selected by the terminal is to be used for processing the transaction. The process by which a cardholder may select one of multiple applications mutually supported by the card and terminal for use in processing the transaction. The process of determining that the presenter of the card is the valid cardholder. A method used to confirm the identity of a cardholder. Currency, including traveller’s cheques, paid to a cardholder using a card. -2 December 2005 Common Payment Application Specification 3 Definitions Cashback Certificate Certification Authority (CA) Ciphertext Combined DDA/Application Cryptogram Generation (CDA) Command Common Core Definitions (CCD) Concatenation Cryptogram Cryptographic Algorithm Cryptographic Key Cryptography Cash obtained in conjunction with, and processed as, a purchase transaction. The public key and identity of an entity together with some other information, rendered unforgeable by signing with the private key of the certification authority which issued that certificate. A trusted third party that establishes a proof that links a public key and other relevant information to its owner. Enciphered information. A form of offline dynamic data authentication, combined with processing of the GENERATE AC command. A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. A minimum common set of card application implementation options, card application behaviours, and data element definitions sufficient to accomplish an EMV transaction, as defined in EMV Book 3. Two elements are concatenated by appending the bytes from the second element to the end of the first. Bytes from each element are represented in the resulting string in the same sequence in which they were presented to the terminal by the ICC, that is, most significant byte first. Within each byte bits are ordered from most significant bit to least significant. A list of elements or objects may be concatenated by concatenating the first pair to form a new element, using that as the first element to concatenate with the next in the list, and so on. Result of a cryptographic operation. An algorithm operating under the control of a cryptographic key and used to protect the confidentiality and/or integrity of input data. A sequence of bits used by a cryptographic algorithm. The art or science of keeping messages secret and/or secure. December 2005 -3 3 Definitions Common Payment Application Specification CVM List Data Authentication Data Encryption Standard (DES) Data Integrity Decipherment DES key Digital Signature Dynamic Data Authentication (DDA) EMV Specifications Encipherment Exclusive-OR Expired Card An issuer-defined list contained within a chip application establishing the hierarchy of methods for verifying the authenticity of a cardholder. Validation that data stored in the integrated circuit card has not been altered since card issuance. See also Offline Data Authentication. The public domain symmetric key cryptography algorithm of the National Institute for Standards and Technology. A property of data that has not been altered or destroyed in an unauthorised manner. The reversal of a corresponding encipherment. A 64-bit secret parameter of the Data Encryption Standard algorithm, consisting of 56 bits that must be independent and random, and 8 error-detecting bits set to make the parity of each 8-bit byte of the key odd. An asymmetric cryptographic transformation of data that allows the recipient of the data to prove the origin and integrity of the data, and that protects the sender and the recipient of the data against forgery by third parties, and the sender against forgery by the recipient. A form of offline data authentication where the card generates a digital signature using transaction-specific data elements, for validation by the terminal to protect against skimming. Technical specifications maintained by JCB International, MasterCard International, and Visa International to create standards and ensure global interoperability for use of chip technology in the payment industry. The reversible transformation of data by a cryptographic algorithm to produce ciphertext. Binary addition with no carry, giving the following values: 0 ⊕ 0 = 0 0 ⊕ 1 = 1 1 ⊕ 0 = 1 1 ⊕ 1 = 0 A card on which the embossed, encoded, or printed expiration date has passed. -4 December 2005 Common Payment Application Specification 3 Definitions Financial Transaction Floor Limit Function Hardware Security Module (HSM) Hash Function Hash Result ICC Master Key (MK) Integrated Circuit(s) Integrated Circuit(s) Card (ICC) International Organization for Standardization (ISO) Interoperability Issuer The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services for payment or in cash disbursement. A currency amount that the Payment System has established for single transactions at specific types of merchants, above which online authorisation is required. A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. A secure module used to store cryptographic keys and perform cryptographic functions. A function that maps strings of bits to fixed-length strings of bits, satisfying the following two properties:
  • It is computationally infeasible to find for a given output an input which maps to this output.
  • It is computationally infeasible to find for a given input a second input that maps to the same output. Additionally, if the hash function is required to be collision-resistant, it must also satisfy the following property:
  • It is computationally infeasible to find any two distinct inputs that map to the same output. The string of bits that is the output of a hash function. A key unique to the card, which is used to derive a session key. Electronic component(s) designed to perform processing and/or memory functions. A card into which one or more integrated circuits are inserted to perform processing and memory functions. The specialised international agency that establishes and publishes international technical standards. The ability of all card acceptance devices and terminals to accept and read all chip cards that are properly programmed and that support one of the applications supported by the terminal. A Payment System member that issues cards. December 2005 -5 3 Definitions Common Payment Application Specification Issuer Action Code (IAC) Issuer Authentication Key Key Expiry Date Key Generation Keypad Message Message Authentication Code (MAC) Nibble Offline Approval Issuer-configured rules which the terminal uses to determine whether a transaction should be declined offline, sent online for an authorisation, or declined if online is not available. EMV defines the following, which reflect the issuer-selected action to be taken upon analysis of the TVR data element:
  • IAC - Default: rules that determine when a transaction should be declined offline if it cannot go online
  • IAC - Denial: rules that determine when a transaction should be declined offline
  • IAC - Online: rules that determine when a transaction should be sent online for authorisation Validation of the issuer by the card to ensure the integrity of the authorisation response. See Authorisation Response Cryptogram (ARPC). A sequence of bits that controls the operation of a cryptographic transformation. The date after which a signature made with a particular key is no longer valid. Example: Issuer certificates signed by the CA key must expire on or before the CA Key Expiration date. CA keys may be removed from terminals after this date has passed. The creation of a new key for subsequent use. Arrangement of numeric, command, and, where required, function and/or alphanumeric keys laid out in a specific manner. A string of bytes sent by the terminal to the card or vice versa, excluding transmission-control characters. A digital code generated using a symmetric cryptographic algorithm that protects the sender and the recipient of data against forgery by third parties. The four most significant or least significant bits of a byte of data. A transaction that is approved (accepted) at the point of transaction between the card and terminal without an authorisation response from the issuer or from a proxy for the issuer. -6 December 2005 Common Payment Application Specification 3 Definitions Offline Data Authentication Offline Decline Offline PIN Offline PIN Verification Offline-only Terminal Online Authorisation Online Card Authentication Online PIN Online-capable Terminal Padding Payment System Environment A process whereby the card is validated at the point of transaction using RSA public key technology to protect against counterfeit or skimming. EMV includes three forms:
  • Static Data Authentication (SDA)
  • Dynamic Data Authentication (DDA)
  • Combined DDA/AC Generation (CDA) A transaction that is declined (not accepted) at the point of transaction between the card and terminal without an authorisation response from the issuer or from a proxy for the issuer. A PIN value stored on the card that is validated at the point of transaction between the card and the terminal. The process whereby a cardholder-entered PIN is passed to the card for comparison to a PIN value stored secretly on the card. A card acceptance device that is not capable of sending transactions online for issuer authorisation. A method of requesting an authorisation through a communications network other than voice to an issuer or issuer representative. A process performed by the issuer to validate that the card is authentic, and to protect against data manipulation. A method of PIN verification whereby the PIN entered by the cardholder into the terminal PIN pad is enciphered and included in the online authorisation request message sent to the issuer. A card acceptance device that is able to send transactions online to the issuer for authorisation. EMV describes such a terminal as “offline with online capability.” Appending extra bits or bytes to either side of a data string. The set of logical conditions established within the ICC when a payment system application conforming to this specification has been selected, or when a Directory Definition File (DDF) used for payment system application purposes has been selected. December 2005 -7 3 Definitions Common Payment Application Specification Personalisation PIN Pad Plaintext Point of Transaction Post-issuance Update Private Key Public Key Public Key Certificate Public Key Cryptographic Algorithm Public Key Pair Purchase Transaction Random Selection Receipt The process of populating a card with the application data that makes it ready for use. Arrangement of numeric and command keys to be used for personal identification number (PIN) entry. Data in its original unenciphered form. The physical location where a merchant or acquirer (in a face-to-face environment) or an unattended terminal (in an unattended environment) completes a transaction. A command sent by the issuer through the terminal via an authorisation response to update the electronically stored contents of a chip card. That key of an entity’s asymmetric key pair that is kept secret and should only be used by that entity. In the case of a digital signature scheme, the private key defines the signature function. That key of an entity’s asymmetric key pair that can be made public. In the case of a digital signature scheme, the public key defines the verification function. The public key information of an entity signed by the certification authority and thereby rendered unforgeable. A cryptographic algorithm that allows the secure exchange of information, but does not require a shared secret key, through the use of two related keys: a public key which may be distributed in the clear and a private key which is kept secret. The two mathematically related keys—a public key and a private key—which, when used with the appropriate public key cryptographic algorithm, can allow the secure exchange of information, without the secure exchange of a secret. A retail purchase of goods or services; a point-of-sale transaction. An EMV online-capable terminal function that allows for the selection of transactions for online processing. Part of the Terminal Risk Management function. A paper record of a transaction generated for the cardholder at the point of transaction. -8 December 2005 Common Payment Application Specification 3 Definitions Response RSA (Rivest, Shamir, Adleman) Script Secret Key Secure Messaging Session Key Static Data Authentication (SDA) Symmetric Cryptographic Technique Template Terminal A message returned by the ICC to the terminal after the processing of a command message received by the ICC. A public key cryptosystem developed by Rivest, Shamir, and Adleman, used for data encipherment and authentication. A command or a string of commands transmitted by the issuer to the terminal for the purpose of being sent serially to the ICC as commands. Typically used to provide post-issuance updates to application data. A key used with symmetric cryptographic techniques and usable only by a set of specified entities. It cannot be disclosed publicly without compromising the security of the system. This is not the same as the private key in a public/private key pair. A process that enables messages to be sent from one entity to another, and protects against unauthorised modification or viewing. A temporary cryptographic key computed in volatile memory and not valid after a session is ended. A type of Offline Data Authentication whereby the terminal validates a cryptographic value placed on the card during personalisation. This validation protects against some types of counterfeit, but does not protect against copying and replaying. A cryptographic technique that uses the same secret key for both the originator’s and recipient’s transformation. Without knowledge of the secret key, it is computationally infeasible to compute either the originator’s or the recipient’s transformation. Value field of a constructed data object, defined to give a logical grouping of data objects. The device used in conjunction with the ICC at the point of transaction to perform a financial transaction. The terminal incorporates the interface device and may also include other components and interfaces such as host communications. December 2005 -9 3 Definitions Common Payment Application Specification Terminal Action Code (TAC) Terminate Transaction Token Authentication Transaction Transaction Certificate (TC) Transient Data Velocity Checking Visa Low-Value Payment (VLP) Rules which the terminal uses to determine whether a transaction should be declined offline, sent online for an authorisation, or declined if online is not available. EMV defines the following, which reflect the acquirer-selected action to be taken upon analysis of the TVR data element:
  • TAC - Default: rules that determine when a transaction should be declined offline if it cannot go online
  • TAC - Denial: rules that determine when a transaction should be declined offline
  • TAC - Online: rules that determine when a transaction should be sent online for authorisation Stop the application processing for the current transaction and deactivate the card. A non-payment functionality supported in the application which allows the card to generate a token that can be used to authenticate that the card and cardholder are valid. An action taken by a terminal at the user’s request. For a POS terminal, a transaction might be payment for goods, etc. A transaction selects among one or more applications as part of its processing flow. An Application Cryptogram generated when accepting a transaction Data that is specific to the current transaction. This data is reset at the beginning of each transaction. A card risk management function used to control how much is being spent offline or how many transactions are being conducted offline. Allows for quick low-value transactions at terminals that support the functionality. -10 December 2005 Common Payment Application Specification 4 Abbreviations, Notations, Conventions, Terminology, and Symbols 4.1 Abbreviations a AAC AC ADR AEF AFL AID AIP an ans App. ARC ARPC ARQC ATC ATM AUC auth. b BER C CA CCD CCI CDA Alphabetic Application Authentication Cryptogram Application Cryptogram Application Decisional Results Application Elementary File Application File Locator Application Identifier Application Interchange Profile Alphanumeric Alphanumeric Special Application Authorisation Response Code Authorisation Response Cryptogram Authorisation Request Cryptogram Application Transaction Counter Automated Teller Machine Application Usage Control Authentication Binary Basic Encoding Rules (defined in ISO/IEC 8825-1) Conditional Certification Authority Common Core Definitions Common Core Identifier Combined DDA/Application Cryptogram Generation December 2005 -1 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations Common Payment Application Specification CDOL Cert. CIAC CID CLA CPA CPS CRM CSU CV CV Rule CVM CVR DDA DDF DDOL DES DKI DOL EMV FC FCI FIPS GEN AC GPO hex. HSM IA IAC IAD ICC IDN Card Risk Management Data Object List Certificate Card Issuer Action Code Cryptogram Information Data Class Byte of the Command Message Common Payment Application EMVCo Common Personalisation Specification Card Risk Management Card Status Update Cryptogram Version Cardholder Verification Rule Cardholder Verification Method Card Verification Results Dynamic Data Authentication Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Standard Derivation Key Index Data Object List Europay, MasterCard, Visa Format Code File Control Information Federal Information Processing Standard GENERATE APPLICATION CRYPTOGRAM GET PROCESSING OPTIONS Hexadecimal Hardware Security Module Issuer Authentication Issuer Action Code (Denial, Default, Online) Issuer Application Data Integrated Circuit Card ICC Dynamic Number -2 December 2005 Common Payment Application Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations INS Int’l ISO L Lc LD Le LEN M MAC MK MKAC MKSMC MKSMI MTA n N/A NCA NI NIC NPE New Lc P1 P2 PAN PDOL PIN PK POS PTH Req Instruction Byte of the Command Message International International Organization for Standardization Length Length of the Command Data Field Length of the Plaintext Data in the Command Data Field Maximum Expected Length of the Response Data Field Length Mandatory Message Authentication Code ICC Master Key for Session Key Generation Master Key for Application Cryptogram Generation Master Key for Secure Messaging for Confidentiality Master Key for Secure Messaging for Integrity Maximum Transaction Amount Numeric Not Applicable Length of the Certification Authority Public Key Modulus Length of the Issuer Public Key Modulus Length of the ICC Public Key Modulus Length of the ICC PIN Encipherment Public Key Modulus Length of Command Data including Secure Messaging Components Parameter 1 Parameter 2 Primary Account Number Processing Options Data Object List Personal Identification Number Public Key Point Of Service Previous Transaction History Requirement December 2005 -3 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations Common Payment Application Specification RFU RID RSA SDA SFI SMC SMI SSAD SW1 SW2 TAC TC TLV TSI TVR Txn var. VLP YYMM YYMMDD Reserved for Future Use Registered Application Provider Identifier Rivest, Shamir, Adleman Static Data Authentication Short File Identifier Secure Messaging for Confidentiality Secure Messaging for Integrity Signed Static Application Data Status Byte One Status Byte Two Terminal Action Code(s) (Default, Denial, Online) Transaction Certificate Tag-Length-Value Transaction Status Information Terminal Verification Results Transaction Variable Visa Low-Value Payment year, month year, month, day -4 December 2005 Common Payment Application Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.2 Notations 4.2 Notations '0' to '9' and 'A' to 'F' ‘Bit Name’ xb, xxb xx A:= B A = B AND OR X ⊕ Y [bx] [x] [x][by] A / n x*y C:= (A || B) Element x Leftmost Rightmost 16 hexadecimal characters The bit defined as “Bit Name” in a data element. Binary values Any value A is assigned the value of B The value of A is equal to the value of B Logical AND Logical OR The symbol '⊕' denotes bit-wise exclusive-OR and is defined as follows: X ⊕ Y The bit-wise exclusive-OR of the data blocks X and Y. If one data block is shorter than the other, then it is first padded to the left with sufficient binary zeros to make it the same length as the other. Bit x of the referenced data element Byte x of the referenced data element Bit y of byte x of the referenced data element The integer division of A by n; that is, the unique integer d for which there exists an integer r, 0 ≤ r < n, such that: A = dn + r Multiply x by y The concatenation of an n-bit number A and an m-bit number B, which is defined as C = 2m A + B. Instance x of data element Element (for example, Accumulator x could be Accumulator 1 or Accumulator 2). Applies to a sequence of bits, bytes, or digits and used interchangeably with the term “most significant”. If C = (A || B) as above, then A is the leftmost n bits of C. Applies to a sequence of bits, bytes, or digits and used interchangeably with the term “least significant”. If C = (A || B) as above, then B is the rightmost m bits of C. December 2005 -5 4 Abbreviations, Notations, Conventions, and Terminology 4.3 Data Element Format Conventions Common Payment Application Specification 4.3 Data Element Format Conventions The EMV specifications use the following data element formats: a Alphabetic data elements contain a single character per byte. The permitted characters are alphabetic only (a to z and A to Z, upper and lower case). an Alphanumeric data elements contain a single character per byte. The permitted characters are alphabetic (a to z and A to Z, upper and lower case) and numeric (0 to 9). ans Alphanumeric Special data elements contain a single character per byte. The permitted characters and their coding are shown in the Common Character Set table in EMV Book 4, Annex B. There is one exception: The permitted characters for Application Preferred Name are the non-control characters defined in the ISO/IEC 8859 part designated in the Issuer Code Table Index associated with the Application Preferred Name. b These data elements consist of either unsigned binary numbers or bit combinations that are defined elsewhere in the specification. Binary example: The Application Transaction Counter (ATC) is defined as “b” with a length of two bytes. An ATC value of 19 is stored as Hex '00 13'. Bit combination example: Processing Options Data Object List (PDOL) is defined as “b” with the format shown in EMV Book 3, section 5.4. cn Compressed numeric data elements consist of two numeric digits (having values in the range Hex '0'–'9') per byte. These data elements are left justified and padded with trailing hexadecimal 'F's. Example: The Application Primary Account Number (PAN) is defined as “cn” with a length of up to ten bytes. A value of 1234567890123 may be stored in the Application PAN as Hex '12 34 56 78 90 12 3F FF' with a length of 8. n Numeric data elements consist of two numeric digits (having values in the range Hex '0' – '9') per byte. These digits are right justified and padded with leading hexadecimal zeroes. Other specifications sometimes refer to this data format as Binary Coded Decimal (“BCD”) or unsigned packed. Example: Amount, Authorised (Numeric) is defined as “n 12” with a length of six bytes. A value of 12345 is stored in Amount, Authorised (Numeric) as Hex '00 00 00 01 23 45'. -6 December 2005 Common Payment Application Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.3 Data Element Format Conventions var. Variable data elements are variable length and may contain any bit combination. Additional information on the formats of specific variable data elements is available elsewhere. December 2005 -7 4 Abbreviations, Notations, Conventions, and Terminology 4.4 Terminology Common Payment Application Specification 4.4 Terminology This section clarifies several terms used throughout the specification. Proprietary “Proprietary” indicates concepts that are not defined in this specification and/or that are outside the scope of this specification. Mandatory/Required/Recommended/Optional One objective of CPA is to define a core set of functionality that must be available to issuers in every implementation of CPA. The minimum requirements and issuer-options reflect the EMV and CCD mandatory items in addition to requirements the payment systems determine must be available to all issuers. All other functionality is optional and not required. Many features required to be supported by a CPA implementation are not mandated to be used by issuers. This document specifies requirements for an implementation of the CPA specification.
  • Functionality that is an option for the application vendor to implement is called an implementer-option, and the functionality is characterised as implementer-optional. If implemented, it is the issuer’s choice whether to use the functionality.
  • Functionality that is an option for the Issuer to use is called an issuer-option and the functionality is characterised as issuer-optional. -8 December 2005 Common Payment Application Specification 4 Abbreviations, Notations, Conventions, and Terminology 4.4 Terminology The following terminology is used to indicate these distinctions. mandatory required shall issuer-option should optional may implementer-op

仅显示部分内容。全文请阅读原文。