PCI Watch

Tracking changes across the Payment Card Industry

Book 2 – Security and Key Management

v4.4 Specifications
Contact Acceptance Device

EMV® Integrated Circuit Card Specifications for Payment Systems Book 2 Security and Key Management 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 2 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. 104: Issuer guidance on TVR bit setting for CDA Specification Bulletin no. 137: CDA Specification Bulletin no. 144: Terminal Unpredictable Number generation Specification Bulletin no. 162: AES Key Derivation Erratum Specification Bulletin no. 163: Changes to PIN Pad requirements Specification Bulletin no. 178, Third Edition: Tokenisation Data Objects – Payment Account Reference (PAR) Specification Bulletin no. 185, Second Edition: Biometric Terminal Specification Specification Bulletin no. 208: Clarification of Maximum Public Key Lengths 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 13 2 Normative References 14 3 Definitions 17 4 Abbreviations, Notations, Conventions, and Terminology 25 4.1 Abbreviations 25 4.2 Notations 32 4.3 Data Element Format Conventions 34 4.4 Terminology 35 Part II – Security and Key Management Techniques 5 Static Data Authentication (SDA) 37 5.1 Keys and Certificates 39 5.1.1 Static Data to be Authenticated 42 5.1.2 Certification Revocation List 43 5.2 Retrieval of Certification Authority Public Key 44 5.3 Retrieval of Issuer Public Key 44 5.4 Verification of Signed Static Application Data 47 6 Offline Dynamic Data Authentication (DDA, CDA) 49 6.1 Keys and Certificates 53 6.1.1 Static Data To Be Authenticated 56 6.1.2 Certification Revocation List 56 6.2 Retrieval of Certification Authority Public Key 57 6.3 Retrieval of Issuer Public Key 57 6.4 Retrieval of ICC Public Key 59 6.5 Dynamic Data Authentication (DDA) 61 6.5.1 Dynamic Signature Generation 61 6.5.2 Dynamic Signature Verification 63 6.6 Combined DDA/Application Cryptogram Generation (CDA) 65 October 2022

©

6.6.1 Dynamic Signature Generation 66 6.6.2 Dynamic Signature Verification 69 6.6.3 Sample CDA Flow 72 7 PIN and Biometric Data Encipherment Using RSA 76 7.1 Keys and Certificates 77 7.2 PIN Encipherment and Verification 80 7.3 Biometric Data Encipherment and Recovery 82 8 Application Cryptogram and Issuer Authentication 86 8.1 Application Cryptogram Generation 86 8.1.1 Data Selection 86 8.1.2 Application Cryptogram Algorithm 87 8.2 Issuer Authentication 88 8.2.1 ARPC Method 1 88 8.2.2 ARPC Method 2 89 8.3 Key Management 89 9 Secure Messaging 90 9.1 Secure Messaging Format 90 9.2 Secure Messaging for Integrity and Authentication 90 9.2.1 Command Data Field 90 9.2.2 MAC Session Key Derivation 92 9.2.3 MAC Computation 92 9.3 Secure Messaging for Confidentiality 94 9.3.1 Command Data Field 94 9.3.2 Encipherment Session Key Derivation 94 9.3.3 Encipherment/Decipherment 95 9.4 Key Management 95 10 CA Public Key Management Principles and Policies 96 11 Terminal Security and Key Management Requirements 97 11.1 Security Requirements for PIN Pads 97 11.2 Key Management Requirements 97 11.2.1 Certification Authority Public Key Introduction 97 11.2.2 Certification Authority Public Key Storage 100 11.2.3 Certification Authority Public Key Withdrawal 102 11.3 Unpredictable Number Generation 104 12 Offline Dynamic Data Authentication Using ECC (XDA) 106 12.1 Keys and Certificates 108 12.1.1 Certification Revocation List 109 12.2 Retrieval of Certification Authority Public Key 110 12.3 Authentication and Recovery of Issuer Public Key 111 October 2022

©

12.4 Authentication and Recovery of ICC Public Key 114 12.5 XDA Signature Generation and Verification 118 12.5.1 Requesting, Generating, and Verifying an XDA Signature 118 12.5.2 Dynamic Signature Generation 118 12.5.3 Dynamic Signature Verification 121 12.5.4 Sample XDA Flow 121 13 Offline Data Encipherment Using ECC 124 13.1 Keys and Certificates 124 13.2 PIN Encipherment 125 13.3 PIN Decipherment and Verification 127 13.4 Biometric Data Encipherment 128 13.5 Biometric Data Decipherment and Recovery 131 Part III – Annexes Annex A Security Mechanisms 133 A1 Symmetric Mechanisms 133 A1.1 Encipherment 133 A1.2 Message Authentication Code 134 A1.3 Session Key Derivation 137 A1.4 Master Key Derivation 138 A2 Asymmetric Mechanisms 141 A2.1 Digital Signature Scheme Using RSA 141 A2.2 Digital Signature Scheme Using ECC 143 A2.3 Encryption Scheme Using ECC 145 Annex B Approved Cryptographic Algorithms 151 B1 Symmetric Algorithms 151 B1.1 Data Encryption Standard (DES) 8-byte block cipher 151 B1.2 Advanced Encryption Standard (AES) 16-byte block cipher 151 B2 Asymmetric Algorithms 152 B2.1 RSA Algorithm 152 B2.2 Elliptic Curve Cryptography (ECC) 154 B2.3 Hash Algorithms (for ECC) 161 B2.4 Cryptographic Algorithm Suites (for ECC) 163 B2.5 Random Number Generation (for ECC) 164 B2.6 Integer Conversion Functions (for ECC) 165 B3 Hashing Algorithms (for RSA) 168 B3.1 Secure Hash Algorithm (SHA-1) 168 Annex C Informative References 169 October 2022

©

Annex D Implementation Considerations 170 D1 Issuer and ICC RSA Public Key Length Considerations 170 D1.1 Issuer Public Key Restriction 170 D1.2 ICC Public Key Restriction 171 D2 Format 1 Secure Messaging Illustration 173 D2.1 Securing the Command APDU 173 D2.2 Encipherment 176 D2.3 MAC Computation 176 D3 Application Transaction Counter Considerations 178 D4 CDA Modes 179 Part IV – Common Core

Definitions

Common Core Definitions 183 Changed Sections 183 6 Offline Dynamic Data Authentication 183 6.5 Dynamic Data Authentication (DDA) 183 6.6 Combined DDA/Application Cryptogram Generation (CDA) 184 8 Application Cryptogram and Issuer Authentication 185 8.1 Application Cryptogram Generation 185 8.2 Issuer Authentication 186 8.3 Key Management 186 9 Secure Messaging 187 9.1 Secure Messaging Format 187 9.2 Secure Messaging for Integrity and Authentication 187 9.3 Secure Messaging for Confidentiality 188 9.4 Key Management 188 Index 189 October 2022

©

Tables Table 1: Required ICC Data Elements for SDA 38 Table 2: Issuer Public Key Data To Be Signed by Certification Authority 40 Table 3: Static Application Data To Be Signed by Issuer 41 Table 4: Data Objects Required for SDA 42 Table 5: Minimum Data for Certificate Revocation List Entry 43 Table 6: Format of Data Recovered from Issuer Public Key Certificate 45 Table 7: Format of Data Recovered from Signed Static Application Data 47 Table 8: Required ICC Data Elements for Offline Dynamic Data Authentication 51 Table 9: Data Element Generated for Offline Dynamic Data Authentication 52 Table 10: Issuer Public Key Data To Be Signed by Certification Authority 54 Table 11: ICC Public Key Data To Be Signed by Issuer 55 Table 12: Data Objects Required for Public Key Authentication for Offline Dynamic Data Authentication 56 Table 13: Format of Data Recovered from Issuer Public Key Certificate 58 Table 14: Format of Data Recovered from ICC Public Key Certificate 60 Table 15: Dynamic Application Data To Be Signed 62 Table 16: Additional Data Objects Required for Dynamic Signature Generation and Verification 63 Table 17: Format of Data Recovered from Signed Dynamic Application Data 64 Table 18: Dynamic Application Data To Be Signed 68 Table 19: 32-38 Leftmost Bytes of ICC Dynamic Data 68 Table 20: Data Objects Included in Response to GENERATE AC for TC or ARQC 69 Table 21: Data Objects Included in Response to GENERATE AC for AAC 69 Table 22: Format of Data Recovered from Signed Dynamic Application Data 70 Table 23: ICC PIN Encipherment Public Key Data To Be Signed by Issuer 78 Table 24: Data Objects Required for Retrieval of ICC PIN Encipherment Public Key 79 Table 25: Data To Be Enciphered for PIN Encipherment 80 Table 26: Data To Be Enciphered for Biometric Encipherment 83 Table 27: Biometric Verification Data Template 84 Table 28: Recommended Minimum Set of Data Elements for Application Cryptogram Generation 87 Table 29: ECC Self-Signed Certification Authority Public Key & Related Data (Binary Encoding) 99 Table 30: Minimum Set of Certification Authority Public Key Related Data Elements To Be Stored in Terminal (RSA) 101 Table 31: Minimum Set of Certification Authority Public Key Related Data Elements To Be Stored in Terminal (ECC) 102 Table 32: Data Elements Used to Generate Terminal Unpredictable Number (UN) 104 Table 33: Data Element Generated for XDA 107 Table 34: ICC Data Required for Public Key Authentication for XDA and ECC ODE 109 Table 35: Issuer Public Key Certificate Tag '90' (ECC) 112 Table 36: ICC Public Key Certificate Tag '9F46' (XDA) and Tag '9F2D' (ODE) 115 Table 37: Dynamic Application Data To Be Signed (XDA) 119 Table 38: Format of XDA Signed Dynamic Application Data 120 October 2022

©

Table 39: Data Objects Included in Response to GENERATE AC with XDA Signature 120 Table 40: Data To Be Enciphered for PIN Encipherment (ECC) 126 Table 41: Data To Be Enciphered for Biometric Encipherment 129 Table 42: Biometric Verification Data Template 130 Table 43: Upper Bounds for Size of Moduli 152 Table 44: Selected Elliptic Curves 158 Table 45: Parameters of Curve P-256 158 Table 46: Parameters of Curve P-521 159 Table 47: Recognised Hash Algorithms 161 Table 48: Cryptographic Algorithm Suite Indicators for ECC Signatures 163 Table 49: Cryptographic Algorithm Suite Indicators for Offline Data Encipherment (e.g. for PIN or Biometrics) 164 Table 50: Data Lengths in GENERATE AC Response 171 Table 51: CDA Modes 179 Table CCD 1: Data Objects in Response to GENERATE AC for TC or ARQC 184 Table CCD 2: Data Objects in Response to GENERATE AC for AAC 184 Table CCD 3: Data Elements for Application Cryptogram Generation 185 October 2022

©

Figures Figure 1: Diagram of SDA 37 Figure 2: Diagram of Offline Dynamic Data Authentication 50 Figure 3: CDA Sample Flow Part 1 of 3 73 Figure 4: CDA Sample Flow Part 2 of 3 74 Figure 5: CDA Sample Flow Part 3 of 3 75 Figure 6: Format 1 Command Data Field for Secure Messaging for Integrity and Authentication 91 Figure 7: Format 2 Command Data Field for Secure Messaging for Integrity and Authentication 91 Figure 8: Format 1 – Data Object for Confidentiality 94 Figure 9: Format 2 Command Data Field for Secure Messaging for Confidentiality 94 Figure 10: ECC Self-signed Certification Authority Public Key Diagram 98 Figure 11: Diagram of Offline Dynamic Data Authentication 106 Figure 12: XDA Sample Flow Part 1 of 2 122 Figure 13: XDA Sample Flow Part 2 of 2 123 Figure 14: Decimalisation for Master Key Derivation 139 October 2022

©

Part I General October 2022

©

1

Scope

This document, the Integrated Circuit Card (ICC) Specifications for Payment Systems – Book 2, Security and Key Management, describes the minimum security functionality required of integrated circuit cards (ICCs) and terminals to ensure correct operation and interoperability. Additional requirements and recommendations are provided with respect to the on-line communication between ICC and issuer and the management of cryptographic keys at terminal, issuer, and payment system level. The Integrated Circuit Card Specifications for Payment Systems includes the following additional documents, all available on http://www.emvco.com:

  • Book 1 – Application Independent ICC to Terminal Interface Requirements
  • Book 3 – Application Specification
  • Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements EMVCo also publishes security guidelines (see informative references 3 and 5).

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 2 consists of the following parts: Part I Part II Part III Part IV – General – Security and Key Management Techniques – Annexes – Common Core Definitions Part I includes this introduction, as well as information applicable to all Books: normative references, definitions, abbreviations, notations, data element format convention, and terminology. October 2022

©

1 Scope 1.3 Underlying Standards Part II covers:

  • Offline static data authentication (SDA)
  • Offline dynamic data authentication (DDA and CDA and XDA)
  • Offline PIN encipherment
  • Application cryptogram generation and issuer authentication
  • Secure messaging
  • Public key management principles and policies
  • Terminal security and key management requirements Part III (Annexes A-D) specifies the security mechanisms and the approved cryptographic algorithms required to implement the security functions specified, provides a list of informative references, and discusses implementation considerations. Part IV 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

©

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

©

2 Normative References ISO/IEC 14888-3 ISO/IEC 15946-1 ISO/IEC 15946-5 ISO 16609 ISO/IEC 18031 ISO/IEC 18033-2 ISO/IEC 18033-3 ISO/IEC 19772 ISO/IEC 19785-3 ISO/IEC 19794 ISO/IEC 19794-2 SEC 1 Information technology – Security techniques – Digital signatures with appendix — Part 3: Discrete logarithm based mechanisms Information technology – Security techniques – Cryptographic techniques based on elliptic curves — Part 1: General Information technology – Security techniques – Cryptographic techniques based on elliptic curves — Part 5: Elliptic curve generation Banking – Requirements for message authentication using symmetric techniques Information technology – Security techniques – Random bit generation Information technology – Security techniques – Encryption algorithms – Part 2: Asymmetric ciphers Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers Information technology – Security techniques – Authenticated encryption Information technology – Common Biometric Exchange Formats Framework – Patron format specifications Information technology – Biometric data interchange formats Information technology – Biometric data interchange formats – Part 2: Finger minutiae data 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 Cryptogram Cryptographic Algorithm Data Integrity Decipherment DEM1 Digital Signature Dynamic Data Authentication Elliptic Curve Cryptography Encipherment Exclusive-OR Extended Data Authentication Facial Verification Financial Transaction A conducting element ensuring galvanic continuity between integrated circuit(s) and external interfacing equipment. Result of a cryptographic operation. An algorithm that transforms data in order to hide or reveal its information content. The property that data has not been altered or destroyed in an unauthorised manner. The reversal of a corresponding encipherment. A family of data encapsulation mechanisms defined in ISO/IEC 18033-2. 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. A form of offline dynamic data authentication Public key cryptography based on the algebraic structure of elliptic curves over finite fields. The reversible transformation of data by a cryptographic algorithm to produce ciphertext. Binary addition with no carry, giving the following values: 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = 0 A form of offline dynamic data authentication. The process of determining that the face presented is valid. 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 Function Hash Function Hash Result I2OSP Integrated Circuit(s) Integrated Circuit(s) Card Interface Device Iris Verification Issuer Action Code The process of determining that the finger presented is valid. A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. A function that maps strings of bits to fixed-length strings of bits, satisfying the following two properties:
  • It is computationally infeasible to find for a given output an input which maps to this output.
  • It is computationally infeasible to find for a given input a second input that maps to the same output. Additionally, if the hash function is required to be collision-resistant, it must also satisfy the following property:
  • It is computationally infeasible to find any two distinct inputs that map to the same output. The string of bits that is the output of a hash function. An integer to octet string conversion primitive function defined in ISO/IEC 18033-2. Electronic component(s) designed to perform processing and/or memory functions. A card into which one or more integrated circuits are inserted to perform processing and memory functions. That part of a terminal into which the ICC is inserted, including such mechanical and electrical devices as may be considered part of it. The process of determining that the iris presented is valid. 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 Key Key

Introduction

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

©

3 Definitions Path Payment System Environment Physical Compromise PIN Pad Plaintext Potential Compromise Private Key Public Key Public Key Certificate Response RSA-KEM RSATransform Concatenation of file identifiers without delimitation. 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. 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. Arrangement of numeric and command keys to be used for personal identification number (PIN) entry. Also known as a “PIN Entry Device” (PED). Unenciphered information. 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. 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. That key of an entity’s asymmetric key pair that can be made public. In the case of a digital signature scheme, the public key defines the verification function. The public key information of an entity signed by the certification authority and thereby rendered unforgeable. A message returned by the ICC to the terminal after the processing of a command message received by the ICC. A family of key encapsulation mechanisms defined in ISO/IEC 18033-2. 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 NF 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 Norme Française October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations 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 RFU RID 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 Reserved for Future Use Registered Application Provider Identifier October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations 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 var. XDA 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 Variable (see section 4.3) Extended Data Authentication October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.1 Abbreviations YYMM YYMMDD 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' xx A:= B A = B A ≡ B mod n A mod n A / n Y:= ALG(K)[X] X = ALG-1(K)[Y] Y:= Sign (SK)[X] X = Recover(PK)[Y] C:= (A || B) Leftmost Rightmost 16 hexadecimal characters Any value A is assigned the value of B Value of A is equal to the value of B Integers A and B are congruent modulo the integer n, that is, there exists an integer d such that (A – B) = dn The reduction of the integer A modulo the integer n, that is, the unique integer r, 0 ≤ r &lt; n, for which there exists an integer d such that A = dn + r 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 Encipherment of a data block X with a block cipher as specified in section A1, using a secret key K Decipherment of a data block Y with a block cipher as specified in section A1, using a secret key K The signing of a data block X with an asymmetric reversible algorithm as specified in section A2, using the private key SK The recovery of the data block X with an asymmetric reversible algorithm as specified in section A2, using the public key PK The concatenation of an n-bit number A and an m-bit number B, which is defined as C = 2m A + B. Applies to a sequence of bits, bytes, or digits and used interchangeably with the term “most significant”. If C = (A || B) as above, then A is the leftmost n bits of C. Applies to a sequence of bits, bytes, or digits and used interchangeably with the term “least significant”. If C = (A || B) as above, then B is the rightmost m bits of C. October 2022 © 4 Abbreviations, Notations, Conventions, and Terminology 4.2 Notations H:= Hash[MSG] X ⊕ Y MIN (x, y) Hashing of a message MSG of arbitrary length using a 160-bit hash function 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. 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 Security and Key Management Techniques October 2022 © 5 Static Data Authentication (SDA) This section describes SDA, an offline data authentication mechanism that utilises RSA public key cryptography. Offline static data authentication is performed by the terminal using a digital signature scheme based on public key techniques to confirm the legitimacy of critical ICC-resident static data. This detects unauthorised alteration of data after personalisation. The only form of offline static data authentication defined is Static Data Authentication (SDA) that verifies the data identified by the Application File Locator (AFL) and by the optional Static Data Authentication Tag List. SDA requires the existence of a certification authority, which is a highly secure cryptographic facility that ‘signs’ the issuer’s public keys. Every terminal conforming to this specification shall contain the appropriate certification authority’s public key(s) for every application recognised by the terminal. This specification permits multiple AIDs to share the same ‘set’ of Certification Authority Public Keys. The relationship between the data and the cryptographic keys is shown in Figure 1. Static application data Issuer Private Key (Issuer) S I Public Key (Issuer) P I Certification Authority Private Key (CA) S CA Public Key (CA) PCA Acquirer Distributed to Acquirer (Resides in Terminal) Signed Static Application Data (SSAD) Issuer PK Certificate Issuer PK Certificate IC Card IC Terminal Issuer PK Certificate and SSAD Card provides to Terminal:  Issuer PK Certificate (PI signed by CA using SCA)  Signed Static Application Data (SSAD) (signed by the Issuer using SI) Terminal:  Uses PCA to verify that the Issuer’s PI was signed by the CA  Uses PI to verify that the Card’s SSAD was signed by the Issuer Figure 1: Diagram of SDA ICCs that support SDA shall contain the data elements listed in Table 1: October 2022 © 5 Static Data Authentication (SDA) Required Data Element Certification Authority Public Key Index Issuer Public Key Certificate Signed Static Application Data Issuer Public Key Remainder Issuer Public Key Exponent Length 1 var. var. var. var.

Description

Contains a binary number that indicates which of the application’s Certification Authority Public Keys and its associated algorithm that reside in the terminal is to be used with this ICC. Provided by the appropriate certification authority to the card issuer. When the terminal verifies this data element, it authenticates the Issuer Public Key plus additional data as described in section 5.3. Generated by the issuer using the private key that corresponds to the public key authenticated in the Issuer Public Key Certificate. It is a digital signature covering critical ICC-resident static data elements, as described in section 5.4. The presence of this data element in the ICC is conditional. See section 5.1 for further explanation. Provided by the issuer. See section 5.1 for further explanation. Table 1: Required ICC Data Elements for SDA To support SDA, each terminal shall be able to store six Certification Authority Public Keys per Registered Application Provider Identifier (RID) and shall associate with each such key the key-related information to be used with the key (so that terminals can in the future support multiple algorithms and allow an evolutionary transition from one to another, as discussed in section 11.2.2). The terminal shall be able to locate any such key (and the key-related information) given the RID and Certification Authority Public Key Index as provided by the ICC. SDA shall use a reversible algorithm as specified in section A2.1 and section B2. Section 5.1 contains an overview of the keys and certificates involved in the SDA process, and sections 5.2 to 5.4 specify the three main steps in the process, namely:

  • Retrieval of the Certification Authority Public Key by the terminal
  • Retrieval of the Issuer Public Key by the terminal
  • Verification of the Signed Static Application Data by the terminal If SDA fails then the terminal shall set the ‘SDA failed’ bit in the Terminal Verification Results (TVR) to 1. October 2022 © 5 Static Data Authentication (SDA) 5.1 Keys and Certificates 5.1 Keys and Certificates To support SDA, an ICC shall contain the Signed Static Application Data, which is signed with the Issuer Private Key. The Issuer Public Key shall be stored on the ICC with a public key certificate. The bit length of all moduli shall be a multiple of 8, the leftmost bit of its leftmost byte being 1. All lengths are given in bytes. The signature scheme specified in section A2.1 is applied to the data specified in Table 2 using the Certification Authority Private Key SCA in order to obtain the Issuer Public Key Certificate. The public key pair of the certification authority has a public key modulus of NCA bytes, where NCA ≤ 248. The Certification Authority Public Key Exponent shall be equal to 3 or 216 + 1. The signature scheme specified in section A2.1 is applied to the data specified in Table 3 using the Issuer Private Key SI in order to obtain the Signed Static Application Data. The public key pair of the issuer has an Issuer Public Key Modulus of NI bytes, where NI ≤ NCA ≤ 248. If NI > (NCA − 36), the Issuer Public Key Modulus is split into two parts, namely:
  • the Leftmost Digits of the Issuer Public Key, consisting of the NCA − 36 most significant bytes of the modulus, and
  • the Issuer Public Key Remainder, consisting of the remaining NI − (NCA − 36) least significant bytes of the modulus. The Issuer Public Key Exponent shall be equal to 3 or 216 + 1. All the information necessary for SDA is specified in Table 4 and stored in the ICC. With the exception of the RID, which can be obtained from the Application Identifier (AID; see Book 1 section 12.2.1), this information may be retrieved with the READ RECORD command. If any of this data is missing, SDA has failed. October 2022 © 5 Static Data Authentication (SDA) 5.1 Keys and Certificates Field Name Certificate Format Issuer Identifier Certificate Expiration Date Certificate Serial Number Hash Algorithm Indicator Issuer Public Key Algorithm Indicator Issuer Public Key Length Issuer Public Key Exponent Length Issuer Public Key or Leftmost Digits of the Issuer Public Key Issuer Public Key Remainder Issuer Public Key Exponent Length 1 4 2 3 1 1 1 1 NCA – 36 0 or NI – NCA + 36 1 or 3 Description Hex value '02' Leftmost 3-8 digits from the Primary Account Number (PAN) (padded to the right with Hex 'F's) MMYY after which this certificate is invalid Binary number unique to this certificate assigned by the certification authority Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme 1 Identifies the digital signature algorithm to be used with the Issuer Public Key 1 Identifies the length of the Issuer Public Key Modulus in bytes Identifies the length of the Issuer Public Key Exponent in bytes If NI ≤ NCA – 36, consists of the full Issuer Public Key padded to the right with NCA – 36 – NI bytes of value 'BB' If NI > NCA – 36, consists of the NCA – 36 most significant bytes of the Issuer Public Key 2 Present only if NI > NCA – 36 and consists of the NI – NCA + 36 least significant bytes of the Issuer Public Key. Issuer Public Key Exponent equal to 3 or 216 + 1 Format b cn 8 n 4 b b b b b b b b Table 2: Issuer Public Key Data To Be Signed by Certification Authority (i.e., input to the hash algorithm) 1 See Annex B for specific values assigned to approved algorithms. 2 As can be seen in section A2.1, NCA − 22 bytes of the data signed are retrieved from the signature. Since the length of the first through the eighth data elements in Table 2 is 14 bytes, there are NCA − 22 − 14 = NCA − 36 bytes remaining in the signature to store the Issuer Public Key Modulus. October 2022 © 5 Static Data Authentication (SDA) 5.1 Keys and Certificates Field Name Signed Data Format Hash Algorithm Indicator Data Authentication Code Pad Pattern Static Data to be Authenticated Length 1 1 2 Description Hex Value '03' Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme 3 Issuer-assigned code NI − 26 var. Pad pattern consisting of NI − 26 bytes of value 'BB' 4 Static data to be authenticated as specified in Book 3 section 10.3 (see also section 5.1.1) Table 3: Static Application Data To Be Signed by Issuer (i.e., input to the hash algorithm) Format b b b b — 3 See Annex B for specific values assigned to approved algorithms. 4 As can be seen in section A2.1, NI − 22 bytes of the data signed are retrieved from the signature. Since the length of the first through the third data elements in Table 3 is 4 bytes, there are NI − 22 − 4 = NI − 26 bytes left for the data to be stored in the signature. October 2022 © 5 Static Data Authentication (SDA) 5.1 Keys and Certificates 5.1.1 Static Data to be Authenticated Input to the authentication process is formed from the records identified by the AFL, followed by the value of the Application Interchange Profile (AIP), if identified by the optional Static Data Authentication Tag List (tag '9F4A'). If present, the Static Data Authentication Tag List shall only contain the tag '82' identifying the AIP. Tag — '8F' '90' '92' '9F32' '93' — Length 5 1 NCA NI – NCA + 36 1 or 3 NI var. Value Registered Application Provider Identifier (RID) Certification Authority Public Key Index Issuer Public Key Certificate Issuer Public Key Remainder, if present Issuer Public Key Exponent Signed Static Application Data Static data to be authenticated as specified in Book 3 section 10.3 (see also section 5.1.1) Table 4: Data Objects Required for SDA Format b b b b b b — October 2022 © 5 Static Data Authentication (SDA) 5.1 Keys and Certificates 5.1.2 Certification Revocation List The terminal may support a Certification Revocation List (CRL) that lists the Issuer Public Key Certificates that payment systems have revoked. If, during SDA, a concatenation of the RID and Certification Authority Public Key Index from the card and the Certificate Serial Number recovered from the Issuer Public Key Certificate is on this list, SDA fails as described in section 5.3 step 10. At a minimum each entry in the CRL shall contain the following data: Name Registered Application Provider Identifier (RID) Certification Authority Public Key Index Certificate Serial Number Additional Data Description Identifiers the application provider Identifies the public key in conjunction with the RID Number unique to this certificate assigned by the certification authority Optional terminal proprietary data, such as the date the certificate was added to the revocation list Format b b b b Length 5 1 3 var. Table 5: Minimum Data for Certificate Revocation List Entry Additional data such as the date the certificate was added to the CRL may be included in the CRL entry. The terminal shall be able to support at least thirty entries in the CRL for each RID for which the terminal has CA Public Keys. The terminal shall be able to update the CRL as requested by the acquirer. The payment systems provide these updates to the acquirer. A reliable method of maintaining the CRL is defined by the terminal vendor and the acquirer and should meet the security requirements of the acquirer. It is the responsibility of the payment system to ensure that the number of revoked certificates does not exceed the maximum number of entries that terminals are required to support and the responsibility of the acquirer to ensure that appropriate entries are deleted in order to make way for new entries. October 2022 © 5 Static Data Authentication (SDA) 5.2 Retrieval of Certification Authority Public Key 5.2 Retrieval of Certification Authority Public Key The terminal reads the Certification Authority Public Key Index. Using this index and the RID, the terminal shall identify and retrieve the terminal-stored Certification Authority Public Key Modulus and Exponent and the associated key-related information, and the corresponding algorithm to be used. If the terminal does not have the key stored associated with this index and RID, SDA has failed.

5.3 Retrieval of Issuer Public Key 1

If the Issuer Public Key Certificate has a length different from the length of the Certification Authority Public Key Modulus obtained in the previous section, SDA has failed. 2. In order to obtain the recovered data specified in Table 6, apply the recovery function specified in section A2.1 to the Issuer Public Key Certificate using the Certification Authority Public Key in conjunction with the corresponding algorithm. If the Recovered Data Trailer is not equal to 'BC', SDA has failed. October 2022

©

5 Static Data Authentication (SDA) 5.3 Retrieval of Issuer Public Key Field Name Recovered Data Header Certificate Format Issuer Identifier Certificate Expiration Date Certificate Serial Number Hash Algorithm Indicator Issuer Public Key Algorithm Indicator Issuer Public Key Length Issuer Public Key Exponent Length Issuer Public Key or Leftmost Digits of the Issuer Public Key Hash Result Recovered Data Trailer Length 1 1 4 2 3 1 1 1 1 NCA −36 20 1 Description Hex Value '6A' Hex Value '02' Leftmost 3-8 digits from the PAN (padded to the right with Hex 'F's) MMYY after which this certificate is invalid Binary number unique to this certificate assigned by the certification authority Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme 5 Identifies the digital signature algorithm to be used with the Issuer Public Key 5 Identifies the length of the Issuer Public Key Modulus in bytes Identifies the length of the Issuer Public Key Exponent in bytes If NI ≤ NCA − 36, consists of the full Issuer Public Key padded to the right with NCA – 36 – NI bytes of value 'BB' If NI > NCA – 36, consists of the NCA – 36 most significant bytes of the Issuer Public Key 6 Hash of the Issuer Public Key and its related information Hex value 'BC' Format b b cn 8 n 4 b b b b b b b b Table 6: Format of Data Recovered from Issuer Public Key Certificate 3. Check the Recovered Data Header. If it is not '6A', SDA has failed. 4. Check the Certificate Format. If it is not '02', SDA has failed. 5 See Annex B for specific values assigned to approved algorithms. 6 As can be seen in section A2.1, NCA − 22 bytes of the data signed are retrieved from the signature. Since the length of the second through the ninth data elements in Table 6 is 14 bytes, there are NCA − 22 − 14 = NCA − 36 bytes left for the data to be stored in the signature. October 2022

©

5 Static Data Authentication (SDA) 5.3 Retrieval of Issuer Public Key 5. Concatenate from left to right the second to the tenth data elements in Table 6 (that is, Certificate Format through Issuer Public Key or Leftmost Digits of the Issuer Public Key), followed by the Issuer Public Key Remainder (if present), and finally the Issuer Public Key Exponent. 6. Apply the indicated hash algorithm (derived from the Hash Algorithm Indicator) to the result of the concatenation of the previous step to produce the hash result. 7. Compare the calculated hash result from the previous step with the recovered Hash Result. If they are not the same, SDA has failed. 8. Verify that the Issuer Identifier matches the leftmost 3-8 PAN digits (allowing for the possible padding of the Issuer Ide

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