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

1、 ETSI TS 1Universal Mobile TelCryptograph(3GPP TS 33.1TECHNICAL SPECIFICATION133 105 V13.0.0 (2016elecommunications System (LTE; 3G Security; phic algorithm requirements .105 version 13.0.0 Release 1316-01) (UMTS); 13) ETSI ETSI TS 133 105 V13.0.0 (2016-01)13GPP TS 33.105 version 13.0.0 Release 13Re

2、ference RTS/TSGS-0333105vd00 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 Importan

3、t notice The 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 aut

4、horization 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 shoul

5、d be aware 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 http:/portal.etsi.org/tb/status/status.asp If you find errors in the present document, please send your comment to one of the following serv

6、ices: 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 sh

7、all 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 2016. All rights reserved. DECTTM, PLUGTESTSTM, UMTSTMand the ETSI logo are Trade Marks of ETSI registered f

8、or 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. GSM and the GSM logo are Trade Marks registered and owned by the GSM Association. ETSI ETSI TS 133 105 V13.0.0 (2016-01)23GPP TS 33.105 version 13.

9、0.0 Release 13Intellectual 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-members, and can be found in ETSI SR 000 314: “Intelle

10、ctual 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/). Pursuant to the ETSI IPR Policy, no investigation, includi

11、ng 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 document. Foreword This Technical Specification (TS) has

12、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 references to the corresponding ETSI deliverables. The cross ref

13、erence 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“, “can“ and “cannot“ are to be interpreted as described in

14、 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 V13.0.0 (2016-01)33GPP TS 33.105 version 13.0.0 Release 13Contents Intellectual Property Rights

15、 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 requirements . 8g34.1 Resilience . 8g34.2 World-wide availabi

16、lity 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-synchronisation token in the USIM . 9g35.1.1.4 Re-synchr

17、onisation 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.4 f2 . 11g35.1.6.5 f3 . 11g35.1.6.6 f4 . 12g35.1.6.7 f

18、5 . 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.7.10 IK 13g35.1.7.11 AK . 14g35.2 Data confidentiality

19、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 . 15g3ETSI ETSI TS 133 105 V13.0.0 (2016-01)43GPP TS 33.105 version 13.0.0 Release 135.2.7 Interfaces to the algorithm 16g35

20、.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 . 18g35.3.4 Extent of standardisation 18g35.3.5 Impleme

21、ntation 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 the algorithm specifications 20g36.1 Ownership 20g36.2

22、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 21g37.3 Design conformance test data . 21g37.4 Format and

23、 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 deliverables . 22g3Annex A (informative): Void . 23g3A

24、nnex B (informative): Change history . 24g3History 25g3ETSI ETSI TS 133 105 V13.0.0 (2016-01)53GPP TS 33.105 version 13.0.0 Release 13Foreword This Technical Specification has been produced by the 3rdGeneration Partnership Project (3GPP). The contents of the present document are subject to continuin

25、g 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 follows: Version x.y.z where: x the first digit: 1 present

26、ed 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. z the third digit is incremented when editorial only

27、changes have been incorporated in the document. ETSI ETSI TS 133 105 V13.0.0 (2016-01)63GPP TS 33.105 version 13.0.0 Release 131 Scope This specification constitutes a requirements specification for the security functions which may be used to provide the network access security features defined in 1

28、. 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 algorithm specification, the requirements on test data,

29、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 specific (identified by date of publication, edition num

30、ber, 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 non-specific reference implicitly refers to the latest versio

31、n 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. 3 ISO/IEC 9797: “Information technology - Security techniqu

32、es - 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 definitions apply: Confidentiality: The property that information is n

33、ot 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 received is as claimed. Entity authentication: The provision

34、 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 V13.0.0 (2016-01)73GPP TS 33.105 version 13.0.0 Release 133.2 Sy

35、mbols 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; f2 user authentication function f3 cipher key derivation fu

36、nction 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 For the purposes of the present document, the following abbrev

37、iations 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 of data integrity CK Cipher keyIK Integrity key IMSI Internat

38、ional 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 of signalling messages PDU Protocol data unit RAND Random chal

39、lenge 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 authentication and key agreement XMAC-I Expected MAC used for data in

40、tegrity 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 hand side. A substring may be a bit, byte or other arbitrary le

41、ngth 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 105 V13.0.0 (2016-01)83GPP TS 33.105 version 13.0.0 Release 134

42、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 the effective key space should be impossible. The designers of

43、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 prevent the use of such equipment in certain countries. It is the i

44、ntention 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 more stringent restrictions. It is the intention is that RNC and

45、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 agreement described in clause 6.3 of 1 requires the following cr

46、yptographic 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 function; f4 the integrity key derivation function; f5 the anonymi

47、ty 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 authentication MAC-A = f1K(SQN | RAND | AMF), an expected respo

48、nse 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 concealed sequence number SQN AK = SQN xor AK. Concealment of th

49、e 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 V13.0.0 (2016-01)93GPP TS 33.105 version 13.0.0 Release 13KKSQNRANDAMFCK 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 USIM acts as follows: - If the sequence number is conce