ETSI TS 133 105-2017 Universal Mobile Telecommunications System (UMTS) LTE 3G Security Cryptographic algorithm requirements (V14 0 0 3GPP TS 33 105 version 14 0 0 Release 14)《通用移动通.pdf

1、 ETSI TS 133 105 V14.0.0 (2017-04) Universal Mobile Telecommunications System (UMTS); LTE; 3G Security; Cryptographic algorithm requirements (3GPP TS 33.105 version 14.0.0 Release 14) TECHNICAL SPECIFICATION ETSI ETSI TS 133 105 V14.0.0 (2017-04)13GPP TS 33.105 version 14.0.0 Release 14Reference RTS

2、/TSGS-0333105ve00 Keywords LTE,SECURITY,UMTS ETSI 650 Route des Lucioles F-06921 Sophia Antipolis Cedex - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Siret N 348 623 562 00017 - NAF 742 C Association but non lucratif enregistre la Sous-Prfecture de Grasse (06) N 7803/88 Important notice Th

3、e present document can be downloaded from: http:/www.etsi.org/standards-search The present document may be made available in electronic versions and/or in print. The content of any electronic and/or print versions of the present document shall not be modified without the prior written authorization

4、of ETSI. In case of any existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat. Users of the present document should be aware

5、that the document may be subject to revision or change of status. Information on the current status of this and other ETSI documents is available at https:/portal.etsi.org/TB/ETSIDeliverableStatus.aspx If you find errors in the present document, please send your comment to one of the following servi

6、ces: https:/portal.etsi.org/People/CommiteeSupportStaff.aspx Copyright Notification No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and microfilm except as authorized by written permission of ETSI. The content of the PDF version sha

7、ll not be modified without the written authorization of ETSI. The copyright and the foregoing restriction extend to reproduction in all media. European Telecommunications Standards Institute 2017. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered fo

8、r the benefit of its Members. 3GPPTM and LTE are Trade Marks of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. oneM2M logo is protected for the benefit of its Members GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI

9、TS 133 105 V14.0.0 (2017-04)23GPP TS 33.105 version 14.0.0 Release 14Intellectual Property Rights IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non

10、-members, and can be found in ETSI SR 000 314: “Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards“, which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (https:/ipr.etsi.org/). Pur

11、suant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present do

12、cument. Foreword This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being reference

13、s to the corresponding ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http:/webapp.etsi.org/key/queryform.asp. Modal verbs terminology In the present document “shall“, “shall not“, “should“, “should not“, “may“, “need not“, “will“, “will not“, “

14、can“ and “cannot“ are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions). “must“ and “must not“ are NOT allowed in ETSI deliverables except when used in direct citation. ETSI ETSI TS 133 105 V14.0.0 (2017-04)33GPP TS 33.105 version

15、 14.0.0 Release 14Contents Intellectual Property Rights 2g3Foreword . 2g3Modal verbs terminology 2g3Foreword . 5g31 Scope 6g32 References 6g33 Definitions, symbols, abbreviations and conventions 6g33.1 Definitions 6g33.2 Symbols 7g33.3 Abbreviations . 7g33.4 Conventions 7g34 General algorithm requir

16、ements . 8g34.1 Resilience . 8g34.2 World-wide availability and use . 8g35 Functional algorithm requirements 8g35.1 Authentication and key agreement . 8g35.1.1 Overview 8g35.1.1.1 Generation of quintets in the AuC 8g35.1.1.2 Authentication and key derivation in the USIM 9g35.1.1.3 Generation of re-s

17、ynchronisation token in the USIM . 9g35.1.1.4 Re-synchronisation in the HLR/AuC 10g35.1.2 Use 10g35.1.3 Allocation . 10g35.1.4 Extent of standardisation 11g35.1.5 Implementation and operational considerations 11g35.1.6 Type of algorithm . 11g35.1.6.1 f0 . 11g35.1.6.2 f1 . 11g35.1.6.3 f1* . 11g35.1.6

18、.4 f2 . 11g35.1.6.5 f3 . 11g35.1.6.6 f4 . 12g35.1.6.7 f5 . 12g35.1.6.8 f5* . 12g35.1.7 Interface 12g35.1.7.1 K 12g35.1.7.2 RAND . 12g35.1.7.3 SQN. 12g35.1.7.4 AMF 13g35.1.7.6 MAC-A (equivalent for XMAC-A) 13g35.1.7.7 MAC-S (equivalent for XMAC-S) 13g35.1.7.8 RES (or XRES) . 13g35.1.7.9 CK . 13g35.1.

19、7.10 IK 13g35.1.7.11 AK . 14g35.2 Data confidentiality 14g35.2.1 Overview 14g35.2.2 Use 14g35.2.3 Allocation . 15g35.2.4 Extent of standardisation 15g35.2.5 Implementation and operational considerations 15g35.2.6 Type of algorithm . 15g35.2.7 Interfaces to the algorithm 16g3ETSI ETSI TS 133 105 V14.

20、0.0 (2017-04)43GPP TS 33.105 version 14.0.0 Release 145.2.7.1 CK . 16g35.2.7.2 COUNT-C . 16g35.2.7.3 BEARER. 16g35.2.7.4 DIRECTION . 16g35.2.7.5 LENGTH . 17g35.2.7.6 KEYSTREAM 17g35.2.7.7 PLAINTEXT . 17g35.2.7.8 CIPHERTEXT 17g35.3 Data integrity 18g35.3.1 Overview 18g35.3.2 Use 18g35.3.3 Allocation

21、. 18g35.3.4 Extent of standardisation 18g35.3.5 Implementation and operational considerations 18g35.3.6 Type of algorithm . 18g35.3.7 Interface 19g35.3.7.1 IK 19g35.3.7.2 COUNT-I 19g35.3.7.3 FRESH 19g35.3.7.4 MESSAGE 19g35.3.7.5 DIRECTION . 19g35.3.7.6 MAC-I (and equivalently XMAC-I) . 19g36 Use of

22、the algorithm specifications 20g36.1 Ownership 20g36.2 Design authority . 20g36.3 Users of the specification . 20g36.4 Licensing 20g36.5 Management of the specification 20g37 Algorithm specification and test data requirements . 20g37.1 Specification of the algorithm 21g37.2 Implementors test data 21

23、g37.3 Design conformance test data . 21g37.4 Format and handling of deliverables 21g38 Quality assurance requirements 21g38.1 Quality assurance for the algorithm . 21g38.2 Quality assurance for the specification and test data 22g38.3 Design and evaluation report 22g39 Summary of the design authority

24、 deliverables . 22g3Annex A (informative): Void . 23g3Annex B (informative): Change history . 24g3History 25g3ETSI ETSI TS 133 105 V14.0.0 (2017-04)53GPP TS 33.105 version 14.0.0 Release 14Foreword This Technical Specification has been produced by the 3rdGeneration Partnership Project (3GPP). The co

25、ntents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as fol

26、lows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc

27、. z the third digit is incremented when editorial only changes have been incorporated in the document. ETSI ETSI TS 133 105 V14.0.0 (2017-04)63GPP TS 33.105 version 14.0.0 Release 141 Scope This specification constitutes a requirements specification for the security functions which may be used to pr

28、ovide the network access security features defined in 1. The specification covers the intended use of the functions, the technical requirements on the functions and the requirements as regards standardization. For those functions that require standardization, it also covers the intended use of the a

29、lgorithm specification, the requirements on test data, and quality assurance requirements on both the algorithm and its documentation. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either

30、 specific (identified by date of publication, edition number, version number, etc.) or non-specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a

31、non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. 1 3G TS 33.102: “3rd Generation Partnership Project (3GPP); Technical Specification Group (TSG) SA; 3G Security; Security Architecture“. 2 Wassenaar Arrangement, December 1998

32、. 3 ISO/IEC 9797: “Information technology - Security techniques - Data integrity mechanism using a cryptographic check function employing a block cipher algorithm“. 3 Definitions, symbols, abbreviations and conventions 3.1 Definitions For the purposes of the present document, the following definitio

33、ns apply: Confidentiality: The property that information is not made available or disclosed to unauthorised individuals, entities or processes. Data integrity: The property that data has not been altered in an unauthorised manner. Data origin authentication: The corroboration that the source of data

34、 received is as claimed. Entity authentication: The provision of assurance of the claimed identity of an entity. Key freshness: A key is fresh if it can be guaranteed to be new, as opposed to an old key being reused through actions of either an adversary or authorised party. ETSI ETSI TS 133 105 V14

35、.0.0 (2017-04)73GPP TS 33.105 version 14.0.0 Release 143.2 Symbols For the purposes of the present document, the following symbols apply: | Concatenation Exclusive or f0 random challenge generating function f1 network authentication function f1* the re-synchronisation message authentication function

36、; f2 user authentication function f3 cipher key derivation function f4 integrity key derivation function f5 anonymity key derivation function for normal operation f5* anonymity key derivation function for re-synchronisation f8 UMTS encryption algorithm f9 UMTS integrity algorithm 3.3 Abbreviations F

37、or the purposes of the present document, the following abbreviations apply: 3GPP 3rd Generation Partnership Project AK Anonymity key AuC Authentication Centre AUTN Authentication token COUNT-C Time variant parameter for synchronisation of ciphering COUNT-I Time variant parameter for synchronisation

38、of data integrity CK Cipher key IK Integrity key IMSI International Mobile Subscriber Identity IPR Intellectual Property Right MAC Medium access control (sublayer of Layer 2 in RAN) MAC Message authentication code MAC-A MAC used for authentication and key agreement MAC-I MAC used for data integrity

39、of signalling messages PDU Protocol data unit RAND Random challenge RES User response RLC Radio link control (sublayer of Layer 2 in RAN) RNC Radio network controller SDU Signalling data unit SQN Sequence numberUE User equipment USIM User Services Identity Module XMAC-A Expected MAC used for authent

40、ication and key agreement XMAC-I Expected MAC used for data integrity of signalling messages XRES Expected user response 3.4 Conventions All data variables in this specification are presented with the most significant substring on the left hand side and the least significant substring on the right h

41、and side. A substring may be a bit, byte or other arbitrary length bitstring. Where a variable is broken down into a number of substrings, the leftmost (most significant) substring is numbered 0, the next most significant is numbered 1, and so on through to the least significant. ETSI ETSI TS 133 10

42、5 V14.0.0 (2017-04)83GPP TS 33.105 version 14.0.0 Release 144 General algorithm requirements 4.1 Resilience The functions should be designed with a view to its continued use for a period of at least 20 years. Successful attacks with a work load significantly less than exhaustive key search through t

43、he effective key space should be impossible. The designers of above functions should design algorithms to a strength that reflects the above qualitative requirements. 4.2 World-wide availability and use Legal restrictions on the use or export of equipment containing cryptographic functions may preve

44、nt the use of such equipment in certain countries. It is the intention that UE and USIMs which embody such algorithms should be free from restrictions on export or use, in order to allow the free circulation of 3G terminals. Network equipment, including RNC and AuC, may be expected to come under mor

45、e stringent restrictions. It is the intention is that RNC and AuC which embody such algorithms should be exportable under the conditions of the Wassenaar Arrangement 2. 5 Functional algorithm requirements 5.1 Authentication and key agreement 5.1.1 Overview The mechanism for authentication and key ag

46、reement described in clause 6.3 of 1 requires the following cryptographic functions: f0 the random challenge generating function; f1 the network authentication function; f1* the re-synchronisation message authentication function; f2 the user authentication function; f3 the cipher key derivation func

47、tion; f4 the integrity key derivation function; f5 the anonymity key derivation function for normal operation; f5* the anonymity key derivation function for re-synchronisation. 5.1.1.1 Generation of quintets in the AuC To generate a quintet the HLR/AuC: - computes a message authentication code for a

48、uthentication MAC-A = f1K(SQN | RAND | AMF), an expected response XRES = f2K(RAND), a cipher key CK = f3K(RAND) and an integrity key IK = f4K(RAND) where f4 is a key generating function. - If SQN is to be concealed, in addition the HLR/AuC computes an anonymity key AK = f5K(RAND) and computes the co

49、ncealed sequence number SQN AK = SQN xor AK. Concealment of the sequence number is optional. - Finally, the HLR/AuC assembles the authentication token AUTN = SQN AK | AMF | MAC-A and the quintet Q = (RAND, XRES, CK, IK, AUTN). ETSI ETSI TS 133 105 V14.0.0 (2017-04)93GPP TS 33.105 version 14.0.0 Release 14KKSQNRANDAMFCK IKMAC-A XRESf3f4f1f2AKf5SQN AKxorKAUTN = SQN AK | AMF | MAC-AQ = (RAND, XRES, CK, IK, AUTN)Figure 1: Generation of quintets in the AuC 5.1.1.2 Authentication and key derivation in the USIM Upon receipt of a (RAND, AUTN) pair the