ANSI X9.63 (2011) (R2017) - Key Agreement and Key Transport Using Elliptic Curve Cryptography

Citation preview

American National Standard for Financial Services ANSI X9.63–2011 (R2017) Public Key Cryptography for the Financial Services Industry Key Agreement and Key Transport Using Elliptic Curve Cryptography

Developed by Accredited Standards Committee X9, Incorporated Financial Industry Standards Date Approved: December 21, 2011 Date Reaffirmed: February 10, 2017 American National Standards Institute American National Standards, Technical Reports and Guides developed through the Accredited Standards Committee X9, Inc., are copyrighted. Copying these documents for personal or commercial use outside X9 membership agreements is prohibited without express written permission of the Accredited Standards Committee X9, Inc. For additional information please contact ASC X9, Inc., 275 West Street, Suite 107, Annapolis, MD 21401.

© 2017 ASC X9, Inc. – All rights reserved

1

ANSI X9.63-2011 (R2017)

ii

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Foreword Business practice has changed with the introduction of computer-based technologies. The substitution of electronic transactions for their paper-based predecessors has reduced costs and improved efficiency. Trillions of dollars in funds and securities are transferred daily by telephone, wire services, and other electronic communication mechanisms. The high value or sheer volume of such transactions within an open environment exposes the financial community and its customers to potentially severe risks from the accidental or deliberate disclosure, alteration, substitution, or destruction of data. These risks are compounded by interconnected networks, and the increased number and sophistication of malicious adversaries. Electronically communicated data may be secured through the use of symmetrically keyed encryption algorithms (e.g. FIPS, AES) in combination with public-key cryptography-based key management techniques. This standard, X9.63-2011, Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography, defines a suite of mechanisms designed to facilitate the secure establishment of cryptographic data for the keying of symmetrically keyed algorithms (e.g. TDEA, AES). These mechanisms are based on the elliptic curve analogue of the Diffie-Hellman key agreement mechanism. Because the mechanisms are based on the same fundamental mathematics as the Elliptic Curve Digital Signature Algorithm (ECDSA) (ANS X9.62), additional efficiencies and functionality may be obtained by combining these and other cryptographic techniques. While the techniques specified in this standard are designed to facilitate key management applications, the standard does not guarantee that a particular implementation is secure. It is the responsibility of the financial institution to put an overall process in place with the necessary controls to ensure that the process is securely implemented. Furthermore, the controls should include the application of appropriate audit tests in order to verify compliance. The user’s attention is called to the possibility that compliance with this standard may require the use of an invention covered by patent rights. By publication of this standard, no position is taken with respect to the validity of potential claims or of any patent rights in connection therewith. The patent holders have, however, filed a statement of willingness to grant a license under these rights on reasonable and nondiscriminatory terms and conditions to applicants desiring to obtain such a license. Details may be obtained from the X9 Secretariat, Copyright 2017 by ASC X9 All rights reserved. No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America. © 2017 ASC X9, Inc. – All rights reserved

iii

ANSI X9.63-2011 (R2017)

Suggestions for the improvement or revision of this standard are welcome. They should be sent to the X9 Committee Secretariat, Accredited Standards Committee X9, Inc., Financial Industry Standards, 275 West Street, Suite 107 Annapolis, MD 21401 USA. This standard was processed and approved for submittal to ANSI by the Accredited Standards Committee on Financial Services, X9. Committee approval of the standard does not necessarily imply that all the committee members voted for its approval. At the time that this standard was approved, the X9 committee had the following chairs and administrators: Roy DeCicco, Group Chair, J. P. Morgan Chase Claudia Swendseid, Vice Chair, Federal Reserve Bank Steve Stevens, Executive Director, Accredited Standards Committee X9, Inc. Isabel Bailey, Administrator, Accredited Standards Committee X9, Inc. Janet Busch, Administrator, Accredited Standards Committee X9, Inc. The X9 committee had the following member organizations, with primary representatives:

X9 Member Organization

Representative

ACI Worldwide ......................................................................Doug Grote Advance Auto Parts ...............................................................Anthony Johnson American Bankers Association ..............................................C. Diane Poole American Express Company..................................................Ted Peirce Apriva ....................................................................................Len Sutton BAFT/IFSA............................................................................Joseph Pawelczyk Bank of America ....................................................................Daniel Welch Certicom Corporation ............................................................Daniel Brown Citigroup, Inc. ........................................................................Karla McKenna CUSIP Service Bureau ...........................................................James Taylor Deluxe Corporation ................................................................Ralph Stolp Department of the Treasury, Office of Financial Research ...Michael Donnelly Department of the Treasury, Office of Financial Research ...Bill Nichols Diebold, Inc............................................................................Bruce Chapa Discover Financial Services ...................................................Michelle Zhang Federal Reserve Bank ............................................................Claudia Swendseid First Data Corporation ...........................................................Rick Van Luvender FIS Global ..............................................................................Stephen Gibson-Saxty Fiserv......................................................................................Dan Otten FIX Protocol Ltd - PTL..........................................................Jim Northey Gilbraco..................................................................................Bruce Welch Harland Clarke .......................................................................John McCleary Hewlett Packard .....................................................................Larry Hines IBM Corporation ....................................................................Todd Arnold iv

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Independent Bankers of America...........................................Viveca Ware Ingenico..................................................................................John Spence J. P. Morgan Chase ................................................................Roy DeCicco Key Innovations .....................................................................Scott Spiker KPMG LLP ............................................................................Mark Lundin MagTek, Inc. ..........................................................................Terry Benson MasterCard International .......................................................Mark Kamers NACHA The Electronic Payments Association ....................Robert Unger National Association of Convenience Stores .........................Michael Davis National Security Agency ......................................................Paul Timmel NCR Corporation ...................................................................Steve Stevens RMG-ISITC ...........................................................................Genevy Dimitrion RouteOne ...............................................................................Travis Bully SWIFT/Pan Americas ............................................................Juliette Kennel Symcor, Inc. ..........................................................................Brian Salway TECSEC Incorporated ...........................................................Ed Scheidt The Bank of New York Mellon .............................................David Goldberg The Clearing House ...............................................................Sharon Jablon U. S. Bank ..............................................................................Brian Fickling U. S. Securities and Exchange Commission ..........................Matthew Reed USDA Food and Nutrition Service ........................................Kathy Ottobre VeriFone, Inc. .......................................................................Brad McGuinness VISA ......................................................................................Kim Wagner Wells Fargo Bank ..................................................................Mark Tiggas Wincor Nixdorf Inc ................................................................Ramesh Arunashalam XAC Automation Corporation ..............................................Chuck Chagas XBRL US, Inc. ......................................................................Campbell Pryde At the time that this standard was approved, the X9F subcommittee on Data and Information Security had the following chairs and administrators: Richard J. Sweeney, Former Chair, Proofspace Sandra Lambert, Vice Chair, Certicom Corporation Steve Stevens, Executive Director, Accredited Standards Committee X9, Inc. Isabel Bailey, Administrator, Accredited Standards Committee X9, Inc. Janet Busch, Administrator, Accredited Standards Committee X9, Inc. The X9F subcommittee had the following member organizations, with representatives:

X9F Member Organization

Representative

Acculynk ................................................................................John Herr ACI Worldwide ......................................................................Doug Grote Advance Auto Parts ...............................................................Anthony Johnson American Bankers Association ..............................................Tom Judd American Express Company..................................................Vicky Sammons © 2017 ASC X9, Inc. – All rights reserved

v

ANSI X9.63-2011 (R2017)

Apriva ....................................................................................Paul Coppinger BAFT/IFSA............................................................................Joseph Pawelczyk Bank of America ....................................................................Andi Coleman Burroughs Payments Systems, Inc. .......................................David J. Concannon Certicom Corporation ............................................................Daniel Brown Citigroup, Inc. ........................................................................Chii-Ren Tsai Communications Security Establishment ..............................Jonathan Hammel CUSIP Service Bureau ...........................................................Scott Preiss DeLap LLP.............................................................................Darlene Kargel Deluxe Corporation ................................................................Andy Vo Depository Trust and Clearing Corporation ..........................Robert Palatnick Diebold, Inc............................................................................Bruce Chapa Discover Financial Services ...................................................Jordan Schaefer Equinox Payments .................................................................Gary Zempich Federal Reserve Bank ............................................................Deb Hjortland Ferris and Associates, Inc. .....................................................J. Martin Ferris First Data Corporation ...........................................................Lisa Curry First National Bank of Omaha ...............................................Kristi White Fiserv......................................................................................Bud Beattie GEOBRIDGE Corporation ....................................................Jason Way Gilbraco..................................................................................Bruce Welch Harland Clarke .......................................................................John Petrie Hewlett Packard .....................................................................Larry Hines IBM Corporation ....................................................................Todd Arnold Independent Community Bankers of America ......................Cary Whaley Ingenico..................................................................................John Spence ITS, Inc. (SHAZAM Networks) ............................................Manish Nathwani J. P. Morgan Chase ................................................................Edward Koslow K3DES LLC...........................................................................Azie Amini Key Innovations .....................................................................Scott Spiker KPMG LLP ............................................................................Mark Lundin MagTek, Inc. ..........................................................................Terry Benson Marriott International .............................................................Jude Sylvestre MasterCard International .......................................................Michael Ward Mustang Microsystems, Inc. ..................................................Tami Harris National Association of Convenience Stores .........................Alan Thiemann National Institute of Standards and Technology ....................Elaine Barker National Security Agency ......................................................Paul Timmel NCR Corporation ...................................................................David Norris PCI Security Standards Council.............................................Troy Leach Pitney Bowes, Inc. .................................................................Rick Ryan Proofspace ..............................................................................Paul Doyle Rosetta Techologies ...............................................................Jim Maher RSA, The Security Division of EMC ....................................Steve Schmalz Security Innovation ................................................................William Whyte vi

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

STAR ....................................................................................Lilik Kazaryan Surety, Inc. ............................................................................Dimitrios Andivahis Symcor, Inc. ..........................................................................Brian Salway TECSEC Incorporated ...........................................................Ed Scheidt Thales e-Security, Inc. ..........................................................James Torjussen The Clearing House ...............................................................Henry Farrar Trustwave ...............................................................................John Amaral U. S. Bank ..............................................................................Peter Skirvin University Bank .....................................................................Stephen Ranzini VeriFone, Inc. .......................................................................Dave Faoro VISA ......................................................................................John Sheets Voltage Security, Inc. ...........................................................Martin Luther Wells Fargo Bank ..................................................................Mark Tiggas Wincor Nixdorf Inc ................................................................Michael Nolte XAC Automation Corporation ..............................................Chuck Chagas At the time that this standard was approved, the X9F1 Cryptographic Tool Standards and Guidelines working group that developed this standard had the following chair: Terence Spies, Chair, Voltage Security, Inc. Previously but for a significant portion of the time during which the current edition of this standard was developed, the X9F1 working group chair was: Miles Smid, Orion Security Solutions, Inc. The main editor of the current of the current edition of this standard was: Daniel Brown, Certicom Corporation (a wholly owned subsidiary of Research in Motion, Inc.) Others who provided comments contributing significantly to this edition of this standard were: Elaine Barker, National Institute of Standards and Technology Paul Timmel, National Security Agency Rich Davis, National Security Agency Nick Gajcowski, National Security Agency The X9F1 working group member (and former member) organization, and including representatives, that participated actively in the development of this standard during working group discussions were:

© 2017 ASC X9, Inc. – All rights reserved

vii

ANSI X9.63-2011 (R2017)

X9F1 Member Organization

Representative

Bank of America ....................................................................Jeff Stapleton Bank of America ....................................................................Lawrence LaBella Certicom Corporation ............................................................Daniel Brown Certicom Corporation ............................................................Matthew Campagna Certicom Corporation ............................................................Greg Zaverucha Communications Security Establishment of Canada .............Jonathan Hammell LE Technology Co., Ltd. .......................................................John Lewis MasterCard International .......................................................Michael Ward National Institute of Standards and Technology ....................Elaine Barker National Institute of Standards and Technology ....................John Kelsey National Security Agency ......................................................Mary Baish National Security Agency ......................................................Mike Boyle National Security Agency ......................................................Paul Timmel PCI Security Standards Council.............................................Ralph Poore RSA, The Security Division of EMC ....................................Steve Schmalz Security Innovation ................................................................William Whyte TecSec ....................................................................................Ed Scheidt TecSec ....................................................................................Wai Tsang University Bank .....................................................................Mick Talley Verifone .................................................................................Joachim Vance VISA ......................................................................................Kim Wagner Voltage Security Inc. .............................................................Terence Spies

viii

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Contents X9 MEMBER ORGANIZATION REPRESENTATIVE .................................................................................................. IV X9F MEMBER ORGANIZATION REPRESENTATIVE ................................................................................................. V X9F1 MEMBER ORGANIZATION REPRESENTATIVE ............................................................................................ VIII 1

SCOPE ................................................................................................................................................................ 1

2

DEFINITIONS, ABBREVIATIONS AND REFERENCES ...........................................................................1 2.1 2.2 2.3

3

DEFINITIONS AND ABBREVIATIONS ..................................................................................................................1 SYMBOLS AND NOTATION .............................................................................................................................. 11 NORMATIVE REFERENCES .............................................................................................................................. 14

APPLICATION ................................................................................................................................................ 15 3.1 GENERAL ....................................................................................................................................................... 15 3.2 THE SCHEMES IN THIS STANDARD.................................................................................................................. 16 3.3 IMPLEMENTING THE SCHEMES SECURELY ...................................................................................................... 17 3.4 ANNEXES ....................................................................................................................................................... 17 4 MATHEMATICAL CONVENTIONS .................................................................................................................... 19 4.1 FINITE FIELD ARITHMETIC ............................................................................................................................. 19 4.1.1 The Finite Field Fp............................................................................................................................... 19 4.1.2 The Finite Field F2m ............................................................................................................................. 19 4.2 ELLIPTIC CURVES AND POINTS....................................................................................................................... 19 4.2.1 Point Compression Technique for Elliptic Curves over Fp (Optional) ................................................ 19 4.2.2 Point Compression Technique for Elliptic Curves over F2m (Optional)............................................... 19 4.3 DATA CONVERSIONS ...................................................................................................................................... 19 4.3.1 Integer-to-Octet-String Conversion ..................................................................................................... 19 4.3.2 Octet-String-to-Integer Conversion ..................................................................................................... 20 4.3.3 Field-Element-to-Octet-String Conversion .......................................................................................... 20 4.3.4 Octet-String-to-Field-Element Conversion .......................................................................................... 20 4.3.5 Field-Element-to-Integer Conversion .................................................................................................. 20 4.3.6 Point-to-Octet-String Conversion ........................................................................................................ 20 4.3.7 Octet-String-to-Point Conversion ........................................................................................................ 20

5

CRYPTOGRAPHIC INGREDIENTS ........................................................................................................... 20 5.1 ELLIPTIC CURVE DOMAIN PARAMETER GENERATION AND VALIDATION ....................................................... 20 5.1.1 Primitives for Elliptic Curve Domain Parameter Generation and Validation over Fp........................ 20 5.1.2 Primitives for Elliptic Curve Domain Parameter Generation and Validation over F2m ...................... 21 5.2 KEY PAIR GENERATION AND PUBLIC KEY VALIDATION ................................................................................ 21 5.2.1 Key Pair Generation Primitive ............................................................................................................ 21 5.2.2 Public Key Validation .......................................................................................................................... 21 5.3 CHALLENGE GENERATION PRIMITIVE ............................................................................................................ 21 5.4 DIFFIE-HELLMAN PRIMITIVES ........................................................................................................................ 22 5.4.1 Standard Diffie-Hellman Primitive ...................................................................................................... 22 5.4.2 Modified Diffie-Hellman Primitive ...................................................................................................... 23 5.5 MQV PRIMITIVE ............................................................................................................................................ 23 5.6 AUXILIARY FUNCTIONS ................................................................................................................................. 24 5.6.1 Associate Value Function (avf) ............................................................................................................ 24 5.6.2 Cryptographic Hash Functions............................................................................................................ 25

© 2017 ASC X9, Inc. – All rights reserved

ix

ANSI X9.63-2011 (R2017)

5.6.3 Key Derivation Function (kdf) ............................................................................................................. 26 5.7 MAC SCHEMES .............................................................................................................................................. 27 5.7.1 Tagging Transformation ...................................................................................................................... 28 5.7.2 Tag Checking Transformation ............................................................................................................. 29 5.8 ASYMMETRIC ENCRYPTION SCHEME ............................................................................................................. 29 5.8.1 Encryption Transformation .................................................................................................................. 30 5.8.2 Decryption Transformation ................................................................................................................. 31 5.9 SIGNATURE SCHEME ...................................................................................................................................... 32 5.9.1 Signing Transformation ....................................................................................................................... 33 5.9.2 Verifying Transformation .................................................................................................................... 33 5.10 KEY CONFIRMATION SCHEMES ................................................................................................................. 34 6

KEY AGREEMENT SCHEMES ................................................................................................................... 34 6.1 EPHEMERAL UNIFIED MODEL SCHEME .......................................................................................................... 36 6.2 1-PASS DIFFIE-HELLMAN SCHEME................................................................................................................. 38 6.2.1 Initiator Transformation ...................................................................................................................... 39 6.2.2 Responder Transformation .................................................................................................................. 40 6.3 STATIC UNIFIED MODEL SCHEME .................................................................................................................. 41 6.4 COMBINED UNIFIED MODEL WITH KEY CONFIRMATION SCHEME.................................................................. 42 6.5 1-PASS UNIFIED MODEL SCHEME .................................................................................................................. 43 6.5.1 Initiator Transformation ...................................................................................................................... 44 6.5.2 Responder Transformation .................................................................................................................. 45 6.6 FULL UNIFIED MODEL SCHEME ..................................................................................................................... 46 6.7 FULL UNIFIED MODEL WITH KEY CONFIRMATION SCHEME ........................................................................... 48 6.8 STATION-TO-STATION SCHEME ...................................................................................................................... 49 6.8.1 Initiator Transformation ...................................................................................................................... 50 6.8.2 Responder Transformation .................................................................................................................. 52 6.9 1-PASS MQV SCHEME ................................................................................................................................... 55 6.9.1 Initiator Transformation ...................................................................................................................... 56 6.9.2 Responder Transformation .................................................................................................................. 57 6.10 FULL MQV SCHEME ................................................................................................................................. 57 6.11 FULL MQV WITH KEY CONFIRMATION SCHEME ....................................................................................... 59

7

KEY TRANSPORT SCHEMES ..................................................................................................................... 60 7.1 7.2

1-PASS TRANSPORT SCHEME ......................................................................................................................... 60 3-PASS TRANSPORT SCHEME ......................................................................................................................... 60

ANNEX A (NORMATIVE) NORMATIVE NUMBER-THEORETIC ALGORITHMS ..................................... 61 ANNEX B (INFORMATIVE) MATHEMATICAL BACKGROUND ................................................................... 62 ANNEX C (INFORMATIVE) TABLES OF TRINOMIALS, PENTANOMIALS, AND GAUSSIAN NORMAL BASES ........................................................................................................................................................................ 63 ANNEX D (INFORMATIVE) INFORMATIVE NUMBER-THEORETIC ALGORITHMS ............................. 64 ANNEX E (INFORMATIVE) COMPLEX MULTIPLICATION (CM) ELLIPTIC CURVE GENERATION METHOD ................................................................................................................................................................... 65 ANNEX F (INFORMATIVE) SECURITY CONSIDERATIONS .......................................................................... 66 F.1 THE ELLIPTIC CURVE DISCRETE LOGARITHM PROBLEM ........................................................................... 66 F.2 ELLIPTIC CURVE DOMAIN PARAMETERS ................................................................................................... 66 F.3 KEY PAIRS................................................................................................................................................. 66 F.4 KEY ESTABLISHMENT SCHEMES................................................................................................................ 66 F.4.1 The ECDLP and Key Establishment Schemes ..................................................................................... 66 x

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

F.4.2 F.4.3 F.4.4

Security Attributes and Key Establishment Schemes ........................................................................... 67 Security Attributes of the Schemes in this Standard............................................................................. 68 Appropriate Key Lengths ..................................................................................................................... 70

ANNEX G (INFORMATIVE) EXAMPLES ............................................................................................................. 74 G.1 EXAMPLES OF DATA CONVERSION METHODS ........................................................................................... 74 G.2 EXAMPLES OF SCHEMES OVER THE FIELD F2M ........................................................................................... 77 G.3 EXAMPLES OF SCHEMES OVER THE FIELD FP ............................................................................................. 77 G.4 SAMPLE ELLIPTIC CURVES OVER THE FIELD F2M ....................................................................................... 77 G.4.1 2 Examples with m = 193 .................................................................................................................... 78 G.4.2 2 Examples with m = 233 .................................................................................................................... 79 G.4.3 Example with m = 239 ......................................................................................................................... 81 G.4.4 2 Examples with m = 283 .................................................................................................................... 82 G.4.5 2 Examples with m = 409 .................................................................................................................... 83 G.4.6 2 Examples with m = 571 .................................................................................................................... 85 G.5 SAMPLE ELLIPTIC CURVES OVER THE FIELD FP ......................................................................................... 87 G.5.1 2 Examples with a 192-bit Prime ......................................................................................................... 87 G.5.2 2 Examples with a 224-bit Prime ......................................................................................................... 88 G.5.3 2 Examples with a 256-bit Prime ......................................................................................................... 90 G.5.4 An Example with a 384-bit Prime ........................................................................................................ 92 G.5.5 An Example with a 521-bit Prime ........................................................................................................ 93 ANNEX H (INFORMATIVE) ASN.1 ........................................................................................................................ 95 H.1 SYNTAX FOR FINITE FIELD IDENTIFICATION .............................................................................................. 95 H.2 SYNTAX FOR FINITE FIELD ELEMENTS AND ELLIPTIC CURVE POINTS ....................................................... 98 H.3 SYNTAX FOR ELLIPTIC CURVE DOMAIN PARAMETERS .............................................................................. 98 H.4 SYNTAX FOR PUBLIC KEYS ....................................................................................................................... 99 H.5 SCHEME SYNTAX .................................................................................................................................... 103 H.5.1 Ephemeral Unified Model Scheme ..................................................................................................... 104 H.5.2 1-Pass Diffie-Hellman Scheme .......................................................................................................... 105 H.5.3 Static Unified Model Scheme ............................................................................................................. 105 H.5.4 Combined Unified Model with Key Confirmation Scheme ................................................................ 105 H.5.5 1-Pass Unified Model Scheme ........................................................................................................... 106 H.5.6 Full Unified Model Scheme ............................................................................................................... 106 H.5.7 Full Unified Model with Key Confirmation Scheme .......................................................................... 107 H.5.8 Station-to-Station Scheme .................................................................................................................. 107 H.5.9 1-Pass MQV Scheme .......................................................................................................................... 108 H.5.10 Full MQV Scheme ......................................................................................................................... 108 H.5.11 Full MQV with Key Confirmation Scheme .................................................................................... 108 H.5.12 1-Pass Key Transport Scheme ...................................................................................................... 108 H.5.13 3-Pass Key Transport Scheme ...................................................................................................... 109 H.6 KEY DERIVATION SYNTAX ...................................................................................................................... 109 H.7 ASN.1 MODULE ...................................................................................................................................... 111 ANNEX I (NORMATIVE) LEGACY SCHEMES................................................................................................. 118 I.1 I.2

OVERVIEW ................................................................................................................................................... 118 LEGACY KEY AGREEMENT SCHEMES .......................................................................................................... 118 I.2.1 Combined Unified Model with Key Confirmation ............................................................................. 118 I.2.2 Full Unified Model with Key Confirmation Scheme .......................................................................... 124 I.2.3 Full MQV with Key Confirmation Scheme ........................................................................................ 129 I.3 LEGACY KEY TRANSPORT SCHEMES ............................................................................................................ 134 I.3.1 1-Pass Transport Scheme .................................................................................................................. 135

© 2017 ASC X9, Inc. – All rights reserved

xi

ANSI X9.63-2011 (R2017)

I.3.2

3-Pass Transport Scheme .................................................................................................................. 138

ANNEX J (INFORMATIVE) BIBLIOGRAPHY ................................................................................................... 144

xii

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Figures Figure 1 – Ephemeral Unified Model Scheme ............................................................................. 36 Figure 2 – 1-Pass Diffie-Hellman Scheme ................................................................................... 38 Figure 3 – Static Unified Model Scheme ...................................................................................... 41 Figure 4 – 1-Pass Unified Model Scheme .................................................................................... 43 Figure 5 – Full Unified Model Scheme ........................................................................................ 46 Figure 6 – Station-to-Station Scheme ........................................................................................... 49 Figure 7 – 1-Pass MQV Scheme ................................................................................................... 55 Figure 8 – Full MQV Scheme ....................................................................................................... 58 Figure I-1 – Combined Unified Model with Key Confirmation Scheme ................................... 119 Figure I-2 – Full Unified Model with Key Confirmation Scheme ............................................. 124 Figure I-3 – Full MQV with Key Confirmation Scheme ............................................................ 130 Figure I-4 – 1-Pass Key Transport Scheme ................................................................................ 136 Figure I-5 – 3-Pass Key Transport Scheme ................................................................................ 139

© 2017 ASC X9, Inc. – All rights reserved

xiii

ANSI X9.63-2011 (R2017)

Tables Table F-1 – Attributes Provided by Key Establishment Schemes ................................................ 69 Table F-2 – Guidelines on Aligning Parameter Sizes and Symmetric Key Size .......................... 73

xiv

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Public Key Cryptography for the Financial Service Industry Key Agreement and Key Transport Using Elliptic Curve Cryptography 1

Scope

This Standard specializes ISO/IEC 11740-3 “Informational Technology - Security Techniques Key Management - Part 3: Mechanisms using asymmetric techniques” for use by the financial services industry. This Standard defines key establishment schemes that employ asymmetric cryptographic techniques. The arithmetic operations involved in the operation of the schemes take place in the algebraic structure of an elliptic curve over a finite field. Both key agreement and key transport schemes are specified. The schemes may be used by two parties to compute shared keying data that may then be used by symmetric schemes to provide cryptographic services, e.g., data confidentiality and data integrity. Supporting mathematical definitions and examples are also provided.

2

Definitions, Abbreviations and References

2.1

Definitions and Abbreviations

2.1.1 addition rule An addition rule describes the addition of two elliptic curve points P1 and P2 to produce a third elliptic curve point P3. 2.1.2 approved An cryptographic technique, such as a hash function, key derivation function or digital signature scheme, is Approved if it is approved by the X9 Registry. SD-34, or if it is explicitly identified as Approved in this Standard. 2.1.3 associate value Given an elliptic curve point and corresponding elliptic curve parameters, the associate value is an integer associated with the point. © 2017 ASC X9, Inc. – All rights reserved

1

ANSI X9.63-2011 (R2017)

2.1.4 asymmetric cryptographic algorithm An asymmetric cryptographic algorithm is an algorithm that uses two related keys, a public key and a private key; the two keys have the property that, given the public key, it is computationally infeasible to derive the private key. 2.1.5 authentic An authentic public key is a public key which is assured to belong to some purported party. More generally, an authentic value is a value which is assured to be the same value on both sides of key establishment. 2.1.6 auxiliary function An auxiliary function is a transformation that forms part of a cryptographic scheme. 2.1.7 base point (G) A base point is a selected point on an elliptic curve of large prime order n. 2.1.8 basis A basis is a representation of the elements of the finite field F2m. Two special kinds of basis are polynomial basis and normal basis. (See Annex B.2.) 2.1.9 binary polynomial A binary polynomial is a polynomial whose coefficients are in the field F2. When adding, multiplying, or dividing two binary polynomials, the coefficient arithmetic is performed modulo 2. 2.1.10 bit string A bit string is an ordered sequence of 0’s and 1’s. 2.1.11 certificate A certificate is an electronic document that contains the public key and identity of an entity, together with some other information, that is rendered unforgeable by signing this information with the private key of the Certification Authority which issued that certificate. In this Standard, the term certificate will mean a public-key certificate. 2,1.12 certification authority (CA) A certification authority is a center trusted by one or more entities to create and assign certificates.

2

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 2.1.13 characteristic of a finite field If a finite field has 2m elements, its characteristic is 2. If a finite field has p elements, where p is prime, its characteristic is p. 2.1.14 characteristic 2 finite field A characteristic 2 finite field is a finite field consisting of 2m elements, where m  1 is an integer. In this Standard, the characteristic 2 fields used consist of 2m elements with m prime. 2.1.15 cofactor The cofactor is the integer h = #E(Fq)/n, where #E(Fq) is the order of the elliptic curve E, and n is the order of the base point. 2.1.16 compressed form Compressed form is the octet string representation of a point that uses the point compression technique described in Section 4.2. (See also Section 4.3.6.) 2.1.17 cryptographic hash function A cryptographic hash function is a (mathematical) function which maps values from a large (possibly very large) domain into a smaller range. The function satisfies the following properties: 1.

(One-way) It is computationally infeasible to find any input that maps to any prespecified output;

2.

(Collision free) It is computationally infeasible to find any two distinct inputs that map to the same output.

2.1.18 cryptographic key (key) A cryptographic key is a parameter that determines the operation of a cryptographic function such as: 1.

the transformation from plaintext to ciphertext and vice versa,

2.

the synchronized generation of keying material, or

3.

a digital signature computation or verification.

2.1.19 cryptographic scheme A cryptographic scheme consists of an unambiguous specification of a set of transformations that are capable of providing a cryptographic service when properly implemented and maintained.

© 2017 ASC X9, Inc. – All rights reserved

3

ANSI X9.63-2011 (R2017)

2.1.20 cryptography Cryptography is the discipline that embodies principles, means and methods for the transformation of data in order to hide its information content, prevent its undetected modification, prevent its unauthorized use, or a combination thereof. 2.1.21 cryptoperiod A cryptoperiod is the time span during which a specific key is authorized for use or in which the keys for a given system may remain in effect. 2.1.22 cyclic elliptic curve group The group of points E(Fq) is said to be a cyclic group if there exists a point PE(Fq) of order n, where n = #E(Fq). In this case, E(Fq) = {kP: 0  k  n-1}, i.e. E(Fq) can be expressed as the set of all scalar multiples of P. 2.1.23 data confidentiality Data confidentiality is the assurance provided to entity U that data is unintelligible to entities other than U and V. 2.1.24 data integrity Data integrity is the assurance provided to entity U that data has not been modified by entities other than U and V. 2.1.25 data origin authentication Data origin authentication is the assurance provided to entity U that data is from V. 2.1.26 digital signature A digital signature is the result of a cryptographic transformation of data that, when properly implemented, provides the services of: 1.

origin authentication,

2.

data integrity, and

3.

signer non-repudiation.

2.1.27 EC EC abbreviates Elliptic curve. 2.1.28 ECDLP ECDLP abbreviates Elliptic Curve Discrete Logarithm Problem. (See Annex H.) 4

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 2.1.29 ECDSA ECDSA abbreviates Elliptic Curve Digital Signature Algorithm. 2.1.30 elliptic curve An elliptic curve over Fq is a set of points that satisfy a certain equation specified by two parameters a and b, which are elements of the field Fq. (See Section 4.2.) 2.1.31 elliptic curve key pair (Q, d) Given particular elliptic curve domain parameters, an elliptic curve key pair consists of an elliptic curve public key (Q) and the corresponding elliptic curve private key (d). 2.1.32 elliptic curve private key (d) Given particular elliptic curve domain parameters, an elliptic curve private key, d, is a statistically unique and unpredictable integer in the interval [1, n-1], where n is the prime order of the base point G. 2.1.33 elliptic curve public key (Q) Given particular elliptic curve domain parameters, and an elliptic curve private key d, the corresponding elliptic curve public key, Q, is the elliptic curve point Q = dG, where G is the base point. Note that Q will never equal O (i.e., the point at infinity), since 1  d  n-1. 2.1.34 elliptic curve domain parameters Elliptic curve domain parameters are comprised of a field size q, an indication FR of the basis used (in the case that q = 2m), an optional ECCSEED, two elements a and b in Fq that define an elliptic curve E over Fq, a point G = (xG,yG) of prime order in E(Fq), the order n of G, and the cofactor h. 2.1.35 elliptic curve point If E is an elliptic curve defined over a field Fq, then an elliptic curve point P is either: a pair of field elements (xP, yP) (where xP, yP  Fq) such that the values x = xP and y = yP satisfy the equation defining E, or a special point O, called the point at infinity. O is the identity element of the elliptic curve group. 2.1.36 encryption scheme An encryption scheme is a cryptographic scheme capable of providing data confidentiality. 2.1.37 entity An entity is a party involved in the operation of a cryptographic system. 2.1.38 entity authentication Entity authentication is the assurance provided to entity U that entity U has been involved in a real-time communication with entity V. © 2017 ASC X9, Inc. – All rights reserved

5

ANSI X9.63-2011 (R2017)

2.1.39 ephemeral Ephemeral means relatively short-lived. In this Standard, ephemeral data would be data specific to one execution of a cryptographic scheme. 2.1.40 explicit key authentication Explicit key authentication is the assurance provided to entity U that only entities U and V are potentially capable of obtaining the keying data, and further that the entities U and V actually have obtained the keying data. (Explicit key authentication is implicit key authentication and key confirmation.) 2.1.41 forward secrecy Forward secrecy is the assurance provided to an entity U that the session key established between entities U and V will not be compromised by the compromise of either entity’s static private key in the future. Also known as perfect forward secrecy. 2.1.42 gaussian normal basis (GNB) A Gaussian normal basis is a type of normal basis that can be used to represent the elements of the finite field F2m. 2.1.43 hash function See cryptographic hash function. 2.1.44 hash value A hash value is the result of applying a cryptographic hash function to a bit string. 2.1.45 hybrid form Hybrid form is an octet string representation for both the compressed and uncompressed forms of an elliptic curve point. 2.1.46 implicit key authentication Implicit key authentication is the assurance provided to entity U that only entities U and V are potentially capable of obtaining the keying data. 2.1.47 initiator The initiator is the entity involved in an operation of a scheme that sends the first exchange of the scheme. 2.1.48 irreducible binary polynomial A binary polynomial f(x) is irreducible if it cannot be factored into a product of two or more binary polynomials, each of degree less than the degree of f(x). 6

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 2.1.49 key See cryptographic key. 2.1.50 key agreement scheme A key agreement scheme is a key establishment scheme in which the keying data established is a function of contributions provided by both entities in such a way that neither party can predetermine the value of the keying data. 2.1.51 key-compromise impersonation resilience Key-compromise impersonation resilience is the assurance provided to entity U during an execution of a key establishment scheme that the compromise of U’s static private key has not enabled the impersonation of V to U. 2.1.52 key confirmation Key confirmation is a procedure to provide assurance to one party that another party actually possesses the correct secret keying material, shared secret, or both. 2.1.53 key derivation function A key derivation function is a function that takes a shared secret value as input and outputs keying data suitable for later cryptographic use. 2.1.54 key establishment scheme A key establishment scheme is a cryptographic scheme that establishes keying data suitable for subsequent cryptographic use in cryptographic schemes by its legitimate users. Key agreement schemes and key transport schemes are types of key establishment schemes. 2.1.55 keying data Keying data is data suitable for use as session keys. Keying data is generally the output of a key establishment scheme. 2.1.56 keying material Keying material is the data (e.g., elliptic curve domain parameters, static private and public keys, certificates, and initialization vectors) necessary to establish and maintain cryptographic keying relationships. Keying material is generally the input to a key establishment scheme. 2.1.57 key transport schemes A key transport scheme is a key establishment scheme in which the keying data established is determined entirely by one entity.

© 2017 ASC X9, Inc. – All rights reserved

7

ANSI X9.63-2011 (R2017)

2.1.58 known-key security Known-key security is the assurance provided to entity U that the session key established by an execution of a key establishment scheme will not be compromised by the compromise of other session keys. 2.1.59 message authentication code or MAC scheme A message authentication code or MAC scheme is a (symmetric) cryptographic scheme capable of providing data origin authentication and data integrity. 2.1.60 non-repudiation Non-repudiation is the assurance provided to entity U that a third party can verify that data is from V. 2.1.61 normal basis (NB) A normal basis is a type of basis that can be used to represent the elements of the finite field F2m. 2.1.62 octet An octet is a bit string of length 8. An octet is represented by a hexadecimal string of length 2. The first hexadecimal digit represents the four leftmost bits of the octet, and the second hexadecimal digit represents the four rightmost bits of the octet. For example, 9D represents the bit string 10011101. An octet also represents an integer in the interval [0, 255]. For example, 9D represents the integer 157. 2.1.63 octet string An octet string is an ordered sequence of octets. 2.1.64 optimal normal basis (ONB) An optimal normal basis is a type of Gaussian normal basis that can be used to represent the elements of the finite field F2m. There are two kinds of ONB, called Type I ONB and Type II ONB. 2.1.65 order of a curve The order of an elliptic curve E defined over the field Fq is the number of points on E, including O. This is denoted by #E(Fq). 2.1.66 order of a point The order of a point P is the smallest positive integer n such that nP = O (the point at infinity). 2.1.67 owner The owner is the entity whose identity is associated with a private/public key pair. 8

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 2.1.68 pass A pass in a scheme is a set of data sent from entity U to entity V or received by U from V at a particular stage of an operation of the scheme. 2.1.69 pentanomial A pentanomial is a polynomial of the form xm + xk3 +xk2 +xk1+ 1, where 1  k1 < k2 < k3  m-1. 2.1.70 pentanomial basis (PPB) A pentanomial basis is a type of polynomial basis that can be used to represent the elements of the finite field F2m. 2.1.71 point compression Point compression allows a point P = (xP, yP) to be represented compactly using xP and a single additional bit ~y P derived from xP and yP 2.1.72 polynomial basis (PB) A polynomial basis is a type of basis that can be used to represent the elements of the finite field F2m. 2.1.73 prime finite field A prime finite field is a finite field consisting of p elements, where p is a prime number. 2.1.74 private key In an asymmetric (public-key) system, a private key is that key of an entity’s key pair that is known only by that entity. 2.1.75 protocol A protocol is a special set of rules used by two or more entities that describe the message order and data structures for information exchanged between the entities. 2.1.76 public key In an asymmetric (public-key) system, the public key is that key of an entity’s key pair that may be publicly known. 2.1.77 reduction polynomial The reduction polynomial is an irreducible binary polynomial f(x) of degree m that is used to determine a polynomial basis representation of F2m. 2.1.78 responder A responder is an entity involved in an operation of a scheme that does not send the first pass of the scheme. © 2017 ASC X9, Inc. – All rights reserved

9

ANSI X9.63-2011 (R2017)

2.1.79 scalar multiplication If k is a positive integer, then kP denotes the point obtained by adding together k copies of the point P. The process of computing kP from P and k is called scalar multiplication. 2.1.80 session key A session key is a key established by a key establishment scheme. 2.1.81 shared secret value A shared secret value is an intermediate value in a key establishment scheme from which keying data is derived. 2.1.82 static Static data is relatively long-lived. In this Standard, static data is data that may be common to a number of executions of a cryptographic scheme. 2.1.83 symmetric cryptographic scheme A symmetric cryptographic scheme is a cryptographic scheme in which each transformation is controlled by the same key. 2.1.84 trinomial A trinomial is a polynomial of the form xm + xk + 1, where 1  k  m-1. 2.1.85 trinomial basis (TPB) A trinomial basis is a type of polynomial basis that can be used to represent the elements of the finite field F2m. 2.1.86 type I ONB A type I ONB is a kind of optimal normal basis. 2.1.87 type II ONB A type II ONB is a kind of optimal normal basis. 2.1.88 uncompressed form Uncompressed form is an octet string representation for an uncompressed elliptic curve point. 2.1.89 unknown key-share resilience Unknown key-share resilience is the assurance provided to entity U that, if entities U and V share a session key, V does not mistakenly believe the session key is shared with an entity other than U. 10

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 2.1.90 valid elliptic curve domain parameters Valid elliptic curve domain parameters are a set of elliptic curve domain parameters that have been validated as specified in this Standard. 2.1.91 XOR XOR abbreviates bitwise exclusive-or (also called bitwise addition mod 2), which is an operation on two bit strings of the same bit length. 2.1.92 x -coordinate The x-coordinate of an elliptic curve point, P =(xP, yP), is xP. 2.1.93 y-coordinate The y-coordinate of an elliptic curve point, P =(xP, yP), is yP.

2.2

x, x

Symbols and Notation The square root of x.

[X]

Indicates that the inclusion of the bit string or octet string X is optional, or that multiplication by X is optional.

[x, y]

The interval of integers between and including x and y.

x

Floor: the largest integer  x. For example, 5 = 5 and 5.3 = 5.

x

x mod n

Ceiling: the smallest integer  x. For example, 5 = 5 and 5.3 = 6.

The unique remainder r, 0  r  n - 1, when integer x is divided by n. For example, 23 mod 7 = 2.

x  y (mod n) x is congruent to y modulo n. That is, (x mod n) = (y mod n). a, b

Elements of Fq that define an elliptic curve E over Fq.

avf(P)

The associate value of the EC point P.

d

Elliptic curve private key.

D

Elliptic curve domain parameters. D = (q, FR, ECCSEED, a, b, G, n, h). ECCSEED is an optional parameter.

E

An elliptic curve over the field Fq defined by a and b.

© 2017 ASC X9, Inc. – All rights reserved

11

ANSI X9.63-2011 (R2017)

E(Fq)

The set of all points on an elliptic curve E defined over Fq and including the point at infinity O.

#E(Fq)

If E is defined over Fq, then #E(Fq) denotes the number of points on the curve (including the point at infinity O). #E(Fq) is called the order of the curve E.

f

The length of n in bits; f=log2n.

F2m

The finite field containing q = 2m elements, where m is a positive integer.

Fp

The finite field containing q = p elements, where p is a prime.

Fq

The finite field containing q elements. For this Standard, q is either an odd prime number (q = p, p ≥ 3) or a power of 2 (q = 2m).

FR

Field representation indicator. An indication of the basis used for representing the elements of Fq. FR is NULL if the field is Fp, or F2m with a GNB representation. If the field is F2m with a polynomial basis representation, then FR is the reduction polynomial (a trinomial or a pentanomial).

G

A distinguished point on an elliptic curve of large prime order called the base point or generating point.

gcd(x, y)

The greatest common divisor of integers x and y.

h

h = #E(Fq)/n, where n is the order of the base point G. h is called the cofactor.

l

The length of a field element in octets; l = t / 8.

lmax

Upper bound on the largest prime divisor of the cofactor h.

log2 x

The logarithm of x to the base 2.

LeftShift(u)

The circular left shift rotation of bit string u.

m

The degree of the finite field F2m.

mod

Modulo.

mod f(x)

Arithmetic modulo the polynomial f(x). If f(x) is a binary polynomial, then all coefficient arithmetic is performed modulo 2.

mod n

Arithmetic modulo an integer n.

n

The order of the base point G. n is the primary security parameter.

12

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) O

A special point on an elliptic curve, called the point at infinity. This is the additive identity of the elliptic curve group.

p

An odd prime number.

P

An EC point.

q

The number of elements in the field Fq.

Q

Elliptic Curve public key.

rmin

Lower bound on the desired (prime) order n of the base point G.

ECCSEED

An input to an elliptic curve domain parameter generation or validation primitive that is used to demonstrate that certain components of the domain parameters are verifiably random in the sense that the parameters could not have been selected with any special properties.

t

The length of a field element in bits; t = log2 q. In particular, if q = 2m, then a field element in F2m can be represented as a bit string of bit length t = m.

U, V, U1, U2

An entity or a bit string denoting the identity of an entity.

xP or x(P)

The x-coordinate of a point P.

||X||

Length in octets of the octet string X.

X||Y

Concatenation of two strings X and Y. Both X and Y are either bit strings, or octet strings.

XY

Bitwise exclusive-or (also bitwise addition mod 2) of two bit strings X and Y of the same bit length.

yP

The y-coordinate of a point P.

~y P

The representation of the y-coordinate of a point P when point compression is used.

z or Z

A shared secret value.

Zp

The set of integers modulo p, where p is an odd prime number.

Subscript notation is used to indicate the association of a value to a particular entity, to indicate the life expectancy of a value, or to indicate the association of a value to a particular scheme. For example: —

dU is an EC private key owned by entity U.

© 2017 ASC X9, Inc. – All rights reserved

13

ANSI X9.63-2011 (R2017)

—

Ze is an ephemeral shared secret value.

—

Genc is an EC base point associated with an encryption scheme.

—

Qs,V is a static EC public key owned by entity V.

Occasionally, subscript notation is also used to indicate a counter value associated with some data, or to indicate the base in which a particular value is being expressed if there is some possibility of ambiguity. For example, Hash1 denotes the value of Hashi when the counter i has value 1, and B116 = 101100012 = 177, so subscript 16 can indicate hexadecimal notation, subscript 2 can indicate binary notation and no subscript can indicate decimal . Octet strings are sometimes written in hexadecimal notation. . With the exception of notation that has been well-established in other documents, where possible in this Standard, capital letters will be used in variable names that denote bit strings or octet strings, and capital letters will be excluded from variable names that denote field elements or integers. For example, d is used to denote the integer that specifies an EC private key, and MacData is used to denote the bit string to be tagged using a MAC scheme. Primed variables (e.g., x) denote variables that have been received and whose validity may not have been verified. For example, MacTag denotes the purported tag on MacData, and Qe,V denotes the purported ephemeral EC public key of entity V.

2.3

Normative References

The following standards contain provisions that, through reference in this text, constitute provisions of this American National Standard (ANS). At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this American National Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. Accredited Standards Committee X9 (ASC X9) maintains a register of currently-valid financial industry standards. 1. X9 SD-34, Registry of Approved Cryptographic Resources for Financial Services Industry Standards: a. Registry Resource 00002, Advanced Encryption Standard (AES) b. Registry Resource 00003, Secure Hash Standard (SHS) c. Registry Resource 00004, The Keyed-Hash Message Authentication Code (HMAC) d. Registry Resource 00008, Modes of operation. 14

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) e. Registry Resource 00010, NIST Recommendation for Key Management Part 1: General Guideline 2.

ANS X9.62, Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA).

6.

ISO/IEC 8824-1 | ITU-T Recommendation X.680. Information Technology - Abstract Syntax Notation One (ASN.1): Specification of Basic Notation.

7.

ISO/IEC 8824-2 | ITU-T Recommendation X.681. Information Technology - Abstract Syntax Notation One (ASN.1): Information Object Specification.

8.

ISO/IEC 8824-3 | ITU-T Recommendation X.682. Information Technology - Abstract Syntax Notation One (ASN.1): Constraint Specification.

9.

ISO/IEC 8824-4 | ITU-T Recommendation X.683. Information Technology - Abstract Syntax Notation One (ASN.1): Parametrization of ASN.1 Specifications.

10.

ISO/IEC 8825-1 | ITU-T Recommendation X.690. Information Technology - ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER), and Distinguished Encoding Rules (DER).

11.

ISO/IEC 8825-2 | ITU-T Recommendation X.691. Information Technology - ASN.1 Encoding Rules: Specification of Packed Encoding Rules (PER).

12.

NIST Special Publication 800-56A Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revise). March 2007.

3

Application

3.1

General

The explosion in the use of electronic media to expedite commerce and financial transactions in recent years has led to the need for well-established cryptographic schemes that can provide such services as data integrity and data confidentiality. Symmetric schemes, such as AES, make an attractive choice for the provision of these services systems using symmetric techniques are efficient, and their security requirements are wellunderstood. However, the major drawback with the implementation of such schemes is that any two communicating entities must share a secret key. As the size of a system or the number of entities using a system increases, the establishment of this key can lead to a key management problem. © 2017 ASC X9, Inc. – All rights reserved

15

ANSI X9.63-2011 (R2017)

An attractive solution to this key management problem is for a system to employ asymmetric techniques that allow any pair of entities to establish a secret key suitable for use by a symmetric scheme, despite the fact that the two entities may never have previously engaged in a secure communication with each other. Such asymmetric techniques are known as asymmetric key establishment schemes. Asymmetric techniques for key establishment using elliptic curve cryptography have also been specified in standards ISO 11770-3, and IEEE 1363 and 1363a, SEC 1, and NIST Special Publication 800-56A.

3.2

The Schemes in this Standard

This Standard specifies asymmetric key establishment schemes. Both key agreement and key transport schemes are specified. The operation of each of the schemes employs arithmetic operations in the group of points on an elliptic curve defined over a finite field. The asymmetric key establishment schemes in this Standard are used by an entity U who wishes to establish a symmetric key with another entity V. Each entity has an EC key pair. If U and V simultaneously execute a scheme with corresponding keying material as input, then at the end of the execution of the scheme, U and V will share keying data. The keying data can then be used to supply keys for symmetric algorithms. The precise method used to supply keys for symmetric algorithms from the keying data is beyond the scope of this Standard. This Standard specifies a variety of asymmetric key establishment schemes. Each of the mechanisms, when implemented securely and embedded within a cryptographic system in an appropriate manner, is capable of providing two entities with a secret key suitable for use in symmetric algorithms like AES. A variety of schemes are specified because of the wide variety of services that may or may not be needed for a key establishment scheme to provide, depending on the environment in which the scheme is going to be used. The secret key may be agreed upon by both entities or transported from one entity to the other. Known-key security may be desirable. Any combination of the assurances of entity authentication, key-compromise impersonation, and forward secrecy may be required. These are implementation-specific decisions that this Standard attempts to facilitate. However, this Standard recommends that any implementation of the schemes specified provides explicit key authentication of any key established using the key establishment schemes. Many of the schemes specified here do not directly provide explicit key authentication, and thus, these schemes should be embedded in systems in such a way that explicit key authentication is additionally provided unless it is determined that explicit key authentication is not required. In the specification of each of the schemes, equivalent computations that result in identical output are allowed. 16

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

3.3

Implementing the Schemes Securely

During the description of each scheme specified in this Standard, a list of prerequisites for the operation of the scheme is given. These prerequisites shall be satisfied by any implementation of the scheme. Two common prerequisites for the implementation of schemes in this Standard are that: (1) all entities involved in the use of the schemes are provided with an authentic copy of the elliptic curve parameters being used; and (2) that every entity can obtain a genuine copy of every other entity’s static public key (i.e., the static public key is bound to the entity’s identity). The binding between an entity and its static public key may be accomplished by using a Certification Authority. The binding between an entity and its static public key shall include checking that the entity possesses the corresponding private key. (The process of checking that an entity possesses its private key is often known as “proof of possession”.) However, satisfying the stated prerequisites is not enough to ensure the security of an implementation. The secure implementation of the schemes in this Standard is also dependent upon: 1.

The prevention of unauthorized disclosure, use, modification, substitution, insertion, and deletion of an entity’s static private key ds.

2.

The prevention of unauthorized modification, substitution, insertion, and deletion of the elliptic curve parameters being used.

3.

The secure implementation of the transformations involved in an execution of a scheme so that the integrity and confidentiality of the computations involved is maintained.

Note that this includes the secure destruction of any ephemeral and intermediate values involved in the operation of a scheme. Note also, however, that the effect of some of the most common breaches in the above requirements may be minimized by the selection of an appropriate scheme that provides, for example, assurance of forward secrecy or known-key security. Finally, the secure implementation of the schemes does not guarantee the security of the operation of the implementation. It is the responsibility of the system manager to put an overall process in place with the necessary controls to ensure secure operations. The controls should include the application of appropriate audit tests in order to verify compliance with this Standard.

3.4

Annexes

The annexes to this Standard provide additional requirements and information on the schemes and primitives specified in this Standard and their implementation. © 2017 ASC X9, Inc. – All rights reserved

17

ANSI X9.63-2011 (R2017)

The following normative annexes are an integral part of the Standard. Annex A, for reasons of convenience, is placed immediately after all other normative elements. Annex I includes schemes that should not be used, except for backwards compatibility with implementions of the previous edition of this Standard.

Annex

Contents

A

Normative Number-Theoretic Algorithms

I

Legacy Schemes

The following informative annexes give additional information that may be useful to implementers of this Standard.

Annex

18

Contents

B

Mathematical Background

C

Tables of Trinomials, Pentanomials and Gaussian Normal Bases

D

Informative Number-Theoretic Algorithms

E

Complex Multiplication (CM) Elliptic Curve Generation Method

F

Security Considerations

G

Examples

H

ASN.1

JI

References

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

4

Mathematical Conventions

4.1

Finite Field Arithmetic

4.1.1 The Finite Field Fp See ANS X9.62, A.2.2. 4.1.2 The Finite Field F2m See ANS X9.62, A.2.3. 4.1.2.1

Trinomial and Pentanomial Basis Representation

See ANS X9.62, A.2.3.2. 4.1.2.2 4.1.2.2.1

Gaussian Normal Basis Representation Checking for a Gaussian Normal Basis

See ANS X9.62, A.2.3.3.1. 4.1.2.2.2

The Multiplication Rule for a Gaussian Normal Basis

See ANS X9.62, A.2.3.3.2. 4.1.2.2.3

A Multiplication Algorithm for a Gaussian Normal Basis

See ANS X9.62, A.2.3.3.2.

4.2

Elliptic Curves and Points

See ANS X9.62, A.3. 4.2.1 Point Compression Technique for Elliptic Curves over Fp (Optional) See ANS X9.62, A.3.1.3.2 4.2.2 Point Compression Technique for Elliptic Curves over F2m (Optional) See ANS X9.62, A.3.1.3.3.

4.3

Data Conversions

See ANS X9.62, A.5 4.3.1 Integer-to-Octet-String Conversion See ANS X9.62, A.5.2. © 2017 ASC X9, Inc. – All rights reserved

19

ANSI X9.63-2011 (R2017)

4.3.2 Octet-String-to-Integer Conversion See ANS X9.62, A.5.3. 4.3.3 Field-Element-to-Octet-String Conversion See ANS X9.62, A.5.4. 4.3.4 Octet-String-to-Field-Element Conversion See ANS X9.62, A.5.5. 4.3.5 Field-Element-to-Integer Conversion See ANS X9.62, A.5.6. 4.3.6 Point-to-Octet-String Conversion See ANS X9.62, A.5.7. 4.3.7 Octet-String-to-Point Conversion See ANS X9.62, A.5.8.

5

Cryptographic Ingredients

See ANS X9.62, Clause 6 and X9.62, Annex A.

5.1

Elliptic Curve Domain Parameter Generation and Validation

See ANS X9.62, clause A.3. 5.1.1 Primitives for Elliptic Curve Domain Parameter Generation and Validation over Fp 5.1.1.1

Elliptic Curve Domain Parameter Generation over Fp

See ANS X9.62, clause A.3.5.3. 5.1.1.2

Elliptic Curve Domain Parameter Validation over Fp

See ANS X9.62, clause A.3.5.2.

20

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 5.1.2 Primitives for Elliptic Curve Domain Parameter Generation and Validation over F2m 5.1.2.1

Elliptic Curve Domain Parameter Generation over F2m

See ANS X9.62, clause A.3.5.3. 5.1.2.2

Elliptic Curve Domain Parameter Validation over F2m

See ANS X9.62, clause A.3.5.2.

5.2

Key Pair Generation and Public Key Validation

See ANS X9.62, clause A.4. 5.2.1 Key Pair Generation Primitive See ANS X9.62, clause A.4.3. 5.2.2 Public Key Validation See ANS X9.62, clause A.4.2. 5.2.2.1

Standard Public Key Validation Primitive

See ANS X9.62, clause A.4.2. The standard public key validation primitive shall be used when validating a public key that will be used as input to the standard Diffie-Hellman primitive specified in clause 5.4.1. 5.2.2.2

Embedded Public Key Validation Primitive

See ANS X9.62, clause A.4.2, except that action step (d) is omitted.

5.3

Challenge Generation Primitive

This section specifies the primitive that shall be used to generate challenges in the 3-pass key transport scheme specified in Section 7.2. This primitive shall not be used except for compatability with existing implementations of a previous edition of this standard. Challenges shall be generated using the following transformation: Input: An integer challengelen that is the length in bits of the challenge required. challengelen shall be  112. Actions: Select a random bit string Challenge of length challengelen. The bit string Challenge shall be produced by an Approved random bit generator. © 2017 ASC X9, Inc. – All rights reserved

21

ANSI X9.63-2011 (R2017)

Output: The bit string Challenge.

5.4

Diffie-Hellman Primitives

This section specifies the two Diffie-Hellman primitives that shall be used by the key establishment schemes in this Standard. These primitives derive a shared secret value from a private key owned by an entity A and a public key owned by an entity B when the keys share the same elliptic curve domain parameters. Entity A can be either the the initiator or the responder in a scheme using this primitive. If two entities both correctly execute the same primitive with corresponding keys as inputs, the same shared secret value will be produced. The shared secret value shall only be used as part of the key establishement scheme. Two primitives are specified here: a standard Diffie-Hellman primitive and a modified DiffieHellman primitive. The standard Diffie-Hellman primitive produces a shared secret value in the traditional manner. The modified Diffie-Hellman primitive also produces a shared secret value, but has been modified to resist small subgroup attacks in a way that may, in some cases, be more efficient. (See [8].) 5.4.1 Standard Diffie-Hellman Primitive The shared secret value shall be calculated as follows: Prerequisites: The prerequisite is a set of EC domain parameters D = (q, FR, a, b, ECCSEED, G, n, h), which has been validated using the techniques described in Sections 5.1.1.2 and 5.1.2.2. Input: The standard Diffie-Hellman primitive takes as input: 1.

an EC private key d owned by A.

2.

an EC public key Q owned by B.

The public key Q shall have been validated as specified in Section 5.2.2.1. Actions: The following actions are taken: 1.

Compute the point P=dQ.

2.

Check that PO. If P=O, output ‘invalid’ and stop.

3.

Set z=xP, where xP is the x-coordinate of P.

22

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Output: zFq as the shared secret value. 5.4.2 Modified Diffie-Hellman Primitive The shared secret value shall be calculated as follows: Prerequisites: The prerequisite is a set of EC domain parameters D = (q, FR, a, b, ECCSEED, G, n, h), which has been validated using the techniques described in Sections 5.1.1.2 and 5.1.2.2. Input: The modified Diffie-Hellman primitive takes as input: 1.

an EC private key d owned by A.

2.

an EC public key Q owned by B.

The public key Q shall have been validated as specified in Section 5.2.2. Actions: The following actions are taken: 1.

Compute the point P=hdQ.

2.

Check that PO. If P=O, output ‘invalid’ and stop.

3.

Set z=xP, where xP is the x-coordinate of P.

Output: zFq as the shared secret value.

5.5

MQV Primitive

This section specifies the MQV primitive that shall be used by the key agreement schemes specified in this Standard. This primitive derives a shared secret value from two private keys owned by an entity A and two public keys owned by an entity B when all the keys share the same elliptic curve domain parameters. Entity A can be either the the initiator or the responder in a scheme using this primitive. If the two entities both correctly execute this primitive with corresponding keys as inputs, the same shared secret value will be produced. The shared secret value shall only be used as part of the key establishement scheme. The calculation of the shared secret value incorporates co-factor multiplication. Co-factor multiplication is computationally efficient and helps to prevent security problems like small subgroup attacks (see [8]). © 2017 ASC X9, Inc. – All rights reserved

23

ANSI X9.63-2011 (R2017)

The shared secret value shall be calculated as follows: Prerequisites: The prerequisite is a set of EC domain parameters D = (q, FR, a, b, ECCSEED, G, n, h), which has been validated using the techniques described in Sections 5.1.1.2 and 5.1.2.2. Input: The MQV primitive takes as input: 1.

two EC key pairs (d1,Q1) and (d2,Q2) owned by A.

2.

two EC public keys Q3 and Q4 owned by B.

The key pairs (d1,Q1) and (d2,Q2) shall have been generated using the key pair generation primitive specified in Section 5.2.1. The public keys Q3 and Q4 shall have been validated as specified in Section 5.2.2. Actions: The following actions are taken: 1.

Compute the integer: implicitsigU = (d2 + ( avf(Q2) d1 )) mod n.

2.

Compute the EC point: P = h (implicitsigU( Q4 + (avf(Q4) Q3) )).

3.

Check that PO. If P=O, output ‘invalid’ and stop.

4.

Set z=xP, where xP is the x-coordinate of P.

Output: zFq as the shared secret value.

5.6

Auxiliary Functions

This section specifies three types of auxiliary functions that are used by some of the key agreement schemes and key transport schemes specified in this Standard: associate value functions, cryptographic hash functions and key derivation functions.

5.6.1 Associate Value Function (avf) This section specifies the associate value function that shall be used by some of the schemes in this Standard. 24

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) The associate value function will be used to compute an integer associated with an elliptic curve point. The bit length of the integer is approximately half the bit length of the field elements associated with the elliptic curve point. The associate value function is used by the MQV family of key agreement schemes specified in Section 6. The associate value function shall be calculated as follows: Input: The input to the associate value function is: 1.

A valid set of EC domain parameters D = (q, FR, a, b, ECCSEED, G, n, h).

2.

A point PO on the EC defined by the parameters D.

Actions: Perform the following computations: 1.

Convert xP to an integer using the convention specified in Section 4.3.5.

2.

Calculate (where f=log2n):

3.

Calculate:

xP = xP mod 2f/2.

avf(P) = xP + 2f/2.

Output: The integer avf(P) as the associate value of P.

5.6.2 Cryptographic Hash Functions This section specifies the cryptographic hash functions that shall be used by the schemes in this Standard. The hash functions are used to calculate the hash value associated with a bit string. The hash functions are used by the key derivation function specified in Section 5.6.3 and may be used in key confirmation. An Approved hash function that offers 112 bits of security or more shall be used, i.e. an Approved hash function whose output is 224 bits or more. Possibilities, therefore, include the SHA-256 hash function, which is specified in X9 SD-34 Registry, Item 00003. The Approved hash function SHA-1 should not be used for digital signatures requiring collision resistance, except for compatability with existing implementations, because its collision resistance provides less than 112 bits of security. However, the schemes in this Standard are not © 2017 ASC X9, Inc. – All rights reserved

25

ANSI X9.63-2011 (R2017)

believed to require collision resistance, even when digital signatures are used by the scheme. Nevertheless, implementations should use Approved hash functions with output lengths of 224 bits or more, except where required for backwards compatibility. In cases where the implementation negotiates a hash function with another entity, a hash function whose output length is 224 or more bits shall be selected if both entities support such a hash function. Hash values shall be calculated as follows: Prerequisites: The prerequisite for the operation of the hash function is that an Approved hash function has been chosen. The maximum length of the input to the hash function is denoted by maxhashlen, and the length of the output of the hash function by hashlen. Input: The input to the hash function is a bit string Data of a length less than maxhashlen bits. Actions: Calculate the hash value Hash corresponding to Data using the established hash function. This process is denoted by: Hash=H(Data) where H denotes the chosen hash function. Output: The bit string Hash of length hashlen bits. Note that the hash function operates on bit strings of length less than maxhashlen bits. For example, SHA-256 operates on bit strings of length less than 264 bits. It is assumed that all hash function calls are on bit strings of length less than maxhashlen bits. Any scheme attempting to call the hash function on a bit string of length greater than or equal to maxhashlen bits shall output ‘invalid’ and stop. 5.6.3 Key Derivation Function (kdf) This section specifies key derivation functions (KDFs) that shall be used by the schemes in this Standard. Key derivation functions are used to derive keying data from a shared secret value that is represented as a bit string. Key derivation functions are also used by the asymmetric encryption schemes in Section 5.8. An Approved key derivation function shall be used. The concatenation key derivation function specified in NIST Special Publication 800-56A is Approved. The following key derivation function is also Approved. Keying data shall be calculated as follows: 26

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Prerequisites: The prerequisite for the operation of the key derivation function is that an Approved hash function has been chosen as specified in Section 5.6.2. Input: The input to the key derivation function is: 1.

A bit string Z that is the shared secret value, of bit length at most maxhashlen – 32.

2.

An integer keydatalen that is the length in bits of the keying data to be generated. keydatalen shall be less than (232–1) hashlen

3.

(Optional) A bit string SharedInfo that consists of some data shared by the two entities intended to share the secret value Z. The total bit length of Z and SharedInfo must be at most maxhashlen – 32.

Ingredients: The key derivation function employs one of the hash functions specified in Section 5.6.2. Actions: The key derivation function is computed as follows: 1. 2.

Initiate a 32-bit, big-endian bit string counter as 0000000116.

For i=1 to j= keydatalen/hashlen, do the following: 2.1

Compute Hashi = H(Z || counter || [SharedInfo]).

2.2

Increment counter.

2.3

Increment i.

3.

Let HHashj denote Hashj if keydatalen/hashlen is an integer, and let it denote the (keydatalen – (hashlen)j) leftmost bits of Hashj otherwise.

4.

Set KeyData = Hash1||Hash2||…||Hashj-1||HHashj.

Output: The bit string KeyData of length keydatalen bits. Note that the key derivation function produces keying data of length less than (232–1) hashlen bits. It is assumed that all key derivation function calls are for bit strings of length less than (232– 1) hashlen bits. Any scheme attempting to call the key derivation function for a bit string of length greater than or equal to (232–1) hashlen bits shall output ‘invalid’ and stop.

5.7

MAC schemes

This section specifies the tagging transformation and the tag checking transformation associated with the message authentication code (MAC) schemes that shall be used by the schemes in this Standard. The result of the tagging transformation is called a MacTag. © 2017 ASC X9, Inc. – All rights reserved

27

ANSI X9.63-2011 (R2017)

Each MAC scheme is used as follows. The MacTag sender uses the tagging transformation to compute the tag on some data. The MacTag recipient, after being sent the data and tag, checks the validity of the tag using the tag checking transformation. The MAC scheme is used by some key agreement schemes to provide key confirmation, and by the asymmetric encryption scheme in Section 5.8. An Approved MAC that offers 112 bits of security or more shall be used, i.e. any Approved MAC that uses keys of length 112 bits or more and that outputs tags of length 112 bits or more. Possibilities, therefore, include HMAC, which is specified in Registry Items 00004. The appropriate choice of MAC scheme in a particular application will depend on the operating environment. Issues involved in the decision will often include security requirements and available cryptographic primitives. The interface to a MAC scheme is specified as follows. Prerequisites: The prerequisite for the operation of the MAC scheme is that an Approved MAC scheme has been chosen. The length in bits of the keys used by the MAC scheme is denoted by mackeylen.

5.7.1 Tagging Transformation Data shall be tagged using the tagging transformation specified as follows: Input: The tagging transformation takes as input: 1.

A bit string MacData on which the tag is to computed.

2.

A bit string MacKey of length mackeylen bits to be used as the key.

Actions: Calculate the tag as: MacTag = MACMacKey(MacData), where MACMacKey(MacData) denotes the computation of the tag on MacData under MacKey using the tagging transformation of the established Approved MAC scheme. Output: The bit string MacTag.

28

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 5.7.2 Tag Checking Transformation The purported tag on data shall be checked using the tag checking transformation specified as follows: Input: The tag checking transformation takes as input: 1.

The data, which is a bit string MacData.

2.

The purported tag for MacData, which is a bit string MacTag.

3.

A bit string MacKey of length mackeylen bits to be used as the key.

Actions: Calculate the tag for MacData under the key MacKey as: MacTag = MACMacKey(MacData) using the tagging transformation of the established Approved MAC. Output: If MacTag=MacTag, output ‘valid’; otherwise, output ‘invalid’.

5.8

Asymmetric Encryption Scheme

This section specifies the asymmetric encryption scheme that shall be used by the legacy 1-Pass and 3-Pass key transport schemes specified in Annex I.3, which should not be used except for backwards compatibility with existing implementations of previous editions of this Standard. The asymmetric encryption scheme is Approved for direct encryption of content messages, but not for key establishment. The asymmetric encryption scheme is used as follows. The key transport sender uses the encryption transformation of the scheme to encrypt some data. The key transport receiver, after being sent the encrypted data, decrypts the encrypted data using the decryption transformation of the scheme. Note that extensions of ECIES are specified in other standards, such as SEC1, IEEE 1363A, and ISO 18033-2.

ECIES is specified as follows. Prerequisites: The following are the prerequisites for the use of the scheme: 1. The prerequisite for the operation of the Elliptic Curve Integrated Encryption Scheme is a set of EC domain parameters D = (q, FR, a, b, ECCSEED, G, n, h). The parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. © 2017 ASC X9, Inc. – All rights reserved

29

ANSI X9.63-2011 (R2017)

2. Entities using the scheme shall have established whether to use the standard DiffieHellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2. The entities shall also have established whether to use the standard public key validation primitive specified in Section 5.2.2.1 or the embedded public key validation primitive specified in Section 5.2.2.2. If the standard DiffieHellman primitive is used, then the standard public key validation primitive shall be used. 3. The entities shall have established which Approved MAC scheme as specified in Section 5.7. The length in bits of the keys used by the established MAC scheme will be denoted by mackeylen. 4. The entities shall have established an Approved key derivation function as specified in Section 5.6.3. 5.8.1 Encryption Transformation Data shall be encrypted as follows: Input: The input to the encryption transformation is: 1.

A bit string EncData, which is the data to be encrypted. The length of the bit string EncData will be indicated as encdatalen.

2.

An EC public key Q owned by the receiver

3.

(Optional) Two bit strings of data, SharedData1 and SharedData2, which are shared by the sender and the receiver.

The EC public key Q shall correspond to the EC domain parameters D. Q shall have been validated as specified in Section 5.2.2. Ingredients: The encryption transformation employs the key pair generation primitive specified in Section 5.2.1, one of the Diffie-Hellman primitives specified in Section 5.4, the tagging transformation of the established MAC scheme specified in Section 5.7, and an Approved key derivation functions as specified in Section 5.6.3. Actions: Encrypt the bit string EncData as follows: 1.

Generate an ephemeral key pair (de,Qe) corresponding to the EC domain parameters D, using the key pair generation primitive defined in Section 5.2.1.

2.

Convert Qe to a bit string QE using the convention specified in Section 4.3.6.

3.

Use the established Diffie-Hellman primitive defined in Section 5.4 to derive a shared secret value zFq from de and Q. If the Diffie-Hellman primitive outputs ‘invalid’, output ‘invalid’ and stop.

30

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 4.

Convert zFq to a bit string Z using the convention specified in Section 4.3.3.

5.

Use the established key derivation function to generate keying data KeyData of bit length encdatalen+mackeylen from Z and [SharedData1].

6.

Parse KeyData as an encryption key EncKey of bit length encdatalen and a MAC key MacKey of bit length mackeylen, i.e. parse KeyData as: KeyData = EncKey||MacKey.

7.

Compute MaskedEncData=EncData  EncKey.

8.

Compute the tag MacTag on the bit string: MacData = MaskedEncData||[SharedData2] under the MAC key MacKey using the tagging transformation of the established MAC scheme as specified in Section 5.7.

Output: Output the bit string QE||MaskedEncData||MacTag as the encryption of EncData.

5.8.2 Decryption Transformation The decryption transformation shall be calculated as follows: Input: The input to the decryption transformation is: 1.

A bit string QE||MaskedEncData||MacTag purporting to be the encryption of a bit string.

2.

An EC private key d owned by the recipient.

3.

(Optional) Two bit strings of data, SharedData1 and SharedData2, which are shared by the sender and the recipient.

The private key d shall have been generated using the key pair generation primitive specified in Section 5.2.1. Ingredients: The decryption transformation employs public key validation as specified in Section 5.2.2, one of the Diffie-Hellman primitives specified in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), the tag checking transformation of the established MAC scheme specified in Section 5.7, and an Approved key derivation functions as specified in Section 5.6.3.

© 2017 ASC X9, Inc. – All rights reserved

31

ANSI X9.63-2011 (R2017)

Actions: Decrypt the bit string QE||MaskedEncData||MacTag consisting of the encoding of a purported elliptic curve point Qe, a bit string MaskedEncData of length maskedencdatalen, and a bit string MacTag of the appropriate length as follows: 1. 2.

Convert QE to an elliptic curve point Qe using the convention specified in Section 4.3.7.

Validate the ephemeral public key Qe using public key validation as specified in Section 5.2.2. If the validation primitive outputs ‘invalid’, output ‘invalid’ and stop.

3.

Use the established Diffie-Hellman primitive defined in Section 5.4 to derive a shared secret value zFq from d and Qe. If the Diffie-Hellman primitive outputs ‘invalid’, output ‘invalid’ and stop.

4.

Convert zFq to a bit string Z using the convention specified in Section 4.3.3.

5.

Use the established key derivation function to generate keying data KeyData of bit length maskedencdatalen+mackeylen from Z and [SharedData1].

6.

Parse KeyData as an encryption key EncKey of bit length maskedencdatalen and a MAC key MacKey of bit length mackeylen, i.e. parse KeyData as: KeyData = EncKey||MacKey.

7. 8.

Compute EncData=MaskedEncData  EncKey. Verify that MacTag is the tag on MaskedEncData||[SharedData2] under the key MacKey using the tag checking transformation of the established MAC scheme specified in Section 5.7. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop.

Output: Output EncData as the decryption of QE||MaskedEncData||MacTag.

5.9

Signature Scheme

This section specifies the signature schemes that shall be used by the schemes in this Standard. A signature scheme is used as follows. The signer uses the signing transformation to compute a signature on some data. The verifier, after being sent the data and signature, checks the validity of the signature using the verifying transformation. A signature scheme is used by the Station-to-Station scheme specified in Section 6.8..

32

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) The signature scheme shall be an Approved elliptic curve-based signature scheme, which includes the Elliptic Curve Digital Signature Algorithm (ECDSA) and the Elliptic Curve Pintsov-Vanstone Signature (ECPVS) scheme. ECDSA is specified in ANS X9.62 and shall be implemented as specified in ANS X9.62. ECPVS is specified in ANS X9.92 and shall be implemented as specified in ANS X9.92. Prerequisites: The prerequisite for the operation of the ECDSA is a set of EC domain parameters Dsig = (q, FR, a, b, ECCSEED, G, n, h). The parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. An Approved hash function shall be selected as specified in Section 5.6.2.

5.9.1 Signing Transformation The transformation specified as follows shall be used to sign data: Input: The input to the signing transformation is: 1.

A bit string SignData to be signed.

2.

An elliptic curve private signature key d owned by the sender.

The private key d shall correspond to the EC parameters Dsig, and shall have been generated using the primitive specified in Section 5.2.1. Actions: Compute the values that comprise the signature on SignData. Output: The pair of integers rsig and ssig.

5.9.2 Verifying Transformation The transformation specified as follows shall be used to verify a purported signature: Input: The input to the verifying transformation is: 1.

The data, which is a bit string SignData.

2.

The values that are the purported signature of SignData.

3.

An authentic EC public signature verification key Q owned by the sender.

The public key Q shall correspond to the EC parameters Dsig, and shall have been validated as specified in Section 5.2.2.1. © 2017 ASC X9, Inc. – All rights reserved

33

ANSI X9.63-2011 (R2017)

Actions: Verify the purported signature using the verification transformation. Output: Output ‘valid’ if the verification transformation confirms that the values are a valid signature of SignData; otherwise, output ‘invalid’.

5.10 Key Confirmation Schemes Key confirmation is the assurance that the entities in a key agreement scheme or key transport scheme have indeed established the same keying data. Key confirmation can obtained by using the key confirmation schemes in NIST Special Publication 800-56a, which are Approved for use with this Standard. Some of the legacy key establishment schemes in this Standard included key confirmation, but should not be used except for compatibility with existing implementations of the previous version of this Standard.

6

Key Agreement Schemes

This section specifies the key agreement schemes that are Approved in this Standard. In each case, the key agreement scheme is used by an entity who wishes to agree on keying data with another entity. In some cases, the schemes specified are ‘symmetric’ (i.e., analogous computations are performed by the two entities), and so it suffices to describe just one transformation in terms of two entities U and V. In an execution of a symmetric key agreement scheme, it is possible that the two participating entities execute the transformation simultaneously – in this case neither entity can be identified as the initiator (or responder). If two entities A1 and A2 wish to agree on keying data using a symmetric scheme, A1 executes the transformation with U=A1 and V=A2, while A2 executes the transformation with U=A2 and V=A1. Some of the schemes are ‘asymmetric’ (i.e., different computations are performed by the two entities), and so it is necessary to describe two transformations, one of which is undertaken by U, if U is the initiator, and one of which is undertaken by V, if V is the responder. In this case, the role of initiator or responder shall be established by the protocol. In the specification of each transformation, equivalent computations that result in identical output are allowed. Each of the key agreement schemes has certain prerequisites. These are conditions that shall be satisfied by an implementation of the scheme. However the specification of mechanisms that provide these prerequisites is beyond the scope of this Standard. There are no secrecy requirements for the choices made for the prerequisites (e.g., choice of hash function, DiffieHellman primitive, MAC algorithm, elliptic curve point representation). 34

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Annex F provides guidance on the selection and use of the key agreement schemes. Annex F.4.4 provides guidance for selecting parameter sizes for the various cryptographic components of a key agreement scheme, including n, hashlen, and mackeylen. Each scheme is described in two ways. First a flow diagram of the ordinary operation of the scheme between two entities U and V is provided. This flow diagram is for descriptive purposes only. Then, a formal specification is given, which describes the actions that the entities shall take to use the scheme to establish keying data. The flow diagrams are intended to aid in the understanding of the mechanics of the ‘ordinary’ operation of the schemes in which flows are faithfully relayed between two entities. Note that in ‘real-life’, there is no reason to assume that flows are relayed faithfully between two entities…that is why the schemes must be formally specified in a more technical fashion. When examining the flow diagrams, the following points should be noted: —

For clarity of exposition, optional fields, such as Text and SharedData, are omitted, as are conversions from field elements to octet strings.

—

kdf(Z) denotes the output of a key derivation function (see Section 5.6.3) that is performed on input Z.

The key agreement schemes may involve input, output, or actions, some elements of which may be marked as optional. Optional input and output fields are fields that may or may not be present in implementations of the schemes. The schemes are designed to function whether or not these fields are present. However, if optional shared data (SharedData, SharedData1, SharedData2) is used, then both communicating parties must use the same data in order to derive the same keying data. Optional shared data is allowed to permit flexibility to higher-level protocols that use the key agreement scheme. Specifying the form of the shared data and mechanisms for sharing the data, are beyond the scope of this Standard. Optional actions are actions that may or may not be performed by implementations. The schemes are designed to function whether or not these actions are performed.

© 2017 ASC X9, Inc. – All rights reserved

35

ANSI X9.63-2011 (R2017)

Qe,U

U

V Qe,V

Ze = x([h]de,UQe,V)

Ze = x([h]de,VQe,U) KeyData = kdf(Ze)

KeyData = kdf(Ze)

Figure 1 – Ephemeral Unified Model Scheme

6.1

Ephemeral Unified Model Scheme

This section specifies the ephemeral Unified Model scheme. Figure 1 illustrates the flow of information involved in the use of the ephemeral Unified Model scheme. The scheme is ‘symmetric’, so only one transformation is specified. An entity uses this transformation to agree on keying data with another entity, no matter whether they are the initiator or the responder. Prerequisites: The following are the prerequisites for the use of the scheme: 1. Each entity has an authentic copy of the system’s elliptic curve domain parameters De = (qe, FRe, ae, be, ECCSEEDe, Ge, ne, he) to be used with ephemeral keys. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. 2. Entities using the scheme shall have established whether to use the standard DiffieHellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2. The entities shall also have established whether to use the standard public key validation primitive specified in Section 5.2.2.1 or the embedded public key validation primitive specified in Seciton 5.2.2.2. If the standard DiffieHellman primitive is used, then the standard public key validation primitive shall be used. 3. Finally, entities using the scheme shall have established which key derivation function to use (which may include a hash function).

36

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Note that validation of the EC domain parameters De may not have been performed by the two entities, but may instead have been performed by a party trusted by the entities. Note also that the subscript e is a slight abuse of notation. It is used to indicate that the parameters are associated with ephemeral key pairs, rather than to indicate that the parameters themselves are ephemeral. U shall execute the following transformation to agree on keying data with V; the actions for V are provided when “U” and “V” are exchanged in the description: Input: The input to the key agreement transformation is: 1.

An integer keydatalen, which is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits, which consists of some data shared by U and V.

Ingredients: The key agreement transformation employs the key pair generation primitive in Section 5.2.1, a public key validation method in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used) , and an Approved key derivation function as specified in Section 5.6.3. Actions: Keying data shall be derived as follows: 1.

Generate and exchange ephemeral EC public keys: Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameter set De. Send Qe,U to V. Receive an ephemeral EC public key Qe,V from V that is purportedly owned by V. If this value is not received, output ‘invalid’ and stop.

2.

Verify that Qe,V is a valid key for the parameter set De as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

3.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zeFq from the private key de,U, the purported public key Qe,V, and the parameter set De. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

4.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

5.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Ze and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits.

© 2017 ASC X9, Inc. – All rights reserved

37

ANSI X9.63-2011 (R2017)

Qs,V

U

V Qe,U

Z = x([h]de,UQs,V)

Z = x([h]ds,VQe,U) KeyData = kdf(Z)

KeyData = kdf(Z)

Figure 2 – 1-Pass Diffie-Hellman Scheme

6.2

1-Pass Diffie-Hellman Scheme

This section specifies the 1-pass Diffie-Hellman scheme. Figure 2 illustrates the flow of information involved in the use of the 1-pass Diffie-Hellman scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Section 6.2.1 to agree on keying data with V if U is the scheme’s initiator, and V uses the transformation specified in Section 6.2.2 to agree on keying data with U if V is the scheme’s responder. The essential difference between the role of the initiator and the role of the responder is that the initiator contributes an ephemeral key pair, but no static key pair, while the responder contributes a static key pair, but no ephemeral key pair. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set D = (q, FR, a, b, ECCSEED, G, n, h). These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

2.

Entities using the scheme shall have established whether to use the standard DiffieHellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2. The responder shall also have established whether to use the standard public key validation primitive specified in Section 5.2.2.1 or the embedded public key validation primitive specified in Seciton 5.2.2.2 to validate the initiator’s

38

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) ephemeral public key. If the standard Diffie-Hellman primitive is used, then the standard public key validation primitive shall be used by the responder to validate the initiator’s ephemeral public key. 3.

The entity who acts as a responder shall be bound to a static key pair associated with the system’s elliptic curve domain parameter set D. The binding process shall include the validation of the static public key as specified in Section 5.2.2. If the standard DiffieHellman primitive is used, then the standard public key validation specified in Section 5.2.2.1 shall be used to validate the responder’s static public key.

4.

The entities shall have established an Approved key derivation function as specified in Section 5.6.3).

6.2.1 Initiator Transformation U shall execute the following transformation to agree on keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s static public key Qs,V. Input: The input to the initiator transformation is: 1.

An integer keydatalen, that is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits, that consists of some data shared by U and V.

Ingredients: The initiator transformation employs the key pair generation primitive in Section 5.2.1, one of the Diffie-Hellman primitives in Section 5.4, and an Approved key derivation function as specified in Section 5.6.3. Actions: Keying data shall be derived as follows: 1.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameter set D. Send Qe,U to V.

2.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zFq from the private key de,U, the static public key Qs,V, and the parameter set D. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

3.

Convert z to a bit string Z using the convention specified in Section 4.3.3.

4.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Z and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits. © 2017 ASC X9, Inc. – All rights reserved

39

ANSI X9.63-2011 (R2017)

6.2.2 Responder Transformation V shall execute the following transformation to agree on keying data with U if V is the scheme’s responder: Input: The input to the responder transformation is: 1.

An ephemeral EC public key Qe,U, purportedly owned by U.

2.

An integer keydatalen, which is the length in bits of the keying data to be generated.

3.

(Optional) A bit string SharedData of length shareddatalen bits, which consists of some data shared by U and V.

Ingredients: The key agreement transformation employs the public key validation method in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard DiffieHellman primitive is used, then the standard public key validation method must be used), and an Approved key derivation function as specified in Section 5.6.3. Actions: Keying data shall be derived as follows: 1.

Receive an ephemeral public key Qe,U from U that is purportedly owned by U and verify that Qe,U is a valid key for the parameter set D as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

2.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zFq from the private key ds,V, the purported public key Qe,U, and the parameter set D. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

3.

Convert z to a bit string Z using the convention specified in Section 4.3.3.

4.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Z and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits.

40

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Qs,U

U

V Qs,V

Zs = x([h]ds,UQs,V)

Zs = x([h]ds,VQs,U) KeyData = kdf(Zs)

KeyData = kdf(Zs)

Figure 3 – Static Unified Model Scheme

6.3

Static Unified Model Scheme

This section specifies the static Unified Model scheme. Figure 3 illustrates the flows of information involved in the use of the static Unified Model scheme. The scheme is ‘symmetric’, so only one transformation is specified. An entity uses this transformation to agree on keying data with another entity, no matter whether they are the initiator or the responder. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set Ds = (qs, FRs, as, bs, ECCSEEDs, Gs, ns, hs) to be used with static keys. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

2.

Entities using the scheme shall have established whether to use the standard DiffieHellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2.

3.

Each entity shall be bound to a static key pair associated with the system’s elliptic curve domain parameter set Ds to be used with static keys. The binding process shall include the validation of the static public key as specified in Section 5.2.2. the standard DiffieHellman primitive is used by the scheme, then the standard public key validation primitive specified in Seciton 5.2.2.1 shall be used to to validate each entity's static public key.

© 2017 ASC X9, Inc. – All rights reserved

41

ANSI X9.63-2011 (R2017)

4.

The entities shall have established an Approved key derivation function.

Note that validation of Qs,V has not necessarily been performed by U, but may instead have been performed, for example, by the CA issuing a certificate that binds V and Qs,V. U shall execute the following transformation to agree on keying data with V. U shall obtain an authentic copy of V’s static public key Qs,V. Input: The input to the key agreement transformation is: 1.

An integer keydatalen that is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The key agreement transformation employs one of the Diffie-Hellman primitives in Section 5.4 and an Approved key derivation function as specified in Section 5.3.6. Actions: Keying data shall be derived as follows: 1.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zsFq from the private key ds,U, the public key Qs,V, and the parameter set Ds. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

2.

Convert zs to a bit string Zs using the convention specified in Section 4.3.3.

3.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Zs and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits.

6.4

Combined Unified Model with Key Confirmation Scheme

See Annex I.2.1.

42

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Qs,U

Qs,V

U

V

Qe,U Ze = x([h]de,UQs,V)

Ze = x([h]ds,VQe,U)

Zs = x([h]ds,UQs,V)

Zs = x([h]ds,VQs,U)

KeyData = kdf(Ze || Zs)

KeyData = kdf(Ze || Zs)

Figure 4 – 1-Pass Unified Model Scheme

6.5

1-Pass Unified Model Scheme

This section specifies the 1-pass Unified Model scheme. Figure 4 illustrates the flow of information involved in the use of the 1-pass Unified Model scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Section 6.5.1 to agree on keying data with V if U is the scheme’s initiator, and V uses the transformation specified in Section 6.5.2 to agree on keying data with U if V is the scheme’s responder. The essential difference between the role of the initiator and the role of the responder in the scheme is that the initiator contributes an ephemeral key pair, but the responder does not. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set D = (q, FR, a, b, ECCSEED, G, n, h). These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

2.

Entities using the scheme shall have established whether to use the standard DiffieHellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2. The responder shall also have established whether to use the

© 2017 ASC X9, Inc. – All rights reserved

43

ANSI X9.63-2011 (R2017)

standard public key validation primitive specified in Section 5.2.2.1 or the embedded public key validation primitive specified in Seciton 5.2.2.2 to validate the initiator’s ephemeral public key. If the standard Diffie-Hellman primitive is used, then the standard public key validation primitive shall be used. 3.

Each entity shall be bound to a static key pair associated with the system’s elliptic curve domain parameter set D. The binding process shall include the validation of the static public key as specified in Section 5.2.2. If the standard Diffie-Hellman primitive is used, then the standard public key validation primitive specified in Section 5.2.2.1 shall be used.

4.

The entities shall have established an Approved key derivation function as specified in Section 5.6.3.

6.5.1 Initiator Transformation U shall execute the following transformation to agree on keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s static public key Qs,V. Input: The input to the key agreement transformation is: 1.

An integer keydatalen, which is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits, which consists of some data shared by U and V.

Ingredients: The initiator transformation employs the key pair generation primitive in Section 5.2.1, one of the Diffie-Hellman primitives in Section 5.4, and an Approved key derivation function as specified in Section 5.6.3. Actions: Keying data shall be derived as follows: 1.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameter set D. Send Qe,U to V.

2.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zeFq from the private key de,U, the public key Qs,V, and the parameter set D. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

3.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

4.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zsFq from the private key ds,U, the public key Qs,V, and the parameter set D. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

5.

Convert zs to a bit string Zs using the convention specified in Section 4.3.3.

44

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 6.

Concatenate Ze and Zs to form the shared secret value Z = Ze||Zs.

7.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Z and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits. 6.5.2 Responder Transformation V shall execute the following transformation to agree on keying data with U if V is the scheme’s responder. V shall obtain an authentic copy of U’s static public key Qs,U. Input: The input to the responder transformation is: 1.

An ephemeral EC public key Qe,U purportedly owned by U.

2.

An integer keydatalen that is the length in bits of the keying data to be generated.

3.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The responder transformation employs the public key validation method specified in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), and an Approved key derivation function as specified in Section 5.6.3. Actions: Keying data shall be derived as follows: 1.

Receive an ephemeral public key Qe,U from U that is purportedly owned by U , and verify that Qe,U is a valid key for the parameter set D as specified in Section 5.2.2. If the primitive rejects the key, output ‘invalid’ and stop.

2.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zeFq from the private key ds,V, the purported public key Qe,U, and the parameter set D. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

3.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

4.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zsFq from the private key ds,V, the public key Qs,U, and the parameter set D. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

5.

Convert zs to a bit string Zs using the convention specified in Section 4.3.3.

6.

Concatenate Ze and Zs to form the shared secret value Z = Ze||Zs.

© 2017 ASC X9, Inc. – All rights reserved

45

ANSI X9.63-2011 (R2017)

Qs,U

Qs,V

U

V Qe,U

Qe,V Ze = x([h]de,UQe,V)

Ze = x([h]de,VQe,U)

Zs = x([h]ds,UQs,V)

Zs = x([h]ds,VQs,U)

KeyData = kdf(Ze || Zs)

KeyData = kdf(Ze || Zs)

Figure 5 – Full Unified Model Scheme 7.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Z and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits.

6.6

Full Unified Model Scheme

This section specifies the full Unified Model scheme. Figure 5 illustrates the information flows involved in the use of the full Unified Model scheme. The scheme is ‘symmetric’, so only one transformation is specified. An entity uses this transformation to agree on keying data with another entity no matter whether they are the initiator or the responder. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

46

Each entity has an authentic copy of the system’s elliptic curve domain parameter set De = (qe, FRe, ae, be, ECCSEEDe, Ge, ne, he) to be used with ephemeral keys. These parameters shall have been generated using the parameter generation primitives in © 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. 2.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set Ds = (qs, FRs, as, bs, ECCSEEDs, Gs, ns, hs) to be used with static keys. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. The domain parameter set for static keys Ds and ephemeral De shall be the same, except for backwards compatibility with existing implementations of the previous edition of this Standard.

3.

The entities shall have established whether to use the standard Diffie-Hellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2. Each entity shall also have established whether to use the standard public key validation primitive specified in Section 5.2.2.1 or the embedded public key validation primitive specified in Section 5.2.2.2 to validate ephemeral public keys. If the standard Diffie-Hellman primitive is used by the scheme, then the standard public key validation primitive shall be used by each entity to validate the other entity's ephemeral public key.

4.

Each entity shall be bound to a static key pair associated with the system’s elliptic curve domain parameter set Ds to be used with static keys. The binding process shall include the validation of the static public key as specified in Section 5.2.2. If the standard DiffieHellman primitive is used by the scheme, then the standard public key validation primitive specified in Section 5.2.2.1 shall be used to to validate each entity's static public key.

5.

The entities shall have established an Approved key derivation function as specified in Section 5.6.3.

U shall execute the following transformation to agree on keying data with V. U shall obtain an authentic copy of V’s static public key Qs,V. Input: The input to the key agreement transformation is: 1.

An integer keydatalen that is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The key agreement transformation employs the key pair generation primitive in Section 5.2.1, a public key validation method in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), and an Approved key derivation function as specified in Section 5.6.3. Actions: Keying data shall be derived as follows: © 2017 ASC X9, Inc. – All rights reserved

47

ANSI X9.63-2011 (R2017)

1.

Generate and exchange ephemeral EC public keys: Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameters De. Send Qe,U to V. Receive an ephemeral EC public key Qe,V from V that is purportedly owned by V. If this value is not received, output ‘invalid’ and stop.

2.

Verify that Qe,V is a valid key for the parameter set De as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

3.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zeFq from the private key de,U, the purported public key Qe,V, and the parameter set De. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

4.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

5.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zsFq from the private key ds,U, the public key Qs,V, and the parameter set Ds. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

6.

Convert zs to a bit string Zs using the convention specified in Section 4.3.3.

7.

Concatenate Ze and Zs to form the shared secret value Z = Ze||Zs.

8.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Z and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits.

6.7

Full Unified Model with Key Confirmation Scheme

See Annex I.2.2.

48

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Qsig,U

Qsig,V

Qe,U

U

V

Qe,V, MACMacKey( QEV || QEU || U ), SIGdsig,V( QEV || QEU || U ) MACMacKey( QEU || QEV || V ), SIGdsig,U( QEU || QEV || V ) Ze = x([h]de,UQe,V)

Ze = x([h]de,VQe,U))

MacKey || KeyData = kdf(Ze)

MacKey || KeyData = kdf(Ze)

Figure 6 – Station-to-Station Scheme

6.8

Station-to-Station Scheme

This section specifies the Station-to-Station scheme. The scheme uses a signature scheme to authenticate the ephemeral Unified Model scheme and provide mutual explicit key authentication. Figure 6 illustrates the information flows involved in the use of the Station-to-Station scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Section 6.8.1 to agree on keying data with V if U is the scheme’s initiator, and V uses the transformation specified in Section 6.8.2 to agree on keying data with U if V is the scheme’s responder. The essential difference between the role of the initiator and the role of the responder is merely that the initiator sends the first pass of the exchange. Prerequisites: The following are the prerequisites for the use of the scheme: © 2017 ASC X9, Inc. – All rights reserved

49

ANSI X9.63-2011 (R2017)

1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set De = (qe, FRe, ae, be, ECCSEEDe, Ge, ne, he) to be used with ephemeral keys. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

2.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set Dsig = (qsig, FRsig, asig, bsig, ECCSEEDsig, Gsig, nsig, hsig) to be used with a signature scheme. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

3.

Each entity shall be bound to a static signing key pair (dsig, Qsig) associated with the system’s elliptic curve domain parameter set Dsig for signing. The binding process shall include the validation of the public signature as specified in Section 5.2.2.

4.

The entities shall have established whether to use the standard Diffie-Hellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2. Each entity shall also have established whether to use the standard public key validation primitive specified in Section 5.2.2.1 or the embedded public key validation primitive specified in Section 5.2.2.2 to validate ephemeral public keys. If the standard Diffie-Hellman primitive is used by the scheme, then the standard public key validation primitive shall be used by each entity to validate the other entity's ephemeral public key.

5.

Each entity shall have established an Approved MAC scheme as specified in Section 5.7. mackeylen will denote the length of the keys used by the MAC scheme chosen.

6.

The entities shall have established an Approved key derivation function as specified in Section 5.6.3.

7.

Each entity shall have decided how to represent elliptic curve points as octet strings (i.e., compressed form, uncompressed form, or hybrid form).

6.8.1 Initiator Transformation U shall execute the following transformation to agree on keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s identifier and V’s static public key Qsig,V. Input: The input to the initiator transformation is: 1.

50

An integer keydatalen that is the length in bits of the keying data to be generated.

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 2.

(Optional) A bit string SharedData of length shareddatalen that consists of some data shared by U and V.

Ingredients: The initiator transformation employs the key pair generation primitive in Section 5.2, a public key validation in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), an Approved key derivation function as specified in Section 5.6.3, an Approved MAC scheme as specified in Section 5.7, and an Approved signature scheme as specified in Section 5.9. Actions: Keying data shall be derived as follows: 1.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U, Qe,U) for the parameter set De. Send Qe,U to V .

2.

Then receive an ephemeral public key Qe,V from V that is purportedly owned by V, a pair of integers rsig1 and ssig1 purporting to be a signature, a purported tag MacTag1, and an optional bit string Text1. If this data is not received, output ‘invalid’ and stop.

3.

Verify that Qe,V is a valid key for the parameter set De as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

4.

Convert Qe,U and Qe,V to the octet strings QEU and QEV using the convention in Section 4.3.6. Form the bit string consisting of the bit string QEV, the bit string QEU, U’s identifier, and Text1 (if present): Data1 = QEV || QEU || U || [Text1].

5.

Verify that rsig1 and ssig1 are the components of a valid signature of Data1 under V’s public signature key Qsig,V corresponding to the EC domain parameter set Dsig, using the verifying transformation of the signature scheme in Section 5.9. If the verifying transformation outputs ‘invalid’, output ‘invalid’ and stop.

6.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value ze in Fq from the private key de,U, the purported ephemeral public key Qe,V, and the parameter set De. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

7.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

8.

Use the established key derivation function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret value Ze and the shared data [SharedData].

9.

Parse the leftmost macdatalen bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.

© 2017 ASC X9, Inc. – All rights reserved

51

ANSI X9.63-2011 (R2017)

10.

11.

Verify that MacTag1 is the tag for Data1 under the key MacKey using the tag checking transformation of the established MAC scheme. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop. Form the bit string consisting of the bit string QEU corresponding to U’s ephemeral public key, the bit string QEV corresponding to V’s purported ephemeral public key, V’s identifier, and, optionally, a bit string Text2: Data2 = QEU || QEV || V || [Text2].

12.

Sign Data2 using U’s private signing key dsig,U corresponding to the parameter set Dsig, using the signing transformation of the signature scheme in Section 5.9. If the signing transformation outputs ‘invalid’, output ‘invalid’ and stop. Otherwise the signing transformation outputs the integers rsig2 and ssig2 as the signature of Data2.

13.

Calculate the tag MacTag2 on Data2 under the key MacKey using the tagging transformation of the established MAC scheme: MacTag2 = MACMacKey(Data2). If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send rsig2, ssig2, MacTag2 and Text2 (if present) to V.

Output: The bit string KeyData as the keying data of length keydatalen bits.

6.8.2 Responder Transformation V shall execute the following transformation to agree on keying data with U if V is the scheme’s responder. V shall obtain an authentic copy of U’s identifier and U’s static public key Qsig,U. Input: The input to the responder transformation is: 1.

An ephemeral public key Qe,U purportedly owned by U.

2.

An integer keydatalen that is the length in bits of the keying data to be generated.

3.

(Optional) A bit string SharedData of length shareddatalen that consists of some data shared by U and V.

Ingredients: The responder transformation employs the key pair generation primitive in Section 5.2., a public key validation method in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), an Approved key derivation 52

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) function as specified in Section 5.6.3, an Approved MAC scheme as specified in Section 5.7, and an Approved signature scheme as specified in Section 5.9. Actions: Keying data shall be derived as follows: 1.

Receive an ephemeral public key Qe,U from U that is purportedly owned by U , and verify that Qe,U is a valid key for the parameter set De as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

2.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,V; Qe,V) for the parameter set De.

3.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value ze in Fq from the private key de,V, the purported public key Qe,U, and the parameter set De. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

4.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

5.

Use the established key derivation function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret value Ze and the shared data [SharedData].

6.

Parse the leftmost macdatalen bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.

7.

Convert Qe,U and Qe,V to the octet strings QEU and QEV using the convention in Section 4.3.6. Form the bit string consisting of the bit string QEV, the bit string QEU, U’s identifier, and, optionally, a bit string Text1: Data1 = QEV || QEU || U || [Text1].

8.

Sign Data1 using V’s private signing key dsig,V corresponding to the parameter set Dsig, using the signing transformation of the signature scheme in Section 5.9. If the signing transformation outputs ‘invalid’, output ‘invalid’ and stop. Otherwise the signing transformation outputs the integers rsig1 and ssig1 as the signature of Data1.

9.

Calculate the tag MacTag1 on Data1 under the key MacKey using the tagging transformation of the established MAC scheme: MacTag1 = MACMacKey(Data1). If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send Qe,V, rsig1, ssig1, MacTag1 and if present Text1 to U.

Then receive from U a pair of integers rsig1 and ssig1 purporting to be a signature, a purported tag MacTag2, and an optional bit string Text2. If these values are not received, output ‘invalid’ and stop. © 2017 ASC X9, Inc. – All rights reserved

10.

53

ANSI X9.63-2011 (R2017)

11.

Form the bit string consisting of the bit string QEU corresponding to U’s purported ephemeral public key, the bit string QEV corresponding to V’s ephemeral public key, V’s identifier, and the bit string Text2 (if present): Data2 = QEU || QEV || V || [Text2].

12.

13.

Verify that rsig2 and ssig2 are a valid signature of Data2 under U’s public signature key Qsig,U corresponding to the EC domain parameter set Dsig, using the verifying transformation of the signature scheme in Section 5.9. If the verifying transformation outputs ‘invalid’, output ‘invalid’ and stop. Verify that MacTag2 is the tag for Data2 under the key MacKey using the tag checking transformation of the established MAC scheme. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop.

Output: The bit string KeyData as the keying data of length keydatalen bits.

54

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Qs,U

Qs,V

U

V

Qe,U implicitsigU = de,U + avf(Qe,U) ds,U

implicitsigV = ds,V + avf(Qs,V) ds,V

R = h (implicitsigU (Qs,V + avf(Qs,V) Qs,V )) Z = xR

R = h (implicitsigV ( Qe,U + avf(Qe,U) Qs,U )) Z = xR

KeyData = kdf(Z)

KeyData = kdf(Z)

Figure 7 – 1-Pass MQV Scheme

6.9

1-Pass MQV Scheme

This section specifies the 1-pass MQV scheme. Figure 7 illustrates the information flows involved in the use of the 1-pass MQV scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Section 6.9.1 to agree on keying data with V if U is the scheme’s initiator, and V uses the transformation specified in Section 6.9.2 to agree on keying data with U if V is the scheme’s responder. The essential difference between the role of the initiator and the role of responder in the scheme is that the initiator contributes an ephemeral key pair, but the responder does not. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set D = (q, FR, a, b, ECCSEED, G, n, h). These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the

© 2017 ASC X9, Inc. – All rights reserved

55

ANSI X9.63-2011 (R2017)

parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. 2.

Each entity shall be bound to a static key pair associated with the system’s elliptic curve domain parameter set D. The binding process shall include the validation of the static public key as specified in Section 5.2.2.

3.

The entities shall have established an Approved key derivation function.

6.9.1 Initiator Transformation U shall execute the following transformation to agree on keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s static public key Qs,V. Input: The input to the key agreement transformation is: 1.

An integer keydatalen that is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The initiator transformation employs the key pair generation primitive in Section 5.2.1, the MQV primitive in Section 5.5, the associate value function in Section 5.6.1, and an Approved key derivation function as Specified in Section 5.6.3. Actions: Keying data shall be derived as follows: 1.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameter set D. Send Qe,U to V.

2.

Use the MQV primitive in Section 5.5 to derive a shared secret value zFq from the key pairs (d1,Q1)=(ds,U,Qs,U) and (d2,Q2)=(de,U,Qe,U), the public key Q3=Q4=Qs,V, and the parameter set D. If the MQV primitive outputs ‘invalid’, output ‘invalid’ and stop.

3.

Convert z to a bit string Z using the convention specified in Section 4.3.3.

4.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Z and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits.

56

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 6.9.2 Responder Transformation V shall execute the following transformation to agree on keying data with U if V is the scheme’s responder. V shall obtain an authentic copy of U’s static public key Qs,U. Input: The input to the responder transformation is: 1.

An ephemeral EC public key Qe,U purportedly owned by U.

2.

An integer keydatalen that is the length in bits of the keying data to be generated.

3.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The responder transformation employs a public key validation method in Section 5.2.2, the MQV primitive in Section 5.5, the associate value function in Section 5.6.1, and an Approved derivation function as specified in Section 5.6.3. Actions: Keying data shall be derived as follows: 1.

Receive an ephemeral public key Qe,U from U that is purportedly owned by U , and verify that Qe,U is a valid key for the parameter set D as specified in Section 5.2.2. If the primitive rejects the key, output ‘invalid’ and stop.

2.

Use the MQV primitive in Section 5.5 to derive a shared secret value zFq from the key pair (d1,Q1)=(d2,Q2)=(ds,V,Qs,V), the public keys Q3=Qs,U and Q4= Qe,U, and the parameter set D. If the MQV primitive outputs ‘invalid’, output ‘invalid’ and stop.

3.

Convert z to a bit string Z using the convention specified in Section 4.3.3.

4.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Z and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits.

6.10 Full MQV Scheme This section specifies the full MQV scheme.

© 2017 ASC X9, Inc. – All rights reserved

57

ANSI X9.63-2011 (R2017)

Qs,U

Qs,V

Qe,U

U

V

Qe,V implicitsigU = de,U + avf(Qe,U) ds,U

implicitsigV = de,V + avf(Qe,V) ds,V

R = h (implicitsigU ( Qe,V + avf(Qe,V) Qs,V ))

R = h (implicitsigV ( Qe,U + avf(Qe,U) Qs,U ))

Z = xR

Z = xR

KeyData = kdf(Z)

KeyData = kdf(Z)

Figure 8 – Full MQV Scheme Figure 8 illustrates the information flows involved in the use of the full MQV scheme. The scheme is ‘symmetric’, so only one transformation is specified. An entity uses this transformation to agree on keying data with another entity no matter whether they are the initiator or the responder. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set D = (q, FR, a, b, ECCSEED, G, n, h). These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

2.

Each entity shall be bound to a static key pair associated with the system’s elliptic curve domain parameter set D. The binding process shall include the validation of the static public key as specified in Section 5.2.2.

58

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 3.

The entities shall have established an Approved key derivation function.

U shall execute the following transformation to agree on keying data with V. U shall obtain an authentic copy of V’s static public key Qs,V. Input: The input to the key agreement transformation is: 1.

An integer keydatalen that is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The key agreement transformation employs the key pair generation primitive in Section 5.2.1, a public key validation method in Section 5.2.2, the MQV primitive in Section 5.5, the associate value function in Section 5.6.1, and an Approved key derivation function as specified in Section 5.6.3. Actions: Keying data shall be derived as follows: 1.

Exchange ephemeral EC public keys: Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameter set D. Send Qe,U to V. Receive from V an ephemeral EC public key Qe,V purportedly owned by V. If this value is not received, output ‘invalid’ and stop.

2.

Verify that Qe,V is a valid key for the parameter set D as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

3.

Use the MQV primitive in Section 5.5 to derive a shared secret value zFq from the key pairs (d1,Q1)=(ds,U,Qs,U) and (d2,Q2)=(de,U,Qe,U), the public keys Q3=Qs,V and Q4= Qe,V, and the parameter set D. If the MQV primitive outputs ‘invalid’, output ‘invalid’ and stop.

4.

Convert z to a bit string Z using the convention specified in Section 4.3.3.

5.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Z and the shared data [SharedData].

Output: The bit string KeyData as the keying data of length keydatalen bits.

6.11 Full MQV with Key Confirmation Scheme See Annex I.2.3.

© 2017 ASC X9, Inc. – All rights reserved

59

ANSI X9.63-2011 (R2017)

7

Key Transport Schemes

See Annex I.3.

7.1

1-Pass Transport Scheme

See Annex I.3.1.

7.2

3-Pass Transport Scheme

See Annex I.3.2.

60

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Annex A (normative) Normative Number-Theoretic Algorithms See ANS X9.62, Annex A.

© 2017 ASC X9, Inc. – All rights reserved

61

ANSI X9.63-2011 (R2017)

Annex B (informative) Mathematical Background See ANS X9.62, Annex G, for the some mathematical background to finite fields and elliptic curves.

62

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Annex C (informative) Tables of Trinomials, Pentanomials, and Gaussian Normal Bases See ANS X9.62 Annex H for tables of trinomials, pentanomials and Gaussian normal bases.

© 2017 ASC X9, Inc. – All rights reserved

63

ANSI X9.63-2011 (R2017)

Annex D (informative) Informative Number-Theoretic Algorithms See ANS X9.62, Annex I.

64

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Annex E (informative) Complex Multiplication (CM) Elliptic Curve Generation Method See ANS X9.62 Annex J, which describes a method for generating an elliptic curve with a known order. The method may be used for selecting an appropriate elliptic curve and point (see Annex A).

© 2017 ASC X9, Inc. – All rights reserved

65

ANSI X9.63-2011 (R2017)

Annex F (informative) Security Considerations This annex is provided as an initial guidance for implementers of this Standard. This information should be expected to change over time. Implementers should review the current state-of-the-art attacks on the schemes at the time of implementation. Implementers should also review SEC1 Version 2.0, Appendix B.

F.1

The Elliptic Curve Discrete Logarithm Problem

See ANS X9.62, K.2.

F.2

Elliptic Curve Domain Parameters

See ANS X9.62, K.3.

F.3

Key Pairs

See ANS X9.62, K.4.

F.4

Key Establishment Schemes

This section discusses issues particularly relevant to the security of key establishment schemes and, in particular, the suite of key establishment schemes in this Standard.

F.4.1 The ECDLP and Key Establishment Schemes Each of the key establishment schemes specified in this Standard is dependent for its security on the difficulty of the ECDLP. An adversary of a scheme who is able to solve the ECDLP is able to recover the EC private key from any EC public key, and in this way compromise any key established using the key establishment scheme. However, there is a gap in the above statement. It says that the key establishment schemes are insecure if the ECDLP can be solved, but does not say that the key establishment schemes are 66

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) secure if the ECDLP cannot be solved efficiently. It is conceivable that some attack could be found that compromises the security of the key establishment scheme without contradicting the supposed difficulty of the ECDLP. Much research has focused on closing this gap between the difficulty of the ECDLP and the security of the key establishment schemes. At best, in some cases the research has led to a proof of equivalence between the two problems in some ‘formal model’, while in other cases the equivalence remains a conjecture, albeit one that has not been disproved by a sizeable amount of public scrutiny. A relevant stepping stone between the two problems is the elliptic curve Diffie-Hellman problem (ECDHP). The ECDHP is stated as follows: given an elliptic curve E, a base point PE, and k1P and k2P with k1 and k2 randomly chosen, calculate k1k2P. The relevance of this stepping stone is easily explained. For example, it is clearly the problem that faces a passive adversary of the ephemeral Unified Model scheme. Other results of this kind have been justified in the literature: [2] discusses the equivalence between the ECDHP and the asymmetric encryption scheme in Section 5.8, and [3] discusses the equivalence between the ECDHP and various Unified Model schemes. Both of these equivalences are proved in a ‘formal model’. [12] and [16] discuss the conjectured equivalence between the ECDHP and the MQV schemes. Such equivalences, whether conjectured or ‘formally’ demonstrated, should certainly be viewed with skepticism…‘real-life’ adversaries are seldom restrained to acting within the ‘formal models’ discussed in these results. Nonetheless, the results instill confidence that the relationship between the difficulty of the ECDHP and the security of the scheme is indeed close. Linking the difficulty of the ECDLP to the difficulty of the ECDHP remains to be shown. A result of this type is provided by [4]. This paper shows that provided the ECDLP is exponentially hard (as is currently believed), then the two problems are indeed computationally equivalent. Taken in totality, these results provide some assurance of the statement that ‘the ECDLP is the basis for the security of the EC schemes’.

F.4.2 Security Attributes and Key Establishment Schemes The fundamental goal of any key establishment scheme is to distribute keying data. Ideally, the keying data should have precisely the same attributes as keying data established face-to-face. It should be randomly distributed, and no unauthorized entity should know anything about the keying data. However, while asymmetric key establishment schemes offer many advantages over traditional face-to-face key establishment, there is a price to pay for this added functionality. No asymmetric scheme can offer unconditional security in an information-theoretic sense…this just means that an adversary with unlimited computing power can certainly recover the keying data. In practice, this unavoidable shortcoming does not pose a major problem, since it seems © 2017 ASC X9, Inc. – All rights reserved

67

ANSI X9.63-2011 (R2017)

reasonable to assume that practical adversaries are computationally bounded. Indeed, the security of all widely-used symmetric schemes relies on a similar computational assumption. The goal, then, of an asymmetric key establishment scheme is to be indistinguishable from a face-to-face key establishment as far as any computationally bounded (‘polynomial-time’) adversary is concerned. Such an abstract goal needs to be clarified, and over the years the goal has been reformulated in terms of a number of more concrete attributes: implicit and explicit authentication, forward secrecy, known-key security, etc. These are typically attributes that are provided by face-to-face key establishment, and which have been identified as desirable in the asymmetric setting in various applications. Some of the attributes, such as explicit key authentication, are considered to be important in almost all applications. Others, such as forward secrecy and known-key security, are important in some environments, but less important in others. This Standard provides a suite of key establishment schemes. All the schemes are extremely efficient among schemes of their type. A variety of schemes has been provided so that as large as possible a selection of other desirable attributes may be provided. Section F.4.3 provides guidance on the attributes that may be provided by each of the schemes.

F.4.3 Security Attributes of the Schemes in this Standard This section provides guidance to implementors about which cryptographic services each of the schemes in this Standard may be capable of providing. Table F-2 contains a summary of the services that may be provided by each scheme. The services are discussed in the context of an entity U who has successfully executed the key establishment scheme wishing to establish keying data with entity V. In the table: —

IR indicates that the assurance is provided to both the initiator and the responder.

—

IR? indicates the same thing as IR, with the exception of a theoretical technicality.

—

I indicates that the assurance is provided to the scheme’s initiator.

—

R indicates that the assurance is provided to the scheme’s responder..

—

 indicates that the assurance is not provided to either the initiator or the responder.

—

n/a indicates that the assurance is not applicable.

The names of the services have been abbreviated to save space: IKA denotes implicit key authentication, EKA denotes explicit key authentication, EA denotes entity authentication, K-KS 68

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) denotes known-key security, FS denotes forward secrecy, K-CI denotes key-compromise impersonation resilience, and UK-S denotes unknown key-share resilience. The provision of these assurances is considered in the case that both U and V are honest and have always executed the scheme correctly. The requirement that U and V are honest is certainly necessary for the provision of any service by a key establishment scheme: no key establishment scheme can protect against a dishonest entity who chooses to reveal the session key…just as no encryption scheme can guard against an entity who chooses to reveal confidential data.

Table F-1 – Attributes Provided by Key Establishment Schemes Scheme

Section

IKA

K-KS

FS

K-CI UK-S

Ephemeral Unified Model

6.1



IR?1

n/a.

n/a.





Ephemeral Unified Model (against passive attacks)

6.1

IR



IR

n/a.

n/a.

IR

1-Pass Diffie-Hellman Scheme

6.2

I









I



Static Unified Model

6.3

IR











IR?4

Combined Unified Model with Key Confirmation

6.4

IR

IR

IR

IR

IR



IR

1-Pass Unified Model

6.5

IR







I

IR?4

Full Unified Model

6.6

IR





IR?1

IR?2



IR?4

Full Unified Model with Key Confirmation

6.7

IR

IR

IR

IR

IR



IR

Station-to-Station Scheme 6.8

IR

IR

IR

IR

IR

IR

IR

1-Pass MQV

6.9

IR

Full MQV

6.10

IR



Full MQV with Key Confirmation

6.11

IR

IR

1-Pass Key Transport

7.1

I



© 2017 ASC X9, Inc. – All rights reserved

EKA EA 













I

5

IR

IR?2

IR

5

IR

IR

IR

IR

IR



3



I





69

ANSI X9.63-2011 (R2017)

3-Pass Key Transport

7.2

IR

IR

IR

IR6



IR

IR

Although schemes like the Full Unified Model scheme and the Full MQV scheme do not automatically provide explicit key authentication, explicit key authentication is often provided when the keying data they provide is subsequently used, for example to MAC some data. Notes: 1.

The technicality hinges on the definition of what constitutes ‘another session key’. Known-key security is certainly provided if the scheme is extended so that explicit authentication of all session keys is supplied.

2.

The technicality concerns explicit authentication. Both schemes provide forward secrecy if explicit authentication is supplied for all session keys. If explicit authentication is not supplied, forward secrecy cannot be guaranteed.

3.

The 1-pass key transport scheme can easily be implemented in a manner that provides known-key security when the scheme is used with the elliptic curve integrated encryption scheme. Simply include a counter in the optional Text field, and increment this counter each time a new session key is transported from U to V. Provided that the responder checks that the counter has been incremented each time a new session key is established, this prevents known-key attacks on the scheme involving the replay of previous flows.

4.

These schemes are believed to provide unknown key-share resilience when knowledge of the private key is checked during certification of the static public keys.

5.

These observations were made by Kaliski [10].

6.

The 3-pass key transport scheme provides known-key security when used in conjunction with the elliptic curve integrated encryption scheme.

It is also sometimes of interest to note that the initiator or the responder of a key transport scheme provides the transported key. Of the key transport schemes specified in this Standard, the initiator provides the transported key in the 1-pass key transport scheme, and the responder provides the transported key in the 3-pass key transport scheme.

F.4.4 Appropriate Key Lengths The goal of each key establishment scheme is to establish secret keying data that is shared by two entities. It should be no easier to attack the key establishment scheme than it is to simply guess the established key. That is, when one is establishing keys for subsequent use in a 70

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) symmetric key algorithm, one wants to ensure that the key establishment scheme is at least as strong (i.e. takes at least as many operations to break) as the symmetric key algorithm. This principle should be used to provide guidance on the size of the EC parameters selected, and on the size of parameters for other cryptographic components, including cryptographic hash functions, MAC schemes, challenge generation primitives, elliptic curve generation, and pseudorandom bit generators. This section provides guidance on the minimum sizes of the following parameters if the key establishment scheme is being used to establish symmetric keys of various sizes: 1.

The primary EC security parameter n.

2.

The output length hashlen of the cryptographic hash function employed (Section 5.6.2).

3.

The key length mackeylen of the MAC scheme employed (Section 5.7).

4.

The length challengelen of the random challenge in the challenge generation primitive (Section 5.3).

This guidance is made based on the following assumptions: 1.

The best method to discover the value of a key for a symmetric key scheme is key exhaustion using a few known plaintext/ciphertext pairs. That is, for a 128-bit key, it takes 2128 trial encryptions, etc. This is a goal of any symmetric key scheme.

2.

These symmetric key trial encryptions are able to be done in parallel. That is, if m processors are used to attempt the trial encryptions, the time needed to exhaust the key space is reduced by a factor of m.

3.

The best method for breaking the key establishment scheme is to discover the private key. This is a goal of any asymmetric key establishment scheme.

4.

The best method for recovering an EC private key is to solve the particular ECDLP associated with the key. The best methods to solve the ECDLP are square root methods that take a number of operations that is approximately equal to the square root of the order n of the generator.

5.

These EC operations for solving the ECDLP are able to be done in parallel.

6.

For simplicity, an EC operation is assumed to take the same amount of time as the symmetric key encryption operation. In practice, this is a very conservative assumption: all known practical symmetric key algorithms are faster than known practical public key algorithms.

The above assumptions lead to the guidance that the appropriate EC key size (that is, the size of n) is about twice the size of the symmetric key. Table F-3 describes the bounds on n, hashlen, mackeylen, and challengelen that should be adopted to ensure that the EC key establishment key © 2017 ASC X9, Inc. – All rights reserved

71

ANSI X9.63-2011 (R2017)

is at least as strong as the symmetric algorithm key being established. Note that symmetric key sizes (or strengths) of 80 bits (which appeared in the previous version of this Standard) are not provided in Table F-3.

72

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Table F-2 – Guidelines on Aligning Parameter Sizes and Symmetric Key Size Symmetric key size (in bits)

Lower bound on n

Lower bound on hashlen (in bits)

Lower bound on mackeylen (in bits)

Lower bound on challengelen (in bits)

112

2224

224

112

112

128

2256

256

128

128

192

2384

384

192

192

256

2512

512

256

256

© 2017 ASC X9, Inc. – All rights reserved

73

ANSI X9.63-2011 (R2017)

Annex G (informative) Examples This annex contains 5 parts. -

Annex G.1 presents examples of data conversion methods.

-

Annex G.2 points to an external source (NIST) for examples of Key Agreement schemes defined over F2m.

-

Annex G.3 points to an external source (NIST) for examples Key Agreement schemes defined over Fp.

-

Annex G.4 presents sample elliptic curves over the field F2m with domain parameters for m = 163, 193, 233, 239, 283, 409, and 571.

-

Annex G.5 presents sample elliptic curves over the field Fp with domain parameters for 160bit, 192-bit, 224-bit, 256-bit, 384-bit, and 521-bit primes.

G.1

Examples of Data Conversion Methods

The following are examples of the data conversion techniques that shall be used in this Standard.

Example of Integer-to-Octet-String Conversion. (See Section 4.3.1) Input: x = 123456789, k = 4 Output: M = 075BCD15

Example of Octet-String-to-Integer Conversion. (See Section 4.3.2) Input: M = 0003ABF1CD Output: x = 61600205

2 Examples of Field-Element-to-Octet-String Conversion. (See Section 4.3.3) 1. 74

Input:  = 94311, q =104729 (an odd prime).

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Output: S = 017067 (l = 3). 2.

Input:  = 11011011011101111001101111110110111110001, q = 241.

Output: S = 01B6EF37EDF1 (l = 6).

2 Examples of Octet-String-to-Field-Element Conversion. (See Section 4.3.4) 1.

2.

Input: S = 01E74E (l = 3), q = 224737 (an odd prime).

Output:  = 124750.

Input: S = 0117B2939ACC (l = 6), q = 241.

Output:  = 10001011110110010100100111001101011001100.

2 Examples of Field-Element-to-Integer Conversion. (See Section 4.3.5) 1.

Input:  = 136567, q = 287117, (an odd prime). Output: x = 136567.

2.

Input:  = 11111111001000010011110000110011110101110, q = 241. Output: x = 2191548508078.

2 Examples of Point-to-Octet-String Conversion. (See Section 4.3.6) 1.

Input: p = 1461501637330902918203684832716283019651637554291 and the curve E: y2 = x3+ax+b, where: a = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFAC70, b = B4E134D3 FB59EB8B AB572749 04664D5A F50388BA, and the point P = (xP, yP), where: xP = 770583243196400293316427305222217463947576732373 yP = 629046656899823137693886377666819845291423047061 Output: (compressed form)

© 2017 ASC X9, Inc. – All rights reserved

75

ANSI X9.63-2011 (R2017)

PO = 03 86FA25CF 0A09E7DE D3DC5D0B 90DE16DD 731BEAD5 2.

Input: q = 2163, and the irreducible polynomial which generates F21 6 3 : f = 8 00000000 00000000 00000000 00000000 000000C9, and the curve E: y2+xy = x3+ax2+b over F2163, where: a = 07 B6882CAA EFA84F95 54FF8428 BD88E246 D2782AE2, b = 00 13612DCD DCB40AAB 946BDA29 CA91F73A F958AFD9, and the point is P = (xP , yP), where: xP =

04 89804941 BF14DF94 9439D2CE 24C90953 B572D653,

yP =

03 4A71C824 C95B917C D1385F5C F87162E9 60C066DD.

Output: (compressed form) PO = 0204 89804941 BF14DF94 9439D2CE 24C90953 B572D653.

2 Examples of Octet-String-to-Point Conversion. (See Section 4.3.7) 1.

Input: p = 1461501637330902918203684832716283019651637554291 and the curve E: y2 = x3+ax+b where: a = FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFAC70, b = B4E134D3 FB59EB8B AB572749 04664D5A F50388BA, and the octet string: PO = 03 86FA25CF 0A09E7DE D3DC5D0B 90DE16DD 731BEAD5. Output: The point is P = (xP , yP), where: xP = 770583243196400293316427305222217463947576732373, yP = 629046656899823137693886377666819845291423047061.

2. 76

Input: q = 2163, © 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) and the irreducible polynomial which generates F21 6 3 : f = 8 00000000 00000000 00000000 00000000 000000C9, and the curve E: y2+xy = x3+ax2+b over F2163, where: a = 07 B6882CAA EFA84F95 54FF8428 BD88E246 D2782AE2, b = 00 13612DCD DCB40AAB 946BDA29 CA91F73A F958AFD9, and the octet string: PO = 0204 89804941 BF14DF94 9439D2CE 24C90953 B572D653. Output: The point is P = (xP, yP) , where:

G.2

xP =

04 89804941 BF14DF94 9439D2CE 24C90953 B572D653,

yP =

03 4A71C824 C95B917C D1385F5C F87162E9 60C066DD.

Examples of Schemes over the Field F2m

See http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/KS_ECC_Characteristic2.pdf

G.3

Examples of Schemes over the Field Fp

See http://csrc.nist.gov/groups/ST/toolkit/documents/Examples/KS_ECC_Prime.pdf

G.4

Sample Elliptic Curves over the Field F2m

This section presents sample curves over F2m that may be used to ensure the correct implementation of this Standard. Section G.4.1 gives sample curves over F2193. Section G.4.2 gives sample curves over F2233. Section G.4.3 gives a sample curve over F2239. Section G.4.4 gives sample curves over F2283. Section G.4.5 gives sample curves over F2409. Section G.4.6 gives sample curves over F2571.

© 2017 ASC X9, Inc. – All rights reserved

77

ANSI X9.63-2011 (R2017)

G.4.1 2 Examples with m = 193 This section specifies two sample elliptic curves over F2193. Both examples specify parameters generated verifiably at random using the method described in Annex A.3.3.1. Elliptic Curve Domain Parameter Setup 1.

The field F2193 is generated by the irreducible trinomial: f=

2.

02 00000000 00000000 00000000 00000000 00000000 00008001

The curve is E: y2+xy = x3+ax2+b over F2193.

Example 1 ECCSEED

=

103FAEC7 4D696E67 68756151 75777FC5 B191EF30

a=

00 17858FEB 7A989751 69E171F7 7B4087DE 098AC8A9 11DF7B01

b=

00 FDFB49BF E6C3A89F ACADAA7A 1E5BBC7C C1C2E5D8 31478814

Base point G (with point compression): 0301 F481BC5F 0FF84A74 AD6CDF6F DEF4BF61 79625372 D8C0C5E1

Base point G (without point compression): xG =

01 F481BC5F 0FF84A74 AD6CDF6F DEF4BF61 79625372 D8C0C5E1

yG =

00 25E399F2 903712CC F3EA9E3A 1AD17FB0 B3201B6A F7CE1B05

Order of G: n=

01 00000000 00000000 00000000 C7F34A77 8F443ACC 920EBA49

The cofactor: h=

02

Example 2 ECCSEED

a= 78

=

10B7B4D6 96E67687 56151751 37C8A16F D0DA2211

01 63F35A51 37C2CE3E A6ED8667 190B0BC4 3ECD6997 7702709B

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) b=

00 C9BB9E89 27D4D64C 377E2AB2 856A5B16 E3EFB7F6 1D4316AE

Base point G (with point compression): 0300 D9B67D19 2E0367C8 03F39E1A 7E82CA14 A651350A AE617E8F

Base point G (without point compression): xG =

00 D9B67D19 2E0367C8 03F39E1A 7E82CA14 A651350A AE617E8F

yG =

01 CE943356 07C304AC 29E7DEFB D9CA01F5 96F92722 4CDECF6C

Order of G: n=

01 00000000 00000000 00000001 5AAB561B 005413CC D4EE99D5

The cofactor: h=

02

G.4.2 2 Examples with m = 233 This section specifies two sample elliptic curves over F2233. The first example specifies parameters associated with a Koblitz curve. The second example specifies parameters generated verifiably at random.

Elliptic Curve Domain Parameter Setup (trinomial basis) 1.

The field F2233 is generated by the irreducible trinomial: f=

2.

0200 00000000 00000000 00000000 00000000 00000400 00000000 00000001

The curve is E: y2+xy = x3+ax2+b over F2233.

Example 1 a= b=

0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

Base point G (with point compression): 020172 32BA853A 7E731AF1 29F22FF4 149563A4 19C26BF5 0A4C9D6E EFAD6126

© 2017 ASC X9, Inc. – All rights reserved

79

ANSI X9.63-2011 (R2017)

Base point G (without point compression): xG = 0172 32BA853A 7E731AF1 29F22FF4 149563A4 19C26BF5 0A4C9D6E EFAD6126 yG = 01DB 537DECE8 19B7F70F 555A67C4 27A8CD9B F18AEB9B 56E0C110 56FAE6A3 Order of G: n=

80 00000000 00000000 00000000 00069D5B B915BCD4 6EFB1AD5 F173ABDF

The cofactor: h=

04

Example 2 ECCSEED

a= b=

=

74D59FF0 7F6B413D 0EA14B34 4B20A2DB 049B50C3

0000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 0066 647EDE6C 332C7F8C 0923BB58 213B333B 20E9CE42 81FE115F 7D8F90AD

Base point G (with point compression): 0300FA C9DFCBAC 8313BB21 39F1BB75 5FEF65BC 391F8B36 F8F8EB73 71FD558B

Base point G (without point compression): xG = yG =

00FA C9DFCBAC 8313BB21 39F1BB75 5FEF65BC 391F8B36 F8F8EB73 71FD558B 0100 6A08A419 03350678 E58528BE BF8A0BEF F867A7CA 36716F7E 01F81052

Order of G: n=

0100 00000000 00000000 00000000 0013E974 E72F8A69 22031D26 03CFE0D7

The cofactor: h=

80

02

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) G.4.3 Example with m = 239 This section specifies a sample elliptic curve over F2239. The example specifies parameters associated with a Koblitz curve.

Elliptic Curve Domain Parameter Setup (trinomial basis) 1.

The field F2239 is generated by the irreducible trinomial: f=

2.

8000 00000000 00000000 40000000 00000000 00000000 00000000 00000001

The curve is E: y2+xy = x3+ax2+b over F2239.

Example a= b=

0000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

Base point G (with point compression): 0329A0 B6A887A9 83E97309 88A68727 A8B2D126 C44CC2CC 7B2A6555 193035DC

Base point G (without point compression): xG = yG =

29A0 B6A887A9 83E97309 88A68727 A8B2D126 C44CC2CC 7B2A6555 193035DC 7631 0804F12E 549BDB01 1C103089 E73510AC B275FC31 2A5DC6B7 6553F0CA

Order of G: n=

2000 00000000 00000000 00000000 005A79FE C67CB6E9 1F1C1DA8 00E478A5

The cofactor: h=

04

© 2017 ASC X9, Inc. – All rights reserved

81

ANSI X9.63-2011 (R2017)

G.4.4 2 Examples with m = 283 This section specifies two sample elliptic curves over F2283. The first example specifies parameters associated with a Koblitz curve. The second example specifies parameters generated verifiably at random.

Elliptic Curve Domain Parameter Setup (pentanomial basis) 1.

The field is F2283 generated by the irreducible pentanomial: f=

2.

08000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000010A1

The curve is E: y2+xy = x3+ax2+b over the field F2283.

Example 1 a= b=

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001

Base point G (with point compression): 02 0503213F 78CA4488 3F1A3B81 62F188E5 53CD265F 23C1567A 16876913 B0C2AC24 58492836

Base point G (without point compression): xG = yG =

0503213F 78CA4488 3F1A3B81 62F188E5 53CD265F 23C1567A 16876913 B0C2AC24 58492836 01CCDA38 0F1C9E31 8D90F95D 07E5426F E87E45C0 E8184698 E4596236 4E341161 77DD2259

Order of G: n=

01FFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFE9AE 2ED07577 265DFF7F 94451E06 1E163C61

The cofactor: h= 82

04

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Example 2 ECCSEED

a= b=

=

77E2B073 70EB0F83 2A6DD5B6 2DFC88CD 06BB84BE

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000001 027B680A C8B8596D A5A4AF8A 19A0303F CA97FD76 45309FA2 A581485A F6263E31 3B79A2F5

Base point G (with point compression): 03 05F93925 8DB7DD90 E1934F8C 70B0DFEC 2EED25B8 557EAC9C 80E2E198 F8CDBECD 86B12053

Base point G (without point compression): xG = yG =

05F93925 8DB7DD90 E1934F8C 70B0DFEC 2EED25B8 557EAC9C 80E2E198 F8CDBECD 86B12053 03676854 FE24141C B98FE6D4 B20D02B4 516FF702 350EDDB0 826779C8 13F0DF45 BE8112F4

Order of G: n=

03FFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFEF90 399660FC 938A9016 5B042A7C EFADB307

The cofactor: h=

02

G.4.5 2 Examples with m = 409 This section specifies two sample elliptic curves over F2409. The first example specifies parameters associated with a Koblitz curve. The second example specifies parameters generated verifiably at random.

Elliptic Curve Domain Parameter Setup (trinomial basis) 1.

The field is generated by the irreducible trinomial: f=

2.

02000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00800000 00000000 00000001

The curve is E: y2+xy = x3+ax2+b over the field F2409.

© 2017 ASC X9, Inc. – All rights reserved

83

ANSI X9.63-2011 (R2017)

Example 1 a=

00

b=

01

Base point G (with point compression): 03 0060F05F 658F49C1 AD3AB189 0F718421 0EFD0987 E307C84C 27ACCFB8 F9F67CC2 C460189E B5AAAA62 EE222EB1 B35540CF E9023746

Base point G (without point compression): xG = yG =

060F05F 658F49C1 AD3AB189 0F718421 0EFD0987 E307C84C 27ACCFB8 F9F67CC2 C460189E B5AAAA62 EE222EB1 B35540CF E9023746 1E36905 0B7C4E42 ACBA1DAC BF04299C 3460782F 918EA427 E6325165 E9EA10E3 DA5F6C42 E9C55215 AA9CA27A 5863EC48 D8E0286B

Order of G: n=

330527984395124299475957654016385519914202341482140609642324395022 880711289249191050673258457777458014096366590617731358671

The cofactor: h=

04

Example 2 ECCSEED

b=

=

4099B5A4 57F9D69F 79213D09 4C4BCD4D 4262210B

021A5C2 C8EE9FEB 5C4B9A75 3B7B476B 7FD6422E F1F3DD67 4761FA99 D6AC27C8 A9A197B2 72822F6C D57A55AA 4F50AE31 7B13545F

Base point G (with point compression): 03 015D4860 D088DDB3 496B0C60 64756260 441CDE4A F1771D4D B01FFE5B 34E59703 DC255A86 8A118051 5603AEAB 60794E54 BB7996A7

Base point G (without point compression): xG = yG = 84

15D4860 D088DDB3 496B0C60 64756260 441CDE4A F1771D4D B01FFE5B 34E59703 DC255A86 8A118051 5603AEAB 60794E54 BB7996A7 061B1CF AB6BE5F3 2BBFA783 24ED106A 7636B9C5 A7BD198D 0158AA4F 5488D08F 38514F1F DF4B4F40 D2181B36 81C364BA 0273C706 © 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Order of G: n=

661055968790248598951915308032771039828404682964281219284648798304 157774827374805208143723762179110965979867288366567526771

The cofactor: h=

02

G.4.6 2 Examples with m = 571 This section specifies two sample elliptic curves over F2571. The first example specifies parameters associated with a Koblitz curve. The second example specifies parameters generated verifiably at random.

Elliptic Curve Domain Parameter Setup (pentanomial basis) 1.

The field is generated by the irreducible pentanomial: f=

2.

08000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000425

The curve is E: y2+xy = x3+ax2+b over the field F2571.

Example 1 a = 00 b = 01 Base point G (with point compression): 02 026EB7A8 59923FBC 82189631 F8103FE4 AC9CA297 0012D5D4 60248048 01841CA4 43709584 93B205E6 47DA304D B4CEB08C BBD1BA39 494776FB 988B4717 4DCA88C7 E2945283 A01C8972

Base point G (without point compression): xG =

yG =

026EB7A8 59923FBC 82189631 F8103FE4 AC9CA297 0012D5D4 60248048 01841CA4 43709584 93B205E6 47DA304D B4CEB08C BBD1BA39 494776FB 988B4717 4DCA88C7 E2945283 A01C8972 349DC80 7F4FBF37 4F4AEADE 3BCA9531 4DD58CEC 9F307A54 FFC61EFC 006D8A2C 9D4979C0 AC44AEA7 4FBEBBB9 F772AEDC B620B01A 7BA7AF1B 320430C8 591984F6 01CD4C14 3EF1C7A3

© 2017 ASC X9, Inc. – All rights reserved

85

ANSI X9.63-2011 (R2017)

Order of G: n=

193226876150862917234767594546599367214946366485321749932861762572 575957114478021226813397852270671183470671280082535146127367497406 6617311929682421617092503555733685276673

The cofactor: h=

04

Example 2 ECCSEED

b=

=

2AA058F7 3A0E33AB 486B0F61 0410C53A 7F132310

2F40E7E 2221F295 DE297117 B7F3D62F 5C6A97FF CB8CEFF1 CD6BA8CE 4A9A18AD 84FFABBD 8EFA5933 2BE7AD67 56A66E29 4AFD185A 78FF12AA 520E4DE7 39BACA0C 7FFEFF7F 2955727A

Base point G (with point compression): 03 0303001D 34B85629 6C16C0D4 0D3CD775 0A93D1D2 955FA80A A5F40FC8 DB7B2ABD BDE53950 F4C0D293 CDD711A3 5B67FB14 99AE6003 8614F139 4ABFA3B4 C850D927 E1E7769C 8EEC2D19

Base point G (without point compression): xG =

yG =

303001D 34B85629 6C16C0D4 0D3CD775 0A93D1D2 955FA80A A5F40FC8 DB7B2ABD BDE53950 F4C0D293 CDD711A3 5B67FB14 99AE6003 8614F139 4ABFA3B4 C850D927 E1E7769C 8EEC2D19 37BF273 42DA639B 6DCCFFFE B73D69D7 8C6C27A6 009CBBCA 1980F853 3921E8A6 84423E43 BAB08A57 6291AF8F 461BB2A8 B3531D2F 0485C19B 16E2F151 6E23DD3C 1A4827AF 1B8AC15B

Order of G: n=

386453752301725834469535189093198734429892732970643499865723525145 151914228956042453614399938941577308313388112192694448624687246281 6813070234528288303332411393191105285703

The cofactor: h=

86

02

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

G.5

Sample Elliptic Curves over the Field Fp

This section presents sample curves over Fp that may be used to ensure the correct implementation of this Standard. Section G.5.1 gives sample curves over 192-bit prime fields. Section G.5.2 gives sample curves over 224-bit prime fields. Section G.5.3 gives sample curves over 256-bit prime fields. Section G.5.4 gives a sample curve over a 384-bit prime field. Section G.5.5 gives a sample curve over a 521-bit prime field.

G.5.1 2 Examples with a 192-bit Prime This section specifies two sample elliptic curves over 192-bit prime fields Fp. The first example specifies parameters associated with a Koblitz curve. The second example specifies parameters generated verifiably at random.

Example 1 Elliptic Curve Domain Parameter Setup 1.

The field Fp is generated by the prime: p = 6277101735386680763835789423207666416102355444459739541047

2.

The curve is E: y2 = x3+ax+b over Fp.

Elliptic Curve Domain Parameters a=

00000000 00000000 00000000 00000000 00000000 00000000

b=

00000000 00000000 00000000 00000000 00000000 00000003

Base point G (with point compression): 03 DB4FF10E C057E9AE 26B07D02 80B7F434 1DA5D1B1 EAE06C7D

Base point G (without point compression): xG =

DB4FF10E C057E9AE 26B07D02 80B7F434 1DA5D1B1 EAE06C7D

yG =

9B2F2F6D 9C5628A7 844163D0 15BE8634 4082AA88 D95E2F9D

Order of G: n=

FFFFFFFF FFFFFFFF FFFFFFFE 26F2FC17 0F69466A 74DEFD8D

© 2017 ASC X9, Inc. – All rights reserved

87

ANSI X9.63-2011 (R2017)

The cofactor: h=

01

Example 2 Elliptic Curve Domain Parameter Setup 1.

The field Fp is generated by the prime: p = 6277101735386680763835789423207666416083908700390324961279

2.

The curve is E: y2 = x3+ax+b over Fp.

Elliptic Curve Domain Parameters ECCSEED

=

3045AE6F C8422F64 ED579528 D38120EA E12196D5

a=

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFFFF FFFFFFFC

b=

64210519 E59C80E7 0FA7E9AB 72243049 FEB8DEEC C146B9B1

Base point G (with point compression): 03 188DA80E B03090F6 7CBF20EB 43A18800 F4FF0AFD 82FF1012

Base point G (without point compression): xG =

188DA80E B03090F6 7CBF20EB 43A18800 F4FF0AFD 82FF1012

yG =

07192B95 FFC8DA78 631011ED 6B24CDD5 73F977A1 1E794811

Order of G: n=

FFFFFFFF FFFFFFFF FFFFFFFF 99DEF836 146BC9B1 B4D22831

The cofactor: h=

01

G.5.2 2 Examples with a 224-bit Prime This section specifies two sample elliptic curves over 224-bit prime fields Fp. The first example specifies parameters associated with a Koblitz curve. The second example specifies parameters generated verifiably at random. 88

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Example 1 Elliptic Curve Domain Parameter Setup 1.

The field Fp is generated by the prime: p = 26959946667150639794667015087019630673637144422540572481099315 275117

2.

The curve is E: y2 = x3+ax+b over Fp.

Elliptic Curve Domain Parameters a=

00000000 00000000 00000000 00000000 00000000 00000000 00000000

b=

00000000 00000000 00000000 00000000 00000000 00000000 00000005

Base point G (with point compression): 03 A1455B33 4DF099DF 30FC28A1 69A467E9 E47075A9 0F7E650E B6B7A45C

Base point G (without point compression): xG =

A1455B33 4DF099DF 30FC28A1 69A467E9 E47075A9 0F7E650E B6B7A45C

yG =

7E089FED 7FBA3442 82CAFBD6 F7E319F7 C0B0BD59 E2CA4BDB 556D61A5

Order of G: n=

01 00000000 00000000 00000000 0001DCE8 D2EC6184 CAF0A971 769FB1F7

The cofactor: h=

01

Example 2 Elliptic Curve Domain Parameter Setup 1.

The field Fp is generated by the prime: p = 269599466671506397946670150856585012059533905686870740513765 37403391

2.

The curve is E: y2 = x3+ax+b over Fp.

© 2017 ASC X9, Inc. – All rights reserved

89

ANSI X9.63-2011 (R2017)

Elliptic Curve Domain Parameters ECCSEED

=

BD713447 99D5C7FC DC45B59F A3B9AB8F 6A948BC5

a=

00000000 00000000 00000000 00000000 00000000 00000000 00000001

b=

B4050A85 0C04B3AB F5413256 5044B0B7 D7BFD8BA 270B3943 2355FFB4

Base point G (with point compression): 02 B70E0CBD 6BB4BF7F 321390B9 4A03C1D3 56C21122 343280D6 115C1D21

Base point G (without point compression): xG =

B70E0CBD 6BB4BF7F 321390B9 4A03C1D3 56C21122 343280D6 115C1D21

yG =

BD376388 B5F723FB 4C22DFE6 CD4375A0 5A074764 44D58199 85007E34

Order of G: n=

FFFFFFFF FFFFFFFF FFFFFFFF FFFF16A2 E0B8F03E 13DD2945 5C5C2A3D

The cofactor: h=

01

G.5.3 2 Examples with a 256-bit Prime This section specifies two sample elliptic curves over 256-bit prime fields Fp. The first example specifies parameters associated with a Koblitz curve. The second example specifies parameters generated verifiably at random.

Example 1 Elliptic Curve Domain Parameter Setup 1.

The field Fp is generated by the prime: p = 115792089237316195423570985008687907853269984665640564039457 584007908834671663

2.

90

The curve is E: y2 = x3+ax+b over Fp.

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Elliptic Curve Domain Parameters a= b=

00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000007

Base point G (with point compression): 02 79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798

Base point G (without point compression): xG = yG =

79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8

Order of G: n=

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE BAAEDCE6 AF48A03B BFD25E8C D0364141

The cofactor: h=

01

Example 2 Elliptic Curve Domain Parameter Setup 1.

The field Fp is generated by the prime: p = 115792089210356248762697446949407573530086143415290314195533 631308867097853951

2.

The curve is E: y2 = x3+ax+b over Fp.

Elliptic Curve Domain Parameters ECCSEED

a=

=

C49D3608 86E70493 6A6678E1 139D26B7 819F7E90

FFFFFFFF 00000001 00000000 00000000 00000000 FFFFFFFF FFFFFFFF FFFFFFFC

© 2017 ASC X9, Inc. – All rights reserved

91

ANSI X9.63-2011 (R2017)

b=

5AC635D8 AA3A93E7 B3EBBD55 769886BC 651D06B0 CC53B0F6 3BCE3C3E 27D2604B

Base point G (with point compression): 03 6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296

Base point G (without point compression): xG = yG =

6B17D1F2 E12C4247 F8BCE6E5 63A440F2 77037D81 2DEB33A0 F4A13945 D898C296 4FE342E2 FE1A7F9B 8EE7EB4A 7C0F9E16 2BCE3357 6B315ECE CBB64068 37BF51F5

Order of G: n=

FFFFFFFF 00000000 FFFFFFFF FFFFFFFF BCE6FAAD A7179E84 F3B9CAC2 FC632551

The cofactor: h=

01

G.5.4 An Example with a 384-bit Prime This section specifies a sample elliptic curve over a 384-bit prime field Fp. The example specifies parameters generated verifiably at random.

Example Elliptic Curve Domain Parameter Setup 1.

The field Fp is generated by the prime: p = 394020061963944792122790401001436138050797392704654466679482 93404245721771496870329047266088258938001861606973112319

2.

The curve is E: y2 = x3+ax+b over Fp.

Elliptic Curve Domain Parameters ECCSEED 92

=

A335926A A319A27A 1D00896A 6773A482 7ACDAC73

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) a= b=

FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFE FFFFFFFF 00000000 00000000 FFFFFFFC B3312FA7 E23EE7E4 988E056B E3F82D19 181D9C6E FE814112 0314088F 5013875A C656398D 8A2ED19D 2A85C8ED D3EC2AEF

Base point G (with point compression): 03 AA87CA22 BE8B0537 8EB1C71E F320AD74 6E1D3B62 8BA79B98 59F741E0 82542A38 5502F25D BF55296C 3A545E38 72760AB7

Base point G (without point compression): xG = yG =

AA87CA22 BE8B0537 8EB1C71E F320AD74 6E1D3B62 8BA79B98 59F741E0 82542A38 5502F25D BF55296C 3A545E38 72760AB7 3617DE4A 96262C6F 5D9E98BF 9292DC29 F8F41DBD 289A147C E9DA3113 B5F0B8C0 0A60B1CE 1D7E819D 7A431D7C 90EA0E5F

Order of G: n=

394020061963944792122790401001436138050797392704654466679469052796 27659399113263569398956308152294913554433653942643

The cofactor: h = 01 G.5.5 An Example with a 521-bit Prime This section specifies a sample elliptic curve over a 521-bit prime field Fp. The example specifies parameters generated verifiably at random.

Example Elliptic Curve Domain Parameter Setup 1.

The field Fp is generated by the prime: p = 686479766013060971498190079908139321726943530014330540939446 3459185543183397656052122559640661454554977296311391480858037 121987999716643812574028291115057151

2.

The curve is E: y2 = x3+ax+b over Fp.

© 2017 ASC X9, Inc. – All rights reserved

93

ANSI X9.63-2011 (R2017)

Elliptic Curve Domain Parameters ECCSEED

a=

b=

=

D09E8800 291CB853 96CC6717 393284AA A0DA64BA

01FF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFC 051 953EB961 8E1C9A1F 929A21A0 B68540EE A2DA725B 99B315F3 B8B48991 8EF109E1 56193951 EC7E937B 1652C0BD 3BB1BF07 3573DF88 3D2C34F1 EF451FD4 6B503F00

Base point G (with point compression): 0200C6 858E06B7 0404E9CD 9E3ECB66 2395B442 9C648139 053FB521 F828AF60 6B4D3DBA A14B5E77 EFE75928 FE1DC127 A2FFA8DE 3348B3C1 856A429B F97E7E31 C2E5BD66

Base point G (without point compression): xG =

yG =

C6 858E06B7 0404E9CD 9E3ECB66 2395B442 9C648139 053FB521 F828AF60 6B4D3DBA A14B5E77 EFE75928 FE1DC127 A2FFA8DE 3348B3C1 856A429B F97E7E31 C2E5BD66 118 39296A78 9A3BC004 5C8A5FB4 2C7D1BD9 98F54449 579B4468 17AFBD17 273E662C 97EE7299 5EF42640 C550B901 3FAD0761 353C7086 A272C240 88BE9476 9FD16650

Order of G: n=

686479766013060971498190079908139321726943530014330540939446345918 554318339765539424505774633321719753296399637136332111386476861244 0380340372808892707005449

The cofactor: h=

94

01

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Annex H (informative) ASN.1 The ASN.1 syntax from SEC 1, version 2.0 should be used, where possible. Where not possible, the following definitions may be used. Several different types of information may need to be conveyed during the operation of the schemes specified in this Standard. This section provides Abstract Syntax Notation One (ASN.1) syntax that may be used to convey this information. While it is not required that scheme-related information be represented with ASN.1 syntax, if it is so represented, then the syntax used shall be as defined here. In addition, while it is likely that the ASN.1 definitions provided will be encoded using the Distinguished Encoding Rules (DER), other encoding rules may also be used. The object identifier ansi-X9-63 represents the root of the tree containing all object identifiers defined in this Standard and has the following value: ansi-X9-63 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9Standards(9) x9-63(63) }

As far as possible, the syntax specified in this section follows the syntax specified for elliptic curve cryptographic schemes in ANS X9.62.

H.1

Syntax for Finite Field Identification

This section provides the abstract syntax definitions for the finite fields defined in this Standard. These definitions are used when conveying elliptic curve domain parameters as specified in Section 8.3. A finite field shall be identified by a value of type FieldID{}: FieldID { FIELD-ID:IOSet } ::= SEQUENCE { -- Finite field fieldType FIELD-ID.&id({IOSet}), parameters FIELD-ID.&Type({IOSet}{@fieldType}) } FieldTypes FIELD-ID ::= { { Prime-p IDENTIFIED BY prime-field } | { Characteristic2Set IDENTIFIED BY characteristic-two-field }, … -- Additional field types may be added later -} Characteristic2Set ::= Characteristic-two { {F2mBasisTypes} } FIELD-ID ::= TYPE-IDENTIFIER

© 2017 ASC X9, Inc. – All rights reserved

-- ISO/IEC 8824-2, Annex A 95

ANSI X9.63-2011 (R2017)

is a parameterized type composed of two components, fieldType and parameters. These components are specified by the fields &id and &Type, which form a template for defining sets of information objects, instances of the class FIELD-ID. This class is based on the useful information object class TYPE-IDENTIFIER, described in ISO/IEC 8824-2, Annex A. In an instance of FieldID{}, «fieldType» will contain an object identifier value that uniquely identifies the type contained in «parameters». The effect of referencing «fieldType» in both components of the FieldID{} sequence is to tightly bind the object identifier and its type. FieldID{}

The information object set FieldTypes is used as the single parameter in a reference to type FieldID{} when conveying the identification of a finite field during the operation of the schemes. It contains two objects. Each object, which represents a finite field type, contains a unique object identifier and its associated type. The values of these objects define all of the valid values that may appear in an instance of FieldID{} when it is constrained by FieldTypes (as it is in this Standard). The object identifier id-fieldType represents the root of a tree containing the object identifiers of each field type. It has the following value: id-fieldType OBJECT IDENTIFIER ::= { ansi-X9-62 fieldType(1) }

where: ansi-X9-62 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x9-62(10045) }

The object identifiers prime-field and characteristic-two-field name the two kinds of fields defined in this Standard. They have the following values: prime-field OBJECT IDENTIFIER ::= { id-fieldType 1 } characteristic-two-field OBJECT IDENTIFIER ::= { id-fieldType 2 }

Each of these unique object identifiers is associated with one ASN.1 type, Prime-p and Characteristic-two{}, which specify the precise finite field in use. These types are defined below. When conveying the identification of a finite field Fp, where p is an odd prime, the number p is conveyed as the value of the type Prime-p. Prime-p ::= INTEGER

-- Field size p

When conveying the identification of a finite field F2m, the following syntax is used. Characteristic-two{CHARACTERISTIC-TWO:IOSet} ::= SEQUENCE { m INTEGER, -- Field size 2^m, m prime basis CHARACTERISTIC-TWO.&id({IOSet}), parameters CHARACTERISTIC-TWO.&Type({IOSet}{@basis}) } CHARACTERISTIC-TWO ::= TYPE-IDENTIFIER 96

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) In any instance of type Characteristic-two{}, the value of m specifies the prime degree of the field, the value of basis specifies the type of representation used (ONB,TPB, or PPB), and the value parameters specifies additional information associated with the basis type. The information object set F2mBasisTypes is used as the single parameter in a reference to type Characteristic-two{} when conveying the identification of a characteristic-two finite field during the operation of the schemes. It holds three objects. Each object, which represents a basis type for characteristic-two finite fields, contains a unique OID and its associated type. The values of these objects define all of the valid values that may appear in an instance of Characteristic-two{}. The objects are defined as follows. F2mBasisTypes CHARACTERISTIC-TWO::= { { NULL IDENTIFIED BY gnBasis } | { Trinomial IDENTIFIED BY tpBasis } | { Pentanomial IDENTIFIED BY ppBasis } , … -- Additional basis types may be added later -}

The object identifier id-characteristic-two-basis represents the root of the tree containing the object identifiers for each type of basis for the characteristic-two finite fields. It has the following value: id-characteristic-two-basis OBJECT IDENTIFIER ::= { characteristic-two-field basisType(3) }

The object identifiers gnBasis, tpBasis and ppBasis name the three kinds of basis for characteristic-two finite fields defined in this Standard. They have the following values: gnBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 1 } tpBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 2 } ppBasis OBJECT IDENTIFIER ::= { id-characteristic-two-basis 3 }

Each of these OIDs is associated with one ASN.1 type: NULL, Trinomial, or Pentanomial. The types Trinomial and Pentanomial are defined below. When conveying the use of a Gaussian normal basis, no additional information needs to be conveyed, so the type NULL is used. When conveying the use of a trinomial basis with reduction polynomial xm + xk + 1, the integer k is conveyed as the value of the type Trinomial. Trinomial ::= INTEGER

When conveying the use of a pentanomial basis with reduction polynomial xm+xk1+xk2+xk3+1, the integers k1, k2, and k3 are conveyed as the values k1, k2, and k3 of the type Pentanomial.

© 2017 ASC X9, Inc. – All rights reserved

97

ANSI X9.63-2011 (R2017)

Pentanomial ::= SEQUENCE { k1 INTEGER, k2 INTEGER, k3 INTEGER }

H.2

Syntax for Finite Field Elements and Elliptic Curve Points

This section provides the definitions for finite field elements and elliptic curve points defined in this Standard. These definitions are used when conveying elliptic curve domain parameters as specified in Section 8.3 and when conveying elliptic curve public keys as specified in Section 8.4. A finite field element shall be represented by a value of type FieldElement: FieldElement ::= OCTET STRING

-- Finite field element

The value of FieldElement shall be the octet string representation of the field element following the conversion routine in Section 4.3.3. An elliptic curve point shall be represented by a value of type ECPoint: ECPoint ::= OCTET STRING

-- Elliptic curve point

The value of ECPoint shall be the octet string representation of the elliptic curve point following the conversion routine in Section 4.3.6.

H.3

Syntax for Elliptic Curve Domain Parameters

This section provides the definitions for the elliptic curve domain parameters defined in this Standard. These definitions are used, for example, when conveying the elliptic curve domain parameters associated with an elliptic curve public key within an X.509 certificate as described in Section 8.4. Elliptic curve domain parameters shall be represented by a value of type ECParameters. ECParameters ::= SEQUENCE { version INTEGER { ecpVer1(1) } (ecpVer1), fieldID FieldID {{FieldTypes}}, curve Curve, base ECPoint, order INTEGER, cofactor INTEGER OPTIONAL, ... } 98

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Curve ::= SEQUENCE { a b seed }

FieldElement, FieldElement, BIT STRING OPTIONAL

The components of type ECParameters have the following meanings: -

version

specifies the version number of the elliptic curve domain parameters. It shall have the value 1 for this version of the Standard. The notation above creates an INTEGER named ecpVer1 and gives it a value of one. It is used to constrain version to a single value.

-

identifies the finite field Fq over which the elliptic curve is defined. Finite fields are represented by values of the parameterized type FieldID{}, constrained to the values of the objects defined in the information object set FieldTypes.

-

specifies the coefficients a and b of the elliptic curve E. Each coefficient shall be represented as a value of type FieldElement. The value seed is an optional parameter used to derive the coefficients of a randomly generated elliptic curve.

-

base

-

order specifies

-

is the integer h = #E(Fq)/n. Inclusion of the cofactor is optional – however, it is strongly recommended that the cofactor be included.

H.4

Syntax for Public Keys

fieldID

curve

specifies the base point G on the elliptic curve. The base point shall be represented as a value of type ECPoint. the order n of the base point G.

cofactor

This section provides the syntax for the elliptic curve public keys defined in this Standard. These definitions are used, for example, when conveying an elliptic curve public key (along with the associated elliptic curve domain parameters) within an X.509 certificate. The most common method is found within X.509 certificates, where the public key is specified within the type SubjectPublicKeyInfo, defined as follows. SubjectPublicKeyInfo ::= SEQUENCE { algorithm AlgorithmIdentifier {{ECPKAlgorithms}}, subjectPublicKey BIT STRING }

A reference to parameterized type AlgorithmIdentifier {} tightly binds a set of algorithm object identifiers to their associated parameters types. Type AlgorithmIdentifier {} is defined as: AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { algorithm ALGORITHM.&id({IOSet}), parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL }

© 2017 ASC X9, Inc. – All rights reserved

99

ANSI X9.63-2011 (R2017)

The single parameter ECPKAlgorithms in the reference of type AlgorithmIdentifier{}, the information object set of class ALGORITHM, specifies all of the pairs of valid values of this type. This set contains two objects ecPublicKeyType and ecdsa-SHA1, defined via id-ecPublicKey and ecdsa-with-SHA1, originally defined in ANS X9.62. ECPKAlgorithms ALGORITHM ::= { ecPublicKeyType| ecdsa-SHA1, ... -- Additional algorithms may be added later -} ecPublicKeyType ALGORITHM ::= { OID id-ecPublicKey PARMS Parameters {{ANSICurveNames}} } ecdsa-SHA1 ALGORITHM ::= { OID ecdsa-with-SHA1 PARMS Parameters {{ANSICurveNames}} } ALGORITHM ::= CLASS { &id OBJECT IDENTIFIER UNIQUE , &Type OPTIONAL } WITH SYNTAX { OID &id [PARMS &Type] }

Note that when using the object identifiers ecPublicKeyType and ecdsa-SHA1, the inclusion of the parameters is mandatory. The type subjectPublicKeyInfo is used as follows. «algorithm» indicates the type of public key being conveyed - it includes an identifier for the key type and any associated parameters. The identifier ecPublicKeyType indicates an elliptic curve public key. (Note that this identifier is used for all elliptic curve public keys. The usage of a given key may be delimited by the keyUsage and extendedKeyUsage extensions within X.509 certificates.) id-ecPublicKey OBJECT IDENTIFIER ::= { id-publicKeyType 1 }

where: id-publicKeyType OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) }

The parameters associated with elliptic curve public keys are conveyed via the type Parameters as a choice of three alternatives. This allows a detailed specification of all required values using a choice of ecParameters, the use of a namedCurve as an object identifier substitute for a particular set of elliptic curve domain parameters, or implicitlyCA to indicate that the parameters are explicitly defined elsewhere.

100

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Parameters{CURVES:IOSet} ::= CHOICE { ecParameters ECParameters, namedCurve CURVES.&id({IOSet}), implicitlyCA NULL }

The valid values for the namedCurve choice are constrained to those within the class CURVES. CURVES ::= CLASS { &id } WITH SYNTAX { ID &id }

OBJECT IDENTIFIER UNIQUE

The information object set ANSICurveNames may be used by other standards and by implementations to indicate that the allowed values of CURVES are restricted to the example elliptic curve domain parameters defined in Annexes J.4 and J.5 of this Standard. Each curve object is represented as a unique object identifier value. ANSICurveNames CURVES ::= { { ID ansit163k1 } | -- J.4.1, example 1 -{ ID ansit163r1 } | -- J.4.1, example 2 -{ ID ansit163r2 } | -- J.4.1, example 3 -{ ID ansit193r1 } | -- J.4.2, example 1 -{ ID ansit193r2 } | -- J.4.2, example 2 -{ ID ansit233k1 } | -- J.4.3, example 1 -{ ID ansit233r1 } | -- J.4.3, example 2 -{ ID ansit239k1 } | -- J.4.4, example 1 -{ ID ansit283k1 } | -- J.4.5, example 1 -{ ID ansit283r1 } | -- J.4.5, example 2 -{ ID ansit409k1 } | -- J.4.6, example 1 -{ ID ansit409r1 } | -- J.4.6, example 2 -{ ID ansit571k1 } | -- J.4.7, example 1 -{ ID ansit571r1 } | -- J.4.7, example 2 -{ ID ansip160k1 } | -- J.5.1, example 1 -{ ID ansip160r1 } | -- J.5.1, example 2 -{ ID ansip160r2 } | -- J.5.1, example 3 -{ ID ansip192k1 } | -- J.5.2, example 1 -{ ID ansip192r1 } | -- J.5.2, example 2 -{ ID ansip224k1 } | -- J.5.3, example 1 -{ ID ansip224r1 } | -- J.5.3, example 2 -{ ID ansip256k1 } | -- J.5.4, example 1 -{ ID ansip256r1 } | -- J.5.4, example 2 -{ ID ansip384r1 } | -- J.5.5, example 1 -{ ID ansip521r1 } , -- J.5.6, example 1 -… -- Additional curves may be added later -}

Here, curve identifier names are prefixed by 'ansi' to indicate that they are specified for use in ANSI standards, followed by a single letter to indicate a type of finite field, 't' for characteristic two, or 'p' for prime characteristic. The next three characters are numeric digits that indicate the field size in bits. The final two characters indicate how the curve was selected and the example number. For the curve selection character, an 'r' indicates a curve whose coefficients were selected verifiably at random using a seeded hash. A 'k' indicates a Koblitz curve that facilitates especially efficient implementation. © 2017 ASC X9, Inc. – All rights reserved

101

ANSI X9.63-2011 (R2017)

The object identifier for the example curves are defined as follows. ansit163k1 OBJECT IDENTIFIER ::= { secgCurve 1 } ansit163r1 OBJECT IDENTIFIER ::= { secgCurve 2 } ansit163r2 OBJECT IDENTIFIER ::= { secgCurve 15 } ansit193r1 OBJECT IDENTIFIER ::= { secgCurve 24 } ansit193r2 OBJECT IDENTIFIER ::= { secgCurve 25 } ansit233k1 OBJECT IDENTIFIER ::= { secgCurve 26 } ansit233r1 OBJECT IDENTIFIER ::= { secgCurve 27 } ansit239k1 OBJECT IDENTIFIER ::= { secgCurve 3 } ansit283k1 OBJECT IDENTIFIER ::= { secgCurve 16 } ansit283r1 OBJECT IDENTIFIER ::= { secgCurve 17 } ansit409k1 OBJECT IDENTIFIER ::= { secgCurve 36 } ansit409r1 OBJECT IDENTIFIER ::= { secgCurve 37 } ansit571k1 OBJECT IDENTIFIER ::= { secgCurve 38 } ansit571r1 OBJECT IDENTIFIER ::= { secgCurve 39 } ansip160k1 OBJECT IDENTIFIER ::= { secgCurve 9 } ansip160r1 OBJECT IDENTIFIER ::= { secgCurve 8 } ansip160r2 OBJECT IDENTIFIER ::= { secgCurve 30 } ansip192k1 OBJECT IDENTIFIER ::= { secgCurve 31 } ansip192r1 OBJECT IDENTIFIER ::= { primeCurve 1 } ansip224k1 OBJECT IDENTIFIER ::= { secgCurve 32 } ansip224r1 OBJECT IDENTIFIER ::= { secgCurve 33 } ansip256k1 OBJECT IDENTIFIER ::= { secgCurve 10 } ansip256r1 OBJECT IDENTIFIER ::= { primeCurve 7 } ansip384r1 OBJECT IDENTIFIER ::= { secgCurve 34 } ansip521r1 OBJECT IDENTIFIER ::= { secgCurve 35 }

where: secgCurve OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) }

and: 102

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) primeCurve OBJECT IDENTIFIER ::= { ansi-X9-62 curves(3) prime(1)}

Finally, «subjectPublicKey» contains the actual elliptic curve public key. The public key (a value of type ECPoint, which is an OCTET STRING) is mapped to a subjectPublicKey (a value of type BIT STRING) as follows: the most significant bit of the OCTET STRING value becomes the most significant bit of the BIT STRING value, etc.; the least significant bit of the OCTET STRING becomes the least significant bit of the BIT STRING. Note that when DER-encoding is being used, this means that the raw public key value without prepended DER-encoding tag and length octets is placed in «subjectPublicKey».

H.5

Scheme Syntax

This section provides abstract syntax definitions for the schemes defined in this standard. These definitions are used when identifying the schemes in the messaging associated with the schemes. They may also be used in the extended key usage field of an X.509 certificate containing a static public key associated with the schemes. The schemes are identified by a value of type KeyExchangeSchemeOID, defined as follows. KeyExchangeSchemeOID ::= KEY-EXCHANGE.&id({X963KeyExchangeSchemes})

where the object identifier class KEY-EXCHANGE is defined as: KEY-EXCHANGE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX {ID &id}

Using this syntax, the schemes are identified by an object identifier constrained to lie in the set defined by X963KeyExchangeSchemes.

© 2017 ASC X9, Inc. – All rights reserved

103

ANSI X9.63-2011 (R2017)

X963KeyExchangeSchemes KEY-EXCHANGE ::= { { ID umEphemeral-stdDH-sha1kdf-scheme } | { ID umEphemeral-cofactorDH-sha1kdf-scheme } | { ID dhSinglePass-stdDH-sha1kdf-scheme } | { ID dhSinglePass-cofactorDH-sha1kdf-scheme } | { ID umStatic-stdDH-sha1kdf-scheme } | { ID umStatic-cofactorDH-sha1kdf-scheme } | { ID umSinglePass-stdDH-sha1kdf-scheme } | { ID umSinglePass-cofactorDH-sha1kdf-scheme } | { ID umKeyConfirm-stdDH-sha1kdf-sha1hmac-scheme } | { ID umKeyConfirm-cofactorDH-sha1kdf-sha1hmac-scheme } | { ID umFull-stdDH-sha1kdf-scheme } | { ID umFull-cofactorDH-sha1kdf-scheme } | { ID umFullConfirm-stdDH-sha1kdf-sha1hmac-scheme } | { ID umFullConfirm-cofactorDH-sha1kdf-sha1hmac-scheme } | { ID station-to-station-stdDH-sha1kdf-sha1hmac-ecdsa-scheme } | { ID station-to-station-cofactorDH-sha1kdf-sha1hmac-ecdsa-scheme } | { ID mqvSinglePass-sha1kdf-scheme } | { ID mqvFull-sha1kdf-scheme } | { ID mqvFullConfirm-sha1kdf-sha1hmac-scheme } | { ID onePassTransport-stdDH-sha1kdf-sha1hmac-scheme } | { ID onePassTransport-cofactorDH-sha1kdf-sha1hmac-scheme } | { ID threePassTransport-stdDH-sha1kdf-sha1hmac-ecdsa-scheme } | { ID threePassTransport-cofactorDH-sha1kdf-sha1hmac-ecdsa-scheme } , ... -- Additional key establishment schemes may be added later -}

The remainder of this section specifies the object identifiers for specific schemes. The tree of these object identifiers is represented by the object identifier x9-63-scheme. It has the following value. x9-63-scheme OBJECT IDENTIFIER ::= { ansi-X9-63 schemes(0) }

H.5.1 Ephemeral Unified Model Scheme The Ephemeral Unified Model scheme is defined in Section 6.1. It shall be identified by the object identifier umEphemeral-stdDH-sha1kdf-scheme when used with the standard DiffieHellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. umEphemeral-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 0 }

The Ephemeral Unified Model scheme shall be identified by the object identifier umEphemeralcofactorDH-sha1-scheme when used with the cofactor Diffie Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows.

104

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) umEphemeral-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 1 }

H.5.2 1-Pass Diffie-Hellman Scheme The 1-Pass Diffie-Hellman scheme is defined in Section 6.2. It shall be identified by the object identifier dhSinglePass-stdDH-sha1kdf-scheme when used with the standard Diffie-Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 2 }

The 1-Pass Diffie-Hellman scheme is identified by the object identifier dhSinglePasscofactorDH-sha1kdf-scheme when used with the cofactor Diffie-Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 3 }

H.5.3 Static Unified Model Scheme The Static Unified Model scheme is defined in Section 6.3. It shall be identified by the object identifier umStatic-stdDH-sha1kdf-scheme when used with the standard Diffie-Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. umStatic-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 4 }

The Static Unified Model scheme shall be identified by the object identifier umStaticcofactorDH-sha1kdf-scheme when used with the cofactor Diffie-Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. umStatic-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 5 }

H.5.4 Combined Unified Model with Key Confirmation Scheme The Combined Unified Model with Key Confirmation scheme is defined in Section 6.4. It shall be identified by the object identifier umKeyConfirm-stdDH-sha1kdf-hmac-scheme when used © 2017 ASC X9, Inc. – All rights reserved

105

ANSI X9.63-2011 (R2017)

with the standard Diffie-Hellman primitive and the key derivation function based on SHA-1 and HMAC with SHA-1. This object identifier is defined as follows. umKeyConfirm-stdDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 6 }

The Combined Unified Model with Key Confirmation scheme shall be identified by the object identifier umKeyConfirm-cofactorDH-sha1kdf-hmac-scheme when used with the cofactor DiffieHellman primitive and the key derivation function based on SHA-1 and HMAC with SHA-1. This object identifier is defined as follows. umKeyConfirm-cofactorDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 7 }

H.5.5 1-Pass Unified Model Scheme The 1-Pass Unified Model scheme is defined in Section 6.5. It shall be identified by the object identifier umSinglePass-stdDH-sha1kdf-scheme when used with the standard Diffie-Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. umSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 8 }

The 1-Pass Unified Model scheme shall be identified by the object identifier umSinglePasscofactorDH-sha1kdf-scheme when used with the cofactor Diffie-Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. umSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 9 }

H.5.6 Full Unified Model Scheme The Full Unified Model scheme is defined in Section 6.6. It shall be identified by the object identifier umFull-stdDH-sha1kdf-scheme when used with the standard Diffie-Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. umFull-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 10 }

106

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) The Full Unified Model scheme shall be identified by the object identifier umFull-cofactorDHsha1kdf-scheme when used with the cofactor Diffie-Hellman primitive and the key derivation function based on SHA-1. This object identifier is defined as follows. umFull-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 11 }

H.5.7 Full Unified Model with Key Confirmation Scheme The Full Unified Model with Key Confirmation scheme is defined in Section 6.7. It shall be identified by the object identifier umFullConfirm-stdDH-sha1kdf-sha1hmac-scheme when used with the standard Diffie-Hellman primitive and the key derivation function based on SHA-1 and HMAC with SHA-1. This object identifier is defined as follows. umFullConfirm-stdDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 12 }

The Full Unified Model with Key Confirmation scheme shall be identified by the object identifier umFullConfirm-cofactorDH-sha1kdf-sha1hmac-scheme when used with the cofactor Diffie-Hellman primitive and the key derivation function based on SHA-1 and HMAC with SHA-1. This object identifier is defined as follows. umFullConfirm-cofactorDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 13 }

H.5.8 Station-to-Station Scheme The Station-to-Station scheme is defined in Section 6.8. It shall be identified by the object identifier station-to-station-stdDH-sha1kdf-sha1hmac-ecdsa-scheme when used with the standard Diffie-Hellman primitive, the key derivation function based on SHA-1, HMAC with SHA-1, and ECDSA. This object identifier is defined as follows. station-to-station-stdDH-sha1kdf-sha1hmac-ecdsa-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 14 }

The Station-to-Station scheme shall be identified by the object identifier station-to-stationcofactorDH-sha1kdf-sha1hmac-ecdsa-scheme when used with the cofactor Diffie-Hellman primitive, the key derivation function based on SHA-1, HMAC with SHA-1, and ECDSA. This object identifier is defined as follows. station-to-station-cofactorDH-sha1kdf-sha1hmac-ecdsa-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 15 }

© 2017 ASC X9, Inc. – All rights reserved

107

ANSI X9.63-2011 (R2017)

H.5.9 1-Pass MQV Scheme The 1-Pass MQV scheme is defined in Section 6.9. It shall be identified by the object identifier mqvSinglePass-sha1kdf-scheme when used with the key derivation function based on SHA-1. It is identified as follows. mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 16 }

H.5.10 Full MQV Scheme The Full MQV scheme defined in Section 6.10 shall be identified by the object identifier mqvFull-sha1kdf-scheme when used with the key derivation function based on SHA-1. It is defined as follows. mqvFull-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 17 }

H.5.11 Full MQV with Key Confirmation Scheme The Full MQV with Key Confirmation scheme defined in Section 6.11 shall be identified by the object identifier mqvFullConfirm-sha1kdf-sha1hmac-scheme when used with the key derivation function based on SHA-1, and HMAC with SHA-1. It is defined as follows. mqvFullConfirm-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 18 }

H.5.12 1-Pass Key Transport Scheme The 1-Pass Key Transport scheme is defined in Section 7.1. It shall be identified by the object identifier onePassTransport-stdDH-sha1kdf-sha1hmac-scheme when using the standard DiffieHellman primitive, the key derivation function based on SHA-1, and HMAC with SHA-1, and by the object identifier onePassTransport-cofactorDH-sha1kdf-sha1hmac-scheme when using the cofactor Diffie-Hellman primitive, the key derivation function based on SHA-1, and HMAC with SHA-1. They are defined as follows. onePassTransport-stdDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 19 } 108

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) onePassTransport-cofactorDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 20 }

H.5.13 3-Pass Key Transport Scheme The 3-Pass Key Transport scheme is defined in Section 7.2. It shall be identified by the object identifier threePassTransport-stdDH-sha1kdf-sha1hmac-ecdsa-scheme when using the standard Diffie-Hellman primitive, the key derivation function based on SHA-1, HMAC with SHA-1, and ECDSA, and by the object identifier threePassTransport-cofactorDH-sha1kdf-sha1hmac-ecdsascheme when using the cofactor Diffie-Hellman primitive, the key derivation function based on SHA-1, HMAC with SHA-1, and ECDSA. These are defined as follows. threePassTransport-stdDH-sha1kdf-sha1hmac-ecdsa-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 21 } threePassTransport-cofactorDH-sha1kdf-sha1hmac-ecdsa-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 22 }

H.6

Key Derivation Syntax

This section provides ASN.1 syntax that should be used to encode input to the old key derivation function specified in Section 5.6.3. Note that the use of ASN.1 syntax for this purpose is optional – however, the use of ASN.1 syntax in this scenario can help to ensure that the encoding of information fields is unambiguous. The input to the key derivation function includes a bit string SharedInfo. SharedInfo may contain a value of type X963SharedInfo as defined below. In this event, the octet string value of X963SharedInfo shall be mapped to the bit string SharedInfo by taking the leftmost bit of the leftmost octet of the value of X963SharedInfo as the leftmost bit of SharedInfo and so on. X963SharedInfo ::= SEQUENCE { keyInfo AlgorithmIdentifier{{ANSISymmetricAlgorithms}}, entityUInfo [0] OCTET STRING OPTIONAL, entityVInfo [1] OCTET STRING OPTIONAL, suppPubInfo [2] OCTET STRING OPTIONAL, suppPrivInfo [3] OCTET STRING OPTIONAL }

The components of type X963SharedInfo have the following meanings. -

keyInfo specifies the symmetric algorithm(s) for which the derived key(s) are to be used. It is constrained by ANSISymmetricAlgorithms, described below.

© 2017 ASC X9, Inc. – All rights reserved

109

ANSI X9.63-2011 (R2017)

-

entityUInfo, if present, specifies additional information about the scheme's initiator, such as the entity's X.501 distinguished name, the entity's public key, et cetera.

-

entityVInfo,

-

suppPubInfo, if present, specifies additional public information known to both entities involved in the operation of the scheme.

-

suppPrivInfo,

if present, specifies additional information about the scheme's responder, such as the entity's X.501 distinguished name, the entity's public key, et cetera.

if present, specifies additional private information known to both entities involved in the operation of the scheme.

ANSISymmetricAlgorithms

follows.

delimits the set of values that may appear in keyInfo. It is specified as

ANSISymmetricAlgorithms ALGORITHM ::= { tripleDESalgo | sha1HMACalgo, ... -- Additional symmetric algorithms may be added later -}

The type tripleDESalgo indicates that the derived key(s) will be used by the Triple DES algorithm. TripleDESkeys ::= INTEGER { oneKey (1), twoKeys (2), threeKeys (3) } ( oneKey | twoKeys | threeKeys ) tripleDESalgo ALGORITHM ::= { OID tripleDES PARMS TripleDESkeys } tripleDES OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) algorithms(1) triple-des(2) }

The type hMAC-SHA1 indicates that the derived key(s) will be used by the HMAC algorithm with SHA-1. sha1HMACalgo ALGORITHM ::= { OID sha1HMAC PARMS INTEGER } sha1HMAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 8 1 2 }

(The INTEGER parameter indicates the size of the HMAC key being used 160 indicates that 160-bit HMAC keys are being derived.) 110

- for example, the value

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

H.7

ASN.1 Module

The following ASN.1 module contains all the syntax defined in this Standard. ANSI-X9-63 { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9Standards(9) x9-63(63) module(1) 1 } DEFINITIONS EXPLICIT TAGS ::= BEGIN --- ANS X9.63 Key Agreement and Key Transport using ECC. --- EXPORTS All; ---- Import the required types. -IMPORTS --- The following are imported from ANS X9.62-1998 -CURVES, ECParameters, id-ecPublicKey, id-publicKeyType, primeCurve FROM ANSI-X9-62; --- ANS X9.63 arc: -ansi-X9-63 OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) tc68(133) country(16) x9(840) x9Standards(9) x9-63(63) }

--- Key-exchange Scheme -KeyExchangeSchemeOID ::= KEY-EXCHANGE.&id({X963KeyExchangeSchemes}) KEY-EXCHANGE ::= CLASS { &id OBJECT IDENTIFIER UNIQUE } WITH SYNTAX {ID &id} --- Key-agreement scheme OIDs: -x9-63-scheme OBJECT IDENTIFIER ::= { ansi-X9-63 schemes(0) }

© 2017 ASC X9, Inc. – All rights reserved

111

ANSI X9.63-2011 (R2017)

umEphemeral-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 0 } umEphemeral-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 1 } dhSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 2 } dhSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 3 } umStatic-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 4 } umStatic-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 5 } umKeyConfirm-stdDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 6 } umKeyConfirm-cofactorDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 7 } umSinglePass-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 8 } umSinglePass-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 9 } umFull-stdDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 10 } umFull-cofactorDH-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 11 } umFullConfirm-stdDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 12 } umFullConfirm-cofactorDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 13 }

112

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) station-to-station-stdDH-sha1kdf-sha1hmac-ecdsa-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 14 } station-to-station-cofactorDH-sha1kdf-sha1hmac-ecdsa-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 15 } mqvSinglePass-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 16 } mqvFull-sha1kdf-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 17 } mqvFullConfirm-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 18 } onePassTransport-stdDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 19 } onePassTransport-cofactorDH-sha1kdf-sha1hmac-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 20 } threePassTransport-stdDH-sha1kdf-sha1hmac-ecdsa-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 21 } threePassTransport-cofactorDH-sha1kdf-sha1hmac-ecdsa-scheme OBJECT IDENTIFIER ::= { x9-63-scheme 22 }

--- Scheme Identification --

© 2017 ASC X9, Inc. – All rights reserved

113

ANSI X9.63-2011 (R2017)

X963KeyExchangeSchemes KEY-EXCHANGE ::= { { ID umEphemeral-stdDH-sha1kdf-scheme } | { ID umEphemeral-cofactorDH-sha1kdf-scheme } | { ID dhSinglePass-stdDH-sha1kdf-scheme } | { ID dhSinglePass-cofactorDH-sha1kdf-scheme } | { ID umStatic-stdDH-sha1kdf-scheme } | { ID umStatic-cofactorDH-sha1kdf-scheme } | { ID umSinglePass-stdDH-sha1kdf-scheme } | { ID umSinglePass-cofactorDH-sha1kdf-scheme } | { ID umKeyConfirm-stdDH-sha1kdf-sha1hmac-scheme } | { ID umKeyConfirm-cofactorDH-sha1kdf-sha1hmac-scheme } | { ID umFull-stdDH-sha1kdf-scheme } | { ID umFull-cofactorDH-sha1kdf-scheme } | { ID umFullConfirm-stdDH-sha1kdf-sha1hmac-scheme } | { ID umFullConfirm-cofactorDH-sha1kdf-sha1hmac-scheme } | { ID station-to-station-stdDH-sha1kdf-sha1hmac-ecdsa-scheme } | { ID station-to-station-cofactorDH-sha1kdf-sha1hmac-ecdsa-scheme } | { ID mqvSinglePass-sha1kdf-scheme } | { ID mqvFull-sha1kdf-scheme } | { ID mqvFullConfirm-sha1kdf-sha1hmac-scheme } | { ID onePassTransport-stdDH-sha1kdf-sha1hmac-scheme } | { ID onePassTransport-cofactorDH-sha1kdf-sha1hmac-scheme } | { ID threePassTransport-stdDH-sha1kdf-sha1hmac-ecdsa-scheme } | { ID threePassTransport-cofactorDH-sha1kdf-sha1hmac-ecdsa-scheme } , ... } --- Shared information: -X963SharedInfo ::= SEQUENCE { keyInfo AlgorithmIdentifier{{ANSISymmetricAlgorithms}}, entityUInfo [0] OCTET STRING OPTIONAL, entityVInfo [1] OCTET STRING OPTIONAL, suppPubInfo [2] OCTET STRING OPTIONAL, suppPrivInfo [3] OCTET STRING OPTIONAL } --- Symmetric algorithms: -ANSISymmetricAlgorithms ALGORITHM ::= { tripleDESalgo | sha1HMACalgo, ... } tripleDESalgo ALGORITHM ::= { OID tripleDES PARMS TripleDESkeys }

114

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) tripleDES OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) ansi-x942(10046) algorithms(1) triple-des(2) } TripleDESkeys ::= INTEGER { oneKey (1), twoKeys (2), threeKeys (3) } ( oneKey | twoKeys | threeKeys )

sha1HMACalgo ALGORITHM ::= { OID sha1HMAC PARMS INTEGER } sha1HMAC OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) 8 1 2 } --- Asymmetric algorithms -ECPKAlgorithms ALGORITHM ::= { ecPublicKeyType| ecdsa-SHA1, ... -- Additional algorithms may be added later -} ecPublicKeyType ALGORITHM ::= { OID id-ecPublicKey PARMS Parameters {{ANSICurveNames}} } ecdsa-SHA1 ALGORITHM ::= { OID ecdsa-with-SHA1 PARMS Parameters {{ANSICurveNames}} } ecdsa-with-SHA1 OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 10045 signatures(4) } --- ECDSA is defined in ANS X9.62 -- ecdsa-with-SHA1 was originally defined in ANS X9.62 -ALGORITHM ::= CLASS { &id OBJECT IDENTIFIER UNIQUE , &Type OPTIONAL } WITH SYNTAX { OID &id [PARMS &Type] } AlgorithmIdentifier { ALGORITHM:IOSet } ::= SEQUENCE { algorithm ALGORITHM.&id({IOSet}), parameters ALGORITHM.&Type({IOSet}{@algorithm}) OPTIONAL }

© 2017 ASC X9, Inc. – All rights reserved

115

ANSI X9.63-2011 (R2017)

Parameters{CURVES:IOSet} ::= CHOICE { ecParameters ECParameters, namedCurve CURVES.&id({IOSet}), implicitlyCA NULL } ANSICurveNames CURVES ::= { { ID ansit163k1 } | { ID ansit163r1 } | { ID ansit163r2 } | { ID ansit193r1 } | { ID ansit193r2 } | { ID ansit233k1 } | { ID ansit233r1 } | { ID ansit239k1 } | { ID ansit283k1 } | { ID ansit283r1 } | { ID ansit409k1 } | { ID ansit409r1 } | { ID ansit571k1 } | { ID ansit571r1 } | { ID ansip160k1 } | { ID ansip160r1 } | { ID ansip160r2 } | { ID ansip192k1 } | { ID ansip192r1 } | { ID ansip224k1 } | { ID ansip224r1 } | { ID ansip256k1 } | { ID ansip256r1 } | { ID ansip384r1 } | { ID ansip521r1 } , … } ansit163k1 OBJECT IDENTIFIER ::= { secgCurve 1 } ansit163r1 OBJECT IDENTIFIER ::= { secgCurve 2 } ansit163r2 OBJECT IDENTIFIER ::= { secgCurve 15 } ansit193r1 OBJECT IDENTIFIER ::= { secgCurve 24 } ansit193r2 OBJECT IDENTIFIER ::= { secgCurve 25 } ansit233k1 OBJECT IDENTIFIER ::= { secgCurve 26 } ansit233r1 OBJECT IDENTIFIER ::= { secgCurve 27 } ansit239k1 OBJECT IDENTIFIER ::= { secgCurve 3 } ansit283k1 OBJECT IDENTIFIER ::= { secgCurve 16 } ansit283r1 OBJECT IDENTIFIER ::= { secgCurve 17 } ansit409k1 OBJECT IDENTIFIER ::= { secgCurve 36 } 116

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) ansit409r1 OBJECT IDENTIFIER ::= { secgCurve 37 } ansit571k1 OBJECT IDENTIFIER ::= { secgCurve 38 } ansit571r1 OBJECT IDENTIFIER ::= { secgCurve 39 } ansip160k1 OBJECT IDENTIFIER ::= { secgCurve 9 } ansip160r1 OBJECT IDENTIFIER ::= { secgCurve 8 } ansip160r2 OBJECT IDENTIFIER ::= { secgCurve 30 } ansip192k1 OBJECT IDENTIFIER ::= { secgCurve 31 } ansip192r1 OBJECT IDENTIFIER ::= { primeCurve 1 } ansip224k1 OBJECT IDENTIFIER ::= { secgCurve 32 } ansip224r1 OBJECT IDENTIFIER ::= { secgCurve 33 } ansip256k1 OBJECT IDENTIFIER ::= { secgCurve 10 } ansip256r1 OBJECT IDENTIFIER ::= { primeCurve 7 } ansip384r1 OBJECT IDENTIFIER ::= { secgCurve 34 } ansip521r1 OBJECT IDENTIFIER ::= { secgCurve 35 } secgCurve OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) certicom(132) curve(0) } END -- ANSI-X9-63

© 2017 ASC X9, Inc. – All rights reserved

117

ANSI X9.63-2011 (R2017)

Annex I (normative) Legacy Schemes I.1

Overview

The previous edition of this Standard included key establishment schemes with key confirmation included in the key establishement scheme. The key confirmation in these schemes is incompatible with the key confirmation in NIST Special Publication 800-56A. These schemes should not be used except for backwards compatibility with existing implementations of this Standard. These schemes are included in this Annex. The previous edition of this Standard included key transport schemes. The key transport schemes are not compatible with the key transport scheme in NIST Special Publication 800-56A. These schemes should not be used except for backwards compatibility with existing implementations of this Standard. These are included in this Annex.

I.2

Legacy Key Agreement Schemes

I.2.1

Combined Unified Model with Key Confirmation

This key agreement scheme should not be used except for for backwards compatibility with existing implementations of the previous edition of this Standard. This section specifies the combined Unified Model with key confirmation scheme. The scheme is a hybrid of the ephemeral Unified Model scheme and the static Unified Model scheme in which a MAC is used to provide key confirmation.

118

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Qs,U

Qs,V

Qe,U

U

V

Qe,V, MACMacKey(0216 || V || U || QEV || QEU)

MACMacKey(0316 || U || V || QEU || QEV) Zs = x([h]ds,UQs,V) MacKey = kdf(Zs) Ze = x([h]de,UQe,V) KeyData = kdf(Ze)

Zs = x([h]ds,VQs,U) MacKey = kdf(Zs) Ze = x([h]de,VQe,U) KeyData = kdf(Ze)

Figure I-1 – Combined Unified Model with Key Confirmation Scheme Figure I-1 illustrates the flows of information involved in the use of the combined Unified Model with key confirmation scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Annex I.2.1.1 to agree on keying data with V if U is the scheme’s initiator, and V uses the transformation specified in Annex I.2.1.2 to agree on keying data with U if V is the scheme’s responder. The essential difference between the role of the initiator and the role of the responder is merely that the initiator sends the first pass of the exchange. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set De = (qe, FRe, ae, be, ECCSEEDe, Ge, ne, he) to be used with ephemeral keys. These parameters shall have been generated using the parameter generation primitives in

© 2017 ASC X9, Inc. – All rights reserved

119

ANSI X9.63-2011 (R2017)

Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. 2.

U has an authentic copy of the system’s elliptic curve domain parameter set Ds = (qs, FRs, as, bs, ECCSEEDs, Gs, ns, hs) to be used with static keys. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. It is permitted for De = Ds.

3.

The entities shall have established whether to use the standard Diffie-Hellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2. Each entity shall also have established whether to use the standard public key validation primitive specified in Section 5.2.2.1 or the embedded public key validation primitive specified in Section 5.2.2.2 to validate ephemeral public keys. (If the standard Diffie-Hellman primitive is used by the scheme, then the standard public key validation primitive shall be used by each entity to validate the other entity's ephemeral public key.)

4.

Each entity shall be bound to a static key pair associated with the system’s elliptic curve domain parameters Ds to be used with static keys. The binding process shall include the validation of the static public key as specified in Section 5.2.2. If the standard DiffieHellman primitive is used by the scheme, then the standard public key validation primitive specified in Section 5.2.2.1 shall be used to to validate each entity's static public key.

5.

Each entity shall have established an Approved MAC scheme as specified in Section 5.7. mackeylen is used to denote the length of the keys used by the MAC scheme chosen.

6.

The entities shall have established an Approved key derivation function as specified in Section 5.6.3.

7.

Each entity shall have decided how to represent elliptic curve points as octet strings (i.e., compressed form, uncompressed form, or hybrid form).

I.2.1.1 Initiator Transformation U shall execute the following transformation to agree on keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s identifier and V’s static public key Qs,V. Input: The input to the initiator transformation is: 1.

An integer keydatalen that is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData1 of length shareddata1len bits and a bit string SharedData2 of length shareddata2len bits that consist of some data shared by U and V.

120

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Ingredients: The initiator transformation employs the key pair generation primitive in Section 5.2.1, a public key validation method in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), an Approved key derivation function as specified in Section 5.6.3, and an Approved MAC scheme as specified in Section 5.7. Actions: Keying data shall be derived as follows: 1.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameter set De. Send Qe,U to V.

2.

Receive an ephemeral public key Qe,V from V that is purportedly owned by V, an optional bit string Text1, and a purported tag MacTag1. If these values are not received, output ‘invalid’ and stop.

3.

Verify that Qe,V is a valid key for the parameter set De as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

4.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zsFq from the private key ds,U, the public key Qs,V, and the parameter set Ds. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

5.

Convert zs to a bit string Zs using the convention specified in Section 4.3.3.

6.

Use the established key derivation function to derive keying data MacKey of length mackeylen bits from the shared secret value Zs and the shared data [SharedData1].

7.

Convert Qe,U and Qe,V to octet strings QEU and QEV using the convention in Section 4.3.6. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV, the bit string QEU, and (if present) Text1: MacData1 = 0216 || V || U || QEV || QEU || [Text1].

8.

9.

Verify that MacTag1 is the tag for MacData1 under the key MacKey using the tag checking transformation of the established MAC scheme. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop. Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU corresponding to U’s ephemeral public key, the bit string QEV corresponding to V’s purported ephemeral public key, and optionally a bit string Text2: MacData2 = 0316 || U || V || QEU || QEV || [Text2].

10.

Calculate the tag MacTag2 on MacData2 under the key MacKey using the tagging transformation of the established MAC scheme: MacTag2 = MACMacKey(MacData2).

© 2017 ASC X9, Inc. – All rights reserved

121

ANSI X9.63-2011 (R2017)

If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send MacTag2 and if present Text2 to V. 11.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zeFq from the private key de,U, the purported public key Qe,V, and the parameter set De. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

12.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

13.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Ze and the shared data [SharedData2].

Output: The bit string KeyData as the keying data of length keydatalen bits.

I.2.1.2 Responder Transformation V shall execute the following transformation to agree on keying data with U if V is the scheme’s responder. V shall obtain an authentic copy of U’s identifier and U’s static public key Qs,U. Input: The input to the responder transformation is: 1.

An ephemeral public key Qe,U purportedly owned by U.

2.

An integer keydatalen that is the length in bits of the keying data to be generated.

3.

(Optional) A bit string SharedData1 of length shareddata1len bits and a bit string SharedData2 of length shareddata2len bits that consist of some data shared by U and V.

Ingredients: The responder transformation employs the key pair generation primitive in Section 5.2.1, a public key validation method in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), an Approved key derivation function as specified in Section 5.6.3, and an Approved MAC scheme as specified in Section 5.7. Actions: Keying data shall be derived as follows: 1.

Receive an ephemeral public key Qe,U from U that is purportedly owned by U , and verify that Qe,U is a valid key for the parameter set De as specified in Section 5.2.2. If the primitive rejects the key, output ‘invalid’ and stop.

2.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,V,Qe,V) for the parameter set De.

122

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 3.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zsFq from the private key ds,V, the public key Qs,U, and the parameter set Ds. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

4.

Convert zs to a bit string Zs using the convention specified in Section 4.3.3.

5.

Use the established key derivation function to derive keying data MacKey of length mackeylen bits from the shared secret value Zs and the shared data [SharedData1].

6.

Convert Qe,U and Qe,V to octet strings QEU and QEV using the convention in Section 4.3.6. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV corresponding to V’s ephemeral public key, the bit string QEU corresponding to U’s purported ephemeral public key, and optionally a bit string Text1: MacData1 = 0216 || V || U || QEV || QEU || [Text1].

7.

Calculate the tag MacTag1 for MacData1 under the key MacKey using the tagging transformation of the established MAC scheme. MacTag1 = MACMacKey(MacData1). If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send the ephemeral public key Qe,V, bit string Text1 (if present), and MacTag1 to U.

8. 9.

Then receive from U an optional bit string Text2 and a purported tag MacTag2. If this data is not received, output ‘invalid’ and stop.

Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU, the bit string QEV, and the bit string Text2 (if present): MacData2 = 0316 || U || V || QEU || QEV || [Text2].

10.

Verify that MacTag2 is the valid tag on MacData2 under the key MacKey using the tag checking transformation of the established MAC scheme. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop.

11.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zeFq from the private key de,V, the purported public key Qe,U, and the parameter set De. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

12.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

13.

Use the established key derivation function to derive keying data KeyData of length keydatalen bits from the shared secret value Ze and the shared data [SharedData2].

Output: The bit string KeyData as the keying data of length keydatalen bits.

© 2017 ASC X9, Inc. – All rights reserved

123

ANSI X9.63-2011 (R2017)

Qs,U

Qs,V

Qe,U

U

V

Qe,V, MACMacKey(0216 || V || U || QEV || QEU)

MACMacKey(0316 || U || V || QEU || QEV) Ze = x([h]de,UQe,V)

Ze = x([h]de,VQe,U)

Zs = x([h]ds,UQs,V)

Zs = x([h]ds,VQs,U)

MacKey || KeyData = kdf(Ze || Zs)

MacKey || KeyData = kdf(Ze || Zs)

Figure I-2 – Full Unified Model with Key Confirmation Scheme NOTE: The Combined Unified Model with Key Confirmation scheme only provides implicit key confirmation. Each party only gets the assurance that the other party can compute Ze, and not the assurance that the other party actually has computed Ze.

I.2.2

Full Unified Model with Key Confirmation Scheme

This key agreement scheme should not be used except for backwards compatibility with existing implementation of the previous version of this Standard. This section specifies the full Unified Model with key confirmation scheme. The scheme adds flows to the full Unified Model scheme so that explicit key authentication may be supplied. A MAC scheme is used to provide key confirmation. Figure I-2 illustrates the information flows involved in the use of the full Unified Model with key confirmation scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Section I.2.2.1 to agree on keying data with V if U is the scheme’s initiator, and V 124

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) uses the transformation specified in Section I.2.2.2 to agree keying data with U if V is the scheme’s responder. The essential difference between the role of the initiator and the role of the responder is merely that the initiator sends the first pass of the exchange. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set De = (qe, FRe, ae, be, ECCSEEDe, Ge, ne, he) to be used with ephemeral keys. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

2.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set Ds = (qs, FRs, as, bs, ECCSEEDs, Gs, ns, hs) to be used with static keys. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. The domain parameter set for static keys Ds and ephemeral De shall be the same, except for backwards compatibility with existing implementations of the previous edition of this Standard.

3.

The entities shall have established whether to use the standard Diffie-Hellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2. Each entity shall also have established whether to use the standard public key validation primitive specified in Section 5.2.2.1 or the embedded public key validation primitive specified in Section 5.2.2.2 to validate ephemeral public keys. If the standard Diffie-Hellman primitive is used by the scheme, then the standard public key validation primitive shall be used by each entity to validate the other entity's ephemeral public key.

4.

Each entity shall be bound to a static key pair associated with the system’s elliptic curve domain parameter set Ds to be used with static keys. The binding process shall include the validation of the static public key as specified in Section 5.2.2. If the standard DiffieHellman primitive is used by the scheme, then the standard public key validation primitive specified in Section 5.2.2.1 shall be used to to validate each entity's static public key.

5.

Each entity shall have established an Approved MAC scheme as specified in Section 5.7. mackeylen will denote the length of the keys used by the chosen MAC scheme.

6.

The entities shall have established an Approved key derivation function as specified in Section 5.6.3.

7.

Each entity shall have decided how to represent elliptic curve points as octet strings (i.e., compressed form, uncompressed form, and hybrid form).

© 2017 ASC X9, Inc. – All rights reserved

125

ANSI X9.63-2011 (R2017)

I.2.2.1 Initiator Transformation U shall execute the following transformation to agree on keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s identifier and V’s static public key Qs,V. Input: The input to the initiator transformation is: 1.

An integer keydatalen that is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The initiator transformation employs the key pair generation primitive in Section 5.2.1, the public key validation in Section 5.2.2, the Diffie-Hellman primitive in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), an Approved key derivation function as specified Section 5.6.3, and an Approved MAC scheme as specified in Section 5.7. Actions: Keying data shall be derived as follows: 1.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameter set De. Send Qe,U to V.

2.

Then receive an ephemeral public key Qe,V from V that is purportedly owned by V, an optional bit string Text1, and a purported tag MacTag1. If these values are not received, output ‘invalid’ and stop.

3.

Verify that Qe,V is a valid key for the parameter set De as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

4.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zeFq from the private key de,U, the purported public key Qe,V, and the parameter set De. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

5.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

6.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zsFq from the private key ds,U, the public key Qs,V, and the parameter set Ds. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

7.

Convert zs to a bit string Zs using the convention specified in Section 4.3.3.

8.

Form the shared secret bit string Z as Z = Ze||Zs.

9.

Use the established key derivation function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret value Z and the shared data [SharedData].

126

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 10.

Parse the leftmost macdatalen bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.

11.

Convert Qe,U and Qe,V to octet strings QEU and QEV using the convention in Section 4.3.6. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV, the bit string QEU, and Text1 (if present): MacData1 = 0216 || V || U || QEV || QEU || [Text1].

12.

13.

Verify that MacTag1 is the tag for MacData1 under the key MacKey using the tag checking transformation of the established MAC scheme. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop. Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU corresponding to U’s ephemeral public key, the bit string QEV corresponding to V’s purported ephemeral public key, and optionally a bit string Text2: MacData2 = 0316 || U || V || QEU || QEV || [Text2].

14.

Calculate the tag MacTag2 on MacData2 under the key MacKey using the tagging transformation of the established MAC scheme: MacTag2 = MACMacKey(MacData2). If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send MacTag2 and if present Text2 to V.

Output: The bit string KeyData as the keying data of length keydatalen bits. I.2.2.2 Responder Transformation V shall execute the following transformation to agree on keying data with U if V is the scheme’s responder. V shall obtain an authentic copy of U’s identifier and U’s static public key Qs,U. Input: The input to the responder transformation is: 1.

An ephemeral public key Qe,U purportedly owned by U.

2.

An integer keydatalen that is the length in bits of the keying data to be generated.

3.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The responder transformation employs the key pair generation primitive in Section 5.2.1, a public key validation method in Section 5.2.2, one of the Diffie-Hellman primitives in Section 5.4 (if the standard Diffie-Hellman primitive is used, then the standard public key validation method must be used), an Approved key derivation © 2017 ASC X9, Inc. – All rights reserved

127

ANSI X9.63-2011 (R2017)

function as specified in Section 5.6.3, and an Approved MAC scheme as specified in Section 5.7. Actions: Keying data shall be derived as follows: 1.

Receive an ephemeral public key Qe,U from U that is purportedly owned by U , and verify that Qe,U is a valid key for the parameter set De as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

2.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,V,Qe,V) for the parameter set De.

3.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zeFq from the private key de,V, the purported public key Qe,U, and the parameter set De. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

4.

Convert ze to a bit string Ze using the convention specified in Section 4.3.3.

5.

Use the established Diffie-Hellman primitive in Section 5.4 to derive a shared secret value zsFq from the private key ds,V, the public key Qs,U, and the parameter set Ds. If the primitive outputs ‘invalid’, output ‘invalid’ and stop.

6.

Convert zs to a bit string Zs using the convention specified in Section 4.3.3.

7.

Form the shared secret bit string Z as Z = Ze||Zs.

8.

Use the established key derivation function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret value Z and the shared data [SharedData].

9.

Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.

10.

Convert Qe,U and Qe,V to octet strings QEU and QEV using the convention in Section 4.3.6. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV, the bit string QEU, and optionally a bit string Text1: MacData1 = 0216 || V || U || QEV || QEU || [Text1].

11.

Calculate the tag MacTag1 for MacData1 under the key MacKey using the tagging transformation of the established MAC scheme. MacTag1 = MACMacKey(MacData1). If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send the ephemeral public key Qe,V, the bit string Text1 (if present), and MacTag1 to U.

128

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 12. 13.

Then receive an optional bit string Text2 and a purported tag MacTag2 from U. If this data is not received, output ‘invalid’ and stop. Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU corresponding to U’s purported ephemeral public key, the bit string QEV corresponding to V’s ephemeral public key, and if present the bit string Text2: MacData2 = 0316 || U || V || QEU || QEV || [Text2].

14.

Verify that MacTag2 is the valid tag on MacData2 under the key MacKey using the tag checking transformation of the established MAC scheme. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop.

Output: The bit string KeyData as the keying data of length keydatalen bits.

I.2.3

Full MQV with Key Confirmation Scheme

This section specifies the full MQV with key confirmation scheme. The scheme adds information flows to the full MQV scheme so that explicit key authentication may be supplied. A MAC scheme is used to provide key confirmation. This key agreement scheme should not be used except for backwards compatability with existing implementations of the previous edition of this Standard.

© 2017 ASC X9, Inc. – All rights reserved

129

ANSI X9.63-2011 (R2017)

Qs,U

Qs,V

Qe,U

U

V

Qe,V, MACMacKey(0216 || V || U || QEV || QEU)

MACMacKey(0316 || U || V || QEU || QEV) implicitsigU = de,U + avf(Qe,U) ds,U R = h (implicitsigU ( Qe,V + avf(Qe,V) Qs,V )) Z = xR MacKey || KeyData = kdf(Z)

implicitsigV = de,V + avf(Qe,V) ds,V R = h (implicitsigV ( Qe,U + avf(Qe,U) Qs,U )) Z = xR MacKey || KeyData = kdf(Z)

Figure I-3 – Full MQV with Key Confirmation Scheme Figure I-3 illustrates the information flows involved in the use of the full MQV with key confirmation scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Annex I.2.3.1 to agree on keying data with V if U is the scheme’s initiator, and V uses the transformation specified in Annex I.2.3.2 to agree on keying data with U if V is the scheme’s responder. The essential difference between the role of the initiator and the role of the responder is merely that the initiator sends the first pass of the exchange. Prerequisites: The following are the prerequisites for the use of the scheme: 1. 130

Each entity has an authentic copy of the system’s elliptic curve domain parameter set D = (q, FR, a, b, ECCSEED, G, n, h). These parameters shall have been generated using the © 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. 2.

Each entity shall be bound to a static key pair associated with the system’s elliptic curve domain parameter set D. The binding process shall include the validation of the static public key as specified in Section 5.2.2.

3.

Each entity shall have establihsed an Approved MAC scheme as specified in Section 5.7. mackeylen denotes the length of keys used by the chosen MAC scheme.

4.

The entities shall have established an Approved key derivation function.

5.

Each entity shall have decided how to represent elliptic curve points as octet strings (i.e., compressed form, uncompressed form, or hybrid form).

I.2.3.1 Initiator Transformation U shall execute the following transformation to agree on keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s identifier and V’s static public key Qs,V. Input: The input to the initiator transformation is: 1.

An integer keydatalen that is the length in bits of the keying data to be generated.

2.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The initiator transformation employs the key pair generation primitive in Section 5.2.1, a public key validation method in Section 5.2.2, the MQV primitive in Section 5.5, the associate value function in Section 5.6.1, an Approved key derivation function as specified in Section 5.6.3, and an Approved MAC scheme as specified in Section 5.7. Actions: Keying data shall be derived as follows: 1.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,U,Qe,U) for the parameter set D. Send Qe,U to V.

2.

Then receive from V an ephemeral public key Qe,V purportedly owned by V, an optional bit string Text1, and a purported tag MacTag1. If these values are not received, output ‘invalid’ and stop.

3.

Verify that Qe,V is a valid key for the parameters D as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

© 2017 ASC X9, Inc. – All rights reserved

131

ANSI X9.63-2011 (R2017)

4.

Use the MQV primitive in Section 5.5 to derive a shared secret value zFq from the key pairs (d1,Q1)=(ds,U,Qs,U) and (d2,Q2)=(de,U,Qe,U), the public keys Q3=Qs,V and Q4= Qe,V, and the parameter set D. If the MQV primitive outputs ‘invalid’, output ‘invalid’ and stop.

5.

Convert z to a bit string Z using the convention specified in Section 4.3.3.

6.

Use the established key derivation function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret value Z and the shared data [SharedData].

7.

Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.

8.

Convert Qe,U and Qe,V to the octet strings QEU and QEV using the convention in Section 4.3.6. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV, the bit string QEU, and if present Text1: MacData1 = 0216 || V || U || QEV || QEU || [Text1].

9.

10.

Verify that MacTag1 is the tag for MacData1 under the key MacKey using the tag checking transformation of the established MAC scheme. If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop. Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU corresponding to U’s ephemeral public key, the bit string QEV corresponding to V’s purported ephemeral public key, and optionally a bit string Text2: MacData2 = 0316 || U || V || QEU || QEV || [Text2].

11.

Calculate the tag MacTag2 on MacData2 under the key MacKey using the tagging transformation of the established MAC scheme: MacTag2 = MACMacKey(MacData2). If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send MacTag2 and if present Text2 to V.

Output: The bit string KeyData as the keying data of length keydatalen bits.

I.2.3.2 Responder Transformation V shall execute the following transformation to agree on keying data with U if V is the scheme’s responder. V shall obtain an authentic copy of U’s identifier and U’s static public key Qs,U. 132

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) Input: The input to the responder transformation is: 1.

An ephemeral public key Qe,U purportedly owned by U.

2.

An integer keydatalen that is the length in bits of the keying data to be generated.

3.

(Optional) A bit string SharedData of length shareddatalen bits that consists of some data shared by U and V.

Ingredients: The responder transformation employs the key pair generation primitive in Section 5.2.1, a public key validation method in Section 5.2.2, the MQV primitive in Section 5.5, the associate value function in Section 5.6.1, an Approved key derivation function as specified in Section 5.6.3, and an Approved MAC scheme as specified in Section 5.7. Actions: Keying data shall be derived as follows: 1.

Receive an ephemeral public key Qe,U from U that is purportedly owned by U , and verify that Qe,U is a valid key for the parameter set D as specified in Section 5.2.2. If the validation primitive rejects the key, output ‘invalid’ and stop.

2.

Use the key pair generation primitive in Section 5.2.1 to generate an ephemeral key pair (de,V,Qe,V) for the parameter set D.

3.

Use the MQV primitive in Section 5.5 to derive a shared secret value zFq from the key pairs (d1,Q1)=(ds,V,Qs,V) and (d2,Q2)=(de,V,Qe,V), the public keys Q3=Qs,U and Q4= Qe,U, and the parameter set D. If the MQV primitive outputs ‘invalid’, output ‘invalid’ and stop.

4.

Convert z to a bit string Z using the convention specified in Section 4.3.3.

5.

Use the established key derivation function to derive keying data KKeyData of length mackeylen+keydatalen bits from the shared secret value Z and the shared data [SharedData].

6.

Parse the leftmost mackeylen bits of KKeyData as a MAC key MacKey and the remaining bits as keying data KeyData.

7.

Convert Qe,U and Qe,V to the octet strings QEU and QEV using the convention in Section 4.3.6. Form the bit string consisting of the octet 0216, V’s identifier, U’s identifier, the bit string QEV, the bit string QEU, and, optionally, a bit string Text1: MacData1 = 0216 || V || U || QEV || QEU || [Text1].

8.

Calculate the tag MacTag1 for MacData1 under the key MacKey using the tagging transformation of the established MAC scheme. MacTag1 = MACMacKey(MacData1).

© 2017 ASC X9, Inc. – All rights reserved

133

ANSI X9.63-2011 (R2017)

If the tagging transformation outputs ‘invalid’, output ‘invalid’ and stop. Send to U the ephemeral public key Qe,V, if present the bit string Text1, and MacTag1. 9. 10.

Then receive from U an optional bit string Text2 and a purported tag MacTag2. If this data is not received, output ‘invalid’ and stop.

Form the bit string consisting of the octet 0316, U’s identifier, V’s identifier, the bit string QEU corresponding to U’s purported ephemeral public key, the bit string QEV corresponding to V’s ephemeral public key, and the bit string Text2 (if present): MacData2 = 0316 || U || V || QEU || QEV || [Text2].

11.

Verify that MacTag2 is the valid tag on MacData2 under the key MacKey using the tag checking transformation of the established MAC scheme . If the tag checking transformation outputs ‘invalid’, output ‘invalid’ and stop.

Output: The bit string KeyData as the keying data of length keydatalen bits.

I.3

Legacy Key Transport Schemes

This Annex describes the key transport schemes specified in this Standard. In each case, the key transport scheme is used by an entity who wishes to send keying data to another entity. The schemes specified are ‘asymmetric’ (i.e., different computations are performed by the two entities), so it is necessary to describe two transformations, one of which is undertaken by U if U is the initiator, and one of which is undertaken by V if V is the responder. In the specification of each transformation, equivalent computations that result in identical output are allowed. Each of the key transport schemes has certain prerequisites. These are conditions that must be satisfied by an implementation of the scheme. However, the specification of mechanisms that provide these prerequisites is beyond the scope of this Standard. There are no secrecy requirements for the choices that may be made for the prerequisites (e.g., the choice of hash function, Diffie-Hellman primitive, MAC algorithm, length of challenge). Annex F provides guidance on the selection and use of the key transport schemes. Annex F.4.4 provides guidance for selecting parameter sizes for the various cryptographic components of a key transport scheme including n, hashkeylen, mackeylen, and challengelen. Each key transport scheme is described in two ways. First, a flow diagram of the ordinary operation of the scheme between two entities U and V is provided. This flow diagram is for illustrative purposes only. Then a formal specification is given that describes the actions that the entities must take to use the scheme to establish keying data. 134

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) These flow diagrams are intended to aid in the understanding of the mechanics of the ‘ordinary’ operation of the schemes in which flows are relayed faithfully between two entities. Note that in ‘real-life’, there is no reason to assume that flows are relayed faithfully between two entities; that is why the schemes must be formally specified in a more technical fashion. When examining the flow diagrams, the following points should be noted: —

For clarity of exposition, optional fields such as Text and SharedData are omitted.

—

kdf(Z) denotes the output of an Approved key derivation function in Section 5.6.3 with input Z.

—

ENC and DEC, respectively, denote the encryption and decryption transformations associated with the asymmetric encryption scheme specified in Section 5.8. The subscripts immediately following ENC and DEC denote the keys being used in the operation of the appropriate transformation. Similarly, SIG denotes the signing transformation associated with the ECDSA signature scheme specified in Section 5.9, and MAC denotes the tagging transformation of Section 5.7.

The key transport schemes may involve input, output, or actions, some of which may be marked as optional. Optional input and output fields are fields that may or may not be present in implementations of the schemes. The schemes are designed to function whether or not these fields are present. However, if optional shared data (SharedData1, SharedData2) is used, then both communicating parties must use the same data in order to derive the same keying data. Optional shared data is allowed to permit flexibility with higher-level protocols that use the key agreement scheme. Specifying the form of the shared data, and mechanisms for sharing the data, are beyond the scope of this Standard. Optional actions are actions that may or may not be performed by implementations. The schemes are designed to function whether or not these actions are performed.

I.3.1

1-Pass Transport Scheme

This section specifies the 1-pass transport scheme. This scheme should not be used except for backwards compatibility with existing implementations of the previous version of this Standard.

© 2017 ASC X9, Inc. – All rights reserved

135

ANSI X9.63-2011 (R2017)

Qenc,V

U

V ENCQenc,V( U || KeyData )

KeyData = KeyData

U || KeyData = DECdenc,V( ENCQenc,V( U || KeyData ) ) KeyData = KeyData

Figure I-4 – 1-Pass Key Transport Scheme Figure I-4 illustrates the information flows involved in the use of the 1-pass key transport scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Annex I.31.1 to send keying data to V if U is the scheme’s initiator, and V uses the transformation specified in Annex I.3.1.2 to receive keying data from U if V is the scheme’s responder. The essential difference between the role of the initiator and the role of the responder is that the initiator selects the value of the keying data but does not contribute a static key pair, while the responder contributes a static key pair. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set D = (q, FR, a, b, ECCSEED, G, n, h) to be used with the asymmetric encryption scheme. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

2.

The entities shall have established whether the standard Diffie-Hellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2 will be used with the asymmetric encryption scheme.

3.

Each entity who acts as a responder shall be bound to a static encryption key pair associated with the system’s elliptic curve domain parameter set D. The binding process shall include the validation of the public key as specified in Section 5.2.2. If the standard Diffie- Hellman primitive is used by the scheme, then the standard public key validation primitive specified in Seciton 5.2.2.1 shall be used to to validate the responder's static public key.

136

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 4.

Each entity who acts as an initiator shall be bound to a unique identifier (e.g. distinguished names). All identifiers shall be bit strings of the same bitlength entlen. Entity U’s identifier will be denoted by the bit string U.

5.

Each entity shall have chosen an Approved MAC scheme for use with the asymmetric encryption scheme. mackeylen denotes the length of keys used by the selected MAC scheme.

6.

The entities shall have established an Approved key derivation function as specified in Section 5.6.3.

I.3.1.1 Initiator Transformation U shall execute the following transformation to establish keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s static encryption public key Qenc,V. Input: The input to the initiator transformation is: 1.

A bit string TransportedKeyData of length keydatalen bits that is the keying data to be transported.

2.

(Optional) Two bit strings SharedData1 and SharedData2 that consist of some data shared by U and V.

Ingredients: The initiator transformation employs the encryption transformation of the asymmetric encryption scheme in Section 5.8. Actions: Keying data shall be derived as follows: 1.

Form the bit string consisting of U’s identifier, the keying data to be transported (TransportedKeyData), and, optionally, a bit string Text: EncData = U || TransportedKeyData || [Text].

2.

Encrypt EncData under V’s static public encryption key Qenc,V corresponding to the EC domain parameter set D, with the optional inputs SharedData1 and SharedData2, using the encryption transformation of the asymmetric encryption scheme in Section 5.8. If the encryption transformation outputs ‘invalid’, output ‘invalid’ and stop. Otherwise the encryption transformation outputs a bit string EncryptedData as the encryption of EncData.

3.

Send EncryptedData to V.

Output: The bit string TransportedKeyData of length keydatalen bits as the keying data. NOTE— Including a key counter field in the optional Text field may help to prevent known key attacks.

© 2017 ASC X9, Inc. – All rights reserved

137

ANSI X9.63-2011 (R2017)

I.3.1.2 Responder Transformation V shall execute the following transformation to establish keying data with U if V is the scheme’s responder. V shall obtain an authentic copy of U’s identifier. Input: The input to the responder transformation is: 1.

A bit string EncryptedData purporting to be the encryption of a bit string.

2.

An integer keydatalen that is the length in bits of the expected keying data.

3.

(Optional) Two bit strings SharedData1 and SharedData2 that consist of some data shared by U and V.

Ingredients: The responder transformation employs the decryption transformation of the asymmetric encryption scheme in Section 5.8. Actions: Keying data shall be derived as follows: 1.

Decrypt the bit string EncryptedData using V’s static private decryption key denc,V corresponding to the EC domain parameter set D, with the optional inputs SharedData1 and SharedData2, using the decryption transformation of the asymmetric encryption scheme in Section 5.8. If the decryption transformation outputs ‘invalid’, output ‘invalid’ and stop. Otherwise, the decryption transformation outputs a bit string EncData of length encdatalen bits as the decryption of the bit string.

2.

If encdatalen≠entlen+keydatalen, output ‘invalid’ and stop.

3.

Parse the first entlen bits of EncData as the purported identifier U, and the next keydatalen bits of EncData as transported keying data TransportedKeyData.

4.

Verify that U=U; if not, output ‘invalid’ and stop.

Output: The bit string TransportedKeyData of length keydatalen bits as the keying data.

I.3.2

3-Pass Transport Scheme

This section specifies the 3-pass transport scheme. The scheme uses a signature scheme to provide explicit key authentication for a session key transported using the 1-pass transport scheme specified in Annex I.3.1. This scheme should not be used except for backwards compatibility with existing implementations of the previous editions of this Standard. 138

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017)

Qenc,U, Qsig,U

Qsig,V

ChalU

U

V

ChalV, ENCQenc,U( V || KeyData ), SIGdsig,V( ChalV || ChalU || U || ENCQenc,U( V || KeyData ) )

SIGdsig,U( ChalU || ChalV || V ) V || KeyData = DECdenc,U(ENCQenc,U( V || KeyData ) )

KeyData = KeyData

KeyData = KeyData

Figure I-5 – 3-Pass Key Transport Scheme Figure I-5 illustrates the information flows involved in the use of the 3-pass key transport scheme. The scheme is ‘asymmetric’, so two transformations are specified. U uses the transformation specified in Annex I.3.2.1 to request and receive keying data from V if U is the scheme’s initiator, and V uses the transformation specified in Annex I.3.2.2 to send keying data to U upon request if V is the scheme’s responder. The essential difference between the role of the initiator and the role of the responder is that the initiator sends the first flow of the exchange, while the responder selects the value of the keying data. Prerequisites: The following are the prerequisites for the use of the scheme: 1.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set Denc = (qenc, FRenc, aenc, benc, ECCSEEDenc, Genc, nenc, henc) to be used with the asymmetric encryption scheme. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall

© 2017 ASC X9, Inc. – All rights reserved

139

ANSI X9.63-2011 (R2017)

have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2. 2.

Each entity has an authentic copy of the system’s elliptic curve domain parameter set Dsig = (qsig, FRsig, asig, bsig, ECCSEEDsig, Gsig, nsig, hsig) to be used with the signature scheme. These parameters shall have been generated using the parameter generation primitives in Sections 5.1.1.1 and 5.1.2.1. Furthermore, the parameters shall have been validated using the parameter validation primitives in Sections 5.1.1.2 and 5.1.2.2.

3.

Each entity shall be bound to a static signing key pair associated with the system’s elliptic curve domain parameter set Dsig for signing. The binding process shall include the validation of the public signature as specified in Section 5.2.2. The key binding shall include a unique identifier for each entity (e.g. distinguished names). All identifiers shall be bit strings of the same bitlength entlen. Entity U’s identifier will be denoted by the bit string U. Entity V’s identifier will be denoted by the bit string V.

4.

The entities shall have established whether to use the standard Diffie-Hellman primitive specified in Section 5.4.1 or the modified Diffie-Hellman primitive specified in Section 5.4.2 with the asymmetric encryption scheme.

5.

Each entity who acts as an initiator shall be bound to a static encryption key pair associated with the system’s elliptic curve domain parameter set Denc for encryption. The binding process shall include the validation of the public encryption key as specified in Section 5.2.2. If the standard Diffie- Hellman primitive is used by the scheme, then the standard public key validation primitive specified in Seciton 5.2.2.1 shall be used to to validate the initiator's static public key.

6.

The entities shall have established an Approved MAC scheme for use with the asymmetric encryption scheme. mackeylen denotes the length of keys used by the selected MAC scheme.

7.

The entities shall have established an Approved key derivation function as specified in Section 5.6.3.

8.

The entities shall have established the length of the challenges to be used. challengelen denotes the length chosen. The challengelen shall be  112.

9.

The entities shall have established the length of the keys to be transported. keydatalen denotes the length chosen.

140

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) I.3.2.1 Initiator Transformation U shall execute the following transformation to establish keying data with V if U is the scheme’s initiator. U shall obtain an authentic copy of V’s identifier and V’s static signing public key Qsig,V. Input: The input to the initiator transformation is: 1.

An integer keydatalen that is the length in bits of the keying data to be received.

2.

(Optional) Two bit strings SharedData1 and SharedData2 that consist of some data shared by U and V.

Ingredients: The initiator transformation employs the challenge generation primitive specified in Section 5.3, the signature scheme specified in Section 5.9, and the decryption transformation of the asymmetric encryption scheme in Section 5.8. Actions: Keying data shall be derived as follows: 1. 2.

3.

Use the challenge generation primitive in Section 5.3 to generate a challenge ChallengeU of length challengelen bits. Send ChallengeU to V. Then receive from V a purported challenge ChallengeV, a bit string EncryptedData purporting to be the encryption of a bit string, an optional bit string Text1, and a pair of integers rsig1 and ssig1 purporting to be a signature. If this data is not received, output ‘invalid’ and stop.

Verify that ChallengeV is a bit string of length challengelen bits. If not, output ‘invalid’ and stop.

4.

Decrypt the bit string EncryptedData using U’s private decryption key denc,U corresponding to the EC domain parameter set Denc, with the optional inputs SharedData1 and SharedData2, using the decryption transformation of the asymmetric encryption scheme in Section 5.8. If the decryption transformation outputs ‘invalid’, output ‘invalid’ and stop. Otherwise, the decryption transformation outputs a bit string EncData of length encdatalen bits as the decryption of the bit string.

5.

If encdatalen≠entlen+keydatalen, output ‘invalid’ and stop.

6.

Parse the first entlen bits of EncData as the purported identifier V of V, and the next keydatalen bits of EncData as the transported keying data TransportedKeyData.

7.

Verify that V=V; if not, output ‘invalid’ and stop.

8.

Form the bit string consisting of ChallengeV, ChallengeU, U’s identifier, the bit string EncryptedData, and Text1 (if present): SignData1 = ChallengeV || ChallengeU || U || EncryptedData || [Text1].

© 2017 ASC X9, Inc. – All rights reserved

141

ANSI X9.63-2011 (R2017)

9.

10.

Verify that rsig1 and ssig1 are components of a valid signature of SignData1 under V’s public signature key Qsig,V corresponding to the EC domain parameter set Dsig, using the verifying transformation of the signature scheme in Section 5.9. If the verifying transformation outputs ‘invalid’, output ‘invalid’ and stop.

Form the bit string consisting of ChallengeU, ChallengeV, V’s identifier, and optionally a bit string Text_2: SignData2 = ChallengeU || ChallengeV || V || [Text2].

11.

Sign SignData2 using U’s private signing key dsig,U corresponding to the parameter set Dsig, using the signing transformation of the signature scheme in Section 5.9. If the signing transformation outputs ‘invalid’, output ‘invalid’ and stop. Otherwise, the signing transformation outputs the integers rsig2 and ssig2 as the signature of SignData2.

12.

Send to V the bit string Text2 (if present), rsig2 and ssig2.

Output: The bit string TransportedKeyData of length keydatalen bits.

I.3.2.2 Responder Transformation V shall execute the following transformation to establish keying data with U if V is the scheme’s responder. V shall obtain an authentic copy of U’s identifier, U’s static encryption public key Qenc,U, and U’s static signing public key Qsig,V. Input: The input to the responder transformation is: 1.

A purported challenge ChallengeU from U.

2.

A bit string TransportedKeyData of length keydatalen bits that is the keying data to be transported.

3.

(Optional) Two bit strings SharedData1 and SharedData2 that consist of some data shared by U and V.

Ingredients: The responder transformation employs the challenge generation primitive specified in Section 5.3, the signature scheme specified in Section 5.9, and the encryption transformation of the asymmetric encryption scheme in Section 5.8. Actions: Keying data shall be derived as follows: 1.

142

Verify that ChallengeU is a bit string of length challengelen bits. If not, output ‘invalid’ and stop.

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) 2.

Use the challenge generation primitive in Section 5.3 to generate a challenge ChallengeV of length challengelen bits.

3.

Form the bit string consisting of V’s identifier, TransportedKeyData, and, optionally, a bit string Text1: EncData = V || TransportedKeyData || [Text1].

4.

5.

Encrypt EncData under U’s public encryption key Qenc,U corresponding to the EC domain parameter set Denc, with the optional inputs SharedData1 and SharedData2, using the encryption transformation of the asymmetric encryption scheme in Section 5.8. If the encryption transformation outputs ‘invalid’, output ‘invalid’ and stop. Otherwise, the encryption transformation outputs a bit string EncryptedData as the encryption of EncData.

Form the bit string consisting of ChallengeV, ChallengeU, U’s identifier, the bit string EncryptedData, and optionally a bit string Text1: SignData1 = ChallengeV || ChallengeU || U || EncryptedData || [Text1].

6.

Sign SignData1 using V’s private signing key dsig,V corresponding to the parameter set Dsig, using the signing transformation of the signature scheme in Section 5.9. If the signing transformation outputs ‘invalid’, output ‘invalid’ and stop. Otherwise the signing transformation outputs the integers rsig1 and ssig1 as a signature of SignData1.

7.

Send ChallengeV, the bit string EncryptedData, Text1 (if present), and rsig1 and ssig1 to U.

8. 9.

Then receive from U an optional bit string Text2, and a purported signature rsig2 and ssig2. If this data is not received, output ‘invalid’ and stop.

Form the bit string consisting of ChallengeU, ChallengeV, V’s identifier, and Text2 (if present): SignData2 = ChallengeU || ChallengeV || V || [Text2].

10.

Verify that the pair rsig2 and ssig2 is a valid signature of SignData2 under U’s public signature key Qsig,U corresponding to the EC domain parameter set Dsig, using the verifying transformation of the signature scheme in Section 5.9. If the verifying transformation outputs ‘invalid’, output ‘invalid’ and stop.

Output: The bit string TransportedKeyData of length keydatalen bits.

© 2017 ASC X9, Inc. – All rights reserved

143

ANSI X9.63-2011 (R2017)

Annex J (informative) Bibliography A comprehensive treatment of modern cryptography can be found in [17]. Elliptic curve cryptosystems were first proposed in 1985 independently by Neal Koblitz [11] and Victor Miller [18]. Since then, much research has been undertaken towards improving the efficiency of these systems and evaluating their security. For a summary of this work, consult [7]. For a detailed treatment of the mathematical theory of elliptic curves, see [21]. Three references on the theory of finite fields are the books of McEliece [14], Lidl and Neiderreiter [13], and Jungnickel [9]. Lidl and Neiderreiter’s book [13] contains introductory material on polynomial and normal bases. The hash-based MAC scheme HMAC was introduced by Bellare, Canetti and Krawczyk in [1]. The asymmetric encryption scheme specified in this Standard was introduced by Bellare and Rogaway in [2]. The fundamental concept of asymmetric key agreement was introduced by Diffie and Hellman in [5]. The extensions to the traditional Diffie-Hellman primitive specified in this Standard were introduced in [3], [6], and [16]. See also [12]. The key transport schemes specified here are based on those in [39]. [1]

M. Bellare, R. Canetti, and H. Krawczyk. Keying hash functions for message authentication. In Advances in Cryptology: Crypto '96, pages 1-15, 1996.

[2]

M. Bellare and P. Rogaway. Minimizing the use of random oracles in authenticated encryption schemes. In Proceedings of PKS ‘97, 1997.

[3]

S. Blake-Wilson, D. Johnson, and A.J. Menezes. Key agreement protocols and their security analysis. In Cryptography and Coding, 6th IMA Conference, Springer-Verlag, pages 30-45, 1997.

[4]

D. Boneh and R.J. Lipton. Algorithms for black-box fields and their application to cryptography. In Advances in Cryptology: Crypto ‘96, pages 283-297, 1996.

[5]

W. Diffie and M. Hellman. New directions in cryptography. IEEE Transactions on Information Theory. IT-22(6): 644-654, November 1976.

[6]

W. Diffie, P.C. van Oorschot, and M.J. Wiener. Authentication and authenticated key exchanges. Designs, Codes, and Cryptography. 2, pages 107-125, 1992.

144

© 2017 ASC X9, Inc. – All rights reserved

ANSI X9.63-2011 (R2017) [7]

D. Hankerson, A. Menezes, and S. Vanstone. Guide to Elliptic Curve Cryptography. Springer, 2004.

[8]

D. Johnson. Diffie-Hellman Key Agreement Small Subgroup Attack, a Contribution to X9F1 by Certicom. July 16, 1996.

[9]

D. Jungnickel. Finite Fields: Structure and Arithmetics. B.I.Wissenschaftsverlag, Mannheim, 1993.

[10]

B. Kaliski. MQV vulnerability. Posting to ANSI X9F1 and IEEE P1363 newsgroups. 1998.

[11]

N. Koblitz. Elliptic curve cryptosystems. Mathematics of Computation, 48, pages 203209, 1987.

[12]

L. Law, A. Menezes, M. Qu, J. Solinas, and S. Vanstone. An efficient protocol for authenticated key agreement. Technical report CORR 98-05, Department of Combinatorics & Optimization, University of Waterloo, March, 1998.

[13]

R. Lidl and H. Neiderreiter. Finite Fields. Cambridge University Press, 1987.

[14]

R.J. McEliece. Finite Fields for Computer Scientists and Engineers. Kluwer Academic Publishers, 1987.

[15]

A.J. Menezes, T. Okamoto, and S.A. Vanstone. Reducing elliptic curve logarithms to logarithms in a finite field. IEEE Transactions on Information Theory, 39, pages 16391646, 1993.

[16]

A.J. Menezes, M. Qu, and S.A. Vanstone. Some new key agreement protocols providing implicit authentication. Workshop record. 2nd Workshop on Selected Areas in Cryptography (SAC ‘95), Ottawa, Canada, May 18-19, 1995.

[17]

A.J. Menezes, P.C. van Oorschot, and S.A. Vanstone. Handbook of Applied Cryptography. CRC Press, 1997.

[18]

V. Miller. Uses of elliptic curves in cryptography. In Advances in Cryptology: Crypto ‘85, pages 417-426, 1985.

[19]

SEC 1: Elliptic Curve Cryptography, Version 2.0. See www.secg.org.

[20]

SEC 2: Recommended Elliptic Curve Domain Parameters, Version 2.0. See www.secg.org.

[21]

J. Silverman. The Arithmetic of Elliptic Curves. Springer-Verlag, New York, 1985.

© 2017 ASC X9, Inc. – All rights reserved

145