ENGINE REFERENCE
`DO NOT TAKE FROM THIS ROOM
`
`ANSI X9.17
`1115
`
`Financial Services Technical Publication
`Developed By Accredited
`Standards Committee
`X9 - Financial Services
`
`FINANCIAL INSTITUTION KEY
`MANAGEMENT (WHOLESALE)
`
`Developed by
`Accredited Standards Committ ee
`X9 - Financial Services
`
`PUBLISHED BY
`X9 - SECRETARIAT
`AMERICAN BANKERS ASSOCIATION
`
`IPR2018-00067
`Unified EX1016 Page 1
`
`

`

`
`
`|PR2018—00067
`
`Unified EX1016 Page 2
`
`IPR2018-00067
`Unified EX1016 Page 2
`
`

`

`ANSI®
`X9.17-1995
`
`American National Standard
`for Financial Services
`
`Financial Institution Key Management
`(Wholesale)
`
`Secretariat
`
`American Bankers Association
`
`Approved: October 6, 1995
`
`American National Standards Institute, Inc.
`
`IPR2018-00067
`Unified EX1016 Page 3
`
`

`

`American
`Approval of an American National Standard requires verification by ANSI that the
`requirements for due process, consensus, and other criteria for approval have been met
`National
`by the standards developer.
`Standard
`
`Consensus is established when, in the judgment of the ANSI Board of Standards Review,
`substantial agreement has been reached by directly and materially affected interests.
`Substantial agreement means much more than a simple majority, but not necessarily
`unanimity. Consensus requires that all views and objections be considered, and that a
`concerted effort be made toward their resolution.
`
`The use of American National Standards is completely voluntary; their existence does not
`in any respect preclude anyone, whether he has approved the standards or not from
`manufacturing, marketing, purchasing, or using products, processes, or procedures not
`conforming to the standards.
`
`The American National Standards Institute does not develop standards and will in no
`circumstances give an interpretation of any American National Standard. Moreover, no
`person shall have the right or authority to issue an interpretation of an American National
`Standard in the name of the American National Standards Institute. Requests for
`interpretations should be addressed to the secretariat or sponsor whose name appears
`on the title page of this standard.
`
`CAUTION NOTICE: This American National Standard may be revised or withdrawn at
`any time. The procedures of the American National Standards Institute require that action
`be taken to reaffirm, revise, or withdraw this standard no later than five years from the
`date of approval.
`
`Published by
`
`EDI Support Services, Inc.
`P.O. Box 203, Chardon, OH 44024
`Order Desk: 800-334-4912
`International Orders: 216-97 4-7650
`
`Copyright© 1995 by American Bankers Association, Standards Division
`All rights reserved.
`
`No part of this publication may be reproduced in any form,
`stored in a retrieval system, or transmitted by any means,
`electronic, mechanical, photocopying, recording, or otherwise,
`without prior written permission from the X9 Secretariat,
`c/o American Bankers Association.
`
`Printed in the United States of America
`
`IPR2018-00067
`Unified EX1016 Page 4
`
`

`

`Contents
`
`Page
`Foreword . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii
`
`1
`
`2
`
`Scope ......................................................
`
`1
`
`Definitions and common abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
`
`2.1
`
`2.2
`
`Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
`
`Common abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
`
`3
`
`Key management facility protection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
`
`3.1
`
`3.2
`
`3.3
`
`3.4
`
`3.5
`
`3.6
`
`General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
`
`Facility requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
`
`Key entry. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
`
`Transportation and storage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
`
`Cryptographic module operational integrity. . . . . . . . . . . . . . . . . . . 8
`
`Destruction of keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
`
`4
`
`Key management requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
`
`4.1
`
`4.2
`
`4.3
`
`General requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
`
`Automated key management architecture . . . . . . . . . . . . . . . . . . 9
`
`Automated key management architecture
`
`11
`
`5
`
`Key and initialization vector generation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
`
`5.1
`
`5.2
`
`5.3
`
`General requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
`
`Generation of keys and IVs for manual distribution . . . . . . . . . . . 11
`
`Generation of keys and IVs for automated distribution . . . . . . . . . 11
`
`6
`
`Key and IV distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
`
`6.1
`
`6.2
`
`6.3
`
`6.4
`
`General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
`
`Automated key distribution environments . . . . . . . . . . . . . . . . . . 12
`
`Manual key distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
`
`Automated key distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
`
`7
`
`Key and IV encryption and decryption . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
`
`7.1
`
`7 .2
`
`7.3
`
`7.4
`
`7.5
`
`Notation .............................................
`
`14
`
`Encryption, decryption, authentication and error detection. . . . . . 15
`
`Counters ............................................
`
`19
`
`Offsetting of keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
`
`Notarization of keys ....................................
`
`22
`
`8
`
`Cryptographic service messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
`
`8.1
`
`8.2
`
`General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
`
`Cryptographic service message classes. . . . . . . . . . . . . . . . . . . 25
`
`IPR2018-00067
`Unified EX1016 Page 5
`
`

`

`Contents continued
`
`Page
`
`8.3
`
`8.4
`
`8.5
`
`8.6
`
`Cryptographic service message character set
`and representation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
`
`Cryptographic service message formats ....................
`
`26
`
`Cryptographic service message fields and subfields . . . . . . . . . . 26
`
`Cryptographic service message flow . . . . . . . . . . . . . . . . . . . . . . 28
`
`9
`
`Generating cryptographic service messages. . . . . . . . . . . . . . . . . . . . . . . 34
`
`9.1
`
`9.2
`
`9.3
`
`9.4
`
`9.5
`
`9.6
`
`9.7
`
`9.8
`
`9.9
`
`Cryptographic service message class determination . . . . . . . . . . 34
`
`Generating a disconnect service message. . . . . . . . . . . . . . . . . . 35
`
`Generating an error recovery service message . . . . . . . . . . . . . . 36
`
`Generating an error service message. . . . . . . . . . . . . . . . . . . . . . 40
`
`Generating a key service message ........................
`
`43
`
`Generating a request for service message. . . . . . . . . . . . . . . . . . 50
`
`Generating a request service initiation message .............
`
`53
`
`Generating a response service message . . . . . . . . . . . . . . . . . . . 54
`
`Generating a response to request message .................
`
`56
`
`1 O Processing cryptographic service messages. . . . . . . . . . . . . . . . . . . . . . . 61
`
`10.1 Cryptographic service message class determination . . . . . . . . . . 61
`
`10.2
`
`10.3
`
`10.4
`
`10.5
`
`10.6
`
`10.7
`
`10.8
`
`10.9
`
`Processing a disconnect service message. . . . . . . . . . . . . . . . . . 62
`
`Processing an error recovery service message . . . . . . . . . . . . . . 63
`
`Processing an error service message. . . . . . . . . . . . . . . . . . . . . . 69
`
`Processing a key service message. . . . . . . . . . . . . . . . . . . . . . . . 71
`
`Processing a request for service message. . . . . . . . . . . . . . . . . . 80
`
`Processing a request service initiation message . . . . . . . . . . . . . 84
`
`Processing a response service. . . . . . . . . . . . . . . . . . . . . . . . . . . 87
`
`Processing a response to request message. . . . . . . . . . . . . . . . . 89
`
`11 Key states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
`
`12 Optional field and subfield extensions ............................
`
`97
`
`12.1
`
`Additional subfields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
`
`12.2
`
`Additional fields. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 06
`
`13 Optional messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
`
`13.1 Disconnect notify message {DNM) .......................
`
`113
`
`13.2 Disconnect confirmation message {CFM). . . . . . . . . . . . . . . . . . 120
`
`13.3 Response service message {RSM)
`in response to a DNM or CFM . . . . . . . . . . . . . . . . . . . . . . . . . . 120
`
`ii
`
`IPR2018-00067
`Unified EX1016 Page 6
`
`

`

`Contents continued
`
`13.4
`
`Error service message (ESM) in response to a
`disconnect notify message (DNM), disconnect
`confirmation message (CFM) or a response message
`(RSM) to the DNM or CFM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
`
`14 References ................................................
`
`130
`
`Page
`
`Tables
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`Processing count values (MAC check) . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
`
`IDD Field handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
`
`Service message field and subfield specifications. . . . . . . . . . . . . . . . . . 121
`
`Fields used with each message class: Point-to-point environment . . . . . 123
`
`Fields used with each message class:
`Key Distribution Center environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
`
`Fields used with each message class:
`Key Translation Center environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
`
`Figures
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`7
`
`8
`
`9
`
`Key distribution architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 O
`
`Encryption/decryption of a single key by a single key . . . . . . . . . . . . . . . . 16
`
`Encryption/decryption of a single key by a key pair . . . . . . . . . . . . . . . . . . 17
`
`Encryption/decryption of a key pair by a key pair ....................
`
`18
`
`Point-to-point environment (normal message flow)
`with an example of a DSM originated by Party A. . . . . . . . . . . . . . . . . . . . 28
`
`Point-to-point environment (message flow with error messages)
`with an example of a DSM originated by Party A. . . . . . . . . . . . . . . . . . . . 29
`
`Key Distribution Center environment (normal message flow)
`with an example of a DSM originated by Party A. . . . . . . . . . . . . . . . . . . . 30
`
`Key Distribution Center environment (message flow with error
`messages) with an example of a DSM originated by Party A ..........
`
`31
`
`Key Translation Center environment (normal message flow)
`with an example of a DSM originated by Party A. . . . . . . . . . . . . . . . . . . . 32
`
`10 Key Translation Center environment (message flow with error
`messages) with an example of a DSM originated by Party A ..........
`
`33
`
`11 Key states . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
`
`12 DNM and resulting DSM message flow ..........................
`
`113
`
`iii
`
`IPR2018-00067
`Unified EX1016 Page 7
`
`

`

`Contents continued
`
`Page
`
`Annex A
`
`Examples of key distribution and control
`131
`A.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
`
`A.2 Appointment of encryption personnel . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
`
`A.3 Responsibilities of custodians . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
`
`A.4 Shipment of key material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
`
`A.5 Receipt of keying material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
`
`A.6 Storage of keying material and encryption/authentication
`device physical keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
`
`A.7 Use of keying material .......................................
`
`133
`
`A.8 Destruction of keying material . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
`
`A.9 Archival storage of keys. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
`
`Annex B
`
`Example of manual key distribution . . . . . . . . . . . . . . . . . . . . . . 135
`
`Annex C
`
`Example of pseudorandom & IV generation algorithm . . . . . . . . 137
`
`Annex D
`
`Considerations for a key management system
`within a cryptographic module . . . . . . . . . . . . . . . . . . . . . . . . . . 139
`
`D.1
`
`Introduction .......................
`
`-. . . . . . . . . . . . . . . . . . . . . . . . 139
`
`D.2 Selection of security levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
`
`D.3 Security issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
`
`Annex E
`
`Clearing, sanitizing or destroying recording
`media used for the storage of keying material . . . . . . . . . . . . . . 143
`E.1 Scope ....................................................
`E.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
`
`143
`
`E.3 Magnetic tapes ( reel and cassette formats). . . . . . . . . . . . . . . . . . . . . . . 143
`
`E.4 Flexible magnetic media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
`
`E.5 Rigid magnetic media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
`
`E.6 Magnetic memory units . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
`
`E.7 Display devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
`
`E.8 Optical mass storage media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
`
`E.9 Semiconductor memory devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
`E.1 O Crypto keys and smart cards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
`E.11 Hard copy output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
`
`iv
`
`IPR2018-00067
`Unified EX1016 Page 8
`
`

`

`Contents continued
`
`Page
`
`Annex F
`
`Windows and windows management . . . . . . . . . . . . . . . . . . . . . 147
`
`F.1 Purpose ..................................................
`
`147
`
`F.2 Window size. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
`
`F.3 Detection of duplicate messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
`
`F.4 Processing messages using a window . . . . . . . . . . . . . . . . . . . . . . . . . 147
`
`Table
`
`F1 Processing counters (MAC checks)...
`
`. . . . . . . . . . . . . . . . . . . . . . . . . 148
`
`Annex G
`
`Examples of cryptographic service messages . . . . . . . . . . . . . . 149
`
`G.1 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
`
`G.2 Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
`
`V
`
`IPR2018-00067
`Unified EX1016 Page 9
`
`

`

`Blank page
`Blank page
`
`vi vi
`
`|PR2018—00067
`
`Unified EX1016 Page 10
`
`IPR2018-00067
`Unified EX1016 Page 10
`
`

`

`Foreword (This foreword is not part of American National Standard X9.17-1995.)
`
`Financial institutions are making increased use of the American National Standard
`Data Encryption Algorithm, DEA 1
`, to protect financial messages and other sensitive
`information. Specific examples of this include message encryption and funds
`transfer message authentication.
`
`The DEA algorithm is in the public domain. The security and reliability of any process
`based on the DEA are directly dependent on the protection afforded to a secret
`number, called the key. To provide this security, this standard establishes methods
`for the generation, distribution, storage and destruction of the secret key and other
`related information.
`
`A familiar analogy may be found in the combination lock of a vault. The lock design
`is public knowledge. Security is provided by keeping a number, the combination,
`secret. Secure operation also depends on protective procedures and features which
`prevent surreptitious viewing or determination of the combination by listening to its
`operation. Procedures are also required to ensure that the combination is random
`and cannot be modified by an unauthorized individual without detection.
`
`To support the varying needs of financial institutions and to support interoperability,
`this standard defines both manual and automated methods for exchanging keying
`material.
`
`The key(s) must be:
`
`•
`
`•
`
`randomly generated, distributed, stored, and destroyed or archived in a
`secure, controlled, and auditable manner.
`
`tested during system operation to detect system failures or unauthorized
`changes.
`
`Implementation of these requirements will also require certain system tests, the
`generation of appropriate alarms and the inhibition of operations that could result in
`compromising the key, the data or both.
`
`While the techniques specified in this standard are designed to maintain the security
`and integrity of keys, the standard in no way guarantees that a particular implemen(cid:173)
`tation of the techniques is secure.
`
`It is the responsibility of the financial institution to put overall key management in
`place with the necessary controls to assure that the process is implemented under
`secure procedures. Furthermore, the process should be audited to ensure compli(cid:173)
`ance with the procedures.
`
`There are seven annexes in this standard. Annex A, B, C, D, E, F, and G are
`informative and are not considered part of this standard.
`
`Suggestions for the improvement or revision of this standard will be welcome. They
`should be sent to the X9 Committee Secretariat, American Bankers Association,
`1120 Connecticut Avenue, N.W., Washington, D.C. 20036.
`
`1> X3.92-1981, Data Encryption Algorithm.
`
`vii
`
`IPR2018-00067
`Unified EX1016 Page 11
`
`

`

`This standard was processed and approved for submittal to ANSI by the Accredited
`Standards Committee on Financial Services, X9. Committee approval of this stand(cid:173)
`ard does not necessarily imply that all committee members voted for its approval.
`At the time it approved this standard, the X9 Committee had the following members:
`
`Harold G. Deal, Chairman
`Jack Kilhefner, Vice Chairman, Administration
`Cynthia L. Fuller, Associate Director, ABA Standards Division
`Deborah Katz, Assistant Division Manager, ABA Standards Division
`
`Organization Represented
`.
`Advantis ...........
`American Bankers Association
`American Express Company
`.
`Applied Communications
`. . .
`AT&T Global Information Solutions
`Bank of America . . . . . . . .
`Bank of Boston
`. . . . . . . . . .
`Canadian Bankers Association
`. .
`Canadian Imperial Bank of Commerce
`Chase Manhattan Bank, N.A ..
`Chemical Bank, N.A.
`Citibank
`.....
`.
`CoreStates Bank
`. .
`Deluxe Corporation
`.
`Discover Card Services, Inc.
`Federal Reserve Bank
`Fidelity Investments
`. . .
`IBM Corporation . . . . .
`MasterCard International
`Mellon Bank, N.A. . . . .
`Moore Business Forms, Inc.
`National Security Agency
`. .
`NationsBanc Services, Inc. .
`New York Clearing House . .
`Nat'I Institute of Science & Technology
`PNC Financial Corporation
`UNISYS Corporation
`VISA International .
`Wells Fargo Bank .
`Xerox Corporation .
`
`.
`
`Name of Representative
`. Lore Eisenstaedt
`. Anne Livingston
`. Eileen Bell
`. Sonia Reed
`. Robert K. Kramer
`. John Coombs
`. Georgia Clarke
`. Tom Anderson
`. Dan Conlon
`. John McKessey
`. Frances Silverstein
`. Seymour R. Rosen
`. Kent Seinfeld
`. James Gallup
`. Bill Kabat
`. Michael Garrett
`. Ed Zeitler
`. Harry Hankla
`. Alice Droogan
`. David P. Taddeo
`. Delmer Oddy
`. Gerard A. Rainville, Jr.
`. Harold G. Deal
`. Vincent De Santis
`. Miles Smid
`. John Ericksen
`. Karl T. Sammons
`. Patricia Greenhalgh
`. Jack Kilhefner
`. Mike Oszczakiewicz
`
`Subcommittee X9F, Data and Information Security, which voted on and approved
`this standard, had the following members:
`
`J. Martin Ferris, Chairman
`
`Organization Represented
`3M Corporation
`. . . . . . .
`American Bankers Association
`Applied Communications
`. . .
`AT&T Global Information Solutions
`Bank of America . . . . .
`Bank of America . . . . .
`Bankers Trust
`.....
`.
`Chase Manhattan Bank .
`Chemical Bank, N.A.
`. .
`CoreStates Bank
`Cylink
`.........
`
`.
`
`viii
`
`Name of Representative
`. Gary Pearson
`. Karen Panker
`. Sonia Reed
`. Karen Randall
`. Kathie Gibbons
`. Mack Hicks
`. Frank Sudia
`. Emil D' Angelo
`. Peggy Bruner
`. Kent Seinfeld
`. William Lattin
`
`IPR2018-00067
`Unified EX1016 Page 12
`
`

`

`Organization Represented
`Deluxe Check Printers
`Federal Reserve Bank
`Fischer International
`IBM Corporation . . . .
`Litronic
`.......
`.
`Info Resources
`. . . .
`Kirchman Corporation .
`MasterCard International
`Mellon Bank ......
`.
`Mobius Encryption Technologies
`National Institute of Standards & Technology
`National Security Agency . .
`NationsBanc Services, Inc. .
`Northern Telecom .....
`.
`Norwest Technical Services
`Racal-Guardata . . . . . . .
`U.S. Department of Treasury
`VISA International . . . . . .
`
`Name of Representative
`. James Gallup
`. James Berlin
`. Arthur Weber
`. James Randall
`. James Prohaska
`. Doug Kozlay
`. Blair Rugh
`. Alice Droogan
`. Dain Gary
`. Sherry Shannon
`. Miles Smid
`. Gerard Rainville
`. Don Sawyer
`. Warwick Ford
`. Cathie Briggs
`. Samuel Epstein
`. Martin Ferris
`. Bill Chen
`
`Under ASC X9 procedures, a working group may be established to address specific
`segments of work under the X9 Committee or one of its subcommittees. A working
`group exists only to develop standard(s) or guideline(s) in a specific area and is then
`disbanded. The individual experts are listed with their affiliated organizations.
`However, this does not imply that the organization has approved the content of the
`standard or guideline. (Note: Per X9 policy, company names of non-member
`participants are listed only if, at time of publication, the X9 Secretariat received an
`original signed release permitting such company names to appear in print.)
`
`Working Group X9F3, which reported to X9F and which developed this standard,
`included the following participants:
`
`Gary Chaulklin, Chairman
`
`Organization Represented
`AT&T Bell Laboratories
`Chase Manhattan Bank
`Citicorp, CGIN
`Communication Devices, Inc.
`Department of the Treasury
`
`Federal Reserve Bank of Richmond
`Federal Reserve Bank of Atlanta
`Fischer International
`IBM Corporation
`Internal Revenue Service
`Information Research Engineering, Inc.
`Jones Futurex, Inc.
`Nat'I Institute of Standards and Technology
`National Security Agency
`Racal Guardata, Inc.
`
`Other participants
`
`Name of Representative
`William Oeschger
`Richard Yen
`Perry Gleason
`Tadhg Kelly
`Richard Bauder
`J. Martin Ferris
`Gary Chaulklin
`Richard Sweeney
`Richard Ankney
`James Randall
`Peter Sargent
`Doug Kozlay
`Don Thompson
`Elaine Barker
`Clarence Reaver
`Donald Cole
`
`Glenda Barnes
`
`ix
`
`IPR2018-00067
`Unified EX1016 Page 13
`
`

`

`mm
`
`Blank page
`Blank page
`
`X
`
`|PR2018—00067
`
`Unified EX1016 Page 14
`
`IPR2018-00067
`Unified EX1016 Page 14
`
`

`

`AMERICAN NATIONAL STANDARD
`
`ANSI XS.17-1995
`
`American National Standard for
`Financial Services -
`
`Financial Institution
`Key Management
`(Wholesale)
`
`Scope
`1
`This standard covers both the manual and auto(cid:173)
`mated management of keying material for the
`wholesale financial services industry. This stand(cid:173)
`ard specifies the minimum requirements for the
`management of keying material, including:
`
`• Control during the life of the keying material to
`prevent unauthorized disclosure, modification
`or substitution.
`
`• Distribution of keying material to permit in(cid:173)
`teroperability between cryptographic equip(cid:173)
`ment or facilities.
`
`• Ensuring the integrity of keying material during
`all phases of its life, including its generation,
`distribution, storage, entry, use, and destruc(cid:173)
`tion.
`
`• Recovery in the event of failure of the key
`management process or when the integrity of
`the keying material is questioned.
`
`2
`
`2.1
`
`Definitions and common
`abbreviations
`Definitions
`
`active (key state): A key in the active
`2.1.1
`state may be used to secure information from the
`originator and process received secure informa(cid:173)
`tion.
`
`agent identity: The unique identity of an
`2.1.2
`X9.28 agent.
`
`audit record field: A field containing
`2.1.3
`information about all entities involved in a transac(cid:173)
`tion, as well as indicators of the types of process(cid:173)
`ing that were performed by those entities.
`
`authentication: The act of determining
`2.1.4
`that a message has not been changed since leav-
`
`ing its point of origin. The identity of the originator
`is implicitly verified.
`
`cascading obsolete flag: A character
`2.1.5
`in the ST field of a DSM which indicates that all
`keys explicitly or implicitly identified in the IDD
`fields are to be placed in the obsolete state.
`
`2.1.6
`data.
`
`ciphertext: Encrypted
`
`(enciphered)
`
`communicating pair: Two logical par(cid:173)
`2.1.7
`ties who have previously agreed to exchange data.
`A party and a center exchanging cryptographic
`service messages do not constitute a communi(cid:173)
`cating pair.
`
`compromised obsolete (key state):
`2.1.8
`The integrity or secrecy of the key is suspect.
`
`compromised obsolete flag: A charac(cid:173)
`2.1.9
`ter in the ST field of a DSM which indicates that all
`keys explicitly or implicitly identified in the IDD
`fields are to be placed in the compromised obso(cid:173)
`lete state.
`
`2.1.1 O corresponding key field: Used in the
`context of a KSM, RFS or RTR which is sent in
`response to an RSI which contains a key field. A
`corresponding key field is a key field in the re(cid:173)
`ceived/transmitted message which is the same
`type and subtype as a key field in the transmit(cid:173)
`ted/received message, or vice versa.
`
`2.1.11 cryptoperiod: 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. When key states are used, the cryptoperiod
`is the period of time during which a key is in the
`active and pending obsolete states.
`
`2.1.12 cryptographic key (key): A parameter
`that determines the transformation from plaintext
`to ciphertext and vice versa. (A DEA key is a 64
`bit parameter consisting of 56 independent bits
`and eight bits which may be used as odd parity
`bits.)
`
`cryptographic keying material: See
`2.1.13
`keying material.
`
`cryptographic module: The set of
`2.1.14
`hardware, software, firmware, or some combina(cid:173)
`tion thereof that implements cryptographic logic,
`including cryptographic algorithms. A device
`wherein cryptographic functions (e.g., encryption,
`authentication, key generation) are performed.
`
`1
`
`IPR2018-00067
`Unified EX1016 Page 15
`
`

`

`ANSI XS.17-1995
`
`service message
`cryptographic
`2.1.15
`(CSM): A message for transporting keys or related
`information used to control a keying relationship.
`
`data encryption algorithm (DEA): The
`2.1.16
`encryption algorithm specified by X3.92, Data En(cid:173)
`cryption Algorithm.
`
`data key (KD): A key used to encrypt
`2.1.17
`and decrypt, or to authenticate data.
`
`decryption: A process of transforming
`2.1.18
`ciphertext into plaintext.
`
`degauss: To remove, erase or clear
`2.1.19
`information from magnetic media.
`
`discontinued keys: Keys which have
`2.1.20
`been deleted or marked so as not to be used to
`encrypt or authenticate either data or other keys
`except for message reconstruction. When key
`states are used, the keys may be in either the
`Obsolete or compromised obsolete state.
`
`dual control: A process of utilizing two
`2.1.21
`or more separate entities (usually persons), oper(cid:173)
`ating in concert, to protect sensitive function~ or
`information. Both entities are equally responsible
`for the physical protection of materials involved in
`vulnerable transactions. No single person shall be
`able to access or to utilize the entire set of mate(cid:173)
`rials ( e.g., cryptographic key).For manual key gen(cid:173)
`e ration, conveyance,
`loading, storage and
`retrieval, dual control requires split knowledge of
`a key among the entities. (Also see Split Knowl(cid:173)
`edge)
`
`effective date: Used in the unique iden(cid:173)
`2.1.22
`tification of a key. The date and time when a key
`is to be placed into use or activated (i.e., enters
`the active state).
`
`electronic distribution: Distribution of
`2.1.23
`keying materials between entities by means of an
`electronic communication. Electronic distribution
`does not include electronic key loaders, such as
`smart cards.
`
`encryption: A process of transforming
`2.1.24
`plaintext into ciphertext for the purpose of security
`or privacy.
`
`exclusive-or: A mathematical operation
`2.1.25
`symbol EB defined as:
`
`OEBO =0
`
`OEB1 =1
`
`2
`
`1EB0=1
`1 EB 1 = 0
`Equivalent to binary addition without carry.
`
`explicitly identified key: Used in the
`2.1.26
`context of changing the state of a key to the
`obsolete or compromised obsolete state by send(cid:173)
`ing or receiving a DSM. A key is said to be explicitly
`identified if the name of the key is used in an IDD
`field.
`
`field tag: A unique string of characters
`2.1.27
`which identifies the meaning and location of the
`associated data field.
`
`financial message: A communication
`2.1.28
`containing information which has financial implica(cid:173)
`tions.
`
`highest level key: The key found in the
`2.1.29
`(*)KK or (*)KKU field, if present. If no (*)KK or
`(*)KKU field is present, the highest level key(s) is
`found in the KD or KOU field{s).
`
`immediately activated: A key is said to
`2.1.30
`be immediately activated if no effective date is
`associated with a key; a key is immediately acti(cid:173)
`vated (1) by the receiver when the RSM is sent in
`response to the KSM which carried that key, and
`(2) by the sender when the RSM is received in
`response to the KSM which carried the key.
`
`implicitly identified key: A key is said
`2.1.31
`to be implicitly identified if the (*)KK which was
`used to offset encrypt or notarize that key is ex(cid:173)
`plicitly identified in an IDD field, but the key itself
`is not explicitly identified. When key states are
`used, the term is used in the context of changing
`the state of a key to the obsolete or compromised
`obsolete state by sending or receiving a DSM.
`
`initialization vector (IV): A number
`2.1.32
`used as a starting point for the encryption of a data
`sequence in order to increase security by introduc(cid:173)
`ing additional cryptographic variance and to syn(cid:173)
`chronize cryptographic equipment.
`
`interoperability: The ability
`2.1.33
`to ex(cid:173)
`change keys, both manually and in an automated
`environment, with any other party implementing
`this standard, providing that both implementations
`use compatible options of this standard and com(cid:173)
`patible communications facilities.
`
`2.1.34
`
`key: See cryptographic key.
`
`IPR2018-00067
`Unified EX1016 Page 16
`
`

`

`key component: One of at least two
`2.1.35
`parameters having the format of a cryptographic
`key that is exclusive-or'ed with one or more like
`parameters to form a cryptographic key.
`
`key encrypting key {KK): A key used
`2.1.36
`exclusively to encrypt and decrypt keys.
`
`key exchange transaction: A set of
`2.1.37
`CSMs used to transport keys.
`
`key generator: A device, including as(cid:173)
`2.1.38
`sociated alarms and self-tests,
`for generating
`cryptographic keys (and where needed, IVs).
`
`key loader: An electronic, self contained
`2.1.39
`unit which is capable of storing at least one key
`and transferring that key, upon request, into cryp(cid:173)
`tographic modules.
`
`key management facility: The physi(cid:173)
`2.1.40
`cally protected enclosure (e.g., room or device)
`and its contents where cryptographic elements
`(i