PCI Watch

Tracking changes across the Payment Card Industry

ECC Worked Examples for Book 2

v2.0 Whitepapers
Contact

EMV-SWG-NJ24r95 EMV® Contact Specifications as Enhanced with ECC Crypto Worked Examples EMVCo, LLC (EMVCo) Version 1.0a December 2022

December

EMV-SWG-NJ24r95

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 NONINFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of 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.

December

2. 2. 2. 2. 3. 3. 3. 4. 4. 4. 4. 4. 5. 5. 5. 5. 5. 6. 6. 7. 7.

December

EMV-SWG-NJ24r95 EMV® Contact Specifications as Enhanced by ECC Crypto Worked Examples December 2022 1 Introduction to Document Section 2 of this document introduces the specifics of Elliptic Curve Cryptography (ECC) as used by EMV® Chip enhanced with ECC and specified in Book 2 of version 4.4 of the EMV Integrated Circuit Card Specifications for Payment Systems (EMV ICC v4.4). Section 3 of this document describes the EC-SDSA algorithm for generating and verifying digital signatures (public key certificates and XDA signatures). Section 4 of this document describes the format of Issuer and Card public key certificates. It also defines the Issuer self-signed public key certificate format and the Certification Authority self-signed public key certificate format – these are simply intended to be public key ‘packages’ that can be used for the management of Issuer and Certification Authority public keys. Sections 5 and 6 then provide worked examples of public key certificates and XDA signatures. Note that in this document the most detailed worked example of the EC-SDSA signature process can be found in the section on XDA signature verification. Section 7 describes the algorithm for Offline Data Encipherment (ODE) using Elliptic Curve Cryptography and provides a worked example of encrypting a cardholder entered PIN with subsequent decryption by the card. The specifications in sections 2, 3, 4 and 7.1 of this document are reproduced from Book 2 of the enhanced EMV Chip specifications as defined in EMV ICC v4.4. All worked examples use curve P-256. Note on colour coding

  • Plaintext and linking text: Black
  • Key Material: Red
  • Crypto Output: Green. Revision note: v1.0a corrects v1.0 by changing the value of ICCD Hash Encoding in the ICC public key certificate in section 5.5 from '01' to '00'. This only changes the signature in the ICC public key certificate. December EMV-SWG-NJ24r95 2 ECC

Introduction

As with the current EMV contact specifications, EMV Chip Enhanced uses a 3-layer PKI on the card side but uses Elliptic Curve Cryptography instead of RSA. The supported curves (P-256 and P-521), the signature method (EC-SDSA) and the data structures are specified in Book 2 of EMV ICC v4.4.

2.1 Elliptic Curve parameters EMV Chip Enhanced uses NIST P-256 (with P-521 as contingency) with SHA-2. The Book 2 specifications also provide hooks for certain national algorithms to be used but these will not be subject to EMV testing and approval. Note that the Payment System and Issuers will use the same parameters. n is FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551 G in standard notation 04||x||y is 046B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C2964F E342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5 p is FFFFFFFF00000001000000000000000000000000FFFFFFFFFFFFFFFFFFFFFFFF a is -3 b is 5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B 2.2 Digital Signature Algorithm The ECC signature algorithm is EC-SDSA (see ISO/IEC 14888-3) using SHA-2 (see ISO/IEC 10118-3, FIPS 180). Section 4 provides a basic description of EC-SDSA for informational purposes. A formal specification of EC-SDSA is included in Book 2 of EMV ICC v4.4.

2.3 Terminology and Abbreviations An elliptic curve private key is an integer and the corresponding public key is a point on the elliptic curve determined by multiplying the generator point by the private key. See section 3 for representations of public keys. NSIG NHASH NFIELD Length in bytes of a Payment System signature and of an Issuer signature Length in bytes of the hash function output Length in bytes of an element in the elliptic curve field Fp. Repeated bytes may be indicated using an exponent. For example a string of 16 zero bytes may be represented as 0x0016 = 00000000000000000000000000000000.

December

EMV-SWG-NJ24r95 2.4 Public Key Representation Elliptic curve points such as public keys are represented simply as the x-coordinate of the point. Note that with this representation a value of x can actually represent two points: P = (x, y) and –P = (x, -y). This would mean that a public key certificate on P is also valid for – P. However, this specification requires that the ‘smaller’ value is always used, specifically the non-negative value y that is in the interval [0, (p-1)/2].

December

EMV-SWG-NJ24r95 3 Signature algorithm (for certificates and XDA) 3.1 EC-SDSA This section provides a basic description of EC-SDSA (Schnorr EC-DSA) according to ISO/IEC 14888-3. A more detailed description is to be found in Book 2 of EMV ICC v4.4. Note that for the ECC algorithm suites the bit-length of n (the order of the elliptic curve group) is the same as the bit-length of a field element (an integer modulo p) and the bitlength of the Hash function output is less than or equal to the bit-length of n (so NHASH ≤ NFIELD). As well as using finite field arithmetic and elliptic curve point multiplication, the signature generation and verification algorithms use the following conversions: OS2I(X) is a defined function for converting an octet string X to an integer. I2OS(Y,m) is a defined function for converting an integer Y into a string of m octets. Detailed definitions of these conversion functions are provided in the annex.

3.2 Signature Generation For EC-SDSA the optimised1 computation of a signature S on a message MSG of arbitrary length using a signer’s private key d on an elliptic curve E over Fp with base point G of order n is as follows. Inputs: d, E, n, Hash[] (output length NHASH), MSG (length L ≥ 0). 1. Select a statistically unique and unpredictable integer k where 0 < k < n. (This may be a random or a strong pseudo-random generation process) 2. Compute kG = (x1, y1) on the curve E. Convert the x1 coordinate to a byte string B1 of length NFIELD bytes B1:= I2OS( x1, NFIELD). 3. Compute r:= Hash[ B1 || MSG ]. 4. Compute s’:= (k + (OS2I(r) mod n)d) mod n. 5. Convert s’ to be a fixed length byte string of length NFIELD bytes s:= I2OS(s’, NFIELD). Output: S:= (r, s).

3.3 Signature Verification The verification of an EC-SDSA signature S on a message MSG using the signer’s public key point P on an elliptic curve E over Fp with base point G of order n is as follows. 1 Optimised because only the x-coordinate of kG is input to the hash.

December

EMV-SWG-NJ24r95 Preliminary: Given the x-coordinate of the signer's public key point, calculate P as (x,y) where y = min(y’, p-y’) and where y’ = modsqrt(x3 +ax +b) = (x3 +ax +b)((p+1)/4) mod p. Note that this modsqrt calculation requires p = 3 modulo 4, which is the case for EMV-approved curves. Verification steps:

  • If the length in bytes of S is not NHASH + NFIELD, signature verification fails.
  • Parse S into the NHASH byte string r and the NFIELD byte string s. Thus S = (r, s).
  • Convert s to an integer s' according to the integer conversion function OS2I().
  • Convert r to a non-negative integer r' less than n by using OS2I() followed by reduction modulo n.
  • Check that 0 < s' < n and 0 < r'. If either is not true then signature verification fails.
  • Compute (x2, y2) = s'G – r'P.
  • Convert the x-coordinate x2 to a byte string B2 of NFIELD bytes according to the integer conversion function I2OS().
  • Compute v = Hash[ B2 || MSG ]
  • If v = r, then signature verification is successful; otherwise signature verification fails NHASH is the output length of the hash algorithm in bytes and NFIELD is the length of p (the field size) in bytes. December 4 Public Key Certificate Formats 4.1 Issuer Public Key Certificates The Issuer public key certificate format consists of a prefix followed by a signature block, as defined in Table 1 below. Table 1: Format of Issuer Public Key Certificate (Binary Encoding) Name Description 1 Issuer Certificate Format Always Hex value '12' for this version of the specifications. Length (bytes) 1 2 Issuer Certificate Encoding Always Hex value '00' for this version of the 1 specifications. 3 Issuer Identifier Uniquely identifies the Issuer in the context of 5 the RID (leftmost 3-10 digits from the PAN padded to the right with hex 'F's). 4 Issuer Public Key Algorithm Identifies the algorithm suite to be used with the 1 Suite Indicator Issuer Public Key when verifying issuer signatures. See section 4.5. 5 Issuer Certificate Expiration Issuer Certificate Expiration Date (YYYYMMDD, 4 Date UTC). 6 Issuer Certificate Serial Number Number unique to the payment system key that 3 creates the issuer certificate. 7 RID Payment System identified in the AID (first 5 5 bytes). 8 Certification Authority Public Key Index In conjunction with the RID, identifies which of 1 the Kernel application’s Certification Authority Public Keys (and associated algorithms) to use when verifying the issuer certificate. December Name 9 Issuer Public Key

Description

Representation of Issuer Public Key (x-coordinate of Issuer Public Key point) on the curve identified by the Issuer Public Key Algorithm Suite Indicator. Length (bytes) NFIELD 10 Issuer Public Key Certificate A digital signature on data objects 1 through 9 of NSIG Signature this table. Verified using the Certification Authority Public Key and algorithms identified by data object 8. When using EC-SDSA the length of a digital signature is equal to the length NHASH of the hash plus the length of a field element. Thus, if the signature algorithm suite uses 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 the above Table, the lengths NSIG, NHASH, and NFIELD are determined by the Certification Authority Public Key Algorithm Suite Indicator whereas for item 9 in the above Table the length NFIELD is determined by the Issuer Public Key Algorithm Suite Indicator.

4.2 ICC Public Key Certificates The ICC public key certificate format consists of a prefix followed by a signature block, as defined in Table 2 below. Table 2: Format of ICC Public Key Certificate (Binary Encoding) Name Description Length (bytes) 1 ICC Certificate Format Always Hex value '14' for this version of the 1 specifications. 2 ICC Certificate Encoding Always Hex value '00' for this version of the 1 specifications. 3 ICC Public Key Algorithm Identifies the algorithm suite to be used with 1 Suite Indicator 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').

December

Name Description Length (bytes) 4 ICC Certificate Expiration ICC Certificate Expiration Date (YYYYMMDD, 4 Date UTC). 5 ICC Certificate Expiration ICC Certificate Expiration Time (HHMM, UTC). 2 Time 6 ICC Certificate Serial Number Number assigned to the ICC certificate that is 6 unique amongst all certificates created by the issuer key that created the ICC certificate. 7 ICCD Hash Encoding For this version of the specifications, always 1 Hex value '00', indicating TLV encoding of the input is used when computing the ICCD Hash. 8 ICCD Hash Algorithm Identifies the hash algorithm used to 1 Indicator calculate the ICCD Hash. 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 Certificate A digital signature on data objects 1 through NSIG Signature 10 of this table. Verified using the Issuer Public Key obtained from the certificate in Table 1 and the algorithms identified by the Issuer Public Key Algorithm Suite Indicator. 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 the signature algorithm suite uses 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 2 the lengths NSIG, NHASH, and NFIELD are determined by the Issuer Public Key Algorithm Suite Indicator whereas for item 10 in Table 2 the length NFIELD is determined by the ICC Public Key Algorithm Suite Indicator and for item 9 in Table 2 the length NHASH is determined by the ICCD Hash Algorithm Indicator.

December

4.3 Self-signed Certification Authority Certificate The intention is that the Certification Authority public key will be self-signed for distribution; however, the terminal may use a separate mechanism for integrity protection and to subsequently re-verify the integrity of a Certification Authority public key and its related data. A decomposition of a self-signed Certification Authority public key certificate is shown in the figure below. Figure 1: Self-signed Certification Authority Public Key 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

December

The self-signed Certification Authority public key certificate format consists of a prefix followed by a signature block, as defined in Table 3 below. Table 3: Format of Self-signed Certification Authority Public Key (Binary Encoding) Name 1 Certificate Format Description Always Hex value '20' for this version of the specifications. Length (bytes) 1 2 Certificate Encoding Always Hex value '00' for this version of the 1 specifications. 3 RID Identifies the Payment System to which the 5 Certification Authority public key is associated. The RID identified in the AID (first 5 bytes). 4 Certification Authority Public Key Index When combined with the RID, uniquely identifies 1 the Certification Authority Public Key. 5 Certification Authority Indicates the algorithms to be used with the 1 Public Key Algorithm Suite Certification Authority Public Key. Indicator 6 Certification Authority Public Key Representation of Certification Authority Public Key (x-coordinate of Certification Authority public key point) on the curve identified by the Certification Authority Public Key Algorithm Suite Indicator. NFIELD 7 Certification Authority Public Key Certificate Signature Output of digital signature ECC algorithm on NSIG concatenated first six data objects using the Certification Authority private key on the elliptic curve identified by the Certification Authority Public Key Algorithm Suite Indicator.

December

4.4 Self-signed Issuer Public Key Certificate The recommended self-signed Issuer public key certificate format consists of a prefix followed by a signature block, as defined in Table 4 below. Table 4: Format of Self-signed Issuer Public Key (Binary Encoding) Name Description 1 Certificate Format Always Hex value '28' for this version of the specifications. Length (bytes) 1 2 Certificate Encoding Always Hex value '00' for this version of the 1 specifications. 3 Issuer Identifier Leftmost three to ten digits from the Primary 5 Account Number (PAN), padded on the right with hex 'F's. 4 Issuer Public Key Algorithm Indicates the algorithms to be used with the 1 Suite Indicator Issuer Public Key that is used to verify ICC Public Key Certificates and this Issuer Self-Signed Public Key Certificate. 5 Certificate Expiration Date Year, month, day (YYYYMMDD) after which this 4 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. 6 RID Identifies the Payment System which is 5 requested to sign the Issuer Public Key. 7 Certification Authority Public Key Index When combined with the RID, uniquely identifies 1 the Payment System key to be used to sign the Issuer Public Key and the associated algorithm suite.

December

Name 8 Payment System Proprietary Identifier Description 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). Length (bytes) 4 9 Tracking Number Proprietary Tracking Number whose value is 4 assigned by Payment System or Issuer. Format n 8. 10 Issuer Public Key Representation of Issuer Public Key (x-coordinate of Issuer Public Key point) on the curve identified by the Issuer Public Key Algorithm Suite Indicator. NFIELD 11 Issuer Public Key Certificate Output of digital signature ECC algorithm on NSIG Signature concatenated first ten data objects using the Issuer private key on the elliptic curve identified by the Issuer Public Key Algorithm Suite Indicator.

December

4.5 Algorithm Suite Indicators for Certificates The following Algorithm Suite Indicators for Certificates are assigned: Certificate Algorithm Suite Indicator '10' Signature Mechanism EC-SDSA Hash Algorithm SHA-256 ECC Curve NFIELD / NSIG P-256 32 / 64 '11' EC-SDSA SHA-512 P-521 66 / 130 '80' SM2-DSA SM3 SM2-P256 32 / 64 Note that the Chinese algorithm SM2-DSA (Signature Mechanism) is included for domestic suites.

December

5 Key Pairs and Public Key Certificate Examples This section contains examples of self-signed Certification Authority and Issuer public key certificates, Issuer public key certificates and ICC public key certificates using EC-SDSA, P-256 and SHA-256. It begins by defining three test key pairs.

5.1 Values of Key Pairs for the Worked Examples Certification Authority Key Pair Private Key = 723222B51845E8B41A66263AE90E962148F9CCC3BE45B3E5902CEC0195F2AEAF Public Key (X,Y): X coordinate = F60DAECD42B48FCCA547D942204D6098F1A353A5CD25CBDF2EC1ABFD0170E0FC Y coordinate = 6FD75EAAB356BE98BAA8E99A6FCE303F0C952BC02B4F566F096DD6EFF20C8FE8 Issuer Key Pair Private Key = DD5015968F6E10BE471523C58716FC0A36A40B309E62039DF6ED9FC62C6EA5F8 Public Key (X,Y): X coordinate = CD7400578B1164FEA954658C763C5A94FB3514FA89DB5B3B447AE8F4D5DF870A Y coordinate = 4CB6523AFD465E964F77A6DD5B67C79202E9B39892A8E9D45562D1100493D215 ICC Key Pair Private Key = A5483159423A754D46DC4ED22997686D8BA79AB978AB3FD42BA441B3AC58F9DF Public Key (X,Y): X coordinate = F0D3853D5417FDB5D4204193026B25935DB66A64B255C711F03E5C32FFC7894E Y coordinate = 6C180EE3B9D5453F70033F2C252B6E1A211FF072EDFC289093D51D6856C5CBA2

December

5.2 Self-signed Certification Authority Public Key Certificate Name Length (bytes) Example 1 Format 1 20 2 Certificate Encoding 1 00 3 RID 5 A000000004 4 Certification Authority Public 1 E0 Key Index 5 Certification Authority Public Key Algorithm Suite Indicator 6 Certification Authority Public Key 7 Signature Block 1 NFIELD NSIG 10 F60DAECD42B48FCCA547D942204D6098F1A3 53A5CD25CBDF2EC1ABFD0170E0FC 7796E8770697859834F7E7B5E792EEB69888 2292E7F2B918C4BA37C9EC10CB8984163978 9B9221A744805DC4396365216C2219F71A0F FF078033BEAF149C0C6B

December

5.3 Self-signed Issuer Public Key Certificate Name Length (bytes) Example Certificate Format 1 28 Certificate Encoding 1 00 Issuer Identifier 5 54133390FF Issuer Public Key Algorithm Suite Indicator 1 10 Certificate Expiration Date 4 20351231 RID 5 A000000004 Certification Authority Public Key Index 1 E0 Payment System Proprietary Identifier 4 50656469 Tracking Number 4 67726565 Issuer Public Key NFIELD CD7400578B1164FEA954658C763C5A94FB3514FA89DB 5B3B447AE8F4D5DF870A Issuer Public Key Certificate Signature NSIG CC7BA692B740DD34094A4615E0EB9FA00FC667D9C1F8 E4B475976D29E474B1CA0FF0C8976C166B9D5C487A0E 66FB6210DAD55A639E09FB749329E5DE39197F3E

December

5.4 Issuer Public Key Certificate Name Length (bytes) 1 Issuer Certificate Format 1 2 Issuer Certificate Encoding 1 3 Issuer Identifier 5 4 Issuer Public Key Algorithm 1 Suite Indicators 5 Issuer Certificate 4 Expiration Date 6 Issuer Certificate Serial 3 Number 7 RID 5 8 Certification Authority Public Key Index 9 Issuer Public Key 1 NFIELD 10 Issuer Public Key NSIG Certificate Signature Example 12 00 54133390FF 10 20301231 123456 A000000004 E0 CD7400578B1164FEA954658C763C5A94FB35 14FA89DB5B3B447AE8F4D5DF870A 739061ADBC6FC71C8864EA9D3D6BAB5C9501 C058D895FE0F69D92E22412953DC1ACCCBBE 60809C5694C739CA54CC3FF4CF0964E1B946 C3ED00C4E572A5021988

December

5.5 ICC Public Key Certificate Name Length (bytes) 1 ICC Certificate Format 1 2 ICC Certificate Encoding 1 3 ICC Public Key Algorithm 1 Suite Indicator 4 ICC Certificate Expiration 4 Date 5 ICC Certificate Expiration 2 Time 6 ICC Certificate Serial 6 Number 7 ICCD Hash Encoding 1 8 ICCD Hash Algorithm 1 Indicator 9 ICCD Hash NHASH 10 ICC Public Key NFIELD 11 ICC Public Key Certificate NSIG Signature Example 14 00 10 20291231 2359 987654321000 00 02 059B446E8E48949005786FD0A756881D3BD91B788B1 D684AE9AB1FA527A24EAC F0D3853D5417FDB5D4204193026B25935DB66A64B25 5C711F03E5C32FFC7894E BB678DAF6F224FE008ABED921629F1691D287F5B784 DB28E3551BA9925D162E3815E0AB49D5706DF3164E7 F288473BE9597653052BFC0873DA5951F269938B2C Item 11 above, the Card Public Key Certificate Signature, is the EC-SDSA signature generated using the Issuer private key over the concatenation of items 1-10 above: 1400102029123123599876543210000002 059B446E8E48949005786FD0A756881D3BD91B788B1D684AE9AB1FA527A24EAC F0D3853D5417FDB5D4204193026B25935DB66A64B255C711F03E5C32FFC7894E In this example the ICCD Hash is the hash of the concatenation of the following data items (Signed record, AIP, and AID). The record identified as signed in accordance with section 10.3 of Book 3: 57 12 54 13 33 90 00 00 15 13 D2 51 22 01 00 00 00 00 00 00 5A 08 54 13 33 90 00 00 15 13 5F 24 03 25 12 31

December

5F 25 03 15 11 01 5F 28 02 08 26 5F 34 01 01 8C 1B 9F 02 06 9F 03 06 9F 1A 02 9A 03 9C 01 9F 37 04 8D 0A 91 0A 8A 02 9F 02 06 8E 0A 00 00 00 00 00 00 00 00 1F 03 9F 07 02 FF 00 9F 08 02 00 02 9F 0D 05 00 00 00 01 06 9F 0E 05 00 00 00 00 00 9F 0F 05 84 00 00 01 06 9F 42 02 08 26 95 05 9F 35 01 9F 03 06 5F 2A 02 9F 34 03 (in this example there is only one signed record, with spaces inserted to assist visual parsing) AIP TLV 82 02 9900 AID (terminal) TLV 9F06 07 A0000000041010 (there is no PDOL in this example) The concatenation of the above data is: 57125413339000001513D25122010000000000005A0854133390000015135F24032512315F 25031511015F280208265F3401018C1B9F02069F03069F1A0295055F2A029A039C019F3704 9F35019F34038D0A910A8A029F02069F03068E0A00000000000000001F039F0702FF009F08 0200029F0D0500000001069F0E0500000000009F0F0584000001069F42020826820299009F 0607A0000000041010 and the SHA-256 hash of this data is: 059B446E8E48949005786FD0A756881D3BD91B788B1D684AE9AB1FA527A24EAC

December

6 XDA Signature Example This section presents an example of XDA signature generation and verification using ECSDSA and P-256. Dynamic Application Data to be signed and verified: Signed Data Format CDOL1 Data: Amt auth Amt other (no cashback) Country Code (Belgium) TVR Currency (Euro) Date (1st April 2023) Txn Type (Goods and Services) UN Terminal Type (Online capable CVM Result (offline plaintext OK) POS) PIN Response Data (CID, ATC, AC, IAD) 15 00 00 00 00 02 99 00 00 00 00 00 00 00 56 00 00 00 00 00 09 78 23 04 01 00 11 22 33 44 22 01 00 02 9F 27 01 40 9F 36 02 00 02 9F 26 08 39 65 68 89 AB C1 AF FC 9F 10 20 0F A5 01 9A 38 00 00 00 00 00 00 00 00 00 00 00 0F 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 Thus the input MSG for the signature generation and verification is: 15 00 00 00 00 02 99 00 00 00 00 00 00 00 56 00 00 00 00 00 09 78 23 04 01 00 11 22 33 44 22 01 00 02 9F 27 01 40 9F 36 02 00 02 9F 26 08 39 65 68 89 AB C1 AF FC 9F 10 20 0F A5 01 9A 38 00 00 00 00 00 00 00 00 00 00 00 0F 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 The card public key point P in standard notation 04||x||y is 04F0D3853D5417FDB5D4204193026B25935DB66A64B255C711F03E5C32FFC7894E6C 180EE3B9D5453F70033F2C252B6E1A211FF072EDFC289093D51D6856C5CBA2 The card secret key d is A5483159423A754D46DC4ED22997686D8BA79AB978AB3FD42BA441B3AC58F9DF 6.1 XDA Signature Generation The card generates a random value k which in hex is 3567EA2B31F08C2FD9D2F23D95F69EB565909889031A4607D255E649E9D8D824 The card computes kG =

December

(C5C431DFC0891E09D348251E4DC5966282246DCFDA3E81D0469D2DD573DC3776, 15268168424E598A45E73425757FE28BE81A9582176E4555DC9599A570F27158) which in standard notation is 04||x1||y1 04C5C431DFC0891E09D348251E4DC5966282246DCFDA3E81D0469D2DD573DC377615 268168424E598A45E73425757FE28BE81A9582176E4555DC9599A570F27158 The card computes r = SHA256(I2OS(x1, NFIELD)||MSG) mod n = SHA256(C5C431DFC0891E09D348251E4DC5966282246DCFDA3E81D0469D2DD573DC37 76150000000002990000000000000056000000000009782304010011223344220100 029F2701409F360200029F260839656889ABC1AFFC9F10200FA5019A380000000000 0000000000000F010000000000000000000000000000) mod n = 10DD8EC1D542F5362485EBF8EF71B99512CBE7361A3D453431CF5F64F58CA9B0 The card computes rd mod n = C8647BACBE4231D95FF701831C5021539F10359C021ACC0D5EEB18048EA73CFF The card computes k+rd mod n = FDCC65D7F032BE0939C9F3C0B246C00904A0CE25053512153140FE4E78801523 The XDA signature is S = (10DD8EC1D542F5362485EBF8EF71B99512CBE7361A3D453431CF5F64F58CA9B0, FDCC65D7F032BE0939C9F3C0B246C00904A0CE25053512153140FE4E78801523) 6.2 XDA Signature Verification The terminal confirms that the length of S is correctly 64 bytes (32+32). The terminal parses the received XDA signature as r = 10DD8EC1D542F5362485EBF8EF71B99512CBE7361A3D453431CF5F64F58CA9B0 s = FDCC65D7F032BE0939C9F3C0B246C00904A0CE25053512153140FE4E78801523 This boxed inset shows conversion steps only for completeness. The terminal converts r and s into the decimal integers r' and s': r' = 76284640523582991612207538351039927948767478363402299798569694686712 76394928, reduced modulo n s' = 11479629039084657012957563579890074505926326418240790490910564770391 9381452067

December

and checked to be non-zero and less than n, which for P-256 in decimal is 11579208921035624876269744694940757352999695522413576034242225906106 8512044369 The terminal then computes s'G and r'P as follows: s'G = (BC25BD471786A276D8A36207AB28643DB0E8C1DF5A42781BD5DFE327038C425B, CFBFDA54804C64DE24A59D42A3F72F72F3F01FD82C44BB6780DB4CF907B132F6) which in standard notation is a single string prefixed by '04': 04BC25BD471786A276D8A36207AB28643DB0E8C1DF5A42781BD5DFE327038C425BCF BFDA54804C64DE24A59D42A3F72F72F3F01FD82C44BB6780DB4CF907B132F6 r'P = (242A6604992C96A991E1A789DD3E1997188CA905002F39DA47A9011AFF95761C, E8E8B5D4A45C2AD84A1B1133D18AF950D5CE6D2AF6BE0082B35ACF323548F18C) which in standard notation is a single string prefixed by '04': 04242A6604992C96A991E1A789DD3E1997188CA905002F39DA47A9011AFF95761CE8 E8B5D4A45C2AD84A1B1133D18AF950D5CE6D2AF6BE0082B35ACF323548F18C The terminal then computes (x2, y2) = s'G – r'P = (C5C431DFC0891E09D348251E4DC5966282246DCFDA3E81D0469D2DD573DC3776, 15268168424E598A45E73425757FE28BE81A9582176E4555DC9599A570F27158) which in standard notation is a single string prefixed by '04': 04C5C431DFC0891E09D348251E4DC5966282246DCFDA3E81D0469D2DD573DC377615 268168424E598A45E73425757FE28BE81A9582176E4555DC9599A570F27158 Finally the terminal confirms that v = SHA256(I2OS(x2, NFIELD)||MSG) = SHA256(C5C431DFC0891E09D348251E4DC5966282246DCFDA3E81D0469D2DD573DC37 76150000000002990000000000000056000000000009782304010011223344220100 029F2701409F360200029F260839656889ABC1AFFC9F10200FA5019A380000000000 0000000000000F010000000000000000000000000000) = 10DD8EC1D542F5362485EBF8EF71B99512CBE7361A3D453431CF5F64F58CA9B0 is equal to r, and it is.

December

7 ODE Algorithm and ODE Example This section deals with Offline Data Encipherment (ODE) where the offline CVM is PIN rather than biometrics. Section 7.1 describes the algorithm as specified in Book 2 of EMV ICC v4.4 for encrypting and decrypting a PIN using Elliptic Curve Cryptography and section 7.2 provides a worked example.

7.1 Algorithm for Encrypting and Decrypting a PIN This section describes how the terminal applies the ECC encryption function indicated by the certificate's ICC Public Key Algorithm Suite Indicator to the data specified in Table 5 as MSG in order to obtain Rx (the x-coordinate of the terminal’s ephemeral public key R) and the ciphertext C. It then describes how the card decrypts the ciphertext C using Rx. Table 5: Data to be Enciphered for PIN Encipherment (ECC) Field Name Length Description Format Data Header 1 Hex Value '7F' b PIN Block 8 PIN in PIN Block b ICC Unpredictable Number 8 Unpredictable number obtained from b the ICC with the GET CHALLENGE command The terminal first generates an ephemeral private key d as a random integer between 2 and n-2 and calculates its ephemeral public key point as R=dG. Note that the descriptions below are generic in the sense that they are applicable for processing PIN and biometrics and using either P-256 or P-521. Key Derivation is performed by the terminal as the first part of encryption and by the ICC as the first part of decryption. Key Derivation This description of key derivation is applicable to encryption and decryption.

  • For encryption the notation uses d as the private key of the terminal and Q as the public key point of the ICC.
  • For decryption the notation uses d as the private key of the ICC and Q as the public key point R of the terminal. December Key Derivation is performed in the following steps:
  • Set NumSKs: = 4.
  • Using the function PointMultiply(), compute Z as the x-coordinate of the point dQ.
  • Convert Z from an integer to a bit string according to the integer conversion function I2BS():
  • For P-256, Z is converted to a 256-bit string.
  • For P-521, Z is converted to a 640-bit string; the rightmost 521 bits of Z are a bit string representation of the x-coordinate of the point dQ and so the leftmost 119 bits of Z are zero ‘padding bits’.
  • Apply CMAC to Z to produce an AES key derivation KDK key, using the 128-bit zero string (0128) as the CMAC key: KDK:= CMAC(0)[Z]
  • Derive Ki for i = 1 to NumSKs: Ki:= AES(KDK)['0i' || DerData] where for this specification:
  • DerData is the 15-bytes SKD_VERSION || '00' || T || '02' || '00'  SKD_VERSION is the 1-byte '01'  T is the 11 byte UNODE || 'A5A5A5'  The final 2 bytes represent the length of the output (512 bits in the case of 128-bit session keys with NumSKs equal to 4). For the first encryption/decryption in a transaction initialise a 2-byte variable N to the value '0000'. This is a global variable a copy of which is maintained by terminal and ICC. The terminal increments N after each successful encryption and the ICC increments N after each successful decryption. Encryption The encryption process uses two derived keys:
  • K1 is used for encrypting/decrypting data sent from terminal to ICC
  • K2 is used for authenticating data sent from terminal to ICC. This description assumes that there is no Additional Authenticated Data and so the string A is null with zero length. Encryption of a plaintext MSG, denoted P, takes place in the following steps:
  • If N = 65535 then encryption has failed, so abort and report failure.
  • Generate the Starting Variable SV as the 16-byte all-zero string whose leftmost 2 bytes are set to the value of N. December
  • If the message payload P is null then set C* to be null and skip to step “A is assumed”.
  • If the bit-length of the message payload P is not a multiple of 8, then Encryption has failed, so abort and report failure.
  • If P is not a multiple of 16-bytes, then pad by appending r (0 < r < 16) zero-bytes to P.
  • Partition P into B 16-byte blocks: P:= P1 || P2 ||... || PB
  • Encipher the message payload Ci = Pi ⊕ AES(K1)[ SV + ((i-1) mod 2112)] for 1 <= i <= B
  • If padding had been applied then truncate the final rightmost r bytes from CB thereby creating CB', otherwise set CB' = CB. Set C*:= C1 || C2 ||... || CB'
  • A is assumed to be the null string so set len(A):= 0.
  • Set D to be the 8-byte string of all zero: D:= '0000000000000000' = I2BS(len(A)/8, 64) || A
  • Calculate the 8-byte MAC S as the 8 most significant bytes of CMAC(K2)[D || SV || C*]
  • and append this to C* to create the ciphertext C C:= C* || S.
  • Increment N.
  • Return the x-coordinate of the ephemeral public key Rx, converted to a byte-string of length NFIELD using I2OS(),and the ciphertext C. Concatenate Rx and C to obtain the Enciphered Data Enciphered Data:= Rx || C Decryption If the length of the Enciphered Data is less than o 40 bytes if the curve is P-256, or o 74 bytes if the curve is P-521, then decryption has failed, so abort and report failure. December This description assumes that there is no Additional Authenticated Data and so the string A is null with zero length. Parse the Enciphered Data as Rx || C, where Rx is a string of NFIELD bytes (32 bytes in the case of P-256 and 66 bytes in the case of P-521) and C represents the ciphertext. Convert Rx to an integer using the conversion function OS2I() and then to a point R = (Rx,Ry) using the function Point4x(). R should be the encryptor's public key and as such a point on the curve (implementations should protect against attacks that modify Rx to put R off the curve). After key derivation using the ICC private key and the terminal public key, decryption of the Enciphered Data, takes place in the following steps:
  • If N = 65535 then decryption has failed, so abort and report failure.
  • A is assumed to be the null string so set len(A):= 0.
  • Set D to be the 8-byte string of all zeros: D:= '0000000000000000' = I2BS(len(A)/8, 64) || A
  • Partition the ciphertext C into C* and an 8-byte candidate MAC value S '. If this partition fails, then decryption has failed. C:= C* || S '
  • The bit-length of C* should be a multiple of 8 and will be zero in the case that C* is null (corresponding to a null plaintext). If the bit-length of C* is not a multiple of 8, then decryption has failed, so abort and report failure.
  • Generate the Starting Variable SV as the 16-byte all-zero string whose leftmost 2 bytes are set to the value of N.
  • Calculate the 8-byte MAC S as the 8 most significant bytes of CMAC(K2)[D || SV || C*]
  • If S ≠ S ' then decryption has failed, so abort and report failure.
  • If C* is not a multiple of 16-bytes, then pad by appending r (0 < r < 16) zero-bytes to C*.
  • Partition C* into B 16-byte blocks: C*:= C1 || C2 ||... || CB
  • Decrypt the ciphertext as Pi = Ci ⊕ AES(K1)[ SV + ((i-1) mod 2112)] for 1 <= i <= B
  • If padding had been applied then truncate the final rightmost r bytes from PB December
  • The plaintext MSG is the byte-string P:= P1 || P2 ||... || PB
  • Increment N.
  • Return the plaintext message MSG. No result other than an indication of failure shall be returned in case of failure. December

7.2 Worked Example: PIN with P-256 Encryption The PIN is 1234 and the associated 8-byte PIN block is 24 12 34 FF FF FF FF FF UNODE is the 8-byte string generated by the ICC in the GET CHALLENGE command 4B61726D656C6974 MSG to be encrypted is 7F 24 12 34 FF FF FF FF FF 4B61726D656C6974 The terminal ephemeral private key d is FC65DB263262F82BFC875D6B28AEB00536A50F16CB27DD2E13A43D5DD7CB3A8B The terminal ephemeral public key R=dG in standard notation 04||x||y is 04 308AB0D0E417B75C0D9940FD96758CA7FA19E096E79399E79FF970DB26D4F357 1A2CE3C85EE882D89E6D860E6D53E9B136815F3E1C0E5D1927824D3BD6839B5B so Rx is 308AB0D0E417B75C0D9940FD96758CA7FA19E096E79399E79FF970DB26D4F357 The card public key point Q in standard notation 04||x||y is 04F0D3853D5417FDB5D4204193026B25935DB66A64B255C711F03E5C32FFC7894E6C 180EE3B9D5453F70033F2C252B6E1A211FF072EDFC289093D51D6856C5CBA2 Perform Key Derivation (see below) to derive keys K1 and K2. Padded MSG is P:= P1 || P2 7F241234FFFFFFFFFF4B61726D656C69 74000000000000000000000000000000 Initialise SV to the value of the 2-byte counter N appended with 14 zero bytes: SV = 0x0016 = 00000000000000000000000000000000 Encrypt as C1:= P1 ⊕ AES(K1)[SV] = 7F241234FFFFFFFFFF4B61726D656C69 ⊕ AES(B70930EE63758545B016F6F777A9AFA2)[0x0016] = 7F241234FFFFFFFFFF4B61726D656C69 ⊕ 6E0907A6B561B4A353C38726A355ECE1 = 112D15924A9E4B5CAC88E654CE308088 C2:= P2 ⊕ AES(K1)[SV+1] = 74000000000000000000000000000000 ⊕ AES(B70930EE63758545B016F6F777A9AFA2)[SV+1] = 74000000000000000000000000000000 ⊕ FF281A66719CA2EFF18D50D0D28F8284 = 8B281A66719CA2EFF18D50D0D28F8284

December

where SV+1 = 0x0015||01 So C*:= C1||C2' is 112D15924A9E4B5CAC88E654CE3080888B D:= I2BS(len(A)/8, 64) || A A is specified to be null, so calculate D as 0x008. Calculate the MAC S as the 8 most significant bytes of CMAC(K2)[D||SV||C*] = CMAC(EB7A0402D1DB753228E258755E793229)[0x0024||112D15924A9E4B5CAC88E654CE3080888B] = 09967C92D571004CF7377500A3442386 So the final ciphertext C:= C*||S is 112D15924A9E4B5CAC88E654CE3080888B 09967C92D571004C and the Enciphered data Rx || C is 308AB0D0E417B75C0D9940FD96758CA7FA19E096E79399E79FF970DB26D4F357 112D15924A9E4B5CAC88E654CE3080888B 09967C92D571004C Decryption The Received Enciphered data parsed as Rx || C is 308AB0D0E417B75C0D9940FD96758CA7FA19E096E79399E79FF970DB26D4F357 112D15924A9E4B5CAC88E654CE3080888B 09967C92D571004C Calculate the terminal ephemeral public key point R=(Rx,Ry) by applying Point4x() to Rx. So substitute the value Rx for x in the formula (x3 + ax + b)(p+1)/4) mod p where a=-3: x3 mod p 974417A1C498A777DCC78225F72841727A0CDB24A863A6A970B26F50587C96C7 3x mod p 91A01272AC47261428CBC2F8C360A5F7EE4DA1C4B6BACDB6DFEC5291747EDA05 b mod p 5AC635D8AA3A93E7B3EBBD55769886BC651D06B0CC53B0F63BCE3C3E27D2604B (x3 + ax + b) mod p 606A3B07C28C154B67E77C82AA602236F0DC4010BDFC89E8CC9458FD0BD01D0D (p+1)/4 3FFFFFFFC0000000400000000000000000000000400000000000000000000000 y’ = (x3 + ax + b)(p+1)/4) mod p E5D31C36A1177D28619279F192AC164EC97EA0C2E3F1A2E6D87DB2C4297C64A4 Ry = min (y’, p-y’) 1A2CE3C85EE882D89E6D860E6D53E9B136815F3E1C0E5D1927824D3BD6839B5B The terminal ephemeral public key R in standard notation 04||x||y is 04308AB0D0E417B75C0D9940FD96758CA7FA19E096E79399E79FF970DB26D4F3571A 2CE3C85EE882D89E6D860E6D53E9B136815F3E1C0E5D1927824D3BD6839B5B

December

Perform Key Derivation (see below) to derive keys K1 and K2 and using the terminal ephemeral public key R as Q and the ICC private key as d where d is A5483159423A754D46DC4ED22997686D8BA79AB978AB3FD42BA441B3AC58F9DF Partition the ciphertext C into C* and an 8-byte candidate MAC value S '. If this partition fails, then decryption has failed. C:= C* || S ' 112D15924A9E4B5CAC88E654CE3080888B 09967C92D571004C D:= I2BS(len(A)/8, 64) || A A is specified to be null, so calculate D as 0x008. Set SV to the value of the 2-byte counter N appended with 14 zero bytes: SV = 0x0016 = 00000000000000000000000000000000 Calculate the MAC S as the 8 most significant bytes of CMAC(K2)[D||SV||C*] = CMAC(EB7A0402D1DB753228E258755E793229)[0x0024||112D15924A9E4B5CAC88E654CE3080888B] = 09967C92D571004CF7377500A3442386 Confirm that S is indeed equal to S’. Pad with 15 0x00 bytes and partition C* into 16-byte blocks C* = C1 || C2: 112D15924A9E4B5CAC88E654CE308088 8B000000000000000000000000000000 Decrypt C* as P1:= C1 ⊕ AES(K1)[SV] = 112D15924A9E4B5CAC88E654CE308088 ⊕ AES(B70930EE63758545B016F6F777A9AFA2)[0x0016] = 112D15924A9E4B5CAC88E654CE308088 ⊕ 6E0907A6B561B4A353C38726A355ECE1 = 7F241234FFFFFFFFFF4B61726D656C69 P2:= C2 ⊕ AES(K1)[SV+1] = 8B000000000000000000000000000000 ⊕ AES(B70930EE63758545B016F6F777A9AFA2)[SV+1] = 8B000000000000000000000000000000 ⊕ FF281A66719CA2EFF18D50D0D28F8284 = 74281A66719CA2EFF18D50D0D28F8284 where SV+1 = 0x0015||01 Remove the final 15 padding bytes to reveal the unpadded MSG as: 7F241234FFFFFFFFFF4B61726D656C69 74 Check that the final 8 bytes is UNODE generated by the ICC in the GET CHALLENGE command. If not then fail. Check that the first byte is the header 0x7F. If not then fail.

December

Parse the 8 bytes following the header byte as an ISO-2 PIN block. Key Derivation Perform Diffie-Hellman: dQ in standard notation 04||x||y is 04243949EAA2487A7CBF10E23999375D994AA9D52D518E6CFB3C196ADE1A155CC6C8 3CB49EB01E55F346801395221426B6DFF2C8708DCFFBA077B104E278FD1E61 Giving Z as 243949EAA2487A7CBF10E23999375D994AA9D52D518E6CFB3C196ADE1A155CC6 Calculate KDK:= CMAC(0)[Z] as ECA08EF01F5BDBB37BEB9EFDED2CE5A3 Calculate K1:=AES(KDK)[01 01 00 4B61726D656C6974 A5A5A5 0200] as B70930EE63758545B016F6F777A9AFA2 Calculate K2:=AES(KDK)[02 01 00 4B61726D656C6974 A5A5A5 0200] as EB7A0402D1DB753228E258755E793229

December

Annex A Integer Conversion Functions (for ECC) There are mathematical functions used in this specification (e.g. signature generation) that involve the processing of integers which are represented as bits and bytes. This section therefore specifies how strings of bits and bytes are to be interpreted as integers. Note that because the elliptic curves identified in this specification operate over finite fields with a prime number p of elements, each element of the field is naturally interpreted as a non-negative integer less than p. and points are then represented as pairs of such integers. A1 Integers and Bits and Bytes (Octets) For the purposes of this section the conversion between integers and bytes is mediated by conversion to strings of bits. The conversion functions defined in this section are consistent with those used in the standards of ISO/IEC JTC1 SC27 (see for example ISO/IEC 14888-3 Annex B) and use the term Octet instead of Byte and thereby distinguish OS (Octet String) from BS (Bit String). BS2I() and I2BS() The function BS2I(x) maps a bit string x of length l to a non-negative integer value v, as follows. If x = where x0,…, xl-1 are bits, then the value v is defined as 𝑙𝑙−1 𝑣𝑣 = � 𝑥𝑥𝑘𝑘2𝑘𝑘 𝑘𝑘=0 For the empty string, v is equal to 0.

  • Example: BS2I(000 0010 1010 1100 0001) = 10945 The function I2BS(v,l) which takes as input two non-negative integers v and l, and outputs the unique bit string x of length l such that BS2I(x) = v, if such an x exists. If no such x exists then the function outputs an error message.
  • Example 1: I2BS(10945, 19) = 000 0010 1010 1100 0001
  • Example 2: I2BS(10945, 14) = 10 1010 1100 0001 OS2I() and I2OS() Input for OS2I():
  • An octet string x. December Output:
  • An integer v. The function OS2I(x) takes as input an octet string x and outputs the integer v = BS2I(OS2BS(x)).
  • Example: OS2I() = OS2I('2A' 'C1') = 10945 Input for I2OS():
  • two non-negative integers v and l. Output:
  • An octet string x of length l in octets. The function I2OS(v,l) takes as input two non-negative integers v and l, and outputs the unique octet string x of length l in octets such that OS2I(x) = v, if such an x exists. Otherwise, the function outputs an error message.
  • Example 1: I2OS(10945, 3) = = '00' '2A' 'C1'
  • Example 2: I2OS(10945, 2) = = '2A' 'C1' --end of document-- December 2022 © 2022 EMVCo, LLC. All rights reserved. Any and all uses of the EMV Specifications shall be permitted only pursuant to the terms and conditions of the license agreement between the user and EMVCo found at http://www.emvco.com/. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries