Book 1 – Application Independent ICC to Terminal Interface Requirements

v4.4 Specifications
Contact Acceptance Device

EMV® Integrated Circuit Card Specifications for Payment Systems Book 1 Application Independent ICC to Terminal Interface Requirements Version 4.4 October 2022

Requirements 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

Requirements Revision Log – Version 4.4 The following changes have been made to Book 1 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. 111: Clarification on Application Filtering Specification Bulletin no. 151: Clarification on Cardholder Selection and Cardholder Confirmation Specification Bulletin no. 175: Application Selection Registered Proprietary Data Specification Bulletin no. 178, Third Edition: Tokenisation Data Objects – Payment Account Reference (PAR) Specification Bulletin no. 231: Issuer Identification Number Extended (IINE) Removed Part II, Electromechanical Characteristics, Logical Interface, and Transmission Protocols The topics formerly addressed in Part II are included in EMV Level 1 Specifications for Payment Systems, EMV Contact Interface Specification. Minor editorial clarifications and corrections, including those described in the following: Specification Bulletin no. 175: Application Selection Registered Proprietary Data October 2022

Requirements Part I – General Contents 1 Scope 10 1.1 Changes in Version 4.4 10 1.2 Structure 10 1.3 Underlying Standards 11 1.4 Audience 11 2 Normative References 12 3 Definitions 15 4 Abbreviations, Notations, Conventions, and Terminology 23 4.1 Abbreviations 23 4.2 Notations 30 4.3 Data Element Format Conventions 32 4.4 Terminology 33 Part II – Removed in Version 4.4 Part III – Files, Commands, and Application Selection 10 Files 36 10.1 File Structure 36 10.1.1 Application Definition Files 36 10.1.2 Application Elementary Files 36 10.1.3 Mapping of Files onto ISO/IEC 7816-4 File Structure 37 10.1.4 Directory Structure 37 10.2 File Referencing 38 10.2.1 Referencing by Name 38 10.2.2 Referencing by SFI 38 11 Commands 39 11.1 Message Structure 39 11.1.1 Command APDU Format 40 11.1.2 Response APDU Format 41 11.2 READ RECORD Command-Response APDUs 41 11.2.1 Definition and Scope 41 11.2.2 Command Message 42 October 2022

Requirements 11.2.3 Data Field Sent in the Command Message 42 11.2.4 Data Field Returned in the Response Message 42 11.2.5 Processing State Returned in the Response Message 42 11.3 SELECT Command-Response APDUs 43 11.3.1 Definition and Scope 43 11.3.2 Command Message 43 11.3.3 Data Field Sent in the Command Message 44 11.3.4 Data Field Returned in the Response Message 44 11.3.5 Processing State Returned in the Response Message 47 12 Application Selection 48 12.1 Overview of Application Selection 48 12.2 Data in the ICC Used for Application Selection 50 12.2.1 Coding of Payment System Application Identifier 50 12.2.2 Structure of the PSE 50 12.2.3 Coding of a Payment System Directory 51 12.2.4 Error Handling for FCI Response Data 53 12.3 Building the Candidate List 53 12.3.1 Matching Terminal Applications to ICC Applications 54 12.3.2 Using the PSE 55 12.3.3 Using a List of AIDs 58 12.4 Final Selection 61 12.5 Application Selection Registered Proprietary Data 64 Part IV – Annexes Annex A Removed in Version 4.4 66 Annex B Data Elements Table 67 B1 Data Elements by Name 67 B2 Data Elements by Tag 73 Annex C Examples of Directory Structures 74 C1 Single Application Card 74 C2 Single Level Directory 75 C3 Multi-Level Directory 76 C4 Coding of Proprietary Directories 76 October 2022

Requirements Part V – Common Core

Definitions

Common Core Definitions 79 Changed Sections 79 11 Commands 79 11.3 SELECT Command-Response APDUs 79 11.3.5 Processing State Returned in the Response Message 79 Index 80 October 2022

Requirements Tables Table 1: Command APDU Content 40 Table 2: Response APDU Content 41 Table 3: READ RECORD Command Message 42 Table 4: READ RECORD Command Reference Control Parameter 42 Table 5: SELECT Command Message 43 Table 6: SELECT Command Reference Control Parameter 44 Table 7: SELECT Command Options Parameter 44 Table 8: SELECT Response Message Data Field (FCI) of the PSE 45 Table 9: SELECT Response Message Data Field (FCI) of a DDF 45 Table 10: SELECT Response Message Data Field (FCI) of an ADF 46 Table 11: Payment System Directory Record Format 51 Table 12: ADF Directory Entry Format 52 Table 13: Format of Application Priority Indicator 52 Table 14: Data Elements Table 67 Table 15: Data Elements Tags 73 Table 16: Example of a DDF Directory Entry Format 77 October 2022

Requirements Figures Figure 1: Command APDU Structure 40 Figure 2: Response APDU Structure 41 Figure 3: Terminal Logic Using Directories 57 Figure 4: Using the List of AIDs in the Terminal 60 Figure 5: Simplest Card Structure Single Application 74 Figure 6: Single Level Directory 75 Figure 7: Third Level Directory 76 October 2022

Requirements Part I General October 2022

Requirements 1

Scope

This document, the Integrated Circuit Card (ICC) Specifications for Payment Systems – Book 1, Application Independent ICC to Terminal Interface Requirements, describes the minimum functionality required of integrated circuit cards (ICCs) and terminals to ensure correct operation and interoperability independent of the application to be used. Additional proprietary functionality and features may be provided, but these are beyond the scope of this specification and interoperability cannot be guaranteed. The Integrated Circuit Card Specifications for Payment Systems includes the following additional documents, all available on http://www.emvco.com:

  • Book 2 – Security and Key Management
  • Book 3 – Application Specification
  • Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements 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. Part II, Electromechanical Characteristics, Logical Interface, and Transmission Protocols, was removed in Version 4.4. The topics formerly addressed in Part II are included in EMV Level 1 Specifications for Payment Systems, EMV Contact Interface Specification. The Revision Log at the beginning of the Book provides additional detail about changes to this Book.

1.2 Structure Book 1 consists of the following parts: Part I Part II Part III Part IV Part V – General – Removed in Version 4.4. – Files, Commands, and Application Selection – Annexes – Common Core Definitions October 2022

Requirements 1 Scope 1.3 Underlying Standards 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 III defines data elements, files, and commands as they apply to the exchange of information between an ICC and a terminal. In particular it covers:

  • Data elements and their mapping onto data objects.
  • Structure and referencing of files.
  • Structure and coding of messages between the ICC and the terminal to achieve application selection. Part III also defines the application selection process from the standpoint of both the card and the terminal. The logical structure of data and files within the card that is required for the process is specified, as is the terminal logic using the card structure. Part IV includes a data elements table specific to application selection, and example directory structures. Part V defines an optional extension to be used when implementing the Common Core Definitions (CCD). The Book also includes a revision log and an index.

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.

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

Requirements 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

Requirements 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

Requirements 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

Requirements 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 Requirements 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 Requirements 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 Requirements 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 Requirements 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. 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

Requirements 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

Requirements 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 Requirements 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 Requirements 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations a Alphabetic (see Data Element Format Conventions, section 4.3) 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 Requirements 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 Requirements 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 Requirements 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 Requirements 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 Requirements 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 Requirements 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 Requirements 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 Requirements 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 Requirements 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 Requirements 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 Requirements Part II Removed in Version 4.4 The topics formerly addressed in Part II are included in EMV Contact Interface Specification. October 2022 Requirements Part III Files, Commands, and Application Selection October 2022 Requirements 10 Files An application in the ICC includes a set of items of information, often contained within files. These items of information may be accessible to the terminal after a successful application selection. An item of information is called a data element. A data element is the smallest piece of information that may be identified by a name, a description of logical content, a format, and a coding. It is up to the issuer to ensure that data in the card is of the correct format. The data element directory defined in Annex B includes those data elements that may be used for application selection. Data elements used during application selection that are not specified in Annex B are outside the scope of these specifications.

10.1 File Structure The file organisation applying to this specification is deduced from and complies with the basic organisations as defined in ISO/IEC 7816-4. This section describes the file structure of applications conforming to this specification. The files within the ICC are seen from the terminal as a tree structure. Every branch of the tree is an Application Definition File (ADF) or a Directory Definition File (DDF). An ADF is the entry point to one or more Application Elementary Files (AEFs). An ADF and its related data files are seen as being on the same branch of the tree. A DDF is an entry point to AEFs, ADFs, or other DDFs.

10.1.1 Application Definition Files The tree structure of ADFs:

  • Enables the attachment of data files to an application.
  • Ensures the separation between applications.
  • Allows access to the logical structure of an application by its selection. An ADF is seen from the terminal as a file containing only data objects encapsulated in its file control information (FCI) as shown in Table 10.

10.1.2 Application Elementary Files The structure and use of AEFs is application dependent. For the EMV Debit/Credit application, the files are described in Book 3. October 2022

Requirements 10 Files 10.1 File Structure 10.1.3 Mapping of Files onto ISO/IEC 7816-4 File Structure The following mapping onto ISO/IEC 7816-4 applies:

  • A dedicated file (DF) as defined in ISO/IEC 7816-4 and containing a FCI is mapped onto an ADF or a DDF. It may give access to elementary files and DFs. The DF at the highest level of the card is the master file (MF).
  • An elementary file (EF) as defined in ISO/IEC 7816-4 is mapped onto the AEF. An EF is never used as an entry point to another file. If DFs are embedded, retrieval of the attached EF is transparent to this specification.

10.1.4 Directory Structure When the Payment System Environment (PSE) as described in section 12.2.2 is present, the ICC shall maintain a directory structure for the list of applications within the PSE that the issuer wants to be selected by a directory. In that case, the applications are listed in a Payment System Directory file (DIR file), the location of which is indicated in the FCI of the PSE DDF. The directory structure allows for retrieval of an application using its ADF Name. The location of the DIR file shall be coded in the response message to the selection of the PSE (see the SELECT command). The DIR file is an AEF (in other words, an EF) with a record structure according to this specification including the following data objects according to ISO/IEC 7816-4:

  • One or more records that each contains one or more Application Templates (tag '61') containing an ADF directory entry, that is, DF Name (see Table 11).
  • Optionally, other data objects present within a Directory Discretionary Template (tag '73'). The data objects contained in this template are outside the scope of this specification. Directories are optional within an ICC, and when present there is no defined limit to the number of such directories that may exist. Each such directory is located by a directory SFI data object contained in the FCI of each DDF. October 2022 Requirements 10 Files 10.2 File Referencing 10.2 File Referencing A file may be referred to by a name or a SFI depending on its type.

10.2.1 Referencing by Name Any ADF or DDF in the card is referenced by its DF Name. A DF Name for an ADF corresponds to the AID or contains the AID as the beginning of the DF Name. Each DF Name shall be unique within a given card. A DF Name shall not be a substring of another DF Name on the card.

10.2.2 Referencing by SFI SFIs are used for the selection of AEFs

Any AEF within a given application is referenced by a SFI coded on 5 bits in the range 1 to 30. The coding of the SFI is described in every command that uses it. A SFI shall be unique within an application. October 2022

Requirements 11 Commands 11.1 Message Structure Messages are transported between the terminal and the card according to the transmission protocol selected at the ATR (see EMV Contact Interface Specification). The terminal and the card shall also implement the physical, data link, and transport layers as defined in EMV Contact Interface Specification. To run an application, an additional layer called application protocol is implemented in the terminal. It includes steps consisting of sending a command to the card, processing it in the card, and sending back the response to the terminal. All commands and responses referred to in the remainder of this Book are defined at the application layer. The command message sent from the application layer and the response message returned by the card to the application layer are called Application Protocol Data Units (APDU). A specific response corresponds to a specific command. These are referred to as APDU command-response pairs. In an APDU command-response pair, the command message and the response message may contain data. This section describes the structure of the APDU command-response pairs necessary to the application protocols defined in this specification. This Book describes only those commands necessary to the functioning of application selection. All other commands shall be implemented as required by specific applications, but shall conform to the APDU structures (formats) defined in Book 3 Part II. October 2022

Requirements 11 Commands 11.1 Message Structure 11.1.1 Command APDU Format The command APDU consists of a mandatory header of four bytes followed by a conditional body of variable length, as shown in Figure 1: CLA INS P1 P2 Lc Data Le ← Mandatory Header → ← Conditional Body → Figure 1: Command APDU Structure The number of data bytes sent in the command APDU is denoted by Lc (length of command data field). The maximum number of data bytes expected in the response APDU is denoted by Le (length of expected data). When Le is present and contains the value zero, the maximum number of data bytes available (≤ 256) is requested. READ RECORD and SELECT commands issued during application selection and all case 2 and case 4 commands issued according to Book 3 shall have Le = '00'. The content of a command APDU message is as shown in Table 1: Code CLA INS P1 P2 Lc Data Le

Description

Class of instruction Instruction code Instruction parameter 1 Instruction parameter 2 Number of bytes present in command data field String of data bytes sent in command (= Lc) Maximum number of data bytes expected in data field of response Length 1 1 1 1 0 or 1 var. 0 or 1 Table 1: Command APDU Content The different cases of command APDU structure are described in EMV Contact Interface Specification. October 2022

Requirements 11 Commands 11.2 READ RECORD Command-Response APDUs 11.1.2 Response APDU Format The response APDU format consists of a conditional body of variable length followed by a mandatory trailer of two bytes, as shown in Figure 2: Data SW1 SW2 ← Body → ← Trailer → Figure 2: Response APDU Structure The number of data bytes received in the response APDU is denoted by Lr (length of response data field). Lr is not returned by the transport layer. The application layer may rely on the object oriented structure of the response message data field to calculate Lr if needed. The trailer indicates in two bytes the processing state of the command as returned by the transport layer. The content of a response APDU message is as shown in Table 2: Code Data SW1 SW2 Description String of data bytes received in response Command processing status Command processing qualifier Table 2: Response APDU Content Length var(= Lr) 1 1 11.2 READ RECORD Command-Response APDUs 11.2.1 Definition and Scope The READ RECORD command reads a file record in a linear file. The response from the ICC consists of returning the record. October 2022

Requirements 11 Commands 11.2 READ RECORD Command-Response APDUs 11.2.2 Command Message The READ RECORD command message is coded according to Table 3: Code CLA INS P1 P2 Lc Data Le Value '00' 'B2' Record number Reference control parameter (see Table 4) Not present Not present '00' Table 3: READ RECORD Command Message Table 4 defines the reference control parameter of the command message: b8 b7 b6 b5 b4 b3 b2 b1 Meaning xxx x x SFI 1 0 0 P1 is a record number Table 4: READ RECORD Command Reference Control Parameter 11.2.3 Data Field Sent in the Command Message The data field of the command message is not present.

11.2.4 Data Field Returned in the Response Message The data field of the response message of any successful READ RECORD command contains the record read. Records read during application selection are directory records which are formatted as in section 12.2.3. The format of records read during application processing is application dependent.

11.2.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. October 2022

Requirements 11 Commands 11.3 SELECT Command-Response APDUs 11.3 SELECT Command-Response APDUs 11.3.1 Definition and Scope The SELECT command is used to select the PSE, a DDF, or an ADF corresponding to the submitted file name or AID. The selection of an application is described in section 12. A successful execution of the command sets the path to the PSE, DDF, or ADF. Subsequent commands apply to AEFs associated with the selected PSE, DDF, or ADF using SFIs. The response from the ICC consists of returning the FCI.

11.3.2 Command Message The SELECT command message is coded according to Table 5: Code CLA INS P1 P2 Lc Data Le Value '00' 'A4' Reference control parameter (see Table 6) Selection options (see Table 7) '05'–'10' File name '00' Table 5: SELECT Command Message October 2022

Requirements 11 Commands 11.3 SELECT Command-Response APDUs Table 6 defines the reference control parameter of the SELECT command message: b8 b7 b6 b5 b4 b3 b2 b1 Meaning 000 0 0 1 Select by name 0 0 Table 6: SELECT Command Reference Control Parameter Table 7 defines the selection options P2 of the SELECT command message: b8 b7 b6 b5 b4 b3 b2 b1 Meaning 0 0 First or only occurrence 1 0 Next occurrence Table 7: SELECT Command Options Parameter 11.3.3 Data Field Sent in the Command Message The data field of the command message contains the PSE name or the AID to be selected. During final selection of the application to be used, the data field shall be the DF Name if List of AIDs selection has been used, or ADF Name if PSE selection has been used.

11.3.4 Data Field Returned in the Response Message The data field of the response message contains the FCI specific to the selected PSE, DDF, or ADF. The tags defined in Table 8, Table 9, and Table 10 apply to this specification. No additional data elements shall be present in the FCI template (tag '6F') returned in the response to the SELECT command other than those contained in template 'BF0C'. Padding is not allowed within the FCI returned by the card. Terminals shall accept and correctly parse an FCI containing padding unless the FCI would be rejected due to other errors. Data elements present in templates '6F' and/or 'BF0C' that are not expected or understood by the terminal because the terminal does not support any issuer-specific processing shall be ignored. Table 8 defines the FCI returned by a successful selection of the PSE: October 2022

Requirements 11 Commands 11.3 SELECT Command-Response APDUs Tag Value Presence '6F' FCI Template M '84' DF Name M 'A5' FCI Proprietary Template M '88' SFI of the Directory Elementary File M '5F2D' Language Preference O '9F11' Issuer Code Table Index O 'BF0C' FCI Issuer Discretionary Data O 'XXXX' 1 or more additional proprietary O (Tag constructed according to Book 3 Annex B) data elements from an application provider, issuer, or IC card supplier, or EMV-defined tags that are specifically allocated to 'BF0C' Table 8: SELECT Response Message Data Field (FCI) of the PSE Table 9 defines the FCI returned by a successful selection of a DDF: Tag Value Presence '6F' FCI Template M '84' DF Name M 'A5' FCI Proprietary Template M '88' SFI of the Directory Elementary File M 'BF0C' FCI Issuer Discretionary Data O 'XXXX' 1 or more additional proprietary O (Tag constructed according to Book 3 Annex B) data elements from an application provider, issuer, or IC card supplier, or EMVdefined tags that are specifically allocated to 'BF0C' Table 9: SELECT Response Message Data Field (FCI) of a DDF October 2022

Requirements 11 Commands 11.3 SELECT Command-Response APDUs Table 10 defines the FCI returned by a successful selection of an ADF: Tag Value Presence '6F' FCI Template M '84' DF Name M 'A5' FCI Proprietary Template M '50' Application Label M '87' Application Priority Indicator O '9F38' PDOL O '5F2D' Language Preference O '9F11' Issuer Code Table Index O '9F12' Application Preferred Name O 'BF0C' FCI Issuer Discretionary Data O '9F4D' Log Entry O '9F0A' Application Selection O Registered Proprietary Data 'XXXX' 1 or more additional proprietary O (Tag constructed according to Book 3 Annex B) data elements from an application provider, issuer, or IC card supplier, or EMV-defined tags that are specifically allocated to 'BF0C' Table 10: SELECT Response Message Data Field (FCI) of an ADF October 2022

Requirements 11 Commands 11.3 SELECT Command-Response APDUs 11.3.5 Processing State Returned in the Response Message '9000' indicates a successful execution of the command. ICC support for the selection of a DF using only a partial DF Name is not mandatory. However, if the ICC does support partial name selection, it shall comply with the following:

  • If, after a DF has been successfully selected, the terminal repeats the SELECT command having P2 set to the Next Occurrence option (see Table 7) and with the same partial DF Name, the card shall select a different DF matching the partial name, if another such DF exists.
  • Repeated issuing of the same command with no intervening application level commands shall retrieve all such files, but shall retrieve no file twice.
  • After all matching DFs have been selected, repeating the same command again shall result in no file being selected, and the card shall respond with SW1 SW2 = '6A82' (file not found). October 2022 Requirements 12 Application Selection 12.1 Overview of Application Selection During an EMV card session as defined in EMV Contact Interface Specification, application selection using the commands and techniques described in sections 11 and 12 shall be the first process performed immediately after contact activation/reset of the card and prior to the first application function. If a proprietary processing session (including any proprietary application selection method) is performed immediately before or after an EMV card session, there is no requirement to remove/reinsert the card between the sessions. However, if proprietary processing occurs before the EMV card session, the card contacts shall be deactivated before starting the EMV card session. This section describes the application selection process from the standpoint of both the card and the terminal. It specifies the logical structure of data and files within the card that are required for the process, and then describes the terminal logic using the card structure. It is not recommended that the ICC and the terminal use implicit selection as defined in ISO 7816, as it is not useful in an interchange environment. If used, it shall be performed outside the EMV card session as defined in EMV Contact Interface Specification. The application selection process described in this section is the process by which the terminal uses data in the ICC according to protocols defined herein to determine the terminal program and the ICC application to be used in processing a transaction. The process is described in two steps: 1. Create a list of ICC applications that are supported by the terminal. (This list is referred to below using the name ‘candidate list’.) This process is described in section 12.3. 2. Select the application to be run from the list generated above. This process is described in section 12.4. This section of the specification describes the necessary information in the card and two terminal selection algorithms that yield the correct results. Other terminal selection algorithms that yield the same results are permitted in place of the selection algorithms described here. October 2022 Requirements 12 Application Selection 12.1 Overview of Application Selection A payment system application is comprised of the following:
  • A set of files in the ICC providing data customised by the issuer
  • Data in the terminal provided by the acquirer or the merchant
  • An application protocol agreed upon by both the ICC and the terminal Applications supported by the terminal are identified by AIDs conforming to ISO/IEC 7816-4. Applications supported by the ICC are identified by DF Names conforming to ISO/IEC 7816-4. For further details see section 12.2.1 below). The techniques chosen by the payment systems and described herein are designed to meet the following key ob

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