PCI Watch

Tracking changes across the Payment Card Industry

Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements

v4.4 Specifications
Contact Acceptance Device

EMV® Integrated Circuit Card Specifications for Payment Systems Book 4 Cardholder, Attendant, and Acquirer Interface Requirements Version 4.4 October 2022 ©

The EMV® 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. October 2022

©

Revision Log – Version 4.4 The following changes have been made to Book 4 since the publication of Version 4.3. Numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. Incorporated changes described in the following Specification Bulletins: Specification Bulletin no. 103: Unpredictable Number generation Specification Bulletin no. 144: Terminal Unpredictable Number generation Specification Bulletin no. 148: Clarification on Terminal Support of Multiple Application Version Numbers per AID Specification Bulletin no. 151: Clarification on Cardholder Selection and Cardholder Confirmation Specification Bulletin no. 163: Changes to PIN Pad requirements Specification Bulletin no. 164: Electronic Signature Capture and Electronic Receipt Delivery Specification Bulletin no. 178, Third Edition: Tokenisation Data Objects – Payment Account Reference (PAR) Specification Bulletin no. 185, Second Edition: Biometric Terminal Specification Specification Bulletin 197: Tokenisation Data Objects – Token Requestor ID and Last 4 Digits of PAN Specification Bulletin no. 220, Second Edition: EMV® Contact Kernel Output Specification Bulletin no. 231: Issuer Identification Number Extended (IINE) Specification Bulletin no. 243: Introduction of XDA/ODE for EMV Specifications Minor editorial clarifications and corrections, including those described in the following: Specification Bulletin no. 243: Introduction of XDA/ODE for EMV Specifications October 2022

©

Part I – General Contents 1 Scope 12 1.1 Changes in Version 4.4 12 1.2 Structure 12 1.3 Underlying Standards 13 1.4 Audience 14 2 Normative References 15 3 Definitions 18 4 Abbreviations, Notations, Conventions, and Terminology 26 4.1 Abbreviations 26 4.2 Notations 33 4.3 Data Element Format Conventions 35 4.4 Terminology 36 Part II – General Requirements 5 Terminal Types and Capabilities 38 5.1 Terminal Types 38 5.2 Terminal Capabilities 39 5.3 Terminal Configurations 40 6 Functional Requirements 43 6.1 Application Independent ICC to Terminal Interface Requirements 43 6.2 Security and Key Management 43 6.3 Application Specification 43 6.3.1 Initiate Application Processing 44 6.3.2 Offline Data Authentication 44 6.3.3 Processing Restrictions 47 6.3.4 Cardholder Verification Processing 47 6.3.5 Terminal Risk Management 53 6.3.6 Terminal Action Analysis 53 6.3.7 Card Action Analysis 54 6.3.8 Online Processing 55 6.3.9 Issuer-to-Card Script Processing 55 6.4 Conditions for Support of Functions 56 6.5 Other Functional Requirements 57 October 2022

©

6.5.1 Amount Entry and Management 57 6.5.2 Voice Referrals 57 6.5.3 Transaction Forced Online 58 6.5.4 Transaction Forced Acceptance 58 6.5.5 Transaction Sequence Counter 59 6.5.6 Unpredictable Number 59 6.6 Card Reading 59 6.6.1 IC Reader 60 6.6.2 Exception Handling 60 6.7 Date Management 61 6.7.1 Data Authentication 61 6.7.2 Processing Restrictions 61 6.7.3 Date Management 61 7 Physical Characteristics 62 7.1 Keypad 62 7.1.1 Command Keys 63 7.1.2 PIN Pad 64 7.2 Display 65 7.3 Memory Protection 65 7.4 Clock 65 7.5 Receipt Printer 65 7.6 Magnetic Stripe Reader 66 Part III – Software Architecture 8 Terminal Software Architecture 68 8.1 Environmental Changes 68 8.2 Application Libraries 69 8.3 Application Program Interface 70 8.4 Interpreter 71 8.4.1 Concept 71 8.4.2 Virtual Machine 72 8.4.3 Kernel 72 8.4.4 Application Code Portability 72 8.4.5 Kernel Output 73 8.5 Plugs and Sockets 75 8.6 Biometric Terminal 77 9 Software Management 78 10 Data Management 79 10.1 Application Independent Data 79 October 2022

©

10.1.1 Terminal Related Data 79 10.1.2 Transaction Related Data 80 10.2 Application Dependent Data 81 Part IV – Cardholder, Attendant, and Acquirer Interface 11 Cardholder and Attendant Interface 85 11.1 Language Selection 85 11.2 Standard Messages 86 11.3 Application Selection 89 11.4 Receipt 89 12 Acquirer Interface 90 12.1 Message Content 90 12.1.1 Authorisation Request 92 12.1.2 Financial Transaction Request 94 12.1.3 Authorisation or Financial Transaction Response 96 12.1.4 Financial Transaction Confirmation 97 12.1.5 Batch Data Capture 97 12.1.6 Reconciliation 100 12.1.7 Online Advice 101 12.1.8 Reversal 103 12.2 Exception Handling 105 12.2.1 Unable to Go Online 105 12.2.2 Downgraded Authorisation 106 12.2.3 Authorisation Response Incidents 106 12.2.4 Script Incidents 107 12.2.5 Advice Incidents 107 Part V – Annexes Annex A Coding of Terminal Data Elements 109 A1 Terminal Type 109 A2 Terminal Capabilities 110 A3 Additional Terminal Capabilities 112 A4 CVM Results 115 A5 Issuer Script Results 116 A6 Authorisation Response Code 116 A7 Biometric Terminal Capabilities 117 October 2022

©

Annex B Common Character Set 119 Annex C Example Data Element Conversion 121 Annex D Informative Terminal Guidelines 124 D1 Terminal Usage 124 D2 Power Supply 124 D2.1 External Power Supply 124 D2.2 Battery Requirements 124 D3 Keypad 125 D4 Display 125 D5 Informative References 125 Annex E Examples of Terminals 127 E1 Example 1 – POS Terminal or Electronic Cash Register 128 E2 Example 2 – ATM 129 E3 Example 3 – Vending Machine 130 Index 131 October 2022

©

Tables Table 1: Terms Describing Terminal Types 38 Table 2: Setting of CVM Results, TVR bits, and TSI bits following CVM Processing 51 Table 3: Card Action Analysis 54 Table 4: Key Types 62 Table 5: Command Keys 63 Table 6: Command Key Colours 63 Table 7: Application Dependent Data Elements 81 Table 8: Standard Messages 87 Table 9: ICC-specific Authorisation Request Data Elements 92 Table 10: Existing Authorisation Request Data Elements 93 Table 11: ICC-specific Financial Transaction Request Data Elements 94 Table 12: Existing Financial Transaction Request Data Elements 95 Table 13: ICC-specific Authorisation or Financial Transaction Response Data Elements 96 Table 14: Existing Authorisation or Financial Transaction Response Data Elements 96 Table 15: ICC-specific Financial Transaction Confirmation Data Elements 97 Table 16: Existing Financial Transaction Confirmation Data Elements 97 Table 17: ICC-specific Batch Data Capture Data Elements 98 Table 18: Existing Batch Data Capture Data Elements 99 Table 19: Existing Reconciliation Data Elements 100 Table 20: ICC-specific Online Advice Data Elements 101 Table 21: Existing Online Advice Data Elements 102 Table 22: ICC-specific Reversal Data Elements 103 Table 23: Existing Reversal Data Elements 104 Annexes Table 24: Terminal Type 109 Table 25: Terminal Capabilities Byte 1 – Card Data Input Capability 110 Table 26: Terminal Capabilities Byte 2 – CVM Capability 111 Table 27: Terminal Capabilities Byte 3 – Security Capability 111 Table 28: Add’l Term. Capabilities Byte 1 – Transaction Type Capability 112 Table 29: Add’l Term. Capabilities Byte 2 – Transaction Type Capability 113 Table 30: Add’l Term. Capabilities Byte 3 – Terminal Data Input Capability 113 Table 31: Add’l Term. Capabilities Byte 4 – Term. Data Output Capability 114 Table 32: Add’l Term. Capabilities Byte 5 – Term. Data Output Capability 115 Table 33: CVM Results 115 Table 34: Issuer Script Results 116 Table 35: Authorisation Response Codes 116 Table 36: Biometric Term. Cap. Byte 1 – Offline Biometric Capabilities 117 Table 37: Biometric Term. Cap. Byte 2 – Online Biometric Capabilities 118 Table 38: Biometric Terminal Capabilities Byte 3 – RFU 118 Table 39: Common Character Set 119 Table 40: Data Element Conversion 121 Table 41: Example of POS Terminal or Electronic Cash Register 128 October 2022

©

Table 42: Example of ATM 129 Table 43: Example of Vending Machine 130 October 2022

©

Figures Figure 1: Example of an Attended Terminal 40 Figure 2: Example of a Merchant Host 41 Figure 3: Example of a Cardholder-Controlled Terminal 42 Figure 4: PIN Pad Layout 64 Figure 5: Terminal Software 69 Figure 6: Socket/Plug Relationship 76 Figure 7: Architecture of Biometric Terminal and Card 77 October 2022

©

Part I General October 2022

©

1

Scope

This document, the Integrated Circuit Card Specifications for Payment Systems - Book 4, Cardholder, Attendant, and Acquirer Interface Requirements for Payment Systems, defines the mandatory, recommended, and optional terminal requirements necessary to support the acceptance of integrated circuit cards (ICCs) in accordance with the other documents of the Integrated Circuit Card Specifications for Payment Systems, all available on http://www.emvco.com:

  • Book 1 – Application Independent ICC to Terminal Interface Requirements
  • Book 2 – Security and Key Management
  • Book 3 – Application Specification 1.1 Changes in Version 4.4 This release incorporates all relevant Specification Bulletins, Application Notes, amendments, etc. published up to the date of this release. The Revision Log at the beginning of the Book provides additional detail about changes to this specification.

1.2 Structure Book 4 consists of the following parts: Part I - General Part II - General Requirements Part III - Software Architecture Part IV - Cardholder, Attendant, and Acquirer Interface Part V - Annexes Part I includes this introduction, as well as data applicable to all Books: normative references, definitions, abbreviations, notations, data element format convention, and terminology. Part II addresses:

  • Functional requirements, such as those emerging from the other Books of the Integrated Circuit Card Specifications for Payment Systems
  • General physical characteristics October 2022 © 1 Scope 1.3 Underlying Standards Part III addresses software architecture including software and data management. Part IV discusses:
  • Cardholder and attendant interface
  • Acquirer interface Part V discusses the coding of terminal data elements, lists the common character set, provides an example data element conversion, includes informative terminal guidelines, and provides examples of the physical and functional characteristics of terminals. The Book also includes a revision log and an index. This specification applies to all terminals operating in attended or unattended environments, having offline or online capabilities, and supporting transaction types such as purchase of goods, services, and cash. Terminals include but are not limited to automated teller machines (ATMs), branch terminals, cardholder-activated terminals, electronic cash registers, personal computers, and point of service (POS) terminals. This specification defines the requirements necessary to support the implementation of ICCs. These requirements are in addition to those already defined by individual payment systems and acquirers for terminals that accept magnetic stripe cards. ICC and magnetic stripe acceptance capability may co-exist in the same terminal. It is recognised that different terminal implementations exist depending on business environment and intended usage. This specification defines requirements for those features and functions that are applicable according to the particular operating environment of the terminal. This specification:
  • Does not cover application-specific terminal requirements unique to individual payment systems and those functions not required to support interchange.
  • Does not address cardholder or merchant operating procedures, which are established by individual payment systems.
  • Does not provide sufficient detail to be used as a specification for terminal procurement. Individual payment systems and acquirers will define complementary requirements applicable to different situations that will provide more detailed specifications applicable to terminal implementations.

1.3 Underlying Standards This specification is based on the ISO/IEC 7816 series of standards and should be read in conjunction with those standards. However, if any of the provisions or definitions in this specification differ from those standards, the provisions herein shall take precedence. October 2022

©

1 Scope 1.4 Audience 1.4 Audience This specification is intended for use by manufacturers of ICCs and terminals, system designers in payment systems, and financial institution staff responsible for implementing financial applications in ICCs. October 2022

©

2 Normative

References

The following specifications and standards contain provisions that are referenced in these specifications. The latest version shall apply unless a publication date is explicitly stated. EMV Contact Interface Specification EMV Tokenisation Framework FIPS 202 IEEE P1363 ISO 639-1 ISO 3166 ISO 4217 ISO/IEC 7812-1 ISO/IEC 7813 ISO/IEC 7816-4 ISO/IEC 7816-5 ISO/IEC 7816-6 EMV Level 1 Specifications for Payment Systems, EMV Contact Interface Specification EMV Payment Tokenisation Specification – Technical Framework Framework specification for an interoperable Payment Tokenisation solution. SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions Standard Specifications For Public-Key Cryptography Codes for the representation of names of languages – Part 1: Alpha-2 Code Note: This standard is updated continuously by ISO. Additions/changes to ISO 639-1:1988: Codes for the Representation of Names of Languages are available on: http://www.loc.gov/standards/iso639-2/php/code_changes.php Codes for the representation of names of countries and their subdivisions Codes for the representation of currencies and funds Identification cards – Identification of issuers — Part 1: Numbering System Identification cards – Financial transaction cards Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange Identification cards — Integrated circuit cards — Part 5: Registration of application providers Identification cards – Integrated circuit cards – Part 6: Interindustry data elements for interchange October 2022

©

2 Normative References ISO/IEC 7816-11 Identification cards – Integrated circuit cards – Personal verification through biometric methods ISO 8583:1987 Bank card originated messages – Interchange message specifications – Content for financial transactions ISO 8583:1993 Financial transaction card originated messages – Interchange message specifications ISO/IEC 8825-1 Information technology – ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) ISO/IEC 8859 Information processing – 8-bit single-byte coded graphic character sets ISO 9362 Banking – Banking telecommunication messages – Bank identifier codes ISO 9564-1 Financial services – Personal Identification Number (PIN) management and security – Part 1: Basic principles and requirements for PINs in card-based systems ISO/IEC 9796-2 Information technology – Security techniques – Digital signature schemes giving message recovery – Part 2: Integer factorization based mechanisms ISO/IEC 9797-1 Information technology – Security techniques – Message Authentication Codes – Part 1: Mechanisms using a block cipher ISO/IEC 9797-2 Information technology – Security techniques – Message Authentication Codes (MACs) – Part 2: Mechanisms using a dedicated hash-function ISO/IEC 10116 Information technology – Security techniques – Modes of operation for an n-bit block cipher ISO/IEC 10118-3 Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions ISO/IEC 11770-6 Information technology – Security techniques – Key management — Part 6: Key derivation ISO 13616 Banking and related financial services – International bank account number (IBAN) October 2022

©

2 Normative References ISO/IEC 14888-3 Information technology – Security techniques – Digital signatures with appendix — Part 3: Discrete logarithm based mechanisms ISO/IEC 15946-1 Information technology – Security techniques – Cryptographic techniques based on elliptic curves — Part 1: General ISO/IEC 15946-5 Information technology – Security techniques – Cryptographic techniques based on elliptic curves — Part 5: Elliptic curve generation ISO 16609 Banking – Requirements for message authentication using symmetric techniques ISO/IEC 18031 Information technology – Security techniques – Random bit generation ISO/IEC 18033-2 Information technology – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers ISO/IEC 18033-3 Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers ISO/IEC 19772 Information technology – Security techniques – Authenticated encryption ISO/IEC 19785-3 Information technology – Common Biometric Exchange Formats Framework – Patron format specifications ISO/IEC 19794 Information technology – Biometric data interchange formats ISO/IEC 19794-2 Information technology – Biometric data interchange formats – Part 2: Finger minutiae data SEC 1 Elliptic Curve Cryptography (available at http://www.secg.org) October 2022

©

3

Definitions

The following terms are used in one or more books of these specifications. Application Application Authentication Cryptogram Application Cryptogram Authentication Authorisation Request Cryptogram Authorisation Response Cryptogram Biometric Data Block The application protocol between the card and the terminal and its related set of data. An Application Cryptogram generated by the card when declining a transaction. A cryptogram generated by the card in response to a GENERATE AC command. See also:

  • Application Authentication Cryptogram
  • Authorisation Request Cryptogram
  • Transaction Certificate The provision of assurance of the claimed identity of an entity or of data origin. An Application Cryptogram generated by the card when requesting online authorisation. A cryptogram generated by the issuer in response to an Authorisation Request Cryptogram. A block of data with a specific format that contains information captured from a biometric capture device and that could be used as follows:
  • stored in the card as part of the biometric reference template
  • sent to the ICC in the data field of the PIN CHANGE/UNBLOCK command
  • sent to the ICC in the data field of the VERIFY command for offline biometric verification
  • sent online for verification The format of the BDB is outside the scope of this specification. October 2022 © 3 Definitions Biometric Reference Template Biometric data stored in the card as reference. Data provided by a biometric capture device would be compared against the biometric reference template to determine a match. Biometric Verification The process of determining that the biometrics presented, such as finger, palm, iris, voice, or facial, are valid. Byte 8 bits. Card A payment card as defined by a payment system. Certificate 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. Certification Authority Trusted third party that establishes a proof that links a public key and other relevant information to its owner. Ciphertext Enciphered information. Combined DDA/Application Cryptogram Generation A form of offline dynamic data authentication. Command A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. Command Chaining A mechanism where consecutive command-response pairs can be chained. Compromise The breaching of secrecy or security. Concatenation 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. October 2022 © 3 Definitions Contact A conducting element ensuring galvanic continuity between integrated circuit(s) and external interfacing equipment. Cryptogram Result of a cryptographic operation. Cryptographic Algorithm An algorithm that transforms data in order to hide or reveal its information content. Data Integrity The property that data has not been altered or destroyed in an unauthorised manner. Decipherment The reversal of a corresponding encipherment. DEM1 A family of data encapsulation mechanisms defined in ISO/IEC 18033-2. Digital Signature An asymmetric cryptographic transformation of data that allows the recipient of the data to prove the origin and integrity of the data, and protect the sender and the recipient of the data against forgery by third parties, and the sender against forgery by the recipient. Dynamic Data Authentication A form of offline dynamic data authentication Elliptic Curve Cryptography Public key cryptography based on the algebraic structure of elliptic curves over finite fields. Encipherment The reversible transformation of data by a cryptographic algorithm to produce ciphertext. Exclusive-OR Binary addition with no carry, giving the following values: 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = 0 Extended Data Authentication A form of offline dynamic data authentication. Facial Verification The process of determining that the face presented is valid. Financial Transaction The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services against payment. October 2022 © 3 Definitions Finger Verification The process of determining that the finger presented is valid. Function A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. Hash Function 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. Hash Result The string of bits that is the output of a hash function. I2OSP An integer to octet string conversion primitive function defined in ISO/IEC 18033-2. Integrated Circuit(s) Electronic component(s) designed to perform processing and/or memory functions. Integrated Circuit(s) Card A card into which one or more integrated circuits are inserted to perform processing and memory functions. Interface Device That part of a terminal into which the ICC is inserted, including such mechanical and electrical devices as may be considered part of it. Iris Verification The process of determining that the iris presented is valid. Issuer Action Code Any of the following, which reflect the issuer-selected action to be taken upon analysis of the TVR:
  • Issuer Action Code – Default
  • Issuer Action Code – Denial
  • Issuer Action Code – Online October 2022 © 3 Definitions Kernel The set of functions required to be present on every terminal implementing a specific interpreter. The kernel contains device drivers, interface routines, security and control functions, and the software for translating from the virtual machine language to the language used by the real machine. In other words, the kernel is the implementation of the virtual machine on a specific real machine. Key A sequence of symbols that controls the operation of a cryptographic transformation. Key

Introduction

The process of generating, distributing, and beginning use of a key pair. Key Withdrawal The process of removing a key from service as part of its revocation. Keypad Arrangement of numeric, command, and, where required, function and/or alphanumeric keys laid out in a specific manner. Library A set of high-level software functions with a published interface, providing general support for terminal programs and/or applications. Logical Compromise The compromise of a key through application of improved cryptanalytic techniques, increases in computing power, or combination of the two. Magnetic Stripe The stripe containing magnetically encoded information. Message A string of bytes sent by the terminal to the card or vice versa, excluding transmission-control characters. Message Authentication Code A symmetric cryptographic transformation of data that protects the sender and the recipient of the data against forgery by third parties. Nibble The four most significant or least significant bits of a byte. Offline Data Encipherment Offline encipherment of data, in particular for cardholder PIN and biometric data. See Book 2. Padding Appending extra bits to either side of a data string. Palm Verification The process of determining that the palm presented is valid. October 2022

©

3 Definitions Path Concatenation of file identifiers without delimitation. Payment System Environment A logical construct within the ICC, the entry point to which is a Directory Definition File (DDF) named '1PAY.SYS.DDF01'. This DDF contains a Payment System Directory which in turn contains entries for one or more Application Definition Files (ADFs) which are formatted according to this specification. Physical Compromise The compromise of a key resulting from the fact that it has not been securely guarded, or a hardware security module has been stolen or accessed by unauthorised persons. PIN Pad Arrangement of numeric and command keys to be used for personal identification number (PIN) entry. Also known as a “PIN Entry Device” (PED). Plaintext Unenciphered information. Potential Compromise A condition where cryptanalytic techniques and/or computing power has advanced to the point that compromise of a key of a certain length is feasible or even likely. Private Key That key of an entity’s asymmetric key pair that should only be used by that entity. In the case of a digital signature scheme, the private key defines the signature function. Public Key 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. Public Key Certificate The public key information of an entity signed by the certification authority and thereby rendered unforgeable. Response A message returned by the ICC to the terminal after the processing of a command message received by the ICC. RSA-KEM A family of key encapsulation mechanisms defined in ISO/IEC 18033-2. RSATransform The RSA exponentiation that is used for encryption and decryption, and generating and verifying a signature. October 2022

©

3 Definitions Script 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. Secret Key A key used with symmetric cryptographic techniques and usable only by a set of specified entities. Socket An execution vector defined at a particular point in an application and assigned a unique number for reference. Static Data Authentication Offline static data authentication Symmetric Cryptographic Technique 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. Template Value field of a constructed data object, defined to give a logical grouping of data objects. Terminal 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. Terminal Action Code Any of the following, which reflect the acquirer-selected action to be taken upon analysis of the TVR:

  • Terminal Action Code – Default
  • Terminal Action Code – Denial
  • Terminal Action Code – Online Terminate Card Session End the card session by deactivating the IFD contacts according to EMV Contact Interface Specification and displaying a message indicating that the ICC cannot be used to complete the transaction. Terminate Transaction Stop the current application and deactivate the card. Transaction 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. October 2022 © 3 Definitions Transaction Certificate An Application Cryptogram generated by the card when accepting a transaction. Virtual Machine A theoretical microprocessor architecture that forms the basis for writing application programs in a specific interpreter software implementation. Voice Verification The process of determining that the voice presented is valid. October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations a Alphabetic (see section 4.3, Data Element Format Conventions) AAC Application Authentication Cryptogram AAD Additional Authenticated Data AC Application Cryptogram ADF Application Definition File AEF Application Elementary File AES Advanced Encryption Standard AFL Application File Locator AID Application Identifier AIP Application Interchange Profile an Alphanumeric (see section 4.3) ans Alphanumeric Special (see section 4.3) APDU Application Protocol Data Unit API Application Program Interface ARC Authorisation Response Code ARPC Authorisation Response Cryptogram ARQC Authorisation Request Cryptogram ASI Application Selection Indicator ASN Abstract Syntax Notation ATC Application Transaction Counter ATM Automated Teller Machine ATR Answer to Reset October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations AUC b BCD BDB BEK BER BHT BIC BIT BMK CA CAD C-APDU CBC CBEFF CCD CCI CCYYMMDD CDA CDOL CID CLA cn CPU CRL CSU CV CV Rule Application Usage Control Binary (see section 4.3) Binary Coded Decimal Biometric Data Block Biometric Encryption Key Basic Encoding Rules (defined in ISO/IEC 8825-1) Biometric Header Template Bank Identifier Code Biometric Information Template Biometric MAC Key Certification Authority Card Accepting Device Command APDU Cipher Block Chaining Common Biometric Exchange Formats Framework Common Core Definitions Common Core Identifier Year (4 digits), Month, Day Combined DDA/Application Cryptogram Generation Card Risk Management Data Object List Cryptogram Information Data Class Byte of the Command Message Compressed Numeric (see section 4.3) Central Processing Unit Certificate Revocation List Card Status Update Cryptogram Version Cardholder Verification Rule October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations CVM CVR DDA DDF DDOL DES DF DIR DOL ECB EC-SDSA ECC EF EN FC FCI Hex HHMMSS HMAC I/O IAC IAD IBAN IC ICC ICCD IEC IFD Cardholder Verification Method Card Verification Results Dynamic Data Authentication Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Standard Dedicated File Directory Data Object List Electronic Code Book Elliptic Curve Schnorr Digital Signature Algorithm Elliptic Curve Cryptography Elementary File European Norm Format Code File Control Information Hexadecimal Hours, Minutes, Seconds Keyed-hash Message Authentication Code Input/Output Issuer Action Code (Denial, Default, Online) Issuer Application Data International Bank Account Number Integrated Circuit Integrated Circuit(s) Card Issuer Certified Card Data International Electrotechnical Commission Interface Device October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations IIN IINE INS ISO KD KDF KM KS L l.s. Lc LCOL LDD Le Lr LRC M m.s. MAC max. MF MK MMDD MMYY n NCA Issuer Identification Number Issuer Identification Number Extended Instruction Byte of Command Message International Organization for Standardization Key Derivation Key Derivation Function Master Key Session Key Length Least Significant Exact Length of Data Sent by the TAL in a Case 3 or 4 Command Lower Consecutive Offline Limit Length of the ICC Dynamic Data Maximum Length of Data Expected by the TAL in Response to a Case 2 or 4 Command Length of Response Data Field Longitudinal Redundancy Check Mandatory Most Significant Message Authentication Code Maximum Master File ICC Master Key for session key generation Month, Day Month, Year Numeric (see section 4.3) Length of the Certification Authority Public Key Modulus October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations NF NFIELD NHASH NI NIC NIST NPE NSIG O O/S ODA ODE P1 P2 PAN PAR PC PCA PDOL PI PIC PIN PIX POS pos. PSE R-APDU Norme Française Length of a finite field element Output length of a hash function Length of the Issuer Public Key Modulus Length of the ICC Public Key Modulus National Institute for Standards and Technology Length of the ICC PIN Encipherment Public Key Modulus Length of an ECC Digital Signature Optional Operating System Offline Data Authentication Offline Data Encipherment Parameter 1 Parameter 2 Primary Account Number Payment Account Reference Personal Computer Certification Authority Public Key Processing Options Data Object List Issuer Public Key ICC Public Key Personal Identification Number Proprietary Application Identifier Extension Point of Service Position Payment System Environment Response APDU October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations RFU RID RSA SCA SDA SDAD SFI SHA-1 SHA-2 SHA-256 SHA-3 SI SIC SK SW1 SW2 TAA TAC TAL TC TDOL TLV TPDU TSI TVR UCOL UL UN Reserved for Future Use Registered Application Provider Identifier Rivest, Shamir, Adleman Algorithm Certification Authority Private Key Static Data Authentication Signed Dynamic Application Data Short File Identifier Secure Hash Algorithm 1 Secure Hash Algorithm 2 (includes SHA-256 and SHA-512) Secure Hash Algorithm 256 Secure Hash Algorithm 3 Issuer Private Key ICC Private Key Session Key Status Byte One Status Byte Two Terminal Action Analysis Terminal Action Code(s) (Default, Denial, Online) Terminal Application Layer Transaction Certificate Transaction Certificate Data Object List Tag Length Value Transport Protocol Data Unit Transaction Status Information Terminal Verification Results Upper Consecutive Offline Limit Underwriters Laboratories Incorporated Unpredictable Number October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations var. XDA YYMM YYMMDD Variable (see section 4.3) Extended Data Authentication Year, Month Year, Month, Day October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.2 Notations 4.2 Notations '0' to '9' and 'A' to 'F' 16 hexadecimal characters xx Any value A:= B A is assigned the value of B A = B Value of A is equal to the value of B A ≡ B mod n Integers A and B are congruent modulo the integer n, that is, there exists an integer d such that (A – B) = dn A mod n The reduction of the integer A modulo the integer n, that is, the unique integer r, 0 ≤ r < n, for which there exists an integer d such that A = dn + r A / n 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 Y:= ALG(K)[X] X = ALG-1(K)[Y] Encipherment of a data block X with a block cipher as specified in Book 2 section A1, using a secret key K Decipherment of a data block Y with a block cipher as specified in Book 2 section A1, using a secret key K Y:= Sign (SK)[X] The signing of a data block X with an asymmetric reversible algorithm as specified in Book 2 section A2, using the private key SK X = Recover(PK)[Y] The recovery of the data block X with an asymmetric reversible algorithm as specified in Book 2 section A2, using the public key PK C:= (A || B) The concatenation of an n-bit number A and an m-bit number B, which is defined as C = 2m A + B. Leftmost 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. October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.2 Notations Rightmost 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. H:= Hash[MSG] Hashing of a message MSG of arbitrary length using a 160-bit hash function X ⊕ Y 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. MIN (x, y) The smaller of values x and y. October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.3 Data Element Format Conventions 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). There is one exception: The permitted characters for Payment Account Reference are alphabetic upper case (A to Z) 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 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 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'. 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. October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.4 Terminology 4.4 Terminology business agreement An agreement reached between a payment system and its business partner(s). proprietary Not defined in this specification and/or outside the scope of this specification shall Denotes a mandatory requirement should Denotes a recommendation October 2022 © Part II General Requirements October 2022 © 5 Terminal Types and Capabilities 5.1 Terminal Types As described in section 1, this specification addresses a broad spectrum of terminals. For the purpose of this specification, terminals are categorised by the following:
  • Environment: Attended or unattended
  • Communication: Online or offline
  • Operational control: Financial institution, merchant, or cardholder Table 1 defines the terms used to describe terminal types. Term Attended Unattended Online only Offline with online capability Offline only Operational control Definition An attendant (an agent of the merchant or of the acquirer) is present at the point of transaction and participates in the transaction by entering transaction-related data. The transaction occurs ‘face to face’. The cardholder conducts the transaction at the point of transaction without the participation of an attendant (agent of the merchant or of the acquirer). The transaction does not occur ‘face to face’. The transaction can normally only be approved in real time by transmission of an authorisation request message. Depending upon transaction characteristics, the transaction can be completed offline by the terminal or online in real time. It is equivalent to ‘online with offline capability’. The transaction can only be completed offline by the terminal. Identifies the entity responsible for the operation of the terminal. This does not necessarily equate to the actual owner of the terminal. Table 1: Terms Describing Terminal Types Within this specification, online reflects online communication to acquirer (or its agent). The acquirer is assumed to be capable of communicating to the issuer (or its agent). The type of terminal shall be indicated in Terminal Type. The coding of Terminal Type using the three categories is shown in Annex A. October 2022 © 5 Terminal Types and Capabilities 5.2 Terminal Capabilities 5.2 Terminal Capabilities For the purpose of this specification, terminal capabilities are described in Terminal Capabilities and Additional Terminal Capabilities. The following categories shall be indicated in Terminal Capabilities:
  • Card data input capability - Indicates all the methods supported by the terminal for entering the information from the card into the terminal.
  • Cardholder Verification Method (CVM) capability - Indicates all the methods supported by the terminal for verifying the identity of the cardholder at the terminal.
  • Security capability - Indicates all the methods supported by the terminal for authenticating the card at the terminal and whether or not the terminal has the ability to capture a card. The following categories shall be indicated in Additional Terminal Capabilities:
  • Transaction type capability - Indicates all the types of transactions supported by the terminal.
  • Terminal data input capability - Indicates all the methods supported by the terminal for entering transaction-related data into the terminal.
  • Terminal data output capability - Indicates the ability of the terminal to print or display messages and the character set code table(s) referencing the part(s) of ISO/IEC 8859 supported by the terminal. The coding of Terminal Capabilities and Additional Terminal Capabilities using these categories is shown in Annex A. October 2022 © 5 Terminal Types and Capabilities 5.3 Terminal Configurations 5.3 Terminal Configurations Terminal capabilities and device components vary depending on the intended usage and physical environment. A limited set of configuration examples follow. Figure 1 illustrates an example of an attended terminal where the integrated circuit (IC) interface device (IFD) and PIN pad are integrated but separate from the POS device (such as for an electronic fund transfer terminal or an electronic cash register). Terminal 123 456 ICC 789 C0E IFD POS Device Mag. stripe card C = ‘Cancel’ E = ‘Enter’ Figure 1: Example of an Attended Terminal October 2022 © 5 Terminal Types and Capabilities 5.3 Terminal Configurations Figure 2 illustrates an example of merchant host concentrating devices, which may be of various types and capabilities. POS Device Merchant Host Figure 2: Example of a Merchant Host Within this specification a merchant host to which is connected a cluster of POS devices shall be considered, in its totality, as a ‘terminal’ regardless of the distribution of functions between the host and POS devices. (See section 10 for terminal data management requirements.) October 2022 © 5 Terminal Types and Capabilities 5.3 Terminal Configurations Figure 3 illustrates an example of a cardholder-controlled terminal that is connected via a public network to a merchant or acquirer host. 123 456 789 C0E Cardholder Terminal Public Network C = ‘Cancel’ E = ‘Enter’ Merchant Host Acquirer Host Figure 3: Example of a Cardholder-Controlled Terminal October 2022 © 6 Functional Requirements This Book does not replicate the other Books of the Integrated Circuit Card Specifications for Payment Systems but describes the implementation issues and the impact of those Books on the terminal. This section uses standard messages described in section 11.2 to illustrate the appropriate message displays for the transaction events described below. The usage of Authorisation Response Code, CVM Results, and Issuer Script Results is specified in this section. See Annex A for additional information on coding.

6.1 Application Independent ICC to Terminal Interface Requirements The terminal shall comply with all Parts of Book 1. It shall support all data elements and commands subject to the conditions described in section 6.3.

6.2 Security and Key Management The terminal shall comply with all Parts of Book 2. It shall support all data elements and commands subject to the conditions described in section 6.3.

6.3 Application Specification The terminal shall comply with all Parts of Book 3. It shall support all functions subject to the conditions described in this section. Sections 6.3.1 to 6.3.9 expand upon the terminal functions described in Book 3. October 2022

©

6 Functional Requirements 6.3 Application Specification 6.3.1 Initiate Application Processing When the Processing Options Data Object List (PDOL) includes an amount field (either Amount, Authorised or Amount, Other), an attended terminal (Terminal Type = 'x1', 'x2', or 'x3') shall provide the amount at this point in transaction processing. If the amount is not yet available, the terminal shall obtain the amount and should display the ‘ENTER AMOUNT’ message. For any other terminal type, if the terminal is unable to provide the amount at this point in transaction processing, the amount field in the data element list shall be filled with hexadecimal zeroes. As described in Book 3, if the card returns SW1 SW2 = '6985' in response to the GET PROCESSING OPTIONS command, indicating that the transaction cannot be performed with this application, then the terminal should display the ‘NOT ACCEPTED’ message and shall return to application selection. The terminal shall not allow that application to be selected again for this card session as defined in EMV Contact Interface Specification.

6.3.2 Offline Data Authentication An online-only terminal supporting no form of offline data authentication as indicated in Terminal Capabilities shall set to 1 the ‘Offline data authentication was not performed’ bit in the Terminal Verification Results (TVR). (For details, see Book 3 Annex C.) All other terminals shall be capable of performing SDA, DDA, optionally CDA, and optionally XDA, as described in Books 2 and 3.

6.3.2.1 CDA The following section applies when the selected form of offline data authentication is CDA. When CDA fails prior to the final Terminal Action Analysis (for example, Issuer Public Key recovery fails) preceding the issuance of a first GENERATE AC command or a second GENERATE AC command in the case ‘unable to go online’, the terminal shall set the TVR bit for ‘CDA failed’ to 1 and request the cryptogram type determined by Terminal Action Analysis. In this case, the GENERATE AC command shall not request a CDA signature and no further CDA processing is performed. When a CDA failure is detected after the final Terminal Action Analysis preceding the issuance of a first or second GENERATE AC command, the terminal shall set the ‘CDA failed’ bit in the TVR to 1 and the following rules apply: If CDA fails in conjunction with the first GENERATE AC:

  • If the Cryptogram Information Data (CID) indicates that the card has returned a TC, the terminal shall decline the transaction and not perform a second GENERATE AC command.
  • If the CID indicates that the card has returned an ARQC, the terminal shall complete the transaction processing by performing an immediate second GENERATE AC command requesting an AAC. October 2022 © 6 Functional Requirements 6.3 Application Specification If CDA fails in conjunction with the second GENERATE AC, the terminal shall decline the transaction 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.

6.3.2.2 XDA When the selected form of offline data authentication is XDA, the terminal shall perform the processing defined in the following sections when XDA fails. The first three sections address the three different ways in which XDA can fail and the fourth section describes terminal processing after first GENERATE AC XDA failure. Note: In the following sections, ‘final TAA’ means the Terminal Action Analysis that occurs immediately before issuance of a GENERATE AC command. 6.3.2.2.1 CA ECC Public Key Retrieval Failure If the terminal experiences a CA ECC Public Key retrieval error, the terminal shall set the ‘CA ECC key missing’ bit in the TVR to 1 before the final TAA preceding the first GENERATE AC command. In this case the terminal omits ECC key recovery and XDA signature verification and continues with the processing defined in section 6.3.2.2.4. 6.3.2.2.2 ECC Key Recovery Failure If the terminal experiences an ECC Issuer Public Key or ICC Public Key recovery error, the terminal shall:

  • Set the ‘ECC key recovery failed’ bit in the TVR after issuance of the first GENERATE AC command but before the TAA that occurs following the first GENERATE AC command. However, the ‘ECC key recovery failed’ bit is not set if the ‘CA ECC key missing’ bit is set.
  • Perform the processing defined in section 6.3.2.2.4. Note: The terminal may perform ECC key recovery before issuance of the first GENERATE AC command, but setting of the ‘ECC key recovery failed’ bit in the TVR must occur after issuance of the first GENERATE AC command to ensure that the result of final TAA preceding the first GENERATE AC command does not vary based upon when ECC key recovery is performed by the terminal. If the TVR is included as input to generation of the Application Cryptogram, the issuer should set the ‘ECC key recovery failed’ bit in the TVR to 0 when performing Application Cryptogram verification, as the value of that bit may have changed after the Application Cryptogram was generated. 6.3.2.2.3 XDA Signature Verification Failure After a GENERATE AC command, if either of the following is true:
  • the Signed Dynamic Application Data (SDAD) was not received in the GENERATE AC response
  • verification of the Signed Dynamic Application Data (SDAD) failed October 2022 © 6 Functional Requirements 6.3 Application Specification then when ECC key recovery has ended, the terminal shall:
  • Set the ‘XDA signature verification failed’ bit in the TVR to 1 if CA ECC key retrieval and ECC key recovery were successful.
  • For the first GENERATE AC, perform the processing defined in section 6.3.2.2.4.
  • For the second GENERATE AC, decline the transaction. Note: This will only apply if XDA was successful on the first GENERATE AC as otherwise section 6.3.2.2.4 applies which specifies that the XDA signature on the second GENERATE AC is not verified. 6.3.2.2.4 Terminal Processing After First GENERATE AC XDA Failure The terminal performs the processing described in this section when it experiences an XDA failure, specifically a CA ECC public key retrieval failure (as defined in section 6.3.2.2.1), an ECC key recovery failure (as defined in section 6.3.2.2.2) or an XDA signature verification failure for first GENERATE AC (as defined in section 6.3.2.2.3). If the CID indicated that the card returned a TC or ARQC, the terminal shall:
  • Perform TAA using the TAC-Denial and IAC-Denial. If the IAC-Denial does not exist, a default value with all bits set to 0 is used.
  • If the result of this TAA is to decline the transaction (that is, a TVR bit is 1 and the corresponding TAC-Denial or IAC-Denial bit is also 1), the terminal shall:  If the CID indicated that the card returned a TC, no second GENERATE AC command shall be issued to complete the transaction.  If the CID indicated that the card returned an ARQC, a second GENERATE AC command requesting an AAC shall be issued to complete the transaction. Otherwise (the result of this TAA is not to decline the transaction), the terminal shall attempt to send the transaction online for authorisation1 and:  The TVR value included in the online authorisation shall include the updated values of the ‘ECC key recovery failed’ and the ‘XDA signature verification failed’ bits. Note: If the TVR is included as input to generation of the Application Cryptogram, the issuer should set the ‘ECC key recovery failed’ and the ‘XDA signature verification failed’ bits in the TVR to 0 when performing Application Cryptogram verification, as the value of those bits may have changed after the Application Cryptogram was generated.  If the terminal is able to process the transaction online, then:
  • If the CID indicated that the card returned a TC, the terminal shall not issue a second GENERATE AC command to complete the transaction. Depending on the Authorisation Response Code returned in the response message, the terminal shall determine whether to accept or decline the transaction. 1 In this scenario, a cryptogram type of TC may be sent in the online authorisation. October 2022 © 6 Functional Requirements 6.3 Application Specification
  • If the CID indicated that the card returned an ARQC, the terminal shall issue a second GENERATE AC command to complete the transaction as described in section 6.3.8. Although an XDA signature will be requested it shall not be verified by the terminal.2  If the terminal is for any reason unable to process the transaction online, then:
  • The terminal shall decline the transaction
  • If the CID indicated that the card returned a TC, the terminal shall not issue a second GENERATE AC command to complete the transaction.
  • If the CID indicated that the card returned an ARQC, the terminal shall issue a second GENERATE AC command requesting an AAC to complete the transacti

Shown in part. Read the original for the full text.