TIA-102 AACA-1-2002 Project 25 over-the-Rekeying (OTAR) Protocol Addendum 1 - Key Management Security Requirements for Type 3 Block Encryption Algorithms Addendum No 1 to TIA EIA-1.pdf

《TIA-102 AACA-1-2002 Project 25 over-the-Rekeying (OTAR) Protocol Addendum 1 - Key Management Security Requirements for Type 3 Block Encryption Algorithms Addendum No 1 to TIA EIA-1.pdf》由会员分享，可在线阅读，更多相关《TIA-102 AACA-1-2002 Project 25 over-the-Rekeying (OTAR) Protocol Addendum 1 - Key Management Security Requirements for Type 3 Block Encryption Algorithms Addendum No 1 to TIA EIA-1.pdf（36页珍藏版）》请在麦多课文档分享上搜索。

1、 TIA STANDARD ANSI/TIA-102.AACA-1-2002 Approved: November 27, 2002 Project 25 - Digital Radio Over-the-Air-Rekeying (OTAR) Protocol Addendum 1 Key Management Security Requirements for Type 3 Block Encryption Algorithms TIA-102.AACA-1 (Addendum No. 1 to TIA/EIA-102.AACA) NOVEMBER 2002 TELECOMMUNICATI

2、ONS INDUSTRY ASSOCIATION Representing the telecommunications industry in association with the Electronic Industries Alliance Copyright Electronic Industries Alliance Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-NOTICE TIA En

3、gineering Standards and Publications are designed to serve the public interest through eliminating misunderstandings between manufacturers and purchasers, facilitating interchangeability and improvement of products, and assisting the purchaser in selecting and obtaining with minimum delay the proper

4、 product for their particular need. The existence of such Standards and Publications shall not in any respect preclude any member or non-member of TIA from manufacturing or selling products not conforming to such Standards and Publications. Neither shall the existence of such Standards and Publicati

5、ons preclude their voluntary use by Non-TIA members, either domestically or internationally. Standards and Publications are adopted by TIA in accordance with the American National Standards Institute (ANSI) patent policy. By such action, TIA does not assume any liability to any patent owner, nor doe

6、s it assume any obligation whatever to parties adopting the Standard or Publication. This Standard does not purport to address all safety problems associated with its use or all applicable regulatory requirements. It is the responsibility of the user of this Standard to establish appropriate safety

7、and health practices and to determine the applicability of regulatory limitations before its use. (From Standards Proposal No. 3-4824-AD1, formulated under the cognizance of the TIA TR-8.3 Subcommittee on Encryption.) Published by TELECOMMUNICATIONS INDUSTRY ASSOCIATION 2002 Standards and Technology

8、 Department 2500 Wilson Boulevard Arlington, VA 22201 U.S.A. PRICE: Please refer to current Catalog of TIA TELECOMMUNICATIONS INDUSTRY ASSOCIATION STANDARDS AND ENGINEERING PUBLICATIONS or call Global Engineering Documents, USA and Canada (1-800-854-7179) International (303-397-7956) or search onlin

9、e at http:/www.tiaonline.org/standards/search_n_order.cfm All rights reserved Printed in U.S.A. Copyright Electronic Industries Alliance Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-PLEASE! DONT VIOLATE THE LAW! This documen

10、t is copyrighted by the TIA and may not be reproduced without permission. Organizations may obtain permission to reproduce a limited number of copies through entering into a license agreement. For information, contact: Global Engineering Documents 15 Inverness Way East Englewood, CO 80112-5704 U.S.A

11、. or call U.S.A. and Canada 1-800-854-7179, International (303) 397-7956 Copyright Electronic Industries Alliance Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-NOTICE OF DISCLAIMER AND LIMITATION OF LIABILITY The document to

12、which this Notice is affixed has been prepared by one or more Engineering Committees of the Telecommunications Industry Association (“TIA”). TIA is not the author of the document contents, but publishes and claims copyright to the document pursuant to licenses and permission granted by the authors o

13、f the contents. TIA Engineering Committees are expected to conduct their affairs in accordance with the TIA Engineering Manual (“Manual”), the current and predecessor versions of which are available at http:/www.tiaonline.org/standards/sfg/engineering_manual.cfm. TIAs function is to administer the p

14、rocess, but not the content, of document preparation in accordance with the Manual and, when appropriate, the policies and procedures of the American National Standards Institute (“ANSI”). THE USE OR PRACTICE OF CONTENTS OF THIS DOCUMENT MAY INVOLVE THE USE OF INTELLECTUAL PROPERTY RIGHTS (“IPR”), I

15、NCLUDING PENDING OR ISSUED PATENTS, OR COPYRIGHTS, OWNED BY ONE OR MORE PARTIES. TIA MAKES NO SEARCH OR INVESTIGATION FOR IPR. WHEN IPR CONSISTING OF PATENTS AND PUBLISHED PATENT APPLICATIONS ARE CLAIMED AND CALLED TO TIAS ATTENTION, A STATEMENT FROM THE HOLDER THEREOF IS REQUESTED, ALL IN ACCORDANC

16、E WITH THE MANUAL. TIA TAKES NO POSITION WITH REFERENCE TO, AND DISCLAIMS ANY OBLIGATION TO INVESTIGATE OR INQUIRE INTO, THE SCOPE OR VALIDITY OF ANY CLAIMS OF IPR. ALL WARRANTIES, EXPRESS OR IMPLIED, ARE DISCLAIMED, INCLUDING WITHOUT LIMITATION, ANY AND ALL WARRANTIES CONCERNING THE ACCURACY OF THE

17、 CONTENTS, ITS FITNESS OR APPROPRIATENESS FOR A PARTICULAR PURPOSE OR USE, ITS MERCHANTABILITY AND ITS NON-INFRINGEMENT OF ANY THIRD PARTYS INTELLECTUAL PROPERTY RIGHTS. TIA EXPRESSLY DISCLAIMS ANY AND ALL RESPONSIBILITIES FOR THE ACCURACY OF THE CONTENTS AND MAKES NO REPRESENTATIONS OR WARRANTIES R

18、EGARDING THE CONTENTS COMPLIANCE WITH ANY APPLICABLE STATUTE, RULE OR REGULATION. TIA SHALL NOT BE LIABLE FOR ANY AND ALL DAMAGES, DIRECT OR INDIRECT, ARISING FROM OR RELATING TO ANY USE OF THE CONTENTS CONTAINED HEREIN, INCLUDING WITHOUT LIMITATION ANY AND ALL INDIRECT, SPECIAL, INCIDENTAL OR CONSE

19、QUENTIAL DAMAGES (INCLUDING DAMAGES FOR LOSS OF BUSINESS, LOSS OF PROFITS, LITIGATION, OR THE LIKE), WHETHER BASED UPON BREACH OF CONTRACT, BREACH OF WARRANTY, TORT (INCLUDING NEGLIGENCE), PRODUCT LIABILITY OR OTHERWISE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. THE FOREGOING NEGATION OF D

20、AMAGES IS A FUNDAMENTAL ELEMENT OF THE USE OF THE CONTENTS HEREOF, AND THESE CONTENTS WOULD NOT BE PUBLISHED BY TIA WITHOUT SUCH LIMITATIONS. Copyright Electronic Industries Alliance Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-

21、,-,-TIA-102.AACA - 1 1 ADDENDUM 1 KEY MANAGEMENT SECURITY REQUIREMENTS FOR TYPE 3 BLOCK ENCRYPTION ALGORITHMS 1 Introduction This addendum specifies the general security requirements to be used when transmitting Type 3 Key Management Messages (KMMs) as defined in the Over The Air Rekeying (OTAR) Pro

22、tocol document (reference 1). It also specifies the requirements to encrypt (wrap) Type 3 keys when sent as part of a KMM, the techniques to be used to protect the integrity of KMMs and the mechanism used to protect against the replay of KMMs. The addendum provides support for Triple DES and AES but

23、 is not limited to those algorithms. This addendum is designed to support all block encryption algorithms that have a block size that is a multiple of 2 octets except for DES. The requirements for DES are specified in Annex D of the OTAR Protocol document (reference 1). 2 Revision History Version 0.

24、0, December 20, 2001, first draft. Version 0.1, January 10, 2002, modified key encryption requirements and defined Enhanced MAC frame. Version 0.2, January 11, 2002, fixed typographical errors. Version 0.3, April 3, 2002, modified last paragraph in section 5.3, modified sections 5.4.2 and 5.4.3, fix

25、ed typographical errors. Version 0.4, April 5, 2002, clarified which fields are used in the MAC calculation (section 5.4), fixed additional typographical errors. SP-3-4824-AD1, May 6, 2002, ballot version with example data. TIA/EIA 102.AACA-1, October 4, 2002, modified for minor editorial comments f

26、rom ballot resolution. 3 References The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this

27、Standard are encouraged to investigate the possibility of applying the most recent editions of the standards indicated below. ANSI and TIA maintain registers of currently valid national standards published by them. Copyright Electronic Industries Alliance Provided by IHS under license with EIANot fo

28、r ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-102.AACA - 1 2 1. Project 25 Digital Radio Over The Air Rekeying (OTAR) Protocol, TIA/EIA-102.AACA, April 2001 2. Project 25 Common Air Interface Reserved Values, TIA/EIA-102.BAAC, May 2000 3. Project 25 DES Encryption

29、Protocol, TIA/EIA-102.AAAA, February 2001 4. Project 25 Block Encryption Protocol, TIA/EIA-102.AAAD, July 2002 5. Data Encryption Standard, NIST, FIPS Publication 46-3, October 15, 1999 6. DES Modes of Operation, NIST, FIPS Publication 81, December 2, 1980 7. Data Encryption Algorithm, ANSI, ANSI X3

30、.92 - 1981 8. Data Encryption Algorithm - Modes of Operation, ANSI, ANSI X3.106 1983 9. Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52 1998, July 29, 1998 10. Advanced Encryption Standard, FIPS Publication 197, November 26, 2001 11. Recommendation for Block Cipher Modes of Operation

31、 Methods and Techniques, NIST Special Publication 800-38A, December 2001 12. AES Key Wrap Specification, NIST, http:/csrc.nist.gov/encryption/kms, November 16, 2001 4 Abbreviations AES Advanced Encryption Standard ANSI American National Standards Institute CAI Common Air Interface CIPHK Forward ciph

32、er function (encryption) using key K CIPH-1K Inverse cipher function (decryption) using key K CBC-MAC Cipher Block Chaining-Message Authentication Code CS CheckSum DES Data Encryption Standard ECB Electronic CodeBook mode of operation FIPS Federal Information Processing Standards IV Initialization V

33、ector KEK Key Encryption Key KMF Key Management Facility KMM Key Management Message LSB Least Significant Bit MAC Message Authentication Code MN Message Number MNL Last Message Number MNP Message Number Period MNR Message Number Received MR Mobile Radio MSB Most Significant Bit OFB Output FeedBack m

34、ode of operation OTAR Over-The-Air Rekeying RSI Radio Set Identifier TDEA Triple Data Encryption Algorithm TEK Traffic Encryption Key Copyright Electronic Industries Alliance Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-

35、102.AACA - 1 3 5 Encryption Modes The specification defined in this Addendum requires that an n-bit symmetric block encryption algorithm be used, where n is defined as the block size. It also requires that the block size be an integer multiple of 2 octets (n modulo 16 = 0). An n-bit algorithm shall

36、consist of an n-bit input register, a cipher function that operates on the n-bit input using a k-bit key variable, denoted as K, to produce an n-bit output result and an n-bit output register. The key variable may be any size of k bits. The cipher function typically consists of permutations and non-

37、linear substitutions done in multiple rounds controlled by the key variable. The block encryption algorithm typically consists of an encryption and a decryption function that are inverses of each other. Encryption is the transformation of a usable message, called the plaintext, into an unreadable fo

38、rm, called the ciphertext. Decryption is the transformation that recovers the plaintext from the ciphertext. For any given key, K, the underlying block encryption algorithm consists of two functions that are inverses of each other. The encryption function will be denoted CIPHK and the decryption fun

39、ction will be denoted as CIPH-1K. Key Management Messages use two modes of operation in addition to the Output feedback (OFB) mode as defined in the Block Encryption Protocol (reference 4). Electronic Codebook (ECB) is used by the key wrap algorithm to encrypt keys and Cipher Block Chaining - Messag

40、e Authentication Code (CBC-MAC) is used to authenticate the message. These two modes of operation are described in the following sections. The following parameters are defined for the encryption of the key frame and for the authentication of a Key Management Message (KMM). A key frame contains the k

41、ey variable and pad bits as required. The KMM includes the message and any required pad octets. K = the key used to encrypt (or decrypt) the plaintext (ciphertext), the Key Encryption Key n = number of bits in the encryption algorithm block k = number of bits in the key variable (including the parit

42、y/CRC bits) x = number of n/2-bit blocks required to encrypt the key variable = ceiling2*k/n r = number of pad bits required to expand the length of the key variable to an integer multiple n/2-bit blocks = (x * n/2) k t = number of bits in the MAC field L = number of octets in the key or message blo

43、ck = (x+1) * n/2 m# = specifies one of the octets in the encryption algorithm block 0 = n/2) MAC Length+1 Algorithm ID MAC Length+2 Key ID MAC Length+3 7 6 5 4 3 2 1 0 MAC Message Body Format MAC The MAC field contains the output of the Message Authentication procedure as shown in Figure 5.4.1. The

44、first octet in the MAC field shall contain the first octet of the MAC. The second octet in the MAC field shall contain the second octet of the MAC. This process will continue for the number of octets as defined by the MAC Length field. MAC Length An 8-bit binary number used to indicate the number of

45、 octets in the MAC field. Algorithm ID - The Algorithm ID is used in conjunction with the Key ID to uniquely select the key used to authenticate the message. These fields are used to select the TEK used to generate the MAC key if the Derived Key bit is set. The format for this field is defined in th

46、e Primitive Field Definition section for Algorithm ID in Annex B (reference 1). Key ID - The Key ID is used in conjunction with the Algorithm ID to uniquely select the key used to authenticate the message. These fields are used to select the TEK used to generate the MAC key if the Derived Key bit is

47、 set. The format for this field is defined in the Primitive Field Definition section for Key ID in Annex B (reference 1). Copyright Electronic Industries Alliance Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-102.AACA - 1

48、 17 5.5 Key Updating Key updating will not be supported by Type 3 encryption. Copyright Electronic Industries Alliance Provided by IHS under license with EIANot for ResaleNo reproduction or networking permitted without license from IHS-,-,-TIA-102.AACA - 1 18 5.6 Public Key Messages This section def

49、ines the Composite and Primitive field definitions for Public Key messages which are classified for Type 1 encryption and could not be described in the unclassified Annex B of Reference 1. Public Key is currently not supported by Type 3 encryption. Therefore, the Public Key message fields are not defined in Reference 1 for Type 3 encryption. The following sections are included here since they are referenced in Annex B for Typ