EMV®Issuer and Application Security Guidelines

EMV® Issuer and Application Security Guidelines EMVCo, LLC Version 3.0 October 2023 © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 2 / 82 Legal Notice 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 the EMV® 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 the EMV® 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 the EMV® Specifications. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 3 / 82 TABLE OF CONTENTS 1 Scope .................................................................................................................................. 4 2 References .......................................................................................................................... 5 3 Definitions.......................................................................................................................... 6 4 Abbreviations and Notations .............................................................................................. 8 5 EMV and Cryptography – Overview ................................................................................10 5.1 Introduction ............................................................................................................................ 10 5.2 Payment System Model .......................................................................................................... 10 5.2.1 The Cardholder ............................................................................................................... 11 5.2.2 The Merchant.................................................................................................................. 11 5.2.3 The Issuer ....................................................................................................................... 11 5.2.4 The Acquirer................................................................................................................... 11 5.2.5 The Payment System ...................................................................................................... 12 5.3 Cryptographic Basics.............................................................................................................. 12 5.3.1 Symmetric Algorithms.................................................................................................... 12 5.3.2 Asymmetric Algorithms ................................................................................................. 13 5.4 EMV Card Authentication Methods ....................................................................................... 16 5.4.1 Offline Data Authentication............................................................................................ 16 5.4.2 Kernel 8 Local Authentication........................................................................................ 17 5.4.3 Online Authentication..................................................................................................... 18 5.4.4 Kernel 8 Remote Authentication .................................................................................... 18 5.4.5 Relay Resistance Protocol .............................................................................................. 19 5.4.6 Cardholder Verification Methods ................................................................................... 21 5.5 The Authorisation System ...................................................................................................... 21 6 Security Considerations for EMV Card Issuance..............................................................22 6.1 Issuing Portfolio ..................................................................................................................... 22 6.1.1 Preparation...................................................................................................................... 23 6.1.2 Security Counters ........................................................................................................... 30 6.1.3 Card Production (SDA) .................................................................................................. 30 6.1.4 Card Production (DDA / CDA / XDA / EDA) ............................................................... 31 6.1.5 CVM Choice................................................................................................................... 32 6.1.6 Card Issuance.................................................................................................................. 32 6.2 Key Obsolescence................................................................................................................... 34 6.2.1 Key Retention ................................................................................................................. 34 6.2.2 Key Destruction .............................................................................................................. 35 6.3 Certificate Revocation Lists ................................................................................................... 35 7 Issuer Transaction Processing ...........................................................................................37 7.1 Online Transaction Processing ............................................................................................... 37 7.2 Fraud Detection ...................................................................................................................... 37 7.2.1 By Issuer ......................................................................................................................... 37 7.2.2 By Card........................................................................................................................... 38 7.3 Transaction Clearing............................................................................................................... 38 8 Key Management Practices ...............................................................................................40 8.1 Key Generation – General Guidance ...................................................................................... 40 8.2 Asymmetric Key Transport and Storage ................................................................................ 41 8.3 Symmetric Key Transport and Storage................................................................................... 41 Annex A Cryptographic Algorithms – Worked Examples for CPA ........................................43 A.1 - Introduction ............................................................................................................................... 43 A.2 - Notation Used............................................................................................................................ 44 A.3 - Purchase with Online Authorization.......................................................................................... 45 A.4 - PIN Change ............................................................................................................................... 50 A.5 - Static Data Authentication......................................................................................................... 55 A.6 - Dynamic Data Authentication (DDA) ....................................................................................... 59 A.7 - Combined DDA / AC Generation (CDA) ................................................................................. 71 A.8 - Offline PIN Encipherment......................................................................................................... 76 © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 4 / 82 1 Scope These Security Guidelines are designed to assist issuers of EMV payment cards with key management and issuance processes. The issuer is liable for both the accuracy and the protection of the data used in the provisioning of its cards. Such data includes, in addition to the cardholder and account information, cryptographic keys and other cardholder secrets, that, if revealed to unauthorised parties, could result in the creation of counterfeit cards and fraudulent transactions. To protect against the unauthorised disclosure of this information, issuers must create and manage these types of data in a secure environment. Such an environment is one where the appropriate physical and logical security controls have been implemented and where sufficient audit trails have been established to assure procedural consistency relative to the issuer's security objectives. The guidance presented in the following pages is applicable to all phases of card provisioning, authorisation, and transactional clearing. Where issuers use third party agents to perform these functions, the same principles are also applicable. Application of these principles may also be useful for other payment applications that require and use similar sensitive data. The guidelines are applicable to both chip card issuance and common contactless, otherwise known as Kernel 8, detailed in the EMV Contactless specifications. Some aspects of these Guidelines may also be applicable to the component that represents the card within a Mobile phone acting as a contactless payment card, but the Guidelines are not intended to address security that is specific to mobile technology as compared to contact or contactless cards. The Guidelines are not intended to cover EMV Tokenisation nor EMV 3D-Secure. The materials contained in this document are intended primarily for issuers and their agents. This document is not intended to supersede the requirements and specifications of any Payment System. The document is to be used as a “guideline”, assisting the issuer, the issuer's agent and other third parties regarding the secure implementation of an EMV specification. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 5 / 82 2 References Throughout this document, the following references have been used. These references include the most current version at the time of preparation. For future use the most current versions of these documents should be used. EMV Book 2 EMV Book C-8 EMV Book E EMV CPS EMV SBMP EMV CDCVM EMV Issuance Process EMV Security Evaluations PCI SSC CPPLS ISO 9564-1 ISO 11568 ISO 13491 ISO 16609 ISO 20038 ISO/IEC 18031 ISO/IEC 18032 ISO/IEC 18033-2 Integrated Circuit Card Specifications for Payment Systems, Book 2 Security and Key Management EMV Contactless Specification for Payment Systems, Book C-8 – Kernel 8 Specification EMV Contactless Specification for Payment Systems, Book E Security and Key Management EMV Card Personalisation Specifications Software Based Mobile Payment Security Requirements Consumer Device Cardholder Verification Method Security Requirements EMV Certificate Issuance, Renewal and Extension Process EMV® Security Guidelines: EMVCo Security Evaluation Process PCI SSC Card Production Physical and Logical Security Standards Financial Services – PIN management and security – Part 1: Basic principles and requirements for PINs in card-based systems Financial Services – Key management (retail) Financial Services – Secure cryptographic devices (retail) Financial Services – Requirements for message authentication using symmetric techniques Financial Services - Key Wrap using AES Information technology - Security techniques – Random bit generation Information technology - Security techniques Prime number generation Information technology - Security techniques – Encryption Algorithms – Part 2: Asymmetric ciphers © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 6 / 82 3 Definitions Authentication Certificate (public key) Certification Authority Cryptographic Algorithm Digital Signature A cryptographic process that validates the identity and integrity of data. The public key and the identity of an entity together with some other information, made unforgeable by the signing of the certificate with the private key of the Certification Authority issuing the certificate. The entity that is trusted by one or more other entities to create and assign certificates. A set of rules, setting forth procedures necessary to authenticate or protect data, e.g. to perform encipherment and decipherment of data. The algorithm is specified in a manner that it is not possible to determine any of the secret control parameters, i.e., the secret or private key, except by exhaustive search. The cryptographic transformation of data which provides: • origin authentication, and • data integrity. Dual Control The process of utilising two or more separate entities to protect sensitive information or functions, such that no single entity is able to access or utilise the information or functions. Hash Function A function, which maps values from a large domain into a smaller one. The function satisfies the following properties: 1. It is computationally infeasible to find for a given output, an input that maps to this output. 2. It is computationally infeasible to find for a given input, a second input that maps to the same output. IC Card (ICC) A card with an embedded integrated circuit (chip) that communicates with a point of interaction (terminal). Issuer Identifier The leftmost (3-8 for RSA or 3-10 for ECC) digits of the PAN. Often equal to the BIN. Key Component One of at least two parameters having the characteristics of randomness and format of a cryptographic key that is combined with one or more like parameters, forming the cryptographic key. Key Pair When used in public key cryptography, a public key and its corresponding private key. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 7 / 82 Key Space Keying Material Payment System Physically Secure Device Platform Private Key Pseudo-random Public Key Secret Key Secure Cryptographic Device Split Knowledge A set of all possible keys used by a cryptographic algorithm. The data (e.g. keys, certificates, initialisation vectors) necessary to establish and maintain cryptographic keys. A Payment System includes a number of participants where the issuer and the acquirer distribute responsibilities amongst the different parties according to Payment System rules and according to the allocation of risks. A module that has a negligible probability of entry without detection or erasure of its contents. An integrated circuit (chip) with its dedicated software, Operating System (OS), Run Time Environment (RTE), and Platform environment on which one or more applications (e.g., CPA) can be executed. In an asymmetric algorithm (public key) cryptosystem, the key of an entity's key pair that is known only to that entity. This is not the same as the secret key used in a symmetric algorithm. A process that produces numbers that are statistically random and essentially unpredictable although generated by an algorithmic process. In an asymmetric key system, the key of an entity that is publicly known. A key that is used in a symmetric cryptographic algorithm and cannot be disclosed publicly without compromising the security of the system. This is not the same as the private key in a public/private key pair. A device that provides physically and logically protected cryptographic services and storage (e.g. PIN Entry device or Hardware Security Module), and which may be integrated into a larger system such as a point of sale device. A condition whereby two or more parties, i.e., key custodians, separately and confidentially have custodial control of a constituent part of a cryptographic key that individually conveys no knowledge of the resultant cryptographic key. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 8 / 82 4 Abbreviations and Notations AC AES AIP ARPC ARQC ATC ATM CA CDA CDCVM CDOL CPA CRL CRT DDA DES ECC EDA HSM IAD IC ICC IDN IMKAC IMKSMC IMKSMI MAC MK MKAC MKSMC MKSMI PAN Application Cryptogram Advanced Encryption Standard Application Interchange Profile Authorisation Response Cryptogram Authorisation Request Cryptogram Application Transaction Counter Automated Teller Machine Certification Authority Combined DDA/Application Cryptogram Generation Consumer Device Cardholder Verification Method Card Risk Management Data Object List Common Payment Application Certificate Revocation List Chinese Remainder Theorem Dynamic Data Authentication Data Encryption Standard Elliptic Curve Cryptography Enhanced Data Authentication Hardware Security Module Issuer Application Data Integrated Circuit Integrated Circuit Card ICC Dynamic Number Issuer Master Key for Application Cryptogram computation Issuer Master Key for Secure Messaging for Confidentiality Issuer Master Key for Secure Messaging for Integrity Message Authentication Code Card Master Key Card Master Key for Application Cryptogram computation Card Master Key for Secure Messaging for Confidentiality Card Master Key for Secure Messaging for Integrity Application Primary Account Number © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 9 / 82 POS RRP RSA SCD SDA SDAD SKAC SKSMC SKSMI TC TDES TVR XDA Point of Sale Relay Resistance Protocol Rivest, Shamir, Adleman algorithm Secure Cryptographic Device Static Data Authentication Signed Dynamic Application Data Session Key for Application Cryptogram computation Session Master Key for Secure Messaging for Confidentiality Session Master Key for Secure Messaging for Integrity Transaction Certificate Triple DES (referred to as DES3 in EMV Book 2) Terminal Verification Results Extended Data Authentication © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 10 / 82 5 EMV and Cryptography – Overview 5.1 Introduction The purpose of this overview is to provide a framework for the issuer security guidelines. The EMV payment system model is described together with an outline of the roles of the entities within the model. 5.2 Payment System Model The Payment System (as outlined in Figure 1) consists of the following types of entity: • Cardholders, • Merchants, • Issuers, • Acquirers, and • Payment Systems (e.g. American Express, Discover, JCB, Mastercard, UnionPay and Visa). Figure 1 - System Model The main role of each of these entities is as follows. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 11 / 82 5.2.1 The Cardholder The role of the cardholder includes the following: • To obtain a chip card containing the payment product application by contracting with an issuer. • To choose, remember and possibly update their PIN. • To present their chip card to the merchant device accepting the payment product for payment (ATM, POS, vending machines, etc.). 5.2.2 The Merchant The role of the merchant includes the following: • To obtain payment terminals accepting chip cards by contracting with an acquirer. • To accept chip cards containing the payment products for payment. • To obtain reimbursement for the purchases by collecting and transmitting payment transaction details to the acquirer. 5.2.3 The Issuer The role of the issuer includes the following: • To contract with the cardholder, and to provision and issue a chip card containing the application to the cardholder. This includes the generation and installation of the necessary cryptographic keys in the card to support the application. • To process online transactions. This includes verification of the data and cryptogram from the card together with data from the terminal, plus generation of a cryptogram allowing the card to authenticate the issuer. It also includes verification of online cardholder PINs as part of standard authorisation processing. • To generate update scripts to the card application when appropriate. • To process clearing messages including verification of the data and associated Transaction Certificate, when appropriate. In some circumstances this could be deferred and only checked in the case of dispute. • To reimburse the acquirer for payment transactions. • To securely transmit to any other parties the necessary cryptographic keys needed for the correct operation of the system. 5.2.4 The Acquirer The role of the acquirer includes the following: © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 12 / 82 • To contract with merchants and to deploy payment terminals. This includes the installation and management of Payment System public keys, adequately protected for integrity. • To process payment transactions and to pay the merchant for them. • To transmit the completed transaction records to the issuer in order to obtain the settlement. • To manage the risk conditions relating to online/offline acceptance. 5.2.5 The Payment System The role of the Payment System includes the following: • To specify the system rules for the products and services and to verify compliance with them. • To generate and distribute Payment System public keys. • To certify Issuer Public Keys used within the system. • To operate on-line communication networks between acquirers and issuers. • To perform clearing and settlement for transactions on this network. 5.3 Cryptographic Basics Historically, cryptography has been used to provide data confidentiality and today includes additional cryptographic functions such as data integrity, authentication, and non-repudiation. International standards have been developed to facilitate interoperability of products and services between different vendors and various cryptographic implementations. The materials contained in these guidelines represent the best practices drawn from these different standards. Modern cryptography depends on two basic components: (1) the algorithm, and (2) the cryptographic key, with overall security dependant on public access to the algorithm and secure management of the secret and private keys over the key lifecycle. The algorithms define how ciphertext is obtained from plaintext and vice versa and how data is signed and verified. Algorithms are typically published and have been extensively studied by cryptographers – it is the use of unique keys for every user that ensures that unauthorised parties are unable to decrypt sensitive data or forge another parties' digital signature. There are two basic types of cryptographic algorithms: (1) symmetric or secret key algorithms, and (2) asymmetric or public/private key algorithms and both are used within the context of EMV. 5.3.1 Symmetric Algorithms Symmetric or ‘secret key’ algorithms require that the secret key used for the encryption process also be used in the decryption process. Therefore, the security of the encryption process depends entirely on protection of this secret key. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 13 / 82 The EMV application supports the use of the Data Encryption Standard (DES) in its two-key Triple DES form. This is a symmetric algorithm which is widely used in the financial services industry today. DES belongs to the family of encryption algorithms called “block” ciphers because they process data in blocks As an option, the more recent AES algorithm is also supported. The MAC length is retained at 8 bytes for backwards compatibility. Whilst attacks on Triple DES have been published and therefore there is pressure to deprecate its use and replace it with AES, it is important to understand the context in which the identified weaknesses are relevant. If a single key is to be used to encrypt large volumes of data (of the order of 240 bytes) then Triple DES is a poor choice. However, in EMV session keys are specified to form a single cryptogram for the purposes of a one-off real-time authorisation. Consequently, the weaknesses do not apply in this environment and there is no urgent need for the industry to upgrade to AES, but rather to migrate as the opportunity arises. Potential risks to symmetric keys include: • The physical compromise of the secret key. • Side channel attacks on keys held in chip cards. • Exhaustive key search attacks – currently computationally infeasible for TDES. 5.3.1.1 Hash and Keyed Hash Functions Hash functions take an input data string of arbitrary length and convert it to an output string of a fixed length. With a sufficiently large output length it is computationally impossible to find two input data strings that map to the same hash output, known as a collision. Typically, for data sent between two parties, the data in a message is hashed and if the receiver computes the same hash value from the received message data, it indicates that the data has not been corrupted. A keyed hash function incorporates a symmetric secret key, known only to both parties, into the hash computation. Consequently, if the hash value computed by the receiver matches that from the sender, then the receiver has validated both the integrity of the message data and the authenticity of the sender. 5.3.2 Asymmetric Algorithms Asymmetric or ‘public key’ algorithms are generally based on a “hard” mathematical problem and have a design goal that there should be no better way to attack the scheme other than solving the hard problem. RSA is based on the hard problem of factorisation; that is, for a number consisting of two prime numbers multiplied together, find the primes given only the product, known as the modulus. ECC is based on the hard problem of solving the discrete log problem in a group of points of an elliptic curve. Asymmetric algorithms require the communicating endpoints to use two different, but linked, keys: a “public” key and a “private” key. The RSA and ECC asymmetric algorithms are specified by EMV to create digital signatures for offline data authentication and for offline PIN encipherment. In a digital signature scheme the private key (sometimes referred to as the signature key) is used to generate the © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 14 / 82 signature and the public key (sometimes referred to as the verification key) is used to verify the signature. For offline PIN encipherment, the public key is used for encipherment and the private key is used for decipherment. 5.3.2.1 Asymmetric (RSA & ECC) Keys The security of the private (signature) keys used with the RSA algorithm depends on: • The length of the RSA key modulus, e.g. 1024, 1152, 1408, and 1984 bit keys. • The quality of the prime numbers making up the public/private key modulus. The security of the private (signature) keys used with the ECC algorithm depends on a number of factors including: • The choice of a reputable curve and group generator, e.g. NIST curve P-256. • The quality of the random number generator creating the private key. Potential risks to the private (signature) key include: • The physical security of the private (signature) key from unauthorised access and exposure/compromise whilst in storage, in transit or in use. • Side channel attacks on keys held in chip cards. • Collapse of the underlying algorithm – most unlikely after decades of cryptanalysis. The EMVCo Security Working Group conducts an annual review of Payment System cryptography, including RSA key lengths, based on independent analyses by the participating Payment Systems. Using the recommendations from the review, the Payment Systems may update their Payment System key lifetimes. The lifetime for the longest RSA key (1984-bit) is currently considered to be an ‘anticipated lifetime’ in order to reflect the situation that when looking more than ten years into the future, the variation in prediction becomes too large for a reliable date to be given. Over time this date is also expected to move out, until a lifetime of ten years or less is predicted at which time the date will be considered as an expiry date. 5.3.2.2 Certificates and Certification Authorities EMV follows the usual practice of certificates to validate the source of issuer and card public keys. A certificate is a form of digital signature designed to validate the origin and integrity of a public key. A certificate consists of a public key concatenated with other related data and signed with the private key of a trusted entity known as a Certification Authority (CA). Any entity with a trusted copy of the CA’s Public Key can then verify all certificates generated by that CA and thereby obtain trusted copies of other users’ public keys. In the EMV environment, the Payment System acts as a Certification Authority and creates Issuer Public Key certificates by signing each issuer public key. Issuers act as Certification Authorities and create ICC Public Key certificates by signing each ICC Public Key. The Payment Systems CA’s Public Keys are distributed to the terminals through the acquirers for verifying issuer certificates, thereby yielding trusted copies of issuers’ public keys, used in turn to verify ICC Public Keys. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 15 / 82 © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 16 / 82 5.4 EMV Card Authentication Methods EMV supports offline and online methods for authenticating that a card is genuine and that the data on the card has not been altered since it was provisioned by the issuer. The offline methods require a Public Key Infrastructure (PKI) rooted to a Certification Authority under control of the Payment System as described in 5.3.2.2. 5.4.1 Offline Data Authentication For EMV chip cards, the two RSA based methods of offline data authentication are Dynamic Data Authentication (DDA) and Combined DDA/Application Cryptogram Generation (CDA). There is only one ECC based method of offline data authentication, known as Extended Data Authentication (XDA). • With DDA the terminal verifies a dynamic signature (i.e. different for each transaction) generated by the card using its private key, in order to ensure that the card is not counterfeit and that the card data has not been altered. • With CDA and XDA the card generates a dynamic signature of transaction data including the online cryptogram, in order to provide the protection of DDA while also ensuring that an intermediate (wedge) device has not altered important data going between the card and terminal. The specifications also include a version of RSA based offline data authentication called SDA (Static Data Authentication) which is a simple signature over static card data and was included as historically early cards did not have public key cryptographic capabilities. However, it is not proof against cloning, meaning that the relevant data can be copied from a legitimate card and applied to a counterfeit product (blank stock). Such a cloned card will work in offline environments, but will fail if the transaction is sent online. Given the cryptographic capabilities of modern card products, SDA is no longer recommended and in addition Issuer Action Codes should be set to ensure that any SDA card product that appears in the field will have the transaction sent online, or be declined in an offline only environment. DDA, CDA and XDA are EMV chip card mechanisms providing dynamic data authentication where the terminal uses a digital signature based on a private key internal to the card to authenticate the ICC and to confirm the legitimacy of critical ICC-resident data. This prevents the cloning of cards able to pass offline dynamic data authentication. The relationship between the data and the cryptographic keys is shown in Figure 2. For further information, please refer to EMV Book 2. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 17 / 82 Figure 2 – DDA / CDA / XDA 5.4.2 Kernel 8 Local Authentication For Kernel 8, local authentication is achieved by the reader comparing a MAC computed over selected transaction data by the card, to what should be the same MAC value computed independently by the reader over the same transaction data. The symmetric keys used by each party for the MACs are obtained from a Blinded Diffie-Hellman exchange between the card and the reader. The reader public key pair is an ephemeral value and the card public key is rendered ephemeral by means of a random blinding factor. To complete the local authentication, the reader compares the MAC values, confirms the blinding factor and authenticates the card public key by means of the certificate chain from the issuer and payment system (as for EMV chip cards). The MAC calculation is a two-step process. First the card computes an Issuer Application Data MAC (IAD-MAC) over card data and selected transaction data. This is internal and does not leave the card. The card also calculates the Application Cryptogram (AC - in a similar way as for EMV chip cards) and this is then included with IAD-MAC in a second MAC computation to form the Enhanced Data Authentication MAC (EDA-MAC). The reader duplicates this process independently, first calculating an IAD-MAC from the card data available from the transaction and then MACing this along with the AC value output by the card. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 18 / 82 Figure 3 – Local Authentication 5.4.3 Online Authentication For EMV chip cards, EMV’s online authentication methods are used to validate the card to the issuer and the issuer to the card as well as to prove the authenticity of received data. • With Online Card Authentication the issuer online system validates a cryptogram (an Application Cryptogram called an ARQC) generated by the card from important transaction data using its unique secret key, to show that the card is not counterfeit and that the data has not been altered. • With Online Issuer Authentication, the card validates an issuer-generated cryptogram and then performs internal card management functions, such as the reset of offline counters. • With secure messaging the issuer sends a script update to the card protected by a MAC. The card only applies the updates if the MAC is valid. Secure messaging is also used to encipher confidential data, such as a replacement PIN value during transport between the issuer and the card. • For approved transactions the terminal sends a cryptogram (an Application Cryptogram called a TC) generated by the card with the clearing information for verification by the issuer as evidence of the validity of the completed transaction. 5.4.4 Kernel 8 Remote Authentication For Kernel 8, remote authentication is achieved in the same way as for Online Authentication, by the Issuer re-calculating the ARQC from data supplied in the authorisation request message and comparing it to the value received from the card. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 19 / 82 The input data for ARQC calculation may include the IAD-MAC value calculated by the reader and included in the authorisation request message. If the IAD-MAC calculated internally by the card is included in its ARQC generation and the ARQC validates at the Issuer, the Issuer knows that the card is not counterfeit, that the transaction data has not been altered and that both the card and the reader had the same view of the local data, which was not modified. 5.4.5 Relay Resistance Protocol The C-8 specification includes a Relay Resistance Protocol (RRP). At an early stage in the transaction the reader sends a random value (TRRE – Terminal Relay Resistance Entropy) to the card, which immediately responds with its own random value (DRRE – Device Relay Resistance Entropy) and the reader measures the time of the exchange. In its response, the card also indicates the minimum and maximum processing times that a response should usually take. If the processing time calculated from the reader’s measured response time does not lie between the max and min times, then the reader should consider that a relay attack has been detected. The reader also has an accuracy threshold time value from the acquirer, RRAT (Relay Resistance Accuracy Threshold), which is used in addition to the max time value. Later in the transaction, TRRE, DRRE, tmin, tmax and ttx are all included in the card and reader IAD-MAC calculations. This confirms to the reader, via the EDA-MAC, that the values used in the relay attack detection were not manipulated and similarly the issuer knows the same via the ARQC check. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 20 / 82 Figure 4 – RRP Timing Processing Time is calculated as Measured Time less transmit time for ERRD CAPDU and transmit time for ERRC R-APDU (given by ttx). If the Processing Time does not lie between tmin and tmax then a relay attack is detected. If tmax is exceeded, the corresponding bit is set in the TVR. The terminal has an acquirer value RRAT, which is used alongside tmax (maybe shorter or longer), which if exceeded also results in the corresponding bit being set in the TVR. Later in the transaction, ERRD, DRRE, tmin and tmax are all included in the EDA MAC. This confirms that the values used in the relay attack detection were not manipulated. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 21 / 82 5.4.6 Cardholder Verification Methods EMV supports the following methods for verifying a legitimate cardholder: • Online PIN, where a cardholder-entered value is enciphered by the terminal/PIN pad and sent with an online authorisation request to the issuer for validation. • Offline PIN, where a cardholder-entered value is sent to the card and the ICC compares this value to a reference PIN stored securely on the card. The terminal is informed of the success or failure of the verification. • On device verification for devices such as mobile phones and tablets Consumer Device Cardholder Verification Method (CDCVM). • Signature (cardholder signature) EMV provides for two types of offline PIN verification: • Offline Plaintext PIN, where the cardholder-entered value sent to the ICC is unencrypted. • Offline Enciphered PIN, where the cardholder-entered value is enciphered (RSA or ECC) before being sent and deciphered by the ICC. To prevent PIN probing attacks, dual interface (and contactless-only) cards should not respond to the VERFIY command over the contactless interface. Offline PIN encryption may be supported using either the DDA/CDA keys or dedicated keys. For security reasons the use of dedicated keys is a best practice, however dedicated keys may impact key management and transaction performance. All of the PIN methods involve a precise interaction with the cardholder, the result of which is either right or wrong, whereas signature requires a human comparison that is subjective. 5.5 The Authorisation System Authorisation is a process whereby an issuer or a representative of the issuer approves or declines a transaction in response to an online authorisation request from a merchant via an acquirer. The online authorisation request includes a card generated authorisation cryptogram (ARQC) which the issuer validates to ensure that the card is authentic and the transaction data is unaltered. The online request also includes card and terminal indicators of the results of offline processing. In response to the ARQC, the issuer optionally creates an authorisation response cryptogram (ARPC). The card validates the ARPC to assure that the authorisation response came unaltered from the issuer. In addition to the ARPC described above, issuers can perform post-issuance updates of cards using issuer script commands. For example, the issuer can change the Offline PIN or update a card’s risk parameters. The issuer protects these script commands from undetected alteration by generating a cryptogram (MAC) from the command data. The card validates the MAC before applying the changes. Confidential data is enciphered. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 22 / 82 6 Security Considerations for EMV Card Issuance This section addresses the security related functions that need to be performed by an EMV card issuer. The focus is on the issuance of physical card products. Security measures for provisioning payment credentials to other form factors, such as mobile phones are not addressed specifically. • The generation, management and secure storage of the asymmetric issuer public/private key pairs. • The transfer of the Issuer Public Keys to the Payment System CA for certification. • The storage of Issuer Public Key certificates and the Payment System public keys for verification of these certificates. • The generation of ICC public/private key pairs for use in DDA / CDA / XDA and offline PIN encipherment. • The use of an issuer private key to certify ICC Public Keys or to sign application data for use in SDA. • The optional use of the Certificate Revocation List (CRL) process. • The generation and secure storage of symmetric Issuer Master Keys. • The use of Issuer Master Keys to derive ICC Master Keys used for online authentication and secure messaging. • The secure transport of keying material necessary for card provisioning, including the import/export of Issuer Master Keys (only necessary if other entities are to perform ‘on-behalf’ card verification services). For mobile phone implementations, Issuers are directed to EMVCo Software Based Mobile Payment (SBMP) documentation as follows: - Software-based Mobile Payment Security Requirements document [EMV SBMP], see in particular chapter 3 “Mobile Application Software Life Cycle and best practices”, - For CDCVM-specific considerations: Consumer device Cardholder Verification Method Security Requirements document [EMV CDCVM], chapter 3 “Security Model for a Platform Authentication Mechanism”. 6.1 Issuing Portfolio Issuers perform the following activities during the life of a card issuance programme: • Preparation - to be completed prior to any card issuance. • Card production (SDA) – deprecated. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 23 / 82 • Card production (DDA / CDA / XDA) - the steps for issuing cards employing dynamic data authentication. • Card issuance - the steps to provide cardholders with newly produced EMV cards. • Online transaction processing - the procedures for supporting the ongoing use of EMV cards, including validation of the online cryptogram from EMV cards, verification of online PINs, and update of card application using issuer script commands. • Transaction clearing - the processes for support of clearing and settlement of EMV transactions. • Obsolescence - during the life and at the end of a card issuance programme, various keys will become obsolete and should be destroyed. 6.1.1 Preparation The following activities need to be performed by an issuer prior to any card issuance. They also need to be performed when keys change or certificates expire. 6.1.1.1 Asymmetric (RSA / ECC) Keys Key Pair Generation. The issuer needs to securely generate and store one or more public/private key pairs. This requires the use of protected memory in a physically secure device, utilising a random or pseudo-random number generator and primalitychecking routines (for RSA). Asymmetric Keys include: • Issuer Key Pairs – the private key signs card static data and ICC Public Key certificates. The public key is sent to the Payment System CA to obtain an Issuer Public Key certificate. • ICC Key Pairs – the private key is provisioned on the card and used for DDA/CDA/XDA and/or offline PIN decryption. The public key is signed by the Issuer Private Key to produce the ICC Public Key certificate. [6.1] The minimum recommended RSA key length for a card is 1152 bits, but 1408 is preferred. The minimum recommended key length for an issuer is 1408 bits, but 1920 or 1976 is preferred. The ECC key lengths for both cards and Issuers is 256 bits. It may be noted that the 1920 bit Issuer key length falls on an 8-byte boundary and that the 1976 bit Issuer maximum key length is a result of TLV encoded templates needing to fit within the 254 byte record limit and consequently for the record containing the ICC Public Key Certificate, accommodating the tags and lengths of the certificate and record template means that the size of the certificate has to be less than 254 bytes. For this reason the size is restricted to 247 bytes (1976 bits) which means that the Issuer Public Key which is the same length as the ICC Public Key Certificate is also restricted to a maximum of 247 bytes. For issuer certificates, if the issuer key is not at least 36 bytes shorter than the payment system key, then an Issuer Public Key Remainder field will need to be added to the card records. For card certificates, if the card key is not at least 42 bytes shorter © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 24 / 82 than the issuer key, then an ICC Public Key Remainder field will need to be added to the card records. [6.2] Issuers should periodically review the length of their RSA key pairs and when deemed no longer fit for service should move to a longer key. Equally, public exponents should also be reviewed, particularly with respect to card keys. Issuers should note that whilst it might be reasonably argued that it is unlikely that all the resources required to break a key would be brought to bear on a single card and thus cards are not of high concern, an issuer with a large portfolio under a given issuer key would be a more attractive target, even if only in terms of causing reputational damage from what "might be done". Such reputational damage would not be solely restricted to the Issuer in question but would reflect badly on the payments industry in general. [6.3] The generation of primes should be performed in accordance with ISO/IEC18032. [6.4] For RSA key generation the two primes p and q for any given key pair should be the same length (|N|/2) and differ by at least 2|N|/2 - 100. See also ISO/IEC 18033-2. [6.5] For RSA, when selecting the value of the public exponents consideration should be given to performance issues. In general terminals will take longer to compute when using e = 216 + 1 than when using e = 3 and this may be quite noticeable in lower end devices1. The formats used within EMV for both signature generation and PIN encryption are considered to be secure for both values of e when deployed in ICCs satisfying the current security evaluations. [6.6] The random or pseudo-random process used for key generation should be such that it is not possible to predict any key or determine that certain keys within the key space are significantly more probable than any other. For further information on random or pseudo-random number generators see ISO/IEC 18031. [6.7] The physically secure device used to create the public key pairs and to secure the private key should be tamper responsive and satisfy the security requirements defined for HSMs (see Section 6.1.1.3). [6.8] Where the Payment System permits, it is recommended that the issuer should assign separate key pairs per Issuer Identifier to limit the number of cards using a single key pair 2 and thus the number of cards impacted by a compromise. [6.9] The Issuer Public Key should be managed in such a way that it is unchanged when sent to the CA for certification. [6.10] Issuer public/private key pairs should be unique to each Payment System. 1 For RSA other values than 3 or 216 + 1 are mathematically acceptable, but EMV terminal type approval is limited to the two recommended values, carried in 1 byte and 3 bytes respectively and therefore acceptance of other exponents is not assured. 2 Also in the event of a single issuer private key compromise the number of cards impacted through the Certificate Revocation List (CRL) process is reduced. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Procedural guidance on key generation can be found in Section 8. Page 25 / 82 Receive the Payment System Public Key(s). The issuer needs to receive and securely store one or more Payment System CA Public Keys. [6.11] The issuer should verify the integrity and origin of the CA Public Keys in accordance with the Payment System requirements. Request and Receive Issuer Public Key Certificates. The issuer needs to transfer each Issuer Public Key to the Payment System CA and receive in return a signed public key certificate. [6.12] The Issuer Public Keys should be transferred in such a way that the Payment System CA can verify their integrity and origin. [6.13] Upon receipt of a public key certificate from the Payment System CA, the issuer should verify it using the relevant Payment System Public Key. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 26 / 82 The following is a recommended format for ECC self-signed Issuer public key certificates. Self Signed Issuer Public Key Certificate Format and Encoding Issuer ID Issuer Public Key Alg Suite Ind and Expiry RID, CA PK Index, PS Proprietary Identifier and Tracking Number Issuer Public Key Issuer Private Key SIGN Certificate Signature Figure 5: Self-signed Issuer Public Key © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 27 / 82 Field Name Certificate Format Certificate Encoding Issuer Identifier Length (bytes) 1 1 5 Issuer Public 1 Key Algorithm Suite Indicator Certificate 4 Expiration Date RID Certification Authority Public Key Index Payment System Proprietary Identifier Tracking Number Issuer Public Key 5 1 4 4 NFIELD Issuer Public NSIG Key Certificate Signature Description Hex '28' Format b Hex '00' b Leftmost three to ten digits from the Primary Account Number (PAN), padded on the right with hex 'F's. Indicates the algorithms to be used with the Issuer Public Key that is used to verify ICC Public Key Certificates and this Issuer SelfSigned Public Key Certificate. Year, month, day (YYYYMMDD) after which this certificate is invalid. This field is also used to define the requested expiration date of the Issuer Public Key Certificate generated by the Payment System Certification Authority. Identifies the Payment System which is requested to sign the Issuer Public Key. When combined with the RID, uniquely identifies the Payment System key to be used to sign the Issuer Public Key and the associated algorithm suite. Proprietary Identifier whose usage is determined by the Payment System and whose value is assigned by Payment System or Issuer (e.g. for identifying a service). Proprietary Tracking Number whose value is assigned by Payment System or Issuer. Representation of Issuer Public Key (xcoordinate of Issuer public key point) on the curve identified by the Issuer Public Key Algorithm Suite Indicator. Output of digital signature ECC algorithm on concatenated first ten data objects using the Issuer private key on the elliptic curve identified by the Issuer Public Key Algorithm Suite Indicator. cn 10 b n 8 b b b n 8 b b Table 1: Self-signed Issuer Public Key Payment systems may decide individually whether to adopt the recommendation when processing Issuer certificate requests. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 28 / 82 Note on the use of SHA-1 and collisions It may be noted that EMV RSA based certificate and card signature formats utilise the SHA-1 hash algorithm. This has been brought into question owing to a series of attacks seeking to demonstrate the possibility of collisions. So far these attacks require a large amount of data in the input that can be freely manipulated to result in two manipulated strings that hash to the same output. If the hash output is given (e.g. within an EMV key certificate), then finding another input (e.g. another key) that hashes to the same value (pre-image resistance) is much harder than a simple collision. Even more so to find two inputs that hash to the same value (second-preimage resistance). EMV implementations with issuers and card personalisation that follow the guidance above are not affected by these attacks for the following reasons: • The certificates and signatures are highly structured, giving insufficient free data that can be manipulated. The format is “with message recovery” which means that an attacker essentially only has the Public Key Remainder as the data that can be manipulated. • There is a strictly managed relationship between issuers and the CA. Firstly, entities that are not registered as issuers with a CA are not in a position to request a certificate and secondly the format of the data submitted is specified and checked by a CA before a certificate will be granted. • Similarly, card issuance takes place within a secure environment managed by the issuer. Card certificates are prepared by the issuer as part of the personalisation data and there is no process for a rogue entity to apply for a card certificate. • Card signatures are delivered by code in the card that has been security evaluated. The amount of data that could be manipulated as input by a rogue terminal is limited and there is no practical benefit seen for fraudsters to obtain alternative card signatures based on a hash collision. 6.1.1.2 Symmetric Keys Issuer Master Key Generation. The issuer needs to securely generate and store one or more master derivation keys to be used to derive the ICC Master Keys unique to each card application. This requires the use of protected memory in a physically secure device, utilising a random or pseudo-random number generator. The choice of symmetric algorithm is at issuer discretion, however for historical reasons and for support of a common choice for stand-in services, DES (2TDES) has usually been selected. AES is the more recent recommendation and a gradual migration can be expected. DES/AES keys in the EMV specification are used for specific transaction functions. Card DES/AES keys are derived from an Issuer master derivation key at the time of provisioning. The resultant card level keys are unique. Issuer Master Keys include: © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 29 / 82 • Issuer Master Key (IMKAC) - used to derive the card keys that are used to generate MACs known as Application Cryptograms (AC). • Issuer Master Key for Secure Messaging for Integrity (IMKSMI) - used to derive card keys used in the secure messaging for integrity of post issuance processes between the card and the authorisation system, e.g., card blocking, application blocking/unblocking, updating card specific data, and PIN changes. • Issuer Master Key for Secure Messaging for Confidentiality (IMKSMC) - used to derive card keys used in secure messaging for confidentiality of post issuance processes between the card and the authorisation system, e.g. PIN change. Issuers may use several keys for the same purpose, for example across Issuer Identifier ranges. Payment systems may provide for additional key separation per Issuer Identifier using issuer Master Key sets containing multiple keys. The selected key used may be identified by means of an index, stored on the card and returned in the Issuer Application Data associated with the cryptogram. [6.14] DES/AES keys should be generated either inside a physically secure device protected by tamper responsive mechanisms, OR [6.15] by authorised personnel in component form through a process of combining components, each party generates a component that is the same length as the key being generated. The key combination process takes place inside a physically secure device. Moreover, the method of combining the components must be such that knowledge of any subset of the components yields no knowledge about the key value. Where keys are generated in component form at a card provisioner, at least one component should be generated by an employee of the issuer. [6.16] A random or pseudo-random process should be used such that it is not possible to predict any key or determine that certain keys within the key space are significantly more probable than any other. Further information concerning random or pseudo-random number generators can be found in ISO/IEC 18031. [6.17] It is recommended that issuers assign separate keys per Issuer Identifier in order to limit the number of cards using a single key. [6.18] A key should only be used for the cryptographic purpose for which it was intended and not for any other purpose, e.g., separate master derivation keys should be used to generate the card keys for application cryptogram generation, secure messaging integrity and secure messaging encryption. [6.19] Issuer symmetric master keys should be changed periodically (e.g. annually). This does not mean that keys must be updated in the deployed card base, but rather that the issuer must be able to manage several key versions at a time, each key version being destroyed once the last card containing its derived form has expired and disputes are no longer expected. Further general guidance on key generation is given in Section 8.1. • Transfer of Issuer Master Keys. If the issuer delegates responsibility for card provisioning or generation and verification of online cryptograms to a third party, or to different systems within his own processing centre, then the issuer needs to securely transfer the issuer master key(s) used to derive the ICC keys to the third party or other system (see also Section 8.3). © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 30 / 82 • Backup of Issuer Master Keys. In some situations it may be necessary to recover the issuer master keys used for the provisioning of cards and for the authorisation of card transactions. Inclusion of an offline backup is recommended to support recovery from a system wide attack. [6.20] When backing-up critical master keys it is recommended that a key either be enciphered under another key of at least equal cryptographic strength, or maintained as two or more components, secured using the principles of dual control and split knowledge. This process should be audited. 6.1.1.3 HSMs All key generation, key derivation and signing should be done in an HSM. For guidance on HSM security, see ISO 9564, ISO 13491 and PCI Security Standards Council www.pcisecuritystandards.org. 6.1.2 Security Counters If key use limits are provided by security counters, then values need to be established to control the situation if cards are abused. [6.21] Recommended values for a typical CPA contact online-offline environment are: • Offline PIN Decipherment Error Counter Limit = 500 • ATC maximum usage = 20,000 • AC Session Key Counter Limit = 20,000 • SMI Session Key Counter Limit = 1,000. Note that individual Payment Systems may provide alternative values. The Offline PIN Decipherment Error Counter is only incremented when PIN decipherment fails and the counter is never reset. The AC Session Key Counter is incremented every time an AC session key is derived and is reset when an ARPC is successfully verified. The SMI Session Key Counter is only incremented when the verification of a Secure Messaging MAC fails and is never reset. 6.1.3 Card Production (SDA) The following security relevant steps need to be performed by an issuer for each SDA card issued. This section is retained for continuity – production of SDA cards is no longer recommended. • Static data preparation. The issuer generates the data for card provisioning. The magnetic-stripe check value (CVC/CVV/CSC/CVN) in the Track 2 Equivalent Data should be calculated differently from the value on the magnetic-stripe in accordance with payment system rules. • Signing of static data. The issuer signs selected card static data using an issuer private key to produce the Signed Static Application Data. Two of the important data elements to sign are the SDA Tag List (tag 9F4A) and consequently, the AIP (tag 82). © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 31 / 82 [6.22] Issuers should follow Payment System recommendations and requirements for the data elements to be signed. It is strongly recommended that these include the SDA Tag List with AIP. • ICC Master Key derivation. The ICC Master Keys for application cryptograms and script message security must be derived from the appropriate issuer master key using card data such as Application PAN and Application PAN Sequence Number. • PIN generation. A Reference PIN must be generated for the ICC if offline PIN is supported. Its value should be the same as the online PIN value. • Provide data to card provisioning process. Make arrangements for the Issuer Public Key Certificate, the Certification Authority Public Key Index, Signed Static Application Data, derived secret keys, the Derivation Key Index (if used), and Reference PIN to be provisioned on the cards. All data for provisioning needs to be transferred securely to the card provisioner for writing to the ICC. [6.23] All data should be protected (e.g. by a MAC or signature) from the point at which it leaves the system that created the data, to the point at which it is stored on the card. [6.24] Secret keys and PINs must in addition be kept confidential. 6.1.4 Card Production (DDA / CDA / XDA / EDA) The following security relevant steps need to be performed by an issuer for each card supporting dynamic data authentication or Offline Enciphered PIN. • Static data preparation. The issuer generates the data for card provisioning. This may include an ICC ECC public key in support of contactless Kernel 8 EDA local authentication. • Signing of static data. Although not recommended, if the option to support SDA on a DDA/CDA card is chosen, then the issuer produces the Signed Static Application Data as per 6.1.3. Note that the same static data is also signed as part of signing the ICC Public Key (see below). This is by means of the ICCD Hash for ECC. • ICC Key Pair generation. A unique public/private key pair (RSA or ECC) must be securely generated for each ICC. If a separate key is to be used for offline PIN encipherment then this must also be securely generated. • Signing of ICC Public Key to produce ICC Public Key Certificate. The ICC Public Key (and associated data) together with selected card static data must be signed using one of the Issuer Private Keys to form the ICC Public Key Certificate. The private key used for signing the certificate must correspond to the Issuer Public Key Certificate being provisioned on the card. A similar certificate is produced in the case that a separate key is used for offline PIN encipherment. • ICC Master Key derivation. The ICC Master Keys for application cryptograms and script message security must be derived from the appropriate Issuer Secret Key using card data such as Application PAN and Application PAN Sequence Number. © 1994-2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV® Issuer and Application Security Guidelines Page 32 / 82 • PIN generation. A Reference PIN must be generated for the ICC if offline PIN is supported. Its value should be the same as the online PIN value. • Provide data to card provisioning process. Make arrangements for Certification Authority Public Key Index, Signed Static Application Data, Derivation Key Index (if used), Issuer Public Key Certificate, ICC Public Key Certificate, ICC Private Key, derived secret keys, and Reference PIN to be provided to the card provisioning process. • Card Signature Process. Cards with RSA keys that use CRT (Chinese Remainder Theorem) for the signature calculation require a specific evaluation that it is implemented securely (see Section 6.1.6.2). All data for provisioning needs to be transferred securely to the card provisioner for writing to the ICC. [6.25] All data should be kept confidential by procedural processes and in addition should be cryptographically protected for integrity (e.g. by a MAC or signature) from the point at which it leaves the system that created the data, to the point at which it is stored on the card. [6.26] Secret and private keys and PINs must in addition be kept cryptographically confidential (e.g. by encryption). [6.27] After provisioning both the ICC issuer and the provisioner must erase all records of the ICC private key. 6.1.5 CVM Choice Issuers must provision each ICC with a prioritised list of CVMs supported by the ICC (e.g. online PIN, offline enciphered PIN, offline plaintext PIN, signature, No CVM). If the ICC supports offline PIN then the card should be provisioned with the value of the cardholder’s PIN (note that the PIN may also be loaded into the ICC post-issuance using script commands). If the ICC supports offline enciphered PIN then the ICC must be provisioned with a private key and public key certificate (see Section 6.1.4). The provisioned ICC and PIN must be securely and separately transferred to the cardholder following th