PCI Watch

Tracking changes across the Payment Card Industry

Book 2 – Security and Key Management

v4.3 Specifications
Contact Acceptance DeviceCard

EMV Integrated Circuit Card Specifications for Payment Systems Book 2 Security and Key Management Version 4.3 November 2011

EMV®* Integrated Circuit Card Specifications for Payment Systems Book 2 Security and Key Management Version 4.3 November 2011 * EMV is a registered trademark in the U.S. and other countries and an unregistered trademark elsewhere. The EMV trademark is owned by EMVCo.

EMV 4.3 Book 2 Security and Key Management © 2011 EMVCo, LLC (“EMVCo”). All rights reserved. Any and all uses of these Specifications are subject to the terms and conditions of the EMVCo Terms of Use agreement available at www.emvco.com. These Specifications are provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, 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.

November 2011

EMV 4.3 Book 2 Security and Key Management Revision Log

  • Version 4.3 The following changes have been made to Book 2 since the publication of Version 4.2. Numbering and cross references in this version have been updated to reflect changes introduced by the published bulletins. Updated in support of the following Application Notes: Application Note no. 41 Second Edition: Recommendations for CDA Terminals (revised) Incorporated changes described in the following Specification Bulletins: Specification Bulletin no. 74 Second Edition: AES option in EMV Specification Bulletin no. 78: Removal of DDF Entries from PSE Records Specification Bulletin no. 88: Application Selection Updates Specification Bulletin no. 91: AES Support in Common Core Definitions (CCD) Specification Bulletin no. 92: Various Changes to Book 2 November 2011 EMV 4.3 Book 2 Security and Key Management Part I
  • General Contents 1 Scope 3 1.1 Changes in Version 4.3 3 1.2 Structure 4 1.3 Underlying Standards 4 1.4 Audience 5 2 Normative References 7 3 Definitions 11 4 Abbreviations, Notations, Conventions, and Terminology 21 4.1 Abbreviations 21 4.2 Notations 29 4.3 Data Element Format Conventions 31 4.4 Terminology 33 5 Static Data Authentication (SDA) 37 5.1 Keys and Certificates 40 5.1.1 Static Data to be Authenticated 43 5.1.2 Certification Revocation List 43 5.2 Retrieval of Certification Authority Public Key 44 5.3 Retrieval of Issuer Public Key 45 5.4 Verification of Signed Static Application Data 48 6 Offline Dynamic Data Authentication 51 6.1 Keys and Certificates 55 6.1.1 Static Data to be Authenticated 59 6.1.2 Certification Revocation List 59 6.2 Retrieval of Certification Authority Public Key 60 6.3 Retrieval of Issuer Public Key 60 6.4 Retrieval of ICC Public Key 63 6.5 Dynamic Data Authentication (DDA) 66 6.5.1 Dynamic Signature Generation 66 6.5.2 Dynamic Signature Verification 68 6.6 Combined DDA/Application Cryptogram Generation (CDA) 70 6.6.1 Dynamic Signature Generation 71 6.6.2 Dynamic Signature Verification 74 6.6.3 Sample CDA Flow 77 7 Personal Identification Number Encipherment 81 November 2011 EMV 4.3 Book 2 Security and Key Management 7.1 Keys and Certificates 82 7.2 PIN Encipherment and Verification 85 8 Application Cryptogram and Issuer Authentication 87 8.1 Application Cryptogram Generation 88 8.1.1 Data Selection 88 8.1.2 Application Cryptogram Algorithm 89 8.2 Issuer Authentication 89 8.2.1 ARPC Method 1 89 8.2.2 ARPC Method 2 90 8.3 Key Management 92 9 Secure Messaging 93 9.1 Secure Messaging Format 93 9.2 Secure Messaging for Integrity and Authentication 94 9.2.1 Command Data Field 94 9.2.2 MAC Session Key Derivation 95 9.2.3 MAC Computation 96 9.3 Secure Messaging for Confidentiality 97 9.3.1 Command Data Field 97 9.3.2 Encipherment Session Key Derivation 98 9.3.3 Encipherment/Decipherment 98 9.4 Key Management 98 10 Certification Authority Public Key Management Principles and Policies 99 10.1 Certification Authority Public Key Life Cycle 99 10.1.1 Normal Certification Authority Public Key Life Cycle 99 10.1.2 Certification Authority Public Key Pair Compromise 103 10.2 Principles and Policies by Phase 105 10.2.1 General Principles 105 10.2.2 Planning Phase 105 10.2.3 Generation Phase 106 10.2.4 Distribution Phase 107 10.2.5 Key Usage Phase 108 10.2.6 Detection Phase 109 10.2.7 Assessment Phase 110 10.2.8 Decision Phase 110 10.2.9 Revocation Phase 111 10.3 Sample Timelines 112 10.3.1 Key Introduction 113 10.3.2 Key Withdrawal 114 11 Terminal Security and Key Management Requirements 115 November 2011 Page v EMV 4.3 Book 2 Security and Key Management 11.1 Security Requirements for PIN Pads 115 11.2 Key Management Requirements 115 11.2.1 Certification Authority Public Key Introduction 116 11.2.2 Certification Authority Public Key Storage 117 11.2.3 Certification Authority Public Key Usage 118 11.2.4 Certification Authority Public Key Withdrawal 119 Annex A Security Mechanisms 123 A1 Symmetric Mechanisms 123 A1.1 Encipherment 123 A1.2 Message Authentication Code 125 A1.3 Session Key Derivation 127 A1.4 Master Key Derivation 129 A2 Asymmetric Mechanisms 131 A2.1 Digital Signature Scheme Giving Message Recovery 131 Annex B Approved Cryptographic Algorithms 133 B1 Symmetric Algorithms 133 B1.1 Data Encryption Standard (DES) 8-byte block cipher 133 B1.2 Advanced Encryption Standard (AES) 16-byte block cipher 133 B2 Asymmetric Algorithms 134 B2.1 RSA Algorithm 134 B3 Hashing Algorithms 136 B3.1 Secure Hash Algorithm (SHA-1) 136 Annex C Informative References 137 Annex D Implementation Considerations 139 D1 Issuer and ICC Public Key Length Considerations 139 D1.1 Issuer Public Key Restriction 139 D1.2 ICC Public Key Restriction 140 D2 Format 1 Secure Messaging Illustration 142 D2.1 Securing the Command APDU 142 D2.2 Encipherment 145 D2.3 MAC Computation 145 D3 Application Transaction Counter Considerations 147 D4 CDA Modes 148 Common Core Definitions 153 Changed Sections 153 6 Offline Dynamic Data Authentication 153 6.5 Dynamic Data Authentication (DDA) 153 6.6 Combined DDA/Application Cryptogram Generation (CDA) 154 November 2011 EMV 4.3 Book 2 Security and Key Management 8 Application Cryptogram and Issuer Authentication 155 8.1 Application Cryptogram Generation 155 8.2 Issuer Authentication 156 8.3 Key Management 156 9 Secure Messaging 157 9.1 Secure Messaging Format 157 9.2 Secure Messaging for Integrity and Authentication 157 9.3 Secure Messaging for Confidentiality 158 9.4 Key Management 158 November 2011 EMV 4.3 Book 2 Security and Key Management November 2011 EMV 4.3 Book 2 Security and Key Management Tables Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table Table 1: Required ICC Data Elements for SDA 38 2: Issuer Public Key Data to be Signed by Certification Authority 41 3: Static Application Data to be Signed by Issuer 42 4: Data Objects Required for SDA 43 5: Minimum Data for Certificate Revocation List Entry 44 6: Format of Data Recovered from Issuer Public Key Certificate 46 7: Format of Data Recovered from Signed Static Application Data 48 8: Required ICC Data Elements for offline dynamic data authentication 53 9: Data Element Generated for offline dynamic data authentication 54 10: Issuer Public Key Data to be Signed by Certification Authority 57 11: ICC Public Key Data to be Signed by Issuer 58 12: Data Objects Required for Public Key Authentication for offline dynamic data authentication 59 13: Format of Data Recovered from Issuer Public Key Certificate 61 14: Format of Data Recovered from ICC Public Key Certificate 64 15: Dynamic Application Data to be Signed 67 16: Additional Data Objects Required for Dynamic Signature Generation and Verification 67 17: Format of Data Recovered from Signed Dynamic Application Data 68 18: Dynamic Application Data to be Signed 73 19: 32-38 Leftmost Bytes of ICC Dynamic Data 73 20: Data Objects Included in Response to GENERATE AC for TC or ARQC 74 21: Data Objects Included in Response to GENERATE AC for AAC 74 22: Format of Data Recovered from Signed Dynamic Application Data 75 23: ICC PIN Encipherment Public Key Data to be Signed by Issuer 83 24: Data Objects Required for Retrieval of ICC PIN Encipherment Public Key 84 25: Data to be Enciphered for PIN Encipherment 85 26: Recommended Minimum Set of Data Elements for Application Cryptogram Generation 88 27: Minimum Set of Certification Authority Public Key Related Data Elements to be Stored in Terminal 118 28: Mandatory Upper Bound for Size in Bytes of Moduli 134 29: Data Lengths in GENERATE AC Response 140 30: CDA Modes 148 November 2011 EMV 4.3 Book 2 Security and Key Management Figures Figure 1: Diagram of SDA 38 Figure 2: Diagram of offline dynamic data authentication 52 Figure 3: CDA Sample Flow Part 1 of 3 78 Figure 4: CDA Sample Flow Part 2 of 3 79 Figure 5: CDA Sample Flow Part 3 of 3 80 Figure 6: Format 1 Command Data Field for Secure Messaging for Integrity and Authentication 95 Figure 7: Format 2 Command Data Field for Secure Messaging for Integrity and Authentication 95 Figure 8: Format 1
  • Data Object for Confidentiality 97 Figure 9: Format 2 Command Data Field for Secure Messaging for Confidentiality 98 Figure 10: Certification Authority Public Key Distribution 101 Figure 11: Issuer Public Key Distribution 102 Figure 12: Key

Introduction

Example Timeline 113 Figure 13: Key Withdrawal Example Timeline 114 Figure 14: Decimalization for Master Key Derivation 130 Page x November 2011

EMV 4.3 Book 2 Security and Key Management Part I General November 2011

EMV 4.3 Book 2 Security and Key Management 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.3 This release incorporates all relevant Specification Update 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. November 2011

1 Scope 1.2 Structure EMV 4.3 Book 2 Security and Key Management 1.2 Structure Book 2 consists of the following parts: Part I

  • General Part II
  • Security and Key Management Techniques Part III
  • Annexes Part IV
  • 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. Part II covers:

  • Offline static data authentication (SDA)
  • Offline dynamic data authentication (DDA and CDA)
  • 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.

November 2011

EMV 4.3 Book 2 Security and Key Management 1 Scope 1.4 Audience 1.4 Audience This specification is intended for use by manufacturers of ICCs and terminals, system designers in payment systems, and financial institution staff responsible for implementing financial applications in ICCs. November 2011

EMV 4.3 Book 2 Security and Key Management 2 Normative

References

The following standards contain provisions that are referenced in these specifications. The latest version shall apply unless a publication date is explicitly stated. ISO 639-1 ISO 3166 ISO 4217 ISO/IEC 7811-1 ISO/IEC 7811-3 ISO/IEC 7813 ISO/IEC 7816-1 ISO/IEC 7816-2 ISO/IEC 7816-3 ISO/IEC 7816-4 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/iso6392/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 – Recording technique – Part 1: Embossing Identification cards – Recording technique – Part 3: Location of embossed characters on ID-1 cards Identification cards – Financial transaction cards Identification cards – Integrated circuit(s) cards with contacts – Part 1: Physical characteristics Information technology – Identification cards – Integrated circuit(s) cards with contacts – Part 2: Dimensions and location of contacts Identification cards — Integrated circuit cards — Part 3: Cards with contacts — Electrical interface and transmission protocols Identification cards — Integrated circuit cards — Part 4: Organization, security and commands for interchange November 2011

2 Normative References ISO/IEC 7816-5 ISO/IEC 7816-6 ISO 8583:1987 ISO 8583:1993 ISO/IEC 8825-1 ISO/IEC 8859 ISO 9362 ISO 9564-1:2011 ISO/IEC 9796-2:2010 ISO/IEC 9797-1:2011 ISO/IEC 10116 ISO/IEC 10118-3 ISO/IEC 10373 EMV 4.3 Book 2 Security and Key Management Identification cards — Integrated circuit cards — Part 5: Registration of application providers Identification cards – Integrated circuit cards – Part 6: Interindustry data elements for interchange 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 – Modes of operation for an n-bit block cipher Information technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions Identification cards – Test methods

November 2011

EMV 4.3 Book 2 Security and Key Management 2 Normative References ISO 13491-1 ISO 13616 ISO 16609 ISO/IEC 18031 ISO/IEC 18033-3 Banking – Secure cryptographic devices (retail) – Part 1: Concepts, requirements and evaluation methods Banking and related financial services – International bank account number (IBAN) Banking – Requirements for message authentication using symmetric techniques Information technology - Security techniques Random bit generation Information technology – Security techniques – Encryption algorithms – Part 3: Block ciphers November 2011

EMV 4.3 Book 2 Security and Key Management 3 Definitions The following terms are used in one or more books of these specifications. Accelerated Revocation Application Application Authentication Cryptogram Application Cryptogram Authorisation Request Cryptogram Authorisation Response Cryptogram Asymmetric Cryptographic Technique Authentication Block Byte A key revocation performed on a date sooner than the published key expiry date. 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 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 cryptographic technique that uses two related transformations, a public transformation (defined by the public key) and a private transformation (defined by the private key). The two transformations have the property that, given the public transformation, it is computationally infeasible to derive the private transformation. The provision of assurance of the claimed identity of an entity or of data origin. A succession of characters comprising two or three fields defined as prologue field, information field, and epilogue field. 8 bits. November 2011 3 Definitions Card Certificate Certification Authority Ciphertext Cold Reset Combined DDA/Application Cryptogram Generation Command Compromise Concatenation Contact Cryptogram EMV 4.3 Book 2 Security and Key Management A payment card as defined by a payment system. 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. Trusted third party that establishes a proof that links a public key and other relevant information to its owner. Enciphered information. The reset of the ICC that occurs when the supply voltage (VCC) and other signals to the ICC are raised from the inactive state and the reset (RST) signal is applied. A form of offline dynamic data authentication. A message sent by the terminal to the ICC that initiates an action and solicits a response from the ICC. The breaching of secrecy or security. 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. A conducting element ensuring galvanic continuity between integrated circuit(s) and external interfacing equipment. Result of a cryptographic operation. November 2011 EMV 4.3 Book 2 Security and Key Management 3 Definitions Cryptographic Algorithm Data Integrity Deactivation Sequence Decipherment Digital Signature Dynamic Data Authentication Embossing Encipherment Epilogue Field Exclusive-OR Financial Transaction Function 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 deactivation sequence defined in section 6.1.5 of Book 1. The reversal of a corresponding encipherment. 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 Characters raised in relief from the front surface of a card. The reversible transformation of data by a cryptographic algorithm to produce ciphertext. The final field of a block. It contains the error detection code (EDC) byte(s). Binary addition with no carry, giving the following values: 0 + 0 = 0 0 + 1 = 1 1 + 0 = 1 1 + 1 = 0 The act between a cardholder and a merchant or acquirer that results in the exchange of goods or services against payment. A process accomplished by one or more commands and resultant actions that are used to perform all or part of a transaction. November 2011 3 Definitions EMV 4.3 Book 2 Security and Key Management Guardtime Hash Function Hash Result Inactive Integrated Circuit Module Integrated Circuit(s) Integrated Circuit(s) Card Interface Device Issuer Action Code The minimum time between the trailing edge of the parity bit of a character and the leading edge of the start bit of the following character sent in the same direction. 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. The supply voltage (VCC) and other signals to the ICC are in the inactive state when they are at a potential of 0.4 V or less with respect to ground (GND). The sub-assembly embedded into the ICC comprising the IC, the IC carrier, bonding wires, and contacts. 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. 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 November 2011 EMV 4.3 Book 2 Security and Key Management 3 Definitions Kernel Key Key Expiry Date Key Introduction Key Life Cycle Key Replacement Key Revocation Key Revocation Date Key Withdrawal Keypad 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 date after which a signature made with a particular key is no longer valid. Issuer certificates signed by the key must expire on or before this date. Keys may be removed from terminals after this date has passed. The process of generating, distributing, and beginning use of a key pair. All phases of key management, from planning and generation, through revocation, destruction, and archiving. The simultaneous revocation of a key and introduction of a key to replace the revoked one. The key management process of withdrawing a key from service and dealing with the legacy of its use. Key revocation can be as scheduled or accelerated. The date after which no legitimate cards still in use should contain certificates signed by this key, and therefore the date after which this key can be deleted from terminals. For a planned revocation the Key Revocation Date is the same as the key expiry date. 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. November 2011 3 Definitions EMV 4.3 Book 2 Security and Key Management 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. Padding Appending extra bits to either side of a data string. 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. Plaintext Unenciphered information. Planned Revocation A key revocation performed as scheduled by the published key expiry date. November 2011 EMV 4.3 Book 2 Security and Key Management 3 Definitions Potential Compromise Private Key Prologue Field Public Key Public Key Certificate Response Script Secret Key Signal Amplitude Signal Perturbations Socket 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. The first field of a block. It contains subfields for node address (NAD), protocol control byte (PCB), and length (LEN). 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 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. A key used with symmetric cryptographic techniques and usable only by a set of specified entities. The difference between the high and low voltages of a signal. Abnormalities occurring on a signal during normal operation such as undershoot/overshoot, electrical noise, ripple, spikes, crosstalk, etc. Random perturbations introduced from external sources are beyond the scope of this specification. An execution vector defined at a particular point in an application and assigned a unique number for reference. November 2011 3 Definitions EMV 4.3 Book 2 Security and Key Management State H Voltage high on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. State L Voltage low on a signal line. May indicate a logic one or logic zero depending on the logic convention used with the ICC. 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. T=0 Character-oriented asynchronous half duplex transmission protocol. T=1 Block-oriented asynchronous half duplex transmission protocol. 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 section 6.1.5 of Book 1 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. November 2011 EMV 4.3 Book 2 Security and Key Management 3 Definitions Transaction Transaction Certificate Virtual Machine Warm Reset An action taken by a terminal at the user’s request. For a POS terminal, a transaction might be payment for goods, etc. A transaction selects among one or more applications as part of its processing flow. An Application Cryptogram generated by the card when accepting a transaction A theoretical microprocessor architecture that forms the basis for writing application programs in a specific interpreter software implementation. The reset that occurs when the reset (RST) signal is applied to the ICC while the clock (CLK) and supply voltage (VCC) lines are maintained in their active state. November 2011 EMV 4.3 Book 2 Security and Key Management 4 Abbreviations, Notations, Conventions, and Terminology 4.1 µA µm µs a AAC AC ACK ADF AEF AFL AID AIP an ans APDU API ARC ARPC ARQC ASI ASN ATC Abbreviations Microampere Micrometre Microsecond Alphabetic (see section 4.3, Data Element Format Conventions) Application Authentication Cryptogram Application Cryptogram Acknowledgment Application Definition File Application Elementary File Application File Locator Application Identifier Application Interchange Profile Alphanumeric (see section 4.3) Alphanumeric Special (see section 4.3) Application Protocol Data Unit Application Program Interface Authorisation Response Code Authorisation Response Cryptogram Authorisation Request Cryptogram Application Selection Indicator Abstract Syntax Notation Application Transaction Counter November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 2 4.1 Abbreviations Security and Key Management ATM ATR AUC b BCD BER BIC BGT BWI BWT C CAD C-APDU CBC CCD CCI CDA CDOL CID CIN CLA CLK cn CPU CRL CSU C-TPDU CV Automated Teller Machine Answer to Reset Application Usage Control Binary (see section 4.3) Binary Coded Decimal Basic Encoding Rules (defined in ISO/IEC 8825–1) Bank Identifier Code Block Guardtime Block Waiting Time Integer Block Waiting Time Celsius or Centigrade Card Accepting Device Command APDU Cipher Block Chaining Common Core Definitions Common Core Identifier Combined DDA/Application Cryptogram Generation Card Risk Management Data Object List Cryptogram Information Data Input Capacitance Class Byte of the Command Message Clock Compressed Numeric (see section 4.3) Central Processing Unit Certificate Revocation List Card Status Update Command TPDU Cryptogram Version November 2011 EMV 4.3 Book 2 4 Abbreviations, Notations, Conventions, and Terminology Security and Key Management 4.1 Abbreviations CVM CVR CV Rule CWI CWT D DAD DC DDA DDF DDOL DES DF DIR DOL ECB EDC EF EN etu f FC FCI GND Hex HHMMSS I/O IAC Cardholder Verification Method Card Verification Results Cardholder Verification Rule Character Waiting Time Integer Character Waiting Time Bit Rate Adjustment Factor Destination Node Address Direct Current Dynamic Data Authentication Directory Definition File Dynamic Data Authentication Data Object List Data Encryption Standard Dedicated File Directory Data Object List Electronic Code Book Error Detection Code Elementary File European Norm Elementary Time Unit Frequency Format Code File Control Information Ground Hexadecimal Hours, Minutes, Seconds Input/Output Issuer Action Code (Denial, Default, Online) November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 2 4.1 Abbreviations Security and Key Management IAD IBAN I-block IC ICC ICC IEC IFD IFS IFSC IFSD IFSI IIN INF INS IOH IOL ISO KM KS L l.s. Lc LCOL LDD Le LEN Issuer Application Data International Bank Account Number Information Block Integrated Circuit Integrated Circuit(s) Card Current drawn from VCC International Electrotechnical Commission Interface Device Information Field Size Information Field Size for the ICC Information Field Size for the Terminal Information Field Size Integer Issuer Identification Number Information Field Instruction Byte of Command Message High Level Output Current Low Level Output Current International Organization for Standardization 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 November 2011 EMV 4.3 Book 2 4 Abbreviations, Notations, Conventions, and Terminology Security and Key Management 4.1 Abbreviations Licc Lr LRC M mΩ MΩ m.s. m/s mA MAC max. MF MHz min. MK mm MMDD MMYY N n NAD NAK nAs NCA NF NI NIC Exact Length of Data Available or Remaining in the ICC (as Determined by the ICC) to be Returned in Response to the Case 2 or 4 Command Received by the ICC Length of Response Data Field Longitudinal Redundancy Check Mandatory Milliohm Megohm Most Significant Meters per Second Milliampere Message Authentication Code Maximum Master File Megahertz Minimum ICC Master Key for session key generation Millimetre Month, Day Month, Year Newton Numeric (see section 4.3) Node Address Negative Acknowledgment Nanoampere-second Length of the Certification Authority Public Key Modulus Norme Française Length of the Issuer Public Key Modulus Length of the ICC Public Key Modulus November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 2 4.1 Abbreviations Security and Key Management NIST NPE ns O O/S P1 P2 P3 PAN PC PCA PCB PDOL pF PI PIC PIN PIX POS pos. PSE PTS R-APDU R-block RFU RID RSA RST National Institute for Standards and Technology Length of the ICC PIN Encipherment Public Key Modulus Nanosecond Optional Operating System Parameter 1 Parameter 2 Parameter 3 Primary Account Number Personal Computer Certification Authority Public Key Protocol Control Byte Processing Options Data Object List Picofarad Issuer Public Key ICC Public Key Personal Identification Number Proprietary Application Identifier Extension Point of Service Position Payment System Environment Protocol Type Selection Response APDU Receive Ready Block Reserved for Future Use Registered Application Provider Identifier Rivest, Shamir, Adleman Algorithm Reset November 2011 EMV 4.3 Book 2 4 Abbreviations, Notations, Conventions, and Terminology Security and Key Management 4.1 Abbreviations SAD S-block SCA SDA SFI SHA-1 SI SIC SK SW1 SW2 TAC TAL TC TCK TDOL tF TLV TPDU tR TS TSI TTL TVR UCOL UL V var. Source Node Address Supervisory Block Certification Authority Private Key Static Data Authentication Short File Identifier Secure Hash Algorithm 1 Issuer Private Key ICC Private Key Session Key Status Byte One Status Byte Two Terminal Action Code(s) (Default, Denial, Online) Terminal Application Layer Transaction Certificate Check Character Transaction Certificate Data Object List Fall Time Between 90% and 10% of Signal Amplitude Tag Length Value Transport Protocol Data Unit Rise Time Between 10% and 90% of Signal Amplitude Initial Character Transaction Status Information Terminal Transport Layer Terminal Verification Results Upper Consecutive Offline Limit Underwriters Laboratories Incorporated Volt Variable (see section 4.3) November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 2 4.1 Abbreviations Security and Key Management VCC VCC VIH VIL VOH VOL VPP VPP WI WTX WWT YYMM YYMMDD Voltage Measured on VCC Contact Supply Voltage High Level Input Voltage Low Level Input Voltage High Level Output Voltage Low Level Output Voltage Programming Voltage Voltage Measured on VPP contact Waiting Time Integer Waiting Time Extension Work Waiting Time Year, Month Year, Month, Day November 2011 EMV 4.3 Book 2 4 Abbreviations, Notations, Conventions, and Terminology Security and Key Management 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 &lt; 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] Encipherment of a data block X with a block cipher as specified in Annex A1, using a secret key K X = ALG-1(K)[Y] Decipherment of a data block Y with a block cipher as specified in Annex 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 Annex 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 Annex 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. November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 2 4.2 Notations Security and Key Management Rightmost H:= Hash[MSG] X ⊕ Y 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. 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. November 2011 EMV 4.3 Book 2 4 Abbreviations, Notations, Conventions, and Terminology Security and Key Management 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). 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 Annex B of Book 4. 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'. November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 2 4.3 Data Element Format Conventions Security and Key Management 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. November 2011 EMV 4.3 Book 2 4 Abbreviations, Notations, Conventions, and Terminology Security and Key Management 4.4 Terminology 4.4 Terminology proprietary Not defined in this specification and/or outside the scope of this specification shall Denotes a mandatory requirement should Denotes a recommendation November 2011 4 Abbreviations, Notations, Conventions, and Terminology EMV 4.3 Book 2 4.4 Terminology Security and Key Management November 2011 EMV 4.3 Book 2 Security and Key Management Part II Security and Key Management Techniques November 2011 EMV 4.3 Book 2 Security and Key Management 5 Static Data Authentication (SDA) 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 Issuer PK Certificate and SSAD IC Terminal 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 November 2011 5 Static Data Authentication (SDA) EMV 4.3 Book 2 Security and Key Management Figure 1: Diagram of SDA ICCs that support SDA shall contain the data elements listed in Table 1: 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

November 2011

EMV 4.3 Book 2 Security and Key Management 5 Static Data Authentication (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 Annex A2.1 and Annex 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. November 2011 5 Static Data Authentication (SDA) 5.1 Keys and Certificates EMV 4.3 Book 2 Security and Key Management 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 Annex 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 Annex 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. November 2011 EMV 4.3 Book 2 Security and Key Management 5 Static Data Authentication (SDA) 5.1 Keys and Certificates Field Name Length Description Format Certificate Format 1 Hex value '02' b Issuer Identifier 4 Leftmost 3-8 digits from the cn 8 Primary Account Number (PAN) (padded to the right with Hex 'F's) Certificate Expiration Date 2 MMYY after which this certificate is n 4 invalid Certificate Serial 3 Binary number unique to this b Number certificate assigned by the certification authority Hash Algorithm Indicator 1 Identifies the hash algorithm used b to produce the Hash Result in the digital signature scheme 1 Issuer Public Key Algorithm Indicator 1 Identifies the digital signature b algorithm to be used with the Issuer Public Key 1 Issuer Public Key 1 Identifies the length of the Issuer b Length Public Key Modulus in bytes Issuer Public Key 1 Identifies the length of the Issuer b Exponent Length Public Key Exponent in bytes Issuer Public Key or NCA – 36 If NI ≤ NCA – 36, consists of the full b Leftmost Digits of Issuer Public Key padded to the the Issuer Public right with NCA – 36 – NI bytes of Key value 'BB' If NI > NCA – 36, consists of the NCA – 36 most significant bytes of the Issuer Public Key 2 Issuer Public Key 0 or NI – Present only if NI > NCA – 36 and b Remainder NCA + 36 consists of the NI – NCA + 36 least significant bytes of the Issuer Public Key. Issuer Public Key Exponent 1 or 3 Issuer Public Key Exponent equal to b 3 or 216 + 1 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 Annex 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. November 2011 5 Static Data Authentication (SDA) 5.1 Keys and Certificates EMV 4.3 Book 2 Security and Key Management Field Name Signed Data Format Hash Algorithm Indicator Data Authentication Code Pad Pattern Static Data to be Authenticated Length 1 1 2 NI − 26 var. Description Hex Value '03' Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme 3 Issuer-assigned code Pad pattern consisting of NI − 26 bytes of value 'BB' 4 Static data to be authenticated as specified in section 10.3 of Book 3 (see also section 5.1.1) Format b b b b — Table 3: Static Application Data to be Signed by Issuer (i.e., input to the hash algorithm) 3 See Annex B for specific values assigned to approved algorithms. 4 As can be seen in Annex 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. November 2011 EMV 4.3 Book 2 Security and Key Management 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 section 10.3 of Book 3 (see also section 5.1.1) Table 4: Data Objects Required for SDA Format b b b b b b — 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: November 2011 5 Static Data Authentication (SDA) 5.2 Retrieval of Certification Authority Public Key EMV 4.3 Book 2 Security and Key Management 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 Length 5 b 1 b 3 b 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.

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

November 2011

EMV 4.3 Book 2 Security and Key Management 5 Static Data Authentication (SDA) 5.3 Retrieval of Issuer Public Key 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 Annex 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. November 2011

5 Static Data Authentication (SDA) 5.3 Retrieval of Issuer Public Key EMV 4.3 Book 2 Security and Key Management Field Name Length Description Format Recovered Data 1 Hex Value '6A' b Header Certificate Format 1 Hex Value '02' b Issuer Identifier 4 Leftmost 3-8 digits from the PAN cn 8 (padded to the right with Hex 'F's) Certificate Expiration Date 2 MMYY after which this certificate n 4 is invalid Certificate Serial 3 Binary number unique to this b Number certificate assigned by the certification authority Hash Algorithm Indicator 1 Identifies the hash algorithm used b to produce the Hash Result in the digital signature scheme 5 Issuer Public Key 1 Identifies the digital signature b Algorithm Indicator algorithm to be used with the Issuer Public Key 5 Issuer Public Key Length 1 Identifies the length of the Issuer b Public Key Modulus in bytes Issuer Public Key Exponent Length 1 Identifies the length of the Issuer b Public Key Exponent in bytes Issuer Public Key or NCA −36 If NI ≤ NCA − 36, consists of the full b Leftmost Digits of the Issuer Public Key padded to the Issuer Public Key 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 Result 20 Hash of the Issuer Public Key and b its related information Recovered Data 1 Hex value 'BC' b Trailer 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. 5 See Annex B for specific values assigned to approved algorithms. 6 As can be seen in Annex 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.

November 2011

EMV 4.3 Book 2 Security and Key Management 5 Static Data Authentication (SDA) 5.3 Retrieval of Issuer Public Key 4. Check the Certificate Format. If it is not '02', SDA has failed. 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 Identifier with hexadecimal 'F's). If not, SDA has failed. 9. Verify that the last day of the month specified in the Certificate Expiration Date is equal to or later than today’s date. If the Certificate Expiration Date is earlier than today’s date, the certificate has expired, in which case SDA has failed. 10. Verify that the concatenation of RID, Certification Authority Public Key Index, and Certificate Serial Number is valid. If not, SDA has failed.7 11. If the Issuer Public Key Algorithm Indicator is not recognised, SDA has failed. 12. If all the checks above are correct, concatenate the Leftmost Digits of the Issuer Public Key and the Issuer Public Key Remainder (if present) to obtain the Issuer Public Key Modulus, and continue with the next steps for the verification of the Signed Static Application Data. 7 This step is optional and is to allow the revocation of the Issuer Public Key Certificate against a Certification Revocation List that may be kept by the terminal (see section 5.1.2). November 2011

5 Static Data Authentication (SDA) 5.4 Verification of Signed Static Application Data EMV 4.3 Book 2 Security and Key Management 5.4 Verification of Signed Static Application Data 1. If the Signed Static Application Data has a length different from the length of the Issuer Public Key Modulus, SDA has failed. 2. In order to obtain the Recovered Data specified in Table 7, apply the recovery function specified in Annex A2.1 on the Signed Static Application Data using the Issuer Public Key in conjunction with the corresponding algorithm. If the Recovered Data Trailer is not equal to 'BC', SDA has failed. Field Name Recovered Data Header Signed Data Format Hash Algorithm Indicator Data Authentication Code Pad Pattern Hash Result Recovered Data Trailer Length 1 1 1 2 NI – 26 20 1 Description Hex value '6A' Hex value '03' Identifies the hash algorithm used to produce the Hash Result in the digital signature scheme 8 Issuer-assigned code Pad pattern consisting of NI − 26 bytes of value 'BB' 9 Hash of the Static Application Data to be authenticated Hex Value 'BC' Format b b b b b b b Table 7: Format of Data Recovered from Signed Static Application Data 3. Check the Recovered Data Header. If it is not '6A', SDA has failed. 4. Check the Signed Data Format. If it is not '03', SDA has failed. 5. Concatenate from left to right the second to the fifth data elements in Table 7 (that is, Signed Data Format through Pad Pattern), followed by the static data to be authenticated as specified in section 10.3 of Book 3. If the Static Data Authentication Tag List is present and contains tags other than '82', then SDA has failed. 8 See Annex B for specific values assigned to approved algorithms. 9 As can be seen in Annex A2.1, NI − 22 bytes of the data signed are retrieved from the signature. Since the length of the second through the fourth data elements in Table 7 is 4 bytes, there are NI − 22 − 4 = NI − 26 bytes left for the data to be stored in the signature.

November 2011

EMV 4.3 Book 2 Security and Key Management 5 Static Data Authentication (SDA) 5.4 Verification of Signed Static Application Data 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. If all of the above steps were executed successfully, SDA was successful. The Data Authentication Code recovered in Table 7 shall be stored in tag '9F45'. November 2011

EMV 4.3 Book 2 Security and Key Management 6 Offline Dynamic Data Authentication Offline dynamic data authentication is performed by the terminal using a digital signature scheme based on public key techniques to authenticate the ICC and confirm the legitimacy of critical ICC-resident/generated data and data received from the terminal. This precludes the counterfeiting of any such card. Two forms of offline dynamic data authentication exist:

  • Dynamic Data Authentication (DDA) executed before card action analysis, where the ICC generates a digital signature on ICC-resident/generated data identified by the ICC Dynamic Data and data received from the terminal identified by the Dynamic Data Authentication Data Object List (DDOL).
  • Combined Dynamic Data Authentication/Application Cryptogram Generation (CDA) executed at issuance of the first and second GENERATE AC commands. In the case of a Transaction Certificate (TC) or Authorisation Request Cryptogram (ARQC), the ICC generates a digital signature on ICC-resident/generated data identified by the ICC Dynamic Data, which contains the TC or ARQC, and an Unpredictable Number generated by the terminal10. The AIP denotes the options supported by the ICC. Offline dynamic data authentication requires the existence of a certification authority, 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 2. 10 In order to ensure that the ICC uses the correct value for the Unpredictable Number, the Issuer needs to ensure that both CDOL1 and CDOL2 contain tag '9F37'. November 2011 6 Offline Dynamic Data Authentication EMV 4.3 Book 2 Security and Key Management Private Key (ICC) S IC Issuer Static application data Public Key (ICC) PIC Private Key (Issuer) S I Public Key (Issuer) P I ICC PK Certificate Issuer PK Certificate Certification Authority Private Key (CA) S CA Public Key (CA) PCA Acquirer Distributed to Acquirer (Resides in Terminal) Issuer PK Certificate IC Card Communication between IC card and terminal IC Terminal Card provides to Terminal:  Issuer PK Certificate (PI signed by the CA SCA)  ICC PK Certificate (PIC and static application data signed by Issuer SI)  Card and terminal dynamic data and digital signature (dynamic data signed by Card SIC) Terminal:  Uses PCA to verify that the Issuer’s PI was signed by CA  Uses PI to verify that Card PIC and static application data were signed by Issuer  Uses PIC to verify the card’s signature on the dynamic data Figure 2: Diagram of offline dynamic data authentication November 2011 EMV 4.3 Book 2 Security and Key Management 6 Offline Dynamic Data Authentication ICCs that support offline dynamic data authentication shall contain the data elements listed in Table 8: Required Data Element Certification Authority Public Key Index Issuer Public Key Certificate ICC Public Key Certificate Issuer Public Key Remainder Issuer Public Key Exponent ICC Public Key Remainder ICC Public Key Exponent ICC Private Key Length 1 var. var. var. 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 6.3. Provided by the issuer to the ICC. When the terminal verifies this data element, it authenticates the ICC Public Key plus additional data as described in section 6.4. See section 6.4 for further explanation. Provided by the issuer. See section 6.4 for further explanation. See section 6.4 for further explanation. Provided by the issuer. See section 6.4 for further explanation. ICC internal. Used to generate the Signed Dynamic Application Data as described in sections 6.5 and 6.6. Table 8: Required ICC Data Elements for offline dynamic data authentication November 2011 6 Offline Dynamic Data Authentication EMV 4.3 Book 2 Security and Key Management ICCs that support offline dynamic data authentication shall generate the data element listed in Table 9: Data Element Signed Dynamic Application Data Length var. Description Generated by the ICC using the private key that corresponds to the public key authenticated in the ICC Public Key Certificate. This data element is a digital signature covering critical ICC-resident/generated and terminal data elements, as described in sections 6.5 and 6.6. Table 9: Data Element Generated for offline dynamic data authentication To support offline dynamic data authentication, each terminal shall be able to store six certification authority public keys per 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, see section 11.2.2). The terminal shall be able to locate any such key (and key-related information) given the RID and Certification Authority Public Key Index as provided by the ICC. Offline dynamic data authentication shall use a reversible algorithm as specified in Annex A2.1 and Annex B2. Section 11.2 contains an overview of the keys and certificates involved in the offline dynamic data authentication process. Sections 6.2 to 6.4 specify the initial steps in the process, namely:
  • Retrieval of the Certification Authority Public Key by the terminal.
  • Retrieval of the Issuer Public Key by the terminal.
  • Retrieval of the ICC Public Key by the terminal. If offline dynamic data authentication fails then the TVR bit indicating failure of the attempted method shall be set as follows:
  • If the attempted method is DDA then the terminal shall set the ‘DDA failed’ bit in the TVR to 1.
  • If the attempted method is CDA then the terminal shall set the ‘CDA failed’ bit in the TVR to 1. Sections 6.5 and 6.6 specify the dynamic signature generation and verification processes for each method. November 2011 EMV 4.3 Book 2 Security and Key Management 6 Offline Dynamic Data Authentication 6.1 Keys and Certificates 6.1 Keys and Certificates To support offline dynamic data authentication, an ICC shall own its own unique public key pair consisting of a private signature key and the corresponding public verification key. The ICC Public Key shall be stored on the ICC in a public key certificate. More precisely, a three-layer public key certification scheme is used. Each ICC Public Key is certified by its issuer, and the certification authority certifies the Issuer Public Key. This implies that, for the verification of an ICC signature, the terminal first needs to verify two certificates in order to retrieve and authenticate the ICC Public Key, which is then employed to verify the ICC’s dynamic signature. 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 as specified in Annex A2.1 is applied on the data in Table 10 and on the data in Table 11 using the Certification Authority Private Key SCA and the Issuer Private Key SI in order to obtain the Issuer Public Key Certificate and ICC Public Key Certificate, respectively. The public key pair of the certification authority has a Certification Authority Public Key Modulus of NCA bytes, where NCA ≤ 248. The Certification Authority Public Key Exponent shall be equal to 3 or 216 + 1. The public key pair of the issuer has a Public Key Modulus of NI bytes, where NI ≤ NCA ≤ 248. If NI > (NCA – 36), the Issuer Public Key Modulus is divided into two parts, one part consisting of the NCA – 36 most significant bytes of the modulus (the Leftmost Digits of the Issuer Public Key) and a second part consisting of the remaining NI − (NCA – 36) least significant bytes of the modulus (the Issuer Public Key Remainder). Section D1.1 details additional restrictions on the length of the Issuer Public Key. The Issuer Public Key Exponent shall be equal to 3 or 216 + 1. The public key pair of the ICC has an ICC Public Key Modulus of NIC bytes, where NIC ≤ NI ≤ NCA ≤ 248. If NIC > (NI – 42), the ICC Public Key Modulus is divided into two parts, one part consisting of the NI – 42 most significant bytes of the modulus (the Leftmost Digits of the ICC Public Key) and a second part consisting of the remaining NIC – (NI – 42) least significant bytes of the modulus (the ICC Public Key Remainder). Section D1.2 details additional restrictions on the length of the ICC Public Key. The ICC Public Key Exponent shall be equal to 3 or 216 + 1. November 2011 6 Offline Dynamic Data Authentication 6.1 Keys and Certificates EMV 4.3 Book 2 Security and Key Management To execute offline dynamic data authentication, the terminal shall first retrieve and authenticate the ICC Public Key (this process is called ICC Public Key authentication). All the information necessary for ICC Public Key authentication is specified in Table 12 and stored in the ICC. With the exception of the RID, which can be obtained from the AID, this information may be retrieved with the READ RECORD command. If any of this data is missing, offline dynamic data authentication has failed. November 2011 EMV 4.3 Book 2 Security and Key Management 6 Offline Dynamic Data Authentication 6.1 Keys and Certificates Field Name Length Description Format Certificate Format 1 Hex value '02' b Issuer Identifier 4 Leftmost 3-8 digits from the PAN cn 8 (padded to the right with Hex 'F's) Certificate Expiration 2 MMYY after which this certificate n 4 Date is invalid Certificate Serial 3 Binary number unique to this b Number certificate assigned by the certification authority Hash Algorithm Indicator 1 Identifies the hash algorithm used b to produce the Hash Result in the digital signature scheme 11 Issuer Public Key 1 Identifies the digital signature b Algorithm Indicator algorithm to be used with the Issuer Public Key 11 Issuer Public Key Length 1 Identifies the length of the Issuer b Public Key Modulus in bytes Issuer Public Key Exponent Length 1 Identifies the length of the Issuer b Public Key Exponent in bytes Issuer Public Key or NCA – If NI ≤ NCA – 36, consists of the full b Leftmost Digits of the 36 Issuer Public Key padded to the Issuer Public Key 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 12 Issuer Public Key 0 or NI Present only if NI > NCA – 36 and b Remainder – NCA + consists of the NI – NCA + 36 least 36 significant bytes of the Issuer Public Key Issuer Public Key Exponent 1 or 3 Issuer Public Key Exponent equal b to 3 or 216 + 1 Table 10: Issuer Public Key Data to be Signed by Certification Authority (i.e., input to the hash algorithm) 11 See Annex B for specific values assigned to approved algorithms. 12 As can be seen in Annex 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 10 is 14 bytes, there are NCA − 22 − 14 = N

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