ANSI ASC X9 X9.69-2007 Framework for Key Management Extensions.pdf

1、American National Standard for Financial Services ANSI X9.692006 Framework for Key Management Extensions Accredited Standards Committee X9, Incorporated Financial Industry Standards Date Approved: American National Standards Institute ASC X9, Inc. 2006 All rights reserved ANS ANSI X9.692006 2 ASC X9

2、, Inc. 2006 All rights reservedContents Page Forword .4 Introduction.5 1 Scope17 2 Normative references17 3 Terms, symbols and abbreviated terms17 4 Application .18 4.1 General .18 4.2 The Use of Constructive Key Management 19 4.3 The Use of Key Usage Control Vector.19 4.4 System Algorithm and Syste

3、m Key.19 5 Constructive Key Management19 5.1 Overview.19 5.2 CKM Administration 21 5.2.1 Credentials .21 5.2.2 Splits.21 5.3 Token Distribution.22 5.3.1 Workstation22 5.3.2 Token 22 5.4 Key Creation.22 5.4.1 Key Component Selection23 5.4.2 Key Combiner 23 5.4.3 Key Reconstruction.23 6 Key Usage Cont

4、rol 24 6.1 Overview.24 6.2 Key Binding Methods25 6.2.1 Binding Method 1 25 6.2.2 Binding Method 2 25 6.2.3 Binding Method 3 26 6.2.4 Binding Method 4 26 6.2.5 Binding Method 5 27 6.2.6 Binding Method 6 27 Annex A (informative) Example Key Usage Vector Formats 28 A.1 General .28 A.2 Examples28 Biblio

5、graphy31 ANS ANSI X9.692006 ASC X9, Inc. 2006 All rights reserved 3Figures Figure 1 - Token Distribution 20 Figure 2 - Combiner Function.23 Figure 3 - Key Usage Vector Fields25 ANS ANSI X9.692006 4 ASC X9, Inc. 2006 All rights reservedForword Approval of an American National Standard requires verifi

6、cation by ANSI that the requirements for due process, consensus, and other criteria for approval have been met by the standards developer. Consensus is established when, in the judgment of the ANSI Board of Standards Review, substantial agreement has been reached by directly and materially affected

7、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 e

8、xistence 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 c

9、ircumstances 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 interpretation should be addressed to the se

10、cretariat 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

11、 no later than five years from the date of approval. Published by Accredited Standards Committee X9, Incorporated Financial Industry Standards P.O. Box 4035 Annapolis, MD 21403 USA X9 Online http:/www.x9.org Copyright 2006 ASC X9, Inc. All rights reserved. No part of this publication may be reproduc

12、ed in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Published in the United States of America. ANS ANSI X9.692006 ASC X9, Inc. 2006 All rights reserved 5Introduction This Standard is concerned with symmetric key systems in which the encr

13、ypting key and decrypting key are identical. The security and reliability of any process based on a symmetric cryptographic algorithm is directly dependent on the protection afforded to the secret quantity, called the key. Thus, no matter how strong the algorithm, the system is only as secure as its

14、 key management method. This Standard defines two specific key management methods for controlling and handling keys, called (1) Constructive Key Management and (2) Key Usage Control. Each method can be used independently; or the methods can be used in combination. However, the combined use of the me

15、thods is highly recommended by the ASC X9 Subcommittee responsible for this Standard. Each method is described in a separate section of the Standard. The section on CONSTRUCTIVE KEY MANAGEMENT, systematizes key creation, implementing “dual control” or “split knowledge” by using key components to con

16、struct the final working key. This working key may be used in several ways including as a session key, for a store-and-forward (i.e. e-mail) application, and for file encryption applications, such as archiving, or protecting filed information until needed again by the user. Other applications are al

17、so possible. Until now, this practice of split knowledge key creation has been used mainly to transport key parts into systems where “master keys” were used to protect keys in storage, and to recover the working keys for a current application. With the methodology of this Standard, a working key wil

18、l be created as needed for a specific encryption process, and re-created when needed to decrypt the object. Depending on the application, the key may be saved or destroyed after each use. The working key is never transmitted; the application program only knows it while it is in use. The section on K

19、EY USAGE CONTROL, allows the creator of a key to specify the allowed uses of the key. For example, key usage control information can be used to distinguish key types (data, PIN, or key-encrypting). The type “data key” can be further sub-divided to distinguish data privacy keyskeys used to encrypt an

20、d decrypt datafrom Message Authentication Code (MAC) keys-keys used to protect the integrity of data. The method attaches or binds a “key usage vector” to each generated key, for the life of the key, and is used by the system to ensure that keys are used properly. In short, the key usage vector prev

21、ents abuses and attacks against the key. The key usage vector can be used to protect keys stored within a single system, or to protect keys transmitted from one system to another. This Standard is algorithm independent, and as new cryptographic algorithms with perhaps longer key lengths than current

22、ly in use are developed and adopted by the Financial Community this Standard will still apply. NOTE The users attention is called to the possibility that compliance with this standard may require use of an invention covered by patent rights. By publication of this standard, no position is taken with

23、 respect to the validity of this claim or of any patent rights in connection therewith. The patent holder has, 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. Det

24、ails may be obtained from the standards developer. 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, P.O. Box 4035, Annapolis, MD 21403 USA. This Standa

25、rd 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. ANS ANSI X9.692006 6 ASC X9, Inc. 2006 All rights reservedThe X9 c

26、ommittee had the following members: Jim Schaffer, X9 Chairman Vincent DeSantis, X9 Vice-Chairman Cynthia Fuller, Executive Director Susan Yashinskie, Managing Director Organization Represented RepresentativeAmerican Bankers Association C. Diane Poole American Express Company John Allen American Fina

27、ncial Services Association Mark Zalewski Bank of America Daniel Welch Certicom Corporation Daniel Brown Citigroup, Inc. Gary Word Clarke American Checks, Inc. John McCleary CUSIP Service Bureau James Taylor Deluxe Corporation John FitzPatrick Diebold, Inc. Bruce Chapa Discover Financial Services Kat

28、ie Howser Federal Reserve Bank Dexter Holt First Data Corporation Rick Van Luvender Fiserv Skip Smith FSTC, Financial Services Technology Consortium Daniel Schutzer Hewlett Packard Larry Hines Hypercom Scott SpikerIBM Corporation Todd Arnold Ingenico John Spence Intuit, Inc. Jana Hocker J.P. Morgan

29、Chase refer to Technical Guideline: Technical Guideline: Managing Risk and Migration Planning: Withdrawal of ANSI X9.9 (X9 TG-24-1999) X9.17 Financial Institution Key Management (Wholesale); refer to Technical Guideline: Managing Risk and Migration Planning: Withdrawal of ANSI X9.17 (X9 TG-26 1999)

30、C. The follow terms were changed: Policy Manager was changed to CKM Administration Labels was changed to Credentials ANS ANSI X9.692006 12 ASC X9, Inc. 2006 All rights reserved Credential Manager was changed to Token Distribution D. The document was converted to the current X9/ISO standards template

31、. At the time the original X9.69-1999 was approved, the X9 committee had the following members: Harold Deal, X9 Chairman William E. Lyons, X9 Vice Chairman Cynthia Fuller, Managing Director Organization Represented RepresentativeAmerican Bankers Association Anne Livingston Kawika Daguio American Exp

32、ress Company Bonnie Howard Applied Communications Douglas Grote Cindy Rink Automated Financial Services Tom Clute Banc One Services Corporation William Lyons Bank of America Gretchen Breiling Bankers Roundtable Kit Needlam Keviar Warner Canadian Bankers Association Christine ArjoonLaL Mark Bakic Cha

33、se Manhattan Bank Christopher Dowdell Francis Keenan Citibank Seymour Rosen Cybersafe Corp Glenda Barnes Deluxe Corporation Maury Jansen Ernst See for example ANSI X9.24 Financial Institution Key Management (Retail), or ISO/IEC 11770-2, Key Management, Part 2: Mechanisms using symmetric techniques.

34、Mechanisms to store, archive, delete, destroy, etc. keys; Mechanisms for key recovery in the event of the failure or loss of keys. The Standard also does not define the implementation of key management mechanisms; there may be different products that comply with this Standard and yet are not interop

35、erable. 2 Normative references The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ANS X3.92-1981 Dat

36、a Encryption Algorithm ANS X3.106-1983 Data Encryption Algorithm - Modes of Operation ANS X9.19 Financial Institution Retail Message Authentication ANS X9.52 Triple Data Encryption Algorithms (3DEA) Modes of Operation FIPS 197 Advanced Encryption Standard (AES) 3 Terms, symbols and abbreviated terms

37、 For the purposes of this document, the following terms and definitions apply. ANS ANSI X9.692006 18 ASC X9, Inc. 2006 All rights reserved3.1 3DEA Triple Data Encryption Algorithm 3.2 AES Advanced Encryption Standard 3.3 C Key Usage Control Vector 3.4 CBC Cipher Block Chaining - one of the four mode

38、s of 3DEA 3.5 CKM Constructive Key Management 3.6 ECB Electronic Codebook - one of the four modes of 3DEA 3.7 K Key 3.8 MAC Message Authentication Code 3.9 PIN Personal Identification Number 3.10 PR Private (secret) key of a public key encryption algorithm 3.11 PU Public (non-secret) key of a public

39、 key encryption algorithm 3.12 S Cryptographic Services and Modes provided in the Key Management System 3.13 SMIB Security Management Information Base 3.14 U Usage Field; a binary vector where the bit field specifies the use(s) for each key 4 Application 4.1 General In a cryptographic system it may

40、be desirable to generate keys using a constructive process, where keys are derived from system-specified control information, as well as secret random data. It may also be desirable to attach a “key usage vector” to each key, defining how the key shall be used. ANS ANSI X9.692006 ASC X9, Inc. 2006 A

41、ll rights reserved 194.2 The Use of Constructive Key Management With Constructive Key Management (CKM), key components, called splits, shall be generated with a random or pseudorandom number generator. Each of these splits shall be given a name, called a Credential that provides some meaningful info

42、rmation to the sender, and allows the sender to direct the encrypted object to a selected set of end-users. The working key shall be constructed by combining the addressee splits with the system generated and controlled splits. Thus, with CKM it is possible to create a group key for a particular set

43、 of end-users. Other recipients, who are not members of the group, will be unable to re-construct that particular group key. 4.3 The Use of Key Usage Control Vector With Key Usage Control Vectors, keys shall be generated using any acceptable method of key generation. Then a key usage vector shall be

44、 attached to the key. This vector specifies cryptographic services, modes and key parameters, in which the associated key shall be used. This usage vector shall be securely bound to the key to prevent misuse of the key or misinterpretation of its use. 4.4 System Algorithm and System Key The CKM oper

45、ations system shall use a common system-wide encryption algorithm and key to wrap the header of encrypted objects as they transit communications networks. The purpose is privacy, not security. For example, when multiple objects are sent in a batch mode, recipients need to be able to unwrap the bundl

46、e and determine from the encrypted header information which object(s) is addressed to them. Security is not compromised because the objects themselves are encrypted using secret splits that only the addressees of each object possess. 5 Constructive Key Management 5.1 Overview Constructive Key Manage

47、ment is exactly what the name implies: key is constructed as needed by the originator of the message, and can only be re-constructed by intended recipients. In the interim, Credentials of the key components are associated with the encrypted object. For example, in an e-mail message, they might be pa

48、ssed, encrypted under a system key in the message header (depending on the protocol). In a session-oriented protocol, they might be exchanged as part of the key management protocol, and stored locally in the security management information base (SMIB). This means the encrypting key is always fully r

49、ecoverable and the message is always decryptable by the appropriate audience. There are two major administrative functions required to manage the CKM system: the CKM Administration (see 5.2 CKM Administration) and the Token Distribution (see 5.3 Token Distribution). In large organizations, these could be independent of each other. The CKM Administration function shall design the overall interconnectivity and read-write privileges in the system, and create the Credentials and splits. The Token Distribution function shall