PCI Watch

Tracking changes across the Payment Card Industry

SB nº 243: Introduction of XDA/ODE for EMV Specifications

v1.0 Specification Bulletins
Contact Acceptance Device

EMV® Specification Bulletin No. 243 First Edition October, 2021 Introduction of XDA/ODE for EMV Specifications This Specification Bulletin explains the additional requirements to support XDA/ODE for current EMV Contact Specifications.

Applicability

This Specification Bulletin applies to:

  • 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 3 – Application Specification, Version 4.3, November 2011
  • EMV Integrated Circuit Card Specifications for Payment Systems, Book 4 – Cardholder, Attendant, and Acquirer Interface Requirements, Version 4.3, November 2011

Related Documents

  • None

Effective Date

  • January, 2023

Description

This bulletin describes the requirements to support XDA (Extended Data Authentication) and ODE (Offline Data Encipherment) using ECC (Elliptic Curve Cryptography) for contact EMV transactions. Editorial updates are also included in this bulletin. In some sections, the whole section, paragraph, or table is listed in this Bulletin for readability. Unless otherwise noted, underlined text indicates revisions and strikethroughs indicate deleted text.

countries.

In section 1.2, the following description is added: Part II covers:

  • Offline static data authentication (SDA)
  • Offline dynamic data authentication (DDA and CDA and XDA) In section 2, the following references are added: FIPS 202 IEEE P1363 ISO/IEC 11770-6 ISO/IEC 14888-3 ISO/IEC 15946-1 ISO/IEC 15946-5 ISO/IEC 19772 SEC 1 SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions Standard Specifications For Public-Key Cryptography Information technology – Security techniques – Key management — Part 6: Key derivation Information technology – Security techniques – Digital signatures with appendix — Part 3: Discrete logarithm based mechanisms Information technology – Security techniques – Cryptographic techniques based on elliptic curves — Part 1: General Information technology – Security techniques – Cryptographic techniques based on elliptic curves — Part 5: Elliptic curve generation Information technology – Security techniques – Authenticated encryption Elliptic Curve Cryptography (available at http://www.secg.org) In section 3, Definitions, delete the following terms: Accelerated Revocation A key revocation performed on a date sooner than the published key expiry date. Key Expiry Date 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. countries. Key Life Cycle Key Replacement Key Revocation Key Revocation Date Planned Revocation 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. A key revocation performed as scheduled by the published key expiry date. In section 4.1, the following Abbreviations are added in alphabetical order: AAD AES EC-SDSA ECC ICCD KD NFIELD NHASH NSIG ODA ODE SHA-2 SHA-3 UN XDA Additional Authenticated Data Advanced Encryption Standard Elliptic Curve Schnorr Digital Signature Algorithm Elliptic Curve Cryptography Issuer Certified Card Data Key Derivation Length of a finite field element Output length of a hash function Length of an ECC Digital Signature Offline Data Authentication Offline Data Encipherment Secure Hash Algorithm 2 (includes SHA-256 and SHA-512) Secure Hash Algorithm 3 Unpredictable Number Extended Data Authentication countries. Section 5 is updated as below: This section describes SDA, an offline data authentication mechanism that utilises RSA public key cryptography. Offline static data authentication is performed by the terminal using a digital signature scheme based on public key techniques to confirm the legitimacy of critical ICC-resident static data. This detects unauthorised alteration of data after personalisation. The only form of offline static data authentication defined is Static Data Authentication (SDA) that verifies the data identified by the Application File Locator (AFL) and by the optional Static Data Authentication Tag List. SDA requires the existence of a certification authority, which is a highly secure cryptographic facility that ‘signs’ the issuer’s public keys. Every terminal conforming to this specification shall contain the appropriate certification authority’s public key(s) for every application recognised by the terminal. This specification permits multiple AIDs to share the same ‘set’ of Certification Authority Public Keys. The relationship between the data and the cryptographic keys is shown in Figure 1. Section 5 Table 1 and its description are updated as below: 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 countries. 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. Section 6 is updated as below: 6 Offline Dynamic Data Authentication (DDA, CDA) This section describes DDA and CDA, two offline dynamic data authentication mechanisms that utilise RSA public key cryptography. 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 RSA 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. countries. Section 6 Table 8 and its description are updated as below: ICCs that support DDA or CDA 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 countries. Section 6 Table 9 and its description are updated as below: ICCs that support DDA or CDA 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. DDA and CDA 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 DDA or CDA 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. countries. Section 6.6.1, Description number 1 is updated as below: 1. The terminal issues a first or second GENERATE AC command with the 'CDA signature requested' bits in the GENERATE AC command set to '10' according to sections 6.5.5.4 and 9.3 of Book 3. In Section 7, the first two paragraphs are updated as below: 7 Personal Identification Number and Biometric Data Encipherment using RSA This section relates only to PIN and Biometric Data Encipherment using RSA. If supported, Personal Identification Number (PIN) encipherment for offline PIN verification is performed by the terminal using an RSA based encipherment mechanism in order to ensure the secure transfer of a PIN from a secure tamper-evident PIN pad CVM capture device to the ICC. The entirety of Section 10 is replaced with the following two paragraphs: The contents of this section have been deleted. With the maximum size of RSA keys already in use, there is no longer a need for a structured certification authority process to replace shorter keys, as was required for earlier versions of this specification. Some minor residual content has been incorporated into section 11. Section 11.2 is updated as below: This section specifies the requirements for the management by acquirers of the Certification Authority Public Keys in the terminals. The requirements cover the following phases:
  • Introduction of a Certification Authority Public Key in a terminal
  • Storage of a Certification Authority Public Key in a terminal
  • Usage of a Certification Authority Public Key in a terminal
  • Withdrawal of a Certification Authority Public Key from a terminal Terminal management functions shall allow for the installation and withdrawal of Certification Authority Public Keys by acquirers or their agents. The terminal management processes need to ensure the authenticity of the keys and protect the integrity of the installed keys. Processes also need to confirm the authenticity of the instructions to introduce or withdraw keys and to confirm that the action has been completed. countries. Section 11.2.1 is updated as below: When a payment system has decided thatFor the introduction of a new Certification Authority Public Key is to be introduced, a process is executed that ensures the distribution of the new key from the payment systems make the keys available to each acquirer Acquirers. It is then the acquirer’s responsibility to ensure that the new Certification Authority Public Key and its related data (see section 11.2.2) is conveyed to installed in its terminals. The Certification Authority Public Key will also be made available to Issuers to allow the verification of Issuer Public Key Certificates requested by an Issuer. The following principles apply to the introduction of a Certification Authority Public Key from an acquirer to its terminals:
  • The terminal shall be able to verify that it received the Certification Authority Public Key and its related data error-free from the acquirer.
  • The terminal shall be able to verify that the received Certification Authority Public Key and related data originated from its legitimate acquirer.
  • The acquirer shall be able to confirm that the new Certification Authority Public Key was introduced correctly in its terminals. One process for the introduction of Certification Authority Public Keys into terminals is to install the keys during terminal manufacture and deployment. The keys may be made available by the payment systems to terminal vendors, or acquirers may specify the keys necessary for their particular market segments. On being informed of a new key being available, Acquirers are expected to install it in their terminal base within six months. During installation into the terminal the integrity of the Certification Authority Public Key and its related data is confirmed, see section 10.2 of Book 4. For RSA, the integrity of the Certification Authority Public Key may be protected using a Check Sum calculated in the same manner as is used to protect the integrity in storage as described in section 11.2.2. For ECC, the Certification Authority Public Key will be self-signed for distribution according to Table 26a. A diagram showing the construction of a self-signed Certification Authority Public Key Certificate is shown in Figure 13a. Successful verification of the self-signed Certification Authority Certification Authority Public Key Certificate also ensures that the terminal supports the algorithm suite associated with the Certification Authority Public Key and that will be used for verifying Issuer Public Key Certificates. countries. Self Signed Certification Authority Public Key Certificate Format and Encoding Payment System ID Certification Authority Key Index Certification Authority Public Key Algorithm Suite Indicator Certification Authority Public Key Signature Block Certification Authority Private Key SIGN Figure 13a: ECC Self-signed Certification Authority Public Key Diagram As shown in Figure 13a, the self-signed Certification Authority Public Key Certificate consists of a plain text prefix followed by a signature block. The certificate is specified in the following table where for this version of the specifications the encoding of the certificate is binary (i.e. value, value, value... with no additional identifier or length fields). countries. Name Description Length (bytes) 1 Certificate Format Always Hex value '20'. 1 2 Certificate Encoding Always Hex value '00' for this version 1 of the specifications. 3 RID Identifies the Payment System to 5 which the Certification Authority public key is associated. The RID is identified in the AID (first 5 bytes). 4 Certification Authority When combined with the RID, 1 Public Key Index uniquely identifies the Certification Authority Public Key. 5 Certification Authority Indicates the algorithms to be used 1 Public Key Algorithm with the Certification Authority Suite Indicator Public Key. 6 Certification Authority Representation of Certification NFIELD Public Key Authority Public Key (x-coordinate of Certification Authority public key point) on the curve identified by the Certification Authority Public Key Algorithm Suite Indicator. 7 Certification Authority Output of digital signature ECC NSIG Public Key Certificate algorithm on concatenated first six Signature data objects using the Certification Authority private key on the elliptic curve identified by the Certification Authority Public Key Algorithm Suite Indicator. Table 26a: ECC Self-Signed Certification Authority Public Key & Related Data (Binary Encoding) At the end of the installation, after verifying the integrity of the public key and its related data, the terminal shall apply storage integrity protection of the public key and its related data to allow the subsequent re-verification of their integrity. This may be achieved using the Certification Authority Public Key Check Sum in Tables 27 and 27a or a proprietary mechanism. Section 11.2.2 is updated as below: Terminals that support RSA-based offline static or dynamic data authentication, offline PIN encipherment, or biometric data encipherment shall provide support for at least six RSA Certification Authority Public Keys per RID for EMVCo member EMV-based payment systems’ debit/credit applications based on this specification. countries. Terminals that support XDA or ECC ODE shall provide support for the ECC domain parameters for the two ECC curves specified in Annex B2.2.2 and at least ten ECC Certification Authority Public Keys for either the same or different curves (and related key information) per RID for EMV-based payment systems’ payment applications based on this specification. Each Certification Authority Public Key is uniquely identified by the 5-byte RID that identifies the payment system in question, and the 1-byte Certification Authority Public Key Index, unique per RID and assigned by that payment system to a particular Certification Authority Public Key. For each Certification Authority Public Key, the minimum set of data elements that shall be available in the terminal is specified in Table 27 (for RSA) or Table 27a (for ECC). The RID and the Certification Public Key Index together uniquely identify the Certification Authority Public Key and associate it with the proper payment system. For RSA, the Certification Authority Public Key Algorithm Indicator identifies the digital signature algorithm to be used with the corresponding Certification Authority Public Key. The only acceptable value at this moment is hexadecimal '01', indicating the usage of the RSA algorithm in the digital signature scheme as specified in Annex A2.1 and Annex B2.1. The Hash Algorithm Indicator specifies the hashing algorithm to produce the Hash Result in the digital signature scheme. The only acceptable value at this moment is hexadecimal '01', indicating the usage of the SHA-1 algorithm. For ECC, the Certification Authority Public Key Algorithm Suite Indicator identifies the Algorithm Suite to be used with the corresponding Certification Authority Public Key. The only acceptable values at this moment are those specified in Annex B2.4.1. Like the Certification Authority Public Keys and related data, the integrity of the ECC domain parameters associated with each suite shall be protected by the terminal (as shall other sensitive terminal data and code). The Certification Authority Public Key Index is unique and not duplicated within a RID irrespective of the algorithm associated with the Certification Authority Public Key. An RSA key and an ECC key for the same RID cannot have the same Index. The Certification Authority Public Key Check Sum is derived using the technique specified in section 10.2 of Book 4, to ensure that a Certification Authority Public Key and its related data are received error-free. The terminal may use this data element to subsequently re-verify the integrity of a Certification Authority Public Key and its related data. Alternately, the terminal may use another technique to ensure the integrity of this data. The integrity of the stored Certification Authority Public Keys and their related data should be verified periodically. This may be achieved using the Certification Authority Public Key Check Sum in Table 27 and Table 27a or a proprietary mechanism. Field Name Registered Application Provider Identifier (RID) Length 5 Description Identifies the payment system to which the Certification Authority Public Key is associated Format b countries. Field Name Certification Authority Public Key Index Certification Authority Hash Algorithm Indicator Certification Authority Public Key Algorithm Indicator Certification Authority Public Key Modulus Certification Authority Public Key Exponent Certification Authority Public Key Check Sum 14 Length 1 Description Identifies the Certification Authority Public Key in conjunction with the RID Format b 1 Identifies the hash algorithm used to b produce the Hash Result in the digital signature scheme 1 Identifies the digital signature algorithm b to be used with the Certification Authority Public Key Vvar. Value of the modulus part of the b (max Certification Authority Public Key 248) 1 or 3 Value of the exponent part of the b Certification Authority Public Key, equal to 3 or 216 + 1 20var. A check value calculated on the b concatenation of all parts of the Certification Authority Public Key (RID, Certification Authority Public Key Index, Certification Authority Public Key Modulus, Certification Authority Public Key Exponent) using SHA-1. Alternatively, one of the hash algorithms from section B2.3 may be used Table 27: Minimum Set of Certification Authority Public Key Related Data Elements to be Stored in Terminal (RSA) 40 Only necessary if used to verify the integrity of the Certification Authority Public Key. countries. Field Name Registered Application Provider Identifier (RID) Certification Authority Public Key Index Certification Authority Public Key Algorithm Suite Indicator Certification Authority Public Key Certification Authority Public Key Check Sum 40 Length 5 1 1 2*NFIELD var. Description Identifies the payment system to which the Certification Authority Public Key is associated Identifies the Certification Authority Public Key in conjunction with the RID Identifies the algorithm suite to be used with the Certification Authority Public Key. See section B2.4.1. Representation of Certification Authority Public Key (xy-coordinates of Certification Authority Public Key point) on the curve identified by the Certification Authority Public Key Algorithm Suite Indicator. A check value calculated on the concatenation of the above data elements using a hash algorithm. The same hash algorithm may be used for all keys in the terminal or the hash algorithm associated with the Certification Authority Public Key Algorithm Suite may be used Format b b b b b Table 27a: Minimum Set of Certification Authority Public Key Related Data Elements to be Stored in Terminal (ECC) Section 11.2.3 is updated and combined with section 11.2.4 as below:

11.2.3 Certification Authority Public Key Usage Withdrawal The usage of a Certification Authority Public Key during a transaction shall be as specified in this specification. When a payment system has decided to withdraw revoke one of its Certification Authority Public Keys, an acquirer shall ensure that this Certification Authority Public Key can no longer be used in its terminals for offline static and dynamic data authentication during transactions as of a certain date. It is recommended that acquirers do not implement expiry expiration dates coded into the terminals but instead remove keys according to the expiry expiration dates as indicated by the payment systems. The following principles apply for the withdrawal by an acquirer of Certification Authority Public Keys from its terminals:

countries.

  • The terminal shall be able to verify that it received the withdrawal notification error-free from the acquirer (or its agent).
  • The terminal shall be able to verify that the received withdrawal notification originated from its legitimate acquirer (or its agent).
  • The acquirer shall be able to confirm that a specific Certification Authority Public Key was indeed withdrawn correctly from its terminals. For more details on Certification Authority Public Key revocation and the corresponding timescales involved, see section 10. Other than in the extreme case of a Certification Authority Public Key compromise, keys are expected to be withdrawn on the previously publicised expiration dates. To assist with this, EMVCo will conduct annual review sessions for Certification Authority Public Key pair strength evaluation, using state of the art information and analysis from the fields of computer science, cryptography, and data security. All Certification Authority Public Keys will have December 31st as planned expiration date. Public Key expiration dates will be set well in advance to allow card portfolio lifetimes to meet business needs and Issuers should ensure that IC Cards expire no later than the expiration date of the Issuer Public Key Certificates. Acquirers need to remove the Certification Authority Public Keys from service in their terminals within a specific grace period after expiration. This is expected to be six months starting from the planned expiration date (until June 30th of the following calendar year) but may be deferred at payment system discretion. It may be noted that much of this material relates to the introduction of longer RSA keys, necessary as the shorter keys lose security strength. This sequence will end when the 1984 bit keys reach an expiration date. Whilst ECC keys are expected to be stable in the long term, the ability to install and withdraw keys is still necessary to allow for infrastructure changes, such as the emergence of a new domestic payment system. countries. Section 12 is added after Section 11: 12 Offline Dynamic Data Authentication using ECC (XDA) This section describes Extended Data Authentication (XDA), an offline dynamic data authentication mechanism that utilises ECC public key cryptography. When performing XDA the ICC generates a digital signature that is verified by the terminal. This digital signature authenticates the ICC and confirms the legitimacy of the Application Cryptogram (AC) and other critical data originating from the ICC and terminal. This precludes the counterfeiting of any such card and provides data integrity between the card and the terminal. XDA signatures are generated by the ICC in response to the GENERATE AC command. XDA requires the existence of a certification authority, a highly secure cryptographic facility that ‘signs’ the Issuer’s Public Keys. If a terminal application is configured to be XDA capable then the terminal shall contain the appropriate certification authority’s public key(s) for that application. This specification permits multiple AIDs to share the same Certification Authority Public Keys. The relationship between the data and the cryptographic keys is shown in Figure 13b. See also section 11.2. 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 13b: Diagram of offline dynamic data authentication countries. ICCs that support XDA contain an ICC Private Key that the ICC uses for generating the Signed Dynamic Application Data. ICCs that support XDA shall generate the data element listed in Table 27b: 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 and terminal data, as described in section 12.5. Table 27b: Data Element Generated for XDA XDA uses the signature scheme specified in Annex A2.2 and Annex B2.2. Section 12.1 contains an overview of the keys and certificates involved in the XDA process. Sections 12.2, 12.3 and 12.4 specify the initial steps in the process, namely:
  • Retrieval of the Certification Authority Public Key by the terminal.
  • Authentication and Recovery of the Issuer Public Key by the terminal.
  • Authentication and Recovery of the ICC Public Key by the terminal. If the first of these steps fails then the CA ECC key is considered to be missing and therefore XDA is considered to have failed. If either of the last two of these steps fail then ECC key recovery is considered to have failed and therefore XDA is considered to have failed. Terminal actions in case of ECC key recovery failures are addressed in section 6.3 of Book 4. Note that ECC key recovery failure is not reflected in the Terminal Verification Results before the GENERATE AC command is sent and so cannot influence Terminal Action Analysis until after the GENERATE AC command is sent. The final step of the XDA process consists of generation by the ICC and verification by the terminal of the Signed Dynamic Application Data. Section 12.5 specifies the dynamic signature generation and verification processes for XDA. If dynamic signature verification fails then XDA is considered to have failed. XDA shall only be considered successful if CA key retrieval is successful and ECC key recovery is successful and XDA signature verification is successful. countries.

12.1 Keys and Certificates To support offline dynamic data authentication an ICC shall have its own public key pair consisting of a private signature key and the corresponding public verification key. The ICC Public Key shall be stored in the ICC in a public key certificate tag '9F46'. To support offline data encipherment (PIN or biometrics) a separate public key certificate is required with an independent Algorithm Suite Indicator (see section 13). Two certificates are still required even if the same key pair is used for both XDA and ODE40a. 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 authenticate and recover the ICC Public Key, which is then employed to verify the ICC’s dynamic signature (or to encipher offline data). To generate the Issuer Public Key Certificate, the Certification Authority signs the Issuer Public Key data using the Certification Authority Private Key SCA with the signature scheme specified in Annex A2.2. To generate the ICC Public Key Certificate, the Issuer signs the ICC Public Key data using the Issuer Private Key SI with the signature scheme specified in Annex A2.2. Aside from the Certification Authority Public Key, all the information necessary for ICC Public Key authentication is specified in Table 27c 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. All public keys are ECC keys (a hybrid approach using a combination of RSA and ECC keys is not supported). 40a This is unlike RSA certificates, where if a public key is used for both ODA and ODE then only a single public key certificate is needed.

countries.

Tag — '8F' '90' '9F46' '9F2D' — Name Registered Application Provider Identifier (RID) Certification Authority Public Key Index Issuer Public Key Certificate ICC Public Key Certificate ICC Public Key Certificate for ODE Static data to be authenticated Description 5 byte identifier obtained from the Application Identifier (AID) 1 byte which indicates which of the application’s Certification Authority Public Keys that reside in the terminal is to be used with this ICC. Includes a digital signature on the Issuer Public Key and other data that enables the terminal to obtain an authenticated copy of the Issuer Public Key and other data as described in section 12.3 Includes a digital signature on the ICC Public Key and other data that enables the terminal to obtain an authenticated copy of the ICC Public Key and other data as described in section 12.4. Includes a digital signature on the ICC Public Key for ODE and other data that enables the terminal to obtain an authenticated copy of the ICC Public Key for ODE and other data as described in section 12.4. (only needed if ODE is supported) The ICC-resident static data to be authenticated as specified in section 10.3 of Book 3. Table 27c: ICC Data Required for Public Key Authentication for XDA and ECC ODE 12.1.1 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 XDA 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, ECC key recovery fails as described in section 12.3, Step 7. The requirements for the CRL are listed in section 5.1.2.

countries.

12.2 Retrieval of Certification Authority Public Key To support offline dynamic data authentication (and offline data encipherment), terminals store Certification Authority Public Keys for each RID along with associated key-related information (see section 11.2.2). The terminal is able to locate any such key (and key-related information) given the RID and Certification Authority Public Key Index as provided by the ICC. Using the RID and Certification Authority Public Key Index read from the card, the terminal shall identify and retrieve the terminal-stored Certification Authority Public Key and associated key-related information, including the Certification Authority Public Key Algorithm Suite Indicator. If the terminal does not have the public key associated with this index and RID or the index is missing (per section 7.5 of Book 3), then the terminal shall consider the CA ECC key missing and XDA (and/or ODE) processing is considered to have failed. Otherwise, the terminal shall continue processing with the steps in the following section.

12.3 Authentication and Recovery of Issuer Public Key The Issuer Public Key is contained in the Issuer Public Key Certificate (tag '90') included in data read from the ICC. If the Issuer Public Key Certificate is missing (per section 7.5 of Book 3) then the terminal shall consider ECC key recovery as failed and XDA (and/or ODE) processing is considered to have failed. Authentication and recovery of the Issuer Public Key consists of verification of the signature in the Issuer Public Key Certificate using the Certification Authority Public Key and the algorithms indicated by Certification Authority Public Key Algorithm Suite Indicator, verification of the format and values of the data elements found in the certificate, and recovery of the y-coordinate from the x-coordinate. This process is described below. The result of these verifications is either a valid and authentic copy of the Issuer Public Key, or failure. Table 27d shows the Issuer Public Key Certificate and is the data signed by the Certification Authority Private Key and the resulting signature. That is, the concatenation of the data elements 1 through 9 in this table forms the input to the signature function in Annex A2.2.2. Name Description Length (bytes) 1 Issuer Certificate Always Hex value '12' for this version of the 1 Format specifications. 2 Issuer Certificate Always Hex value '00' for this version of the 1 Encoding specifications.

countries.

Name 3 Issuer Identifier 4 Issuer Public Key Algorithm Suite Indicator 5 Issuer Certificate Expiration Date 6 Issuer Certificate Serial Number 7 RID 8 Certification Authority Public Key Index 9 Issuer Public Key 10 Issuer Public Key Certificate Signature Description Uniquely identifies the Issuer in the context of the RID (leftmost 3-10 digits from the PAN padded to the right with hex 'F's). Identifies the algorithm suite to be used with the Issuer Public Key when verifying issuer signatures. See section B2.4. Issuer Certificate Expiration Date (YYYYMMDD, UTC). Number assigned to the issuer certificate that is unique amongst all certificates created by the payment system key that created the issuer certificate. Payment System identified in the AID (first 5 bytes). In conjunction with the RID, identifies which of the Kernel application’s Certification Authority Public Keys (and associated algorithms) to use when verifying the issuer certificate. Representation of Issuer Public Key (x-coordinate of Issuer Public Key point) on the curve identified by the Issuer Public Key Algorithm Suite Indicator. A digital signature on data objects 1 through 9 of this table. Verified using the Certification Authority Public Key and algorithms identified by data object 8. Length (bytes) 5 1 4 3 5 1 NFIELD NSIG Table 27d: Issuer Public Key Certificate tag '90' (ECC) Note: When using EC-SDSA, the length NSIG of a digital signature is equal to the length NHASH of the hash plus the length of a field element. Thus, if using P-256 and a 256-bit hash algorithm (such as SHA-256), then NHASH = NFIELD = 32 and NSIG = NHASH + NFIELD = 64. Furthermore, for item 10 in Table 27d the lengths NSIG, NHASH, and NFIELD are determined by the Certification Authority Public Key Algorithm Suite Indicator whereas for item 9 in Table 27d the length NFIELD is determined by the Issuer Public Key Algorithm Suite Indicator. To authenticate the Issuer Public Key the terminal shall perform the following steps: 1. Check that the length in bytes of the Issuer Public Key Certificate as defined in Table 27d is equal to NFIELD + NSIG + 21. If this fails, ECC key recovery has failed. 2. Check the Issuer Certificate Format. If it is not '12', ECC key recovery has failed. 3. Check the Issuer Certificate Encoding. If it is not '00', ECC key recovery has failed.

countries.

4. Verify that the Issuer Identifier matches the leftmost 3 - 10 digits of the PAN (tag '5A') (allowing for the possible padding of the Issuer Identifier with hexadecimal 'F's). If not, ECC key recovery has failed. 5. Verify that the date specified in the Issuer Certificate Expiration Date is equal to or later than today’s date. If the Issuer Certificate Expiration Date is earlier than today’s date, the certificate has expired, in which case ECC key recovery has failed. 6. Verify that the RID and the Certification Authority Public Key Index in the certificate matches the RID and the Certification Authority Public Key Index used to retrieve the Certification Authority Public Key. If not, ECC key recovery has failed. 7. Verify that the concatenation of RID, Certification Authority Public Key Index, and Issuer Certificate Serial Number is valid. If not, ECC key recovery has failed.40b 8. Verify that the Issuer Public Key Algorithm Suite Indicator is an approved identifier in accordance with Annex B2.4. If not, then ECC key recovery has failed. 9. Concatenate the first 9 data elements of the Issuer Public Key Certificate 10. Using the Certification Authority Public Key and the algorithms indicated by the associated Certification Authority Public Key Algorithm Suite Indicator, verify as specified in Annex A2.2.3 the Issuer Public Key Certificate Signature contained in the Issuer Public Key Certificate (tag '90') with the concatenated data from step 9 being the MSG as specified in Annex A2.2.3. If signature verification fails then ECC key recovery has failed. 11. Recover the y-coordinate of the Issuer Public Key point using the Point4x() function applied to the x-coordinate obtained from the Issuer Public Key field of the certificate (item 9 in Table 27d) as described in section B2.2.1(e). If the above steps were all successful then authentication and recovery of the Issuer Public Key is successful and the terminal shall continue with the steps in the following section. If any of the above steps were not successful (i.e. ECC key recovery has failed) then XDA (and/or ODE) processing is considered to have failed.

12.4 Authentication and Recovery of ICC Public Key The ICC Public Key is contained in the ICC Public Key Certificate (tag '9F46') included in data read from the ICC. If ODE is supported (see section 13) then the ICC Public Key for ODE is contained in the ICC Public Key Certificate for ODE (tag '9F2D') included in data read from the ICC. If the ICC Public Key Certificate is missing (per section 7.5 of Book 3) then the terminal shall consider ECC key recovery as failed and XDA (and/or ODE) processing is considered to have failed. 40b This step is optional and is to allow the revocation of the Issuer Public Key Certificate against a list that may be kept by the terminal.

countries.

Authentication and recovery of the ICC Public Key consists of verification of the signature in the ICC Public Key Certificate using the Issuer Public Key and the algorithms indicated by the Issuer Public Key Algorithm Suite Indicator, verification of the format and values of the data elements found in the certificate, and recovery of the y-coordinate from the x-coordinate. This process is described below (under ICC Public Key Authentication and Recovery). As well as the ICC Public Key, the signature in the ICC Public Key Certificate is intended to protect the authenticity of certain other static card data. So verification of the signature additionally involves the verification of the format and values of other data elements protected by the certificate and this includes the Static Data to be Authenticated as specified in Book 3 section 10.3. This process is described below (under ICC Public Key Authentication and Recovery). The same certificate format and certificate verification process is used for ICC Public Key Certificates for ODE. The result of these verifications is either a valid and authentic copy of the ICC Public Key and the Static Data to be Authenticated, or ECC key recovery failure. Name Description Length (bytes) 1 ICC Certificate Format Always Hex value '14' for this version of 1 the specifications. 2 ICC Certificate Encoding Always Hex value '00' for this version of 1 the specifications. 3 ICC Public Key Algorithm Suite Indicator Identifies the algorithm suite to be used 1 with the certified ICC Public Key (a Signature Algorithm Suite in the case of tag '9F46' and an ODE Algorithm Suite in the case of tag '9F2D'. See sections B2.4.1 and B2.4.2 respectively). 4 ICC Certificate ICC Certificate Expiration Date 4 Expiration Date (YYYYMMDD, UTC). 5 ICC Certificate ICC Certificate Expiration Time 2 Expiration Time (HHMM, UTC). 6 ICC Certificate Serial Number assigned to the ICC certificate 6 Number that is unique amongst all certificates created by the issuer key that created the ICC certificate 7 ICCD Hash Encoding For this version of the specifications, 1 always Hex value '00', indicating TLV encoding of the input is used when computing the ICCD Hash. 8 ICCD Hash Identifies the hash algorithm used to 1 Algorithm Indicator calculate the ICCD Hash. See section B2.3.

countries.

Name Description Length (bytes) 9 ICCD Hash Hash of the Issuer Certified Card Data (ICCD) using the hash function identified by the ICCD Hash Algorithm Indicator. NHASH 10 ICC Public Key Representation of ICC Public Key (x-coordinate of ICC Public Key point) on the curve identified by the ICC Public Key Algorithm Suite Indicator. NFIELD 11 ICC Public Key A digital signature on data objects 1 NSIG Certificate Signature through 10 of this table. Verified using the Issuer Public Key obtained from the certificate in Table 27d and the algorithms identified by the Issuer Public Key Algorithm Suite Indicator. Table 27e: ICC Public Key Certificate tag '9F46' (XDA) and tag '9F2D' (ODE) Note: When using EC-SDSA the length NSIG of a digital signature is equal to the length of the hash plus the length of a field element. Thus, if using P-256 and a 256-bit hash algorithm (such as SHA-256) then NHASH = NFIELD = 32 and NSIG = NHASH + NFIELD = 64. Furthermore, for item 11 in Table 27e the lengths NSIG, NHASH, and NFIELD are determined by the Issuer Public Key Algorithm Suite Indicator whereas for item 10 in Table 27e the length NFIELD is determined by the ICC Public Key Algorithm Suite Indicator. ICCD Hash As part of ICC Public Key authentication, the terminal shall check that the hash of the Issuer Certified Card Data (ICCD) is equal to the ICCD Hash included in the ICC Public Key Certificate (see Table 27e). The ICCD is the Static Data to be Authenticated which is equal to the concatenation of records identified by the AFL as participating in Offline Data Authentication, the tag, length and value of Application Interchange Profile, the tag, length and value of Application Identifier (AID) – terminal, and the tag, length, and value of PDOL (if received from the card) as specified in section 10.3 of Book 3. It is expected that authenticated records will include Application Primary Account Number (PAN), Application Primary Account Number (PAN) Sequence Number, and Application Expiration Date. Note: For this version of the specifications, the encoding method used for the ICCD is restricted to TLV encoding and so the ICCD Hash will be computed over the data objects formatted in TLV representation as described in section 10.3 of Book 3. ICC Public Key Authentication and Recovery The terminal shall perform the following steps:

countries.

1. Check that the first byte of the certificate is '14' and that the length in bytes of the ICC Public Key Certificate as defined in Table 27e is equal to 17 + NHASH + NFIELD + NSIG. If this fails, ECC key recovery has failed. 2. Check the ICC Certificate Encoding. If it is not '00', ECC key recovery has failed. 3. Check that the certificate expiration time and date recovered from the certificate is later than the current time and date. If this is not the case then the certificate has expired and ECC key recovery has failed. 4. Verify that the ICC Public Key Algorithm Suite Indicator is an approved identifier in accordance with Annex B2.4 (approved for XDA if tag '9F46' or approved for ODE if tag '9F2D'). If not, then ECC key recovery has failed. 5. Verify that the ICCD Hash Algorithm Indicator is an approved identifier in accordance with Annex B2.3). If not, then ECC key recovery has failed. 6. Check that the hash of the Issuer Certified Card Data (ICCD) using the hash algorithm identified by ICCD Hash Algorithm Indicator is equal to the ICCD Hash included in the ICC Public Key Certificate (see Table 27e). If this check fails then ECC key recovery has failed. 7. Concatenate the first 10 data elements of the ICC Public Key Certificate. 8. Using the Issuer Public Key and the algorithms indicated by the associated Issuer Public Key Algorithm Suite Indicator, verify as specified in Annex A2.2.3 the Digital Signature contained in the ICC Public Key Certificate with the concatenated data from step 7 being the MSG as specified in Annex A2.2.3. If signature verification fails, ECC key recovery has failed. 9. Recover the y-coordinate of the ICC Public Key point using the Point4x() function applied to the x-coordinate obtained from the ICC Public Key field of the certificate (item 10 in Table 27e) as described in section B2.2.1(e). If the above steps were all successful then authentication and recovery of the ICC Public Key is successful and the terminal shall continue with the steps in the following section (in case of tag '9F46') or section 13.2 (in case of tag '9F2D'). If any of the above steps were not successful (i.e. ECC key recovery has failed) then XDA processing is considered to have failed (in case of tag '9F46') or ODE processing is considered to have failed (in case of tag '9F2D').

12.5 XDA Signature Generation and Verification Before the terminal can verify the XDA signature it needs to authenticate and recover the relevant public keys as described in sections 12.3 and 12.4. The authentication and recovery of the public keys may happen at any time before processing the response to the first GENERATE AC command.

12.5.1 Requesting, generating and verifying an XDA signature Conditions for requesting an XDA signature are addressed in section 9.3 of Book 3 and section 6.3.2.2 of Book 4.

countries.

The terminal always requests an XDA signature in the GENERATE AC command if XDA is selected. Thus, an XDA signature is requested even if an AAC is requested and even if CA ECC key retrieval has failed or ECC key recovery has failed or, in the case of a second GENERATE AC command, verification of the XDA signature requested in the first GENERATE AC command has failed.40c The ICC generates an XDA signature according to section 12.5.2 if the terminal has requested an XDA signature in the GENERATE AC command. The terminal verifies an XDA signature according to section 12.5.3 if the terminal has requested and received an XDA signature, the Application Cryptogram returned is a TC or ARQC and XDA has not already failed. The terminal does not attempt XDA signature verification if an AAC is returned or if XDA has already failed.

12.5.2 Dynamic Signature Generation The generation of the XDA signature takes place in the following steps. 10. The terminal issues a GENERATE AC command with the 'XDA signature requested' bits in the GENERATE AC command set to '01' according to sections 6.5.5.2 and 9.3 of Book 3. 11. The ICC performs the following steps: a. The ICC generates the AC. b. The ICC generates a digital signature as described in Annex A2.2.2 on the data specified in Table 27f using its ICC Private Key SIC in conjunction with the corresponding algorithms. The resulting digital signature is called the Signed Dynamic Application Data. Creation of Signed Dynamic Application Data The ICC shall sign the dynamic application data shown in Table 27f using the ICC Private Key and the signature function in Annex A2.2.2. The input (MSG) to the signature function is the concatenation of the data elements in Table 27f and the output is the Digital Signature in the Signed Dynamic Application Data. Field Name Signed Data Format Length 1 Description Hex value '15' Format b 40c The reason for always requesting an XDA signature, even if an AAC is requested, is to avoid complicated logic for circumstances that will rarely occur.

countries.

PDOL data (1st GEN AC only) CDOL1 data (1st GEN AC only) CDOL2 data (2nd GEN AC only) Response data LPDOL data LCDOL1 data LCDOL2 data LRESP Values of the data elements specified b by the PDOL and in the order they appear in the PDOL and sent by the terminal in the GET PROCESSING OPTIONS command (Not present if no PDOL was present in final SELECT) Values of the data elements specified b by the CDOL1 in the order they were sent by the terminal in the first GENERATE AC command. (Second GENERATE AC only) b Values of the data elements specified by the CDOL2 in the order they were sent by the terminal in the second GENERATE AC command. TLV-encoded data in the response to b the GEN AC command not including the Signed Dynamic Application Data. See Table 27h. Table 27f: Dynamic Application Data to be Signed (XDA) The Response Data in Table 27f shall be exactly (including their order) as returned in the response to the GENERATE AC command, but not including the Signed Dynamic Application Data. The Signed Dynamic Application Data consists of the concatenation of the Signed Data Format and the Digital Signature. This is illustrated in Table 27g. Field Name Signed Data Format Digital Signature Length 1 Description Hex value '15' NSIG This is the ICC ECC digital signature (r, s). Format b b Table 27g: Format of XDA Signed Dynamic Application Data The ICC response to GENERATE AC commands with XDA signature is coded according to format 2 as specified in section 6.5.5.4 of Book 3 (constructed data object with tag '77') and contains at least the mandatory data objects (TLV coded in the response) specified in Table 27h, and optionally the Issuer Application Data and other data objects. Tag Length Value Presence

countries.

'9F27' 1 Cryptogram Information Data M '9F36' 2 Application Transaction Counter M '9F26' 8 Application Cryptogram M '9F10' var. up to 32 Issuer Application Data O var. Other Data Objects O '9F4B' NSIG + 1 Signed Dynamic Application Data M Table 27h: Data Objects Included in Response to GENERATE AC with XDA signature 12.5.3 Dynamic Signature Verification This section continues the terminal processing from Step 1 of section 12.5.2. The terminal receives and parses the GENERATE AC response. Note: The terminal can determine the type of Application Cryptogram by inspecting the CID in the response. The terminal shall continue XDA processing and verify the XDA signature in the following steps: Verification of Signed Dynamic Application Data 1. Parse the Signed Dynamic Application Data according to Table 27g. If this fails, XDA signature verification has failed. 2. Check the Signed Data Format. If it is not '15', XDA signature verification has failed. 3. Verify the signature (r, s) from Table 27g on the data in Table 27f as specified in Annex A2.2.3, using the ICC Public Key and the associated ICC Public Key Algorithm Suite. If the verification fails, XDA signature verification has failed. If all the above steps were executed successfully, XDA signature verification was successful. Otherwise XDA signature verification has failed.

12.5.4 Sample XDA Flow The figure on the following page is an example of how a terminal might perform XDA. This sample flow provides a generalised illustration of the concepts of XDA. It does not necessarily contain all required steps and does not show parallel processing (for example, overlapping certificate recovery and signature generation). If any discrepancies are found between the text and flow, the text shall be followed. Book 4 sections 6.3.2.2.1 to 6.3.2.2.4 describe the processing for XDA-related failures.

countries.

XDA Offline Data Authentication Processing Terminal app lica tion & ca rd sup port XDA? Yes Check other No Offl ine Data Authen tication methods Set XDA selecte d in TVR Decline Offl ine (AA C) Issue 1st GEN AC for AAC requ esting XDA signature (even if CA ECC key missing) Terminal retrieves CA Pub lic Key and sets CA ECC key missing in TVR if key i s not presen t Terminal Actio n Ana lysis preced ing 1st GEN AC App rove O ffline (TC) or Go Onl ine (ARQC) Note: K ey recovery may be don e a t any time before 1st GEN AC re sp onse p rocessing. If ke y recovery fails the n the TVR is u pdated afte r send ing the 1st GEN AC command. Terminal recovers Issuer and ICC Publ ic Keys from cer tificate s. Issue 1st GEN AC for TC/ ARQC. Requ est XDA signature Complete key recove ry and XDA si gnature ve rification. Update TV R. Note: XDA OK means tha t CA key retrieval, Issue r key reco ve ry, ICC key recovery, and 1st GEN AC X DA signature verifica tion were successfu l. Per form Decli ne AAC 1st GEN AC TC processing Response ARQC 1XDA OK Yes No Go Onl ine Onl ine Ca pable? No Yes Per form onlin e authori sation with upd ate d TVR 1XDA OK No TAA Processi ng TAC/IAC-Denial Yes Per form Appro va l processing TAA Re su lt TC Decline 1st Gen AC Response ARQC 2nd GEN AC for AAC with XDA signature Offline Only Online Processing Per form Decli ne processing

countries.

XDA and Offline-only Processing - 1ARQC 1XDA OK - 1ARQC 1XDA NOK - 1TC 1XDA NOK Yes TAA Processi ng TAC/IAC-Default Offline Only Yes 1XDA OK Online Processing XDA and Online Processing - 1ARQC 1XDA OK - 1ARQC 1XDA NOK - 1TC 1XDA NOK Unable To Go No Onl ine Issuer Response No Decline App rove TAA Re su lt 1st GEN AC Response Reque st TC Reque st A AC ARQC 2nd GEN AC for TC with XDA signature 2nd GEN AC for AAC with XDA signature 2nd GEN AC Response TC TC AAC 1st GEN AC Response ARQC 2nd GEN AC for TC with XDA signature 2nd GEN AC Response TC 1XDA OK Yes TC No 2XDA OK AAC 2XDA OK Yes No Per form Decli ne processing Yes Note: XDA OK means tha t CA key r etri eva l, Issuer ke y recovery, ICC key recovery, and verification of 1st GEN AC X DA signature were all successful. XDA NOK means tha t one of them fai led. XDA OK means tha t 2nd GEN AC X DA signature verifica tion was successful, XDA NOK means tha t it failed. No Per form Appro ve processing Note: If th e issuer has a uth orised the transactio n a nd XDA had failed on 1st GEN AC it is known tha t issuer ha s authori sed de spite th e X DA failure so XDA i s not verified on 2nd GEN AC Figure 13c: XDA Sample Flow

countries.

Section 13 is added after Section 12: 13 Offline Data Encipherment using ECC This section relates to the use of ECC for offline encipherment of data, in particular PINs and biometrics, to ensure the secure transfer of data from the CVM capture device to the ICC. If supported, the ICC shall own a public/private key pair associated with offline data encipherment. The public key is then used by the CVM capture device or a secure component of the terminal (other than the CVM capture device) to derive symmetric keys using an approach based on ISO/IEC 11770-6. These are then used to encipher the input data in accordance with ISO/IEC 19772 Mechanism 5 (Encrypt-then-MAC). If a PIN is to be enciphered then it is first formed into a PIN block as shown in section 6.5.12 of Book 3. Note: It is not possible to mix RSA and ECC during a transaction as the card can only return one Certification Authority Public Key Index and one Issuer Public Key Certificate. Thus, it is not possible to perform ODE using ECC together with ODA using RSA, nor is it possible to perform ODE using RSA with ODA using the ECC based XDA.

13.1 Keys and Certificates If offline data encipherment using ECC is supported by the ICC as indicated by the CVM List, then the ICC has a key pair consisting of a public encipherment key and the corresponding private decipherment key. This specification allows the ICC to use a dedicated ICC public key pair for ECC ODE, or the same ICC public key pair for both XDA and ECC ODE. However, in both cases the ICC will have a dedicated ICC Public Key Certificate for ODE tag '9F2D' containing the ICC Public Key and ICC Public Key Algorithm Suite Indicator (see Table 27e) which is authenticated and recovered using the same process as described in section 12.4.40d 13.2 PIN Encipherment The terminal shall not encipher the PIN (step 3 below) until it has authenticated the ICC public key used for ECC ODE (sections 12.2, 12.3, and 12.4). The exchange of an enciphered PIN between terminal and ICC shall take place in the following steps. 4. The PIN is entered in plaintext format on the PIN pad and a PIN block is constructed as defined in section 6.5.12 of Book 3. 40d ICC Public Key Certificates enforce key usage by including the appropriate Algorithm Suite Indicator.

countries.

5. The terminal issues a GET CHALLENGE command to the ICC to obtain an 8-byte unpredictable number UNODE from the ICC. When the response to the GET CHALLENGE command is anything other than an 8 byte data value with SW1 SW2 = '9000', then the terminal shall consider that the Offline Enciphered PIN (ECC) CVM has failed. Note: a fresh GET CHALLENGE command is issued irrespective of previous CVM processing that may also have used a GET CHALLENGE command. Steps 1 and 2 may be performed in either order. 6. If Key Derivation has already been performed for the current transaction, then do not perform Key Derivation again and use the previously derived keys. If Key Derivation has not yet been performed for the current transaction, then: a) Generate an ephemeral key pair (d, R) as described in B2.2.4, for the curve identified by the certificate's ICC Public Key Algorithm Suite Indicator and set Rx to be the x-coordinate of R converted to a byte-string of length NFIELD using I2OS() per B2.6.1. b) Perform Key Derivation as described in A2.3.2, with the UNODE generated in step 2 as the UN for key derivation UNKD, the certificate's ICC Public Key Algorithm Suite Indicator for the Algorithm Suite Indicator, d from step 3a), and the ICC Public Key for ODE recovered from the ICC Public Key Certificate for ODE (tag '9F2D' as specified in section 13.1) as the point Q, to derive keys and initialise the counter N. 7. Apply the ECC encryption function (see A2.3.3) indicated by the certificate's ICC Public Key Algorithm Suite Indicator (see B2.4), with K140e from step 3b) as KX, K2 from step 3b) as KY, and A set to null, to the data specified in Table 27i as MSG in order to obtain the ciphertext C. If encryption fails, then the terminal shall consider that the Offline Enciphered PIN (ECC) CVM has failed. 8. Concatenate Rx and C to obtain the Enciphered Data Enciphered Data:= Rx || C Field Name Data Header PIN Block ICC Unpredictable Number (UNODE) Length 1 8 8 Description Hex Value '7F' PIN in PIN Block Unpredictable number obtained from the ICC with the GET CHALLENGE command Format b b b Table 27i: Data to be Enciphered for PIN Encipherment (ECC) 9. The terminal issues a VERIFY command including the Enciphered Data obtained in the previous step. 40e The derivation function generates four AES keys, but this specification only uses K1 and K2.

countries.

13.3 PIN Decipherment and Verification The decipherment and verification of an enciphered PIN by the ICC shall take place in the following steps. 10. If the length of the Enciphered Data received in the VERIFY command is less than NFIELD of the curve plus the length of a MAC (both as determined by the Algorithm Suite used by the ICC), the ICC shall return SW1 SW2 = '6984' and Offline Enciphered PIN (ECC) CVM has failed. 11. The ICC extracts Rx from the Enciphered Data received in the VERIFY command and calculates an ECC public key Q using the Point4x() function as described in section B2.2.1(e). Note: The length of Rx is NFIELD for the curve determined by the Algorithm Suite used by the ICC. For P-256 the length of Rx is 32 bytes. For P-521 the length of Rx is 66 bytes. The remainder of the Enciphered Data, after Rx has been extracted, is C. 12. The ICC derives two 128-bit AES keys K1 and K2 using the key derivation process described in A2.3.2, with the UNODE as the UN for key derivation UNKD, the ICC Public Key Algorithm Suite Indicator, the ICC private key for ECC ODE, and Q generated above. 13. To recover the plaintext data specified in Table 27i, the ICC applies the ECC decryption function (see A2.3.4), with K1 and K2 derived in step 3 above as KX and KY respectively, C extracted

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