GISFI GICT.105 - Global ICT Standardisation Forum · Web view. [34] IS-95 security issue: Abstract: . [35] Muxiang Zhang, Christopher Carroll and Agnes

GISFI TR SP.1xxx V1.0.0 (20xx-xx)Technical Report

Global ICT Standardisation Forum for India;Technical Working Group Security and Privacy;

Security in mobile communication systems;Comparison and proposals for India

(Release 1)

The present document has been developed within GISFI and may be further elaborated for the purposes of GISFI.

GISFI

GISFI

GISFI office addressSuite 303, 3rd Floor, Tirupati Plaza, Plot No. 4, Sector 11, Dwarka, New Delhi-110075, India

Tel.: +91-11-47581800 Fax: +91-11-47581801

Internethttp://www.gisfi.org

E-mail: [email protected]

Copyright Notification

No part may be reproduced except as authorized by written permission.The copyright and the foregoing restriction extend to reproduction in all media.

© 2011, GISFIAll rights reserved.

GISFI TR SP.1xxx V1.0.0 (20xx-xx)2Release 1

Contents

Foreword.....................................................................................................................................................5

Introduction.................................................................................................................................................5

1 Scope.................................................................................................................................................6

2 References.........................................................................................................................................6

3 Definitions, symbols and abbreviations............................................................................................93.1 Definitions...................................................................................................................................................93.2 Abbreviations..............................................................................................................................................9

4 Security Mechanisms or Architecture in Mobile Communication Systems...................................104.1 Security Provisions in the Second Generation (2G) and Second Generation - Transitional (2.5G/ 2.75G

[3]) Mobile Communication Systems.......................................................................................................104.1.1 The GSM Evolution............................................................................................................................104.1.1.1 The 2G Global System for Mobile Communication (GSM).........................................................104.1.1.2 The General Packet Radio Service (GPRS) and subsequent Enhanced Data Rates for GSM

Evolution (EDGE).........................................................................................................................104.1.2 The Code Division Multiple Access (CDMA)-based 2G/2.5G evolution..........................................104.2 Security Provisions in the Third Generation (3G) and Third Generation – Transitional (3.5G [25]/ 3.95G

[26]) Mobile Communication Systems.....................................................................................................114.2.1 The Third Generation Partnership Project-based (3GPP-based) Mobile Communication Systems...114.2.2 The Third Generation Partnership Project 2-based (3GPP2-based) Mobile Communication Systems134.2.2.1 The CDMA2000 1x Mobile Communication Systems [17]..........................................................134.2.2.2 The CDMA2000 1xEV-DO Mobile Communication Systems [17].............................................144.3 Security Provisions in the Fourth Generation (4G [27]) Mobile Communication Systems.....................15

5 Security Issues in Mobile Communication Systems.......................................................................165.1 Security Issues in the Second Generation (2G) and Second Generation - Transitional (2.5G/ 2.75G [3])

Mobile Communication Systems..............................................................................................................165.1.1 The GSM Evolution............................................................................................................................165.1.1.1 The 2G Global System for Mobile Communication (GSM) [28]..................................................165.1.1.2 The General Packet Radio Service (GPRS) and subsequent Enhanced Data Rates for GSM

Evolution (EDGE) [31] [32]..........................................................................................................175.1.2 The Code Division Multiple Access (CDMA)-based 2G/2.5G evolution [34]...................................185.2 Security Issues in the Third Generation (3G) and Third Generation Transitional (3.5G [25]/ 3.95G [26])

Mobile Communication Systems..............................................................................................................195.2.1 The Third Generation Partnership Project-based (3GPP-based) Mobile Communication Systems...195.2.2. The Third Generation Partnership Project 2-based (3GPP2-based) Mobile Communication Systems205.2.2.1 The CDMA2000 1x Mobile Communication Systems [39] [40]..................................................205.2.2.2 The CDMA2000 1xEV-DO Mobile Communication Systems [43].............................................205.2.3 Security Issues (perceived) in the 3GPP Fourth Generation (4G [27]) Mobile Communication

Systems................................................................................................................................................20

6 List of Mandatory and Optional Security Features derived from 3GPP (33-series) Security Technical Specifications.................................................................................................................21

6.1 From 3GPP TS 33.102, V11.3.0, (2012-06) (Release 11) [49]:...............................................................216.2 From 3GPP TS 33.401, V11.4.0, (2012-06) (Release 11) [50]:...............................................................236.3 From 3GPP TS 33.210, V12.0.0, (2012-06) (Release 12) [51]:...............................................................256.4 From 3GPP TS 33.310, V11.0.1, (2012-07) (Release 11) [52]:...............................................................276.5 From 3GPP TS 33.402, V11.4.0, (2012-06) (Release 11) [53]:...............................................................316.6 From 3GPP TS 33.320, V11.6.0, (2012-06) (Release 11) [54]:...............................................................326.7 From 3GPP TS 33.328, V10.0.0, (2011-03) (Release 10) [55]:...............................................................376.8 From 3GPP TS 33.234, V11.4.0, (2012-06) (Release 11) [56]:...............................................................406.9 From 3GPP TS 33.105, V10.0.0, (2011-03) (Release 10) [57]:...............................................................436.10 From 3GPP TS 33.110, V10.1.0, (2011-06) (Release 10) [58]:...............................................................436.11 From 3GPP TS 33.141, V12.0.0, (2012-06) (Release 12) [59]:...............................................................446.12 From 3GPP TS 33.203, V12.0.0, (2012-06) (Release 12) [60]:...............................................................45

GISFI


6.13 From 3GPP TS, 33.220, V11.3.0, (2012-06) (Release 11) [61]:..............................................................486.14 From 3GPP TS 33.234, V11.4.0, (2012-06) (Release 11) [62]:...............................................................506.15 From 3GPP TS 33.246, V10.0.0, 2010-12 (Release 10) [63]:..................................................................52

7 Void.................................................................................................................................................53

8 Void.................................................................................................................................................53

9 Conclusions.....................................................................................................................................53

Annex A: Change history..........................................................................................................................54

GISFI


ForewordThis Technical Report has been produced by GISFI.

The contents of the present document are subject to continuing work within the Technical Working Group (TWG) and may change following formal TWG approval. Should the TWG modify the contents of the present document, it will be re-released by the TWG with an identifying change of release date and an increase in version number as follows:

Version x.y.z

where:

x the first digit shows the release to which the document belongs

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 changes have been incorporated in the document.

.

IntroductionThis report introduces the subject of the “Security in Mobile Communication Systems” that is of paramount importance in the times of evolving technologies that also is challenged by threats and attacks on them. It provides an overview of the security implementations/architectures provided in the various generations of wireless/mobile communication technologies. This report also provides a brief description of the various security issues in the various phases of technology evolutions in the various generations of wireless/mobile communication technologies.

Further, this report enlists the Mandatory and Optional requirements, regarding the implementation and/or use of security features, as specified in the 3GPP 33-series Technical Specifications (TSs). It does not mention whether a given security item/feature is mandatory/optional for implementation or use, unless explicitly specified in this document and in the respective TS which has been referred to. This list of Mandatory and Optional requirements has been derived by searching for the keywords: Mandate/ Mandatory, and Optional, as mentioned in the various 3GPP 33-series Technical Specifications that have been referenced.

This list also provides an overview to the concerned Indian Government departments on the 3GPP Standards-based security features, both mandatory and optional, that are to be considered by vendors and operators as part of the Indian Network Security requirements.

GISFI


1 ScopeThis document, study report on Security in Mobile Communication Systems is a deliverable of Security and Privacy working group. The scope of this technical report is to perform a study on the security mechanisms or architecture in different wireless technologies, designed and enhanced over successive evolution phases of a particular wireless technology. Items within the scope of this study are:

1. Identify the Standardized security mechanisms or architecture in the 3GPP and 3GPP2 wireless communication technologies, across successive generations of each technology platform.

2. Identify security issues in each of the wireless technology generation, for the 3GPP and 3GPP2 technology family.

3. Present a gap analysis between the security mechanisms or architectures in each of the wireless technology generation, for the 3GPP and 3GPP2 technology Standards family and the weaknesses or security flaws in the same and provide recommendations for resolution of the same.

4. Propose a list of Mandatory and Optional security features for implementation and/or use, for the latest wireless technologies to be adopted and implemented in the Indian Telecom industry.

2 ReferencesThe following documents contain provisions which, through reference in this text, constitute provisions of the present document.

[1] Eric Southern, Abdelkader Ouda, Abdallah Shami, “Securing USIM-based Mobile Communications from Interoperation of SIM-based Communications”; International Journal for Information Security Research (IJISR), Volume 2, Issues 1/2, March/June 2012; pg. 315, 316.

http://www.infonomics-society.org/IJISR/IJISR_Paper%209.pdf.

[2] Introduction of GPRS and EDGE: http://www.3gpp.org/article/functionality-in-early-gsm.

[3] On GPRS and EDGE: http://www.3gpp.org/article/gprs-edge.

[4] Charles Brookson, “GPRS Security”; December 2001; Pg. 3; http://www.brookson.com/gsm/gprs.pdf.

[5] Ali Dinckan, Aktul Kavas, “Authentication And Ciphering In GPRS Network”; May 2005; pg. 2; www.emo.org.tr/ekler/fedcaffc4aba6e5_ek.pdf.

[6] About cdmaOne: http://www.cdg.org/technology/cdmaone.asp.

[7] About CDMA Technology: http://www.cdg.org/technology/cdmatechnology.asp.

[8] David Tipper, “IS-95 cdmaOne”; University of Pittsburgh, February 2008; Pg. 38 (Slide 93); http://www.sis.pitt.edu/~dtipper/2720/2720_Slides9.pdf.

[9] 3GPP TS 33.102, “3G Security: Security Architecture”; Ver. 11.2.0; February 2012; Pgs. 12, 13.

[10] 3GPP “Overview of 3GPP Release 1999”; V0.1.1; February 2010; Pg. 44.

http://www.3gpp.org/ftp/Information/WORK_PLAN/Description_Releases/Rel-99_description_20100214.zip.

[11] 3GPP “Overview of 3GPP Release 5”; V0.1.1; February 2010; Pg. 19.


[12] 3GPP “Overview of 3GPP Release 6”; V0.1.1; February 2010; pg. 66.


GISFI


[13] 3GPP “Overview of 3GPP Release 7”; V0.9.16; January 2012; Pg. 56- 64.


[14] 3GPP “Overview of 3GPP Release 8”; V0.2.6; March 2012; Pg. 82, 126, 127.


[15] 3GPP “Overview of 3GPP Release 9”; V0.2.5; March 2012; Pg. 48 – 54.


[16] About CDMA2000: http://www.cdg.org/technology/cdma2000.asp.

[17] Naidu Mullaguru, “Security Provisions in CDMA2000 Networks – A Whitepaper”; 80-W3633-1 Rev A, November 2011; Pgs. 4, 13, 17, 19 - 21, 22-29, 30, 32.

http://www.cdg.org/resources/files/white_papers/Qualcomm_Security_Provisions_in_CDMA2000_Networks_80-W3633-1_RevA[2]_Nov2011.pdf.

[18] 3GPP2 C.S0024-0, "cdma2000 High Rate Packet Data Air Interface Specification"; Version 4.0, October 25, 2002; Pgs. 1-2.

[19] 3GPP “Overview of 3GPP Release 10”; V0.1.4; March 2012; Pgs. 37, 90.


[20] 3GPP “Overview of 3GPP Release 11”; V0.1.0; March 2012; Pgs. 65 -74.


[21] 3GPP “Overview of 3GPP Release 12”; V0.0.3; March 2012; Pg. 19.


[22] About the SNOW3G cipher: http://www.heliontech.com/3gpp.htm; http://www.ipcores.com/Snow3G.htm.

[23] About the AES cipher: http://www.heliontech.com/3gpp.htm; http://www.ipcores.com/aes_ip_core.htm.

[24] On the LTE platform integration by the 3GPP and 3GPP2: http://www.gsma.com/aboutus/gsm-technology/lte/.

[25] 3.5G, Terminology, usage of, 3GPP: http://www.3gpp.org/article/w-cdma.

[26] 3.95G, Terminology, usage of, 3GPP: http://www.3gpp.org/A-few-Mbps-ought-to-make-just.

[27] 4G, Terminology, usage of, 3GPP: http://www.3gpp.org/LTE-Advanced.

[28] Mohsen Toorani, Ali A. Beheshti, "Solutions to the GSM Security Weaknesses"; (Copyright © 2008 IEEE. Reprinted from the Proceedings of the 2nd International Conference on Next Generation Mobile Applications, Services, and Technologies (NGMAST'08), pp.576-581, University of Glamorgan, Cardiff, UK, Sep. 2008); Pgs. 2, 3; http://arxiv.org/ftp/arxiv/papers/1002/1002.3175.pdf.

[29] Impersonation of a user and the network, Description of: Emmanuel Gadaix, "GSM and 3G Security, April 2001, Slide: 7.

http://www.google.co.in/url?sa=t&rct=j&q=%22gadiax.ppt%22&source=web&cd=1&ved=0CE8QFjAA&url=http%3A%2F%2Fwww.blackhat.com%2Fpresentations%2Fbh-asia-01%2Fgadiax.ppt&ei=6vMIUJbFIc-trAfWuIjJCA&usg=AFQjCNFfwYvxKR1O5chC15u_Ztu7NWX1oA.

[30] On “Security through Obscurity”: Jeremy Quirke, “Security in the GSM System”; 2004: http://www.it.iitb.ac.in/~kavita/GSM_Security_Papers/Security%2520in%2520the%2520GSM%2520system%252001052004.pdf.

[31] Hakima Chaouchi, Maryline Laurent-Maknavicius, "Wireless and Mobile Network Security"; ISTE Ltd. and John Wiley & Sons, Inc., 2009; Pgs. 343 – 346.

http://mobilemarketingcn.com/ebooks/hotsaleebooks/wireless-and-mobile-network-security.pdf.

GISFI


[32] Christos Xenakis, "Malicious Actions Against the GPRS Technology"; 2006; Pgs. 10-18.

http://www.google.co.in/url?sa=t&rct=j&q=%22Malicious+Actions+Against+the+GPRS+Technology%22&source=web&cd=1&ved=0CEoQFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.106.8814%26rep%3Drep1%26type%3Dpdf&ei=pPQIUKnrF4i0rAfSwN3ICA&usg=AFQjCNGDpaqAL-5D3S925ndn1EnsBKKN5Q.

[33] EDGE network security vulnerabilites, similar to those of GPRS networks:

http://www.cse-cst.gc.ca/its-sti/publications/itspsr-rpssti/itspsr16a-eng.html#a393.

[34] IS-95 security issue: Abstract: http://www.springerlink.com/content/g3cekhvu9wpududq/.

[35] Muxiang Zhang, Christopher Carroll and Agnes Chan, "Analysis of IS-95 CDMA Voice Privacy"; Lecture Notes in Computer Science, 2001, Volume 2012/2001.

https://springerlink3.metapress.com/content/g3cekhvu9wpududq/resource-secured/?target=fulltext.pdf&sid=k3tsrxjhiisqzjlxhmy2xtq5&sh=www.springerlink.com.

[36] L. Ertaul, S. Natte, and G. Saldamli, "Security Evaluation of CDMA2000"; Pg. 1.

http://www.mcs.csueastbay.edu/~lertaul/Security%20Evaluation%20of%20CDMA2000CamReady.pdf.

[37] 3G Networks, Reasons for Vulnerabilities:

http://www.mid-day.com/lifestyle/2010/aug/020810-Hacker-3G-mobile-network.htm.

[38] Kameswari Kotapati, Peng Liu, Yan Sun, Thomas F. LaPorta, "A Taxonomy of Cyber Attacks on 3G Networks"; 2005; Pg. 10.

http://nsrc.cse.psu.edu/tech_report/NAS-TR-0021-2005.pdf.

[39] Sangram Gayal and Dr. S. A. Vetha Manickam, "Comparative analysis Of GSM and CDMA technologies"; 2002; Pg. 14.

http://www.google.co.in/url?sa=t&rct=j&q=%22Comparative+analysis+Of+GSM+and+CDMA+technologies%22&source=web&cd=1&ved=0CE0QFjAA&url=http%3A%2F%2Fciteseerx.ist.psu.edu%2Fviewdoc%2Fdownload%3Fdoi%3D10.1.1.11.3538%26rep%3Drep1%26type%3Dpdf&ei=-_UIUIaFJMvOrQel_sTICA&usg=AFQjCNFwSt32-JcT8pGhASEdnswmLzGoHA.

[40] CDMA20001x Vulnerabilities: http://www.cse-cst.gc.ca/its-sti/publications/itspsr-rpssti/itspsr16a-eng.html#a343.

[41] D. Wagner, L. Simpson, E. Dawson, J. Kelsey, W. Millan, and B. Schneier, "Cryptanalysis of ORYX"; 1999.

http://packetstorm.igor.onlinedirect.bg/cracked/oryx/oryx.pdf.

[42] David Wagner, Bruce Schneier, John Kelsey, "Cryptanalysis of the Cellular Message Encryption Algorithm"; 1999; http://www.schneier.com/paper-cmea.pdf.

[43] CDMA2000 1xEV-DO Vulnerabilties: http://www.cse-cst.gc.ca/its-sti/publications/itspsr-rpssti/itspsr16a-eng.html#a353.

[44] LTE brings new security concerns for telcos: http://www.zdnet.com/lte-brings-new-security-concerns-for-telcos-1339323236/.

[45] Dr. Jinyuan (Stella) Sun, “Computer and Network Security”; Dept. of Electrical Engineering and Computer Science, University of Tennessee, Fall 2011; Slide number: 46; http://web.eecs.utk.edu/~jysun/files/Lec15.pptx.

[46] CDG Document 138, “CDMA Authentication”; Version 0.34; Oct. 12, 2006; Pg. 1

http://www.google.co.in/url?sa=t&rct=j&q=Fraud_WG_CDG138_CDMA_Authentication.doc&source=web&cd=3&cad=rja&ved=0CE4QFjAC&url=https%3A%2F%2Fwiki.cdg.org%2Fw%2Fimages%2Fc%2Fc7%2FFraud_WG_CDG138_CDMA_Authentication.doc&ei=aNktUK7mNY3wrQee9ICwBQ&usg=AFQjCNHAwPGXzzz0vGJeztcFP9r4t3EuIg.

[47] Greg Rose, “The Future of CDMA2000 Security”; 2005; Pg. 6.

GISFI


http://www.cdg.org/news/events/cdmaseminar/050513_tech_forum/5-%20CDG%20-%20Qualcomm.pdf.

[48] N. Seddigh, “Security advances and challenges in 4G wireless networks”, Eighth Annual International Conference on Privacy Security and Trust (PST) 2010, 17 – 19 Aug. 2010.

http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=5593244&url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D5593244.

[49] 3GPP TS 33.102, “3G Security; Security Architecture”, V11.3.0, 2012-06 (Release 11).

[50] 3GPP TS 33.401, “3GPP System Architecture Evolution (SAE); Security architecture”, V11.4.0, 2012-06 (Release 11) .

[51] 3GPP TS 33.210, “3G security; Network Domain Security (NDS); IP network layer security”, V12.0.0, 2012-06 (Release 12).

[52] 3GPP TS 33.310, “Network Domain Security (NDS); Authentication Framework (AF)”, V11.0.1, 2012-07 (Release 11).

[53] 3GPP TS 33.402, “3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses”, V11.4.0, 2012-06 (Release 11).

[54] 3GPP TS 33.320, “Security of Home Node B (HNB) / Home evolved Node B (HeNB)”, V11.6.0, 2012-06 (Release 11).

[55] 3GPP TS 33.328, “IP Multimedia Subsystem (IMS) media plane security”, V10.0.0, 2011-03 (Release 10).

[56] 3GPP TS 33.234, “3G security; Wireless Local Area Network (WLAN) interworking security”, V11.4.0, 2012-06 (Release 11).

[57] 3GPP TS 33.105, “3G Security; Cryptographic Algorithm Requirements”, V10.0.0, 2011-03 (Release 10).

[58] 3GPP TS 33.110, “Key establishment between a Universal Integrated Circuit Card (UICC) and a terminal”, V10.1.0, 2011-06 (Release 10).

[59] 3GPP TS 33.141, “Presence service; Security”, V12.0.0, 2012-06 (Release 12).

[60] 3GPP TS 33.203, “3G Security; Access security for IP-based services”, V12.0.0, 2012-06 (Release 12).

[61] 3GPP TS 33.220, “Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA)”, V11.3.0, 2012-06 (Release 11).

[62] 3GPP TS 33.234, “3G Security; Wireless Local Area Network (WLAN) interworking security”, V11.4.0, 2012-06 (Release 11).

[63] 3GPP TS 33.246, “3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS)”, V10.0.0, 2010-12 (Release 10).

3 Definitions, symbols and abbreviations

3.1 DefinitionsThis document defines the following items.

3.2 AbbreviationsDoT Department of TelecommunicationsICT Information and Communication Technologies

GISFI


4 Security Mechanisms or Architecture in Mobile Communication Systems

4.1 Security Provisions in the Second Generation (2G) and Second Generation - Transitional (2.5G/ 2.75G [3]) Mobile Communication Systems

4.1.1 The GSM Evolution

4.1.1.1 The 2G Global System for Mobile Communication (GSM)

The 2G GSM technology is a digital technology, succeeding the analog (1G) Advanced Mobile Phone System (AMPS), where the radio signals are digitally encrypted. It was made available around the early 90s.

The GSM uses security hashing algorithms (A8, A3, and A5), with different versions of the same such as the A5/1, A5/2, etc. A Private Key encrypts message to the server. The authentication in GSM is a one-way authentication algorithm to authenticate the mobile device to the service provider network. Since the mobile device cannot authenticate the network, it poses threats such as a false base station attack that can listen into user conversations and inject information into the channel. [1]

4.1.1.2 The General Packet Radio Service (GPRS) and subsequent Enhanced Data Rates for GSM Evolution (EDGE)

The 3GPP classifies the 2.5G and the 2.75G systems as follows [2]:

GSM Phase 2+ (Release 1998) GSM Phase 2+ (Release 1997) GSM Phase 2+ (Release 1996),

with the introduction of the GPRS in Release 1997, followed by the introduction of the EDGE in Release 1998.

Based on specifications in Release 97, GPRS typically reached speeds of 40Kbps in the downlink and 14Kbps in the uplink by aggregating GSM time slots into one bearer. Enhancements in Releases R’98 and R’99 meant that GPRS could theoretically reach downlink speeds of up to 171Kbps. The increase in data speeds to 384Kbps placed EDGE as an early pre-taste of 3G, although it was labelled 2.75G by industry watchers. [3]

The GPRS security model, built on the GSM security aspects, includes seven GPRS Encryption Algorithms (GEA) allowed for in the GPRS specifications, along-with the A3, A8 and A5 algorithms. [4]

The GPRS security model also has an identification key Ki (128-bit long identification key) and a ciphering key GPRS-Kc (64-bit key) [5]

4.1.2 The Code Division Multiple Access (CDMA)-based 2G/2.5G evolutioncdmaOne is the brand name that describes a complete digital wireless telecommunications solution based on the TIA/EIA IS-95 CDMA standard, including IS-95A (that provides circuit-switched data connections at 14.4 kbps) and IS-95B (that provides packet-switched data services at 64 kbps) revisions. It represents a second generation (2G) digital radio solution that uses the spectrally efficient Code Division Multiple Access (CDMA) scheme to send voice, data and signalling data (e.g., Caller ID) between mobile telephones and cell sites in a variety of spectrum and regulatory environments, including cellular, personal communication services (PCS), wireless local loop (WLL) and fixed wireless. [6]

GISFI


CDMA is a "spread spectrum" technology, allowing many users to occupy the same time and frequency allocations in a given band/space. CDMA (Code Division Multiple Access) assigns unique codes to each communication to differentiate it from others in the same spectrum. [7] Owing to this uniquely generated code for communication between every user and the network, it also increases security of the communication channel.

cdmaOne uses the Cellular Authentication And Voice Encryption (CAVE) algorithm which uses a 64 bit Authentication-key (A-key) along with Electronic Serial Number (ESN) and Random number to generate a 128-bit Shared Secret Data (SSD). The SSD is divided into two 64 bit blocks as SSD-A for authentication and SSD-B for encryption. cdmaOne employs the Challenge/Response technique for authentication whereas a random number used to create a key for encryption of voice and data. [8]

4.2 Security Provisions in the Third Generation (3G) and Third Generation – Transitional (3.5G [25]/ 3.95G [26]) Mobile Communication Systems

4.2.1 The Third Generation Partnership Project-based (3GPP-based) Mobile Communication SystemsPost the introduction of the GSM Phase2+ (Release 1998) the 3GPP group has framed a security architecture (modified/updated over subsequent 3G technology releases), that not only includes Network Access Control, but also other domains of the mobile communication system.

The 3GPP-based Mobile communication systems between Release 99 (Rel99) until Release 7 are commonly termed as ‘Third Generation (3G) systems’. Likewise, the 3GPP-based Mobile communication systems post-Release 8 until Release 12 (released, as of date) are commonly termed as ‘Fourth Generation (4G) systems’

However, the security architecture designed by the 3GPP, starting from Release 99 until Release 12 remains the same, with modifications/updates over the successive technology releases.

This 3GPP security architecture is as follows [9]:

Figure 1. Overview of the 3GPP Security Architecture.

GISFI


Five security feature groups are defined. Each of these feature groups meets certain threats and accomplishes certain security objectives [9]:

Network access security (I): the set of security features that provide users with secure access to 3G services, and which in particular protect against attacks on the (radio) access link;

Network domain security (II): the set of security features that enable nodes in the provider domain to securely exchange signalling data, and protect against attacks on the wire-line network;

User domain security (III): the set of security features that secure access to mobile stations; Application domain security (IV): the set of security features that enable applications in the user and in the

provider domain to securely exchange messages; Visibility and configurability of security (V): the set of features that enables the user to inform himself

whether a security feature is in operation or not and whether the use and provision of services should depend on the security feature.

The modifications to the above-framed security architecture, starting from 3GPP Rel99 until Release 7, in sequence are as follows:

a) Rel99/ Release 4, Release description [10] : Introduction of the Fraud Information Gathering Service (FIGS) that provides the means for the HPLMN to monitor the activities of its subscribers in a VPLMN. Also introduced in this Release, is the Immediate Service Termination (IST) feature that provides the means for the HPLMN to terminate all the activities of an Home Public Land Mobile Network (HPLMN) subscriber in a Visitor Public Land Mobile Network (VPLMN), if the HPLMN decides (based upon information received via FIGS or other systems) that a roaming subscriber is behaving in a fraudulent or suspicious manner.

b) High Speed Packet Access – Downlink (HSPA-Downlink)/ (Release 5) description [11] : Enhanced Network Domain Security as a stage-2 specification for IP-related security in the UMTS core network. These "Security services" are confidentiality, integrity, authentication and anti-replay protection. They are actually ensured by standard procedures, based on cryptographic techniques. It also defines the security architecture for the UMTS network IP based control plane, covering the control signalling on selected interfaces between UMTS Network Elements.It was identified that 3G systems should provide enhanced security over 2G systems in the area of SS7 network security due to the increased threats linked to the predicted larger Multi-Operator environment. Important Signalling System No. 7 Mobile Application Part (SS7 MAP) signalling is protected with this release.

c) High Speed Packet Access – Uplink (HSPA-Uplink)/ (Release 6) description [12] : Release 6 has the following security enhancements:

i. Enhanced Home Environment (HE) control of security (including positive authentication reporting): In order to facilitate roaming with Telecommunications Industry Association’s (TIA's) Code Division Multiple Access (cdma2000), the 3GPP authentication and key agreement mechanism has been adopted by the TIA TR-45 group. TR-45 have identified requirements for enhancing the degree of control the home environment can exert on the serving network with respect to authentication and key agreement. In particular, two security features, required by TR-45, were added to the 3GPP standard:

ii. Authentication vector revocationiii. Positive authentication result reportingiv. Network Domain Security; Authentication Framework (NDS/AF): The primary objective was for the

authentication framework to provide entity authentication for the nodes that are using NDS/Internet Protocol (IP). The authentication is developed to replace the (not so scalable) default IP Security (IPsec)/Internet Key Exchange (IKE) use of pre-shared secrets to authenticate the network elements.

v. Key Management of group keys for Voice Group Call Services (VGCS)

d) High Speed Packet Access - Plus (HSPA+)/ (Release 7) description [13] : Release 7 has the following security enhancements:

i. Liberty Alliance and 3GPP Security Interworking (LibSec)ii. Trust Requirements for Open Platforms in 3GPP (TrustOP): An Open Platform is a computing platform

with an architecture allowing users to upgrade their hardware and/or update the software running on that

GISFI


platform. Therefore, it is very much desirable that the Open Platform must have secure authentication and authorization mechanisms to protect against eavesdropping, and malicious modification of user data and operator applications residing on the Open Platform.

iii. Development of UEA2 and UIA2 (AlgUEA2): The need for backup algorithms for UTRAN access confidentiality and integrity protection (UEA2, UIA2) was identified, in the event that the KASUMI algorithm is ever broken. The SNOW3G is a stream cipher which uses a 128-bit Key. It provides the basis for the UEA2 confidentiality and UIA2 integrity algorithms introduced in 3GPP Release 7 to provide data security for signalling and user data within the UMTS standard. [22] The algorithms were provided by European Telecommunication Standards Institute Security Algorithms Group of Experts (ETSI SAGE).

iv. Lawful Interception in the 3GPP Rel-7 architecture (LI-7A)v. Key establishment between a Universal Integrated Circuit Card (UICC) and a terminal (KeyEstUTerm):

defines how to provision a shared key between a UICC and a terminal that may host the UICC or be connected to the device hosting the UICC via a local interface.

vi. Security enhancements: Hypertext Transfer Protocol Secure (HTTPS) connection between the UICC and a Network Application Function (NAF), 2G Generic Bootstrapping Architecture (GBA): 2G Subscriber Identity Module (SIM) usage in 3GPP Generic Authentication Architecture (GAA) framework, Generic Authentication Architecture usage extensions and optimisations, and SS7 Transaction Capabilities Application Part (TCAP) security Gateway.

vii. NDS Authentication Framework Extension for Transport Layer Security (NDSAFTLS)

e) Dual Cell/ Carrier High Speed Packet Access (DC-HSPA)/ (Release 8) description [14] : 3GPP Release 8 introduced confidentiality and integrity algorithms based on the Advanced Encryption Standard (AES) 128-bit block cipher with 128-bit key size to provide data security within LTE networks. [23] Release 8 has the following security enhancements:

i. Security Enhancements for IP-Multimedia Subsystem (IMS)ii. Lawful Interception (LI) in the 3GPP Rel-8 (LI8)

iii. Generic Bootstrapping Architecture Push Function (GBAPush)

f) Long Term Evolution (LTE)/ (Release 9) description [15] : Long Term Evolution (LTE) is a mobile network technology that is being deployed by mobile operators on both the GSM and the CDMA technology paths. [24] It is specified by the 3GPP. Release 9 has the following security enhancements:

i. Access Security Enhancementsii. GBAPush enhancements (Generic push layer)

iii. Protection against Unsolicited Communication for IMS (PUCI)iv. IMS Media Plane Security (MEDIASEC)v. Extended Identity Management (GBA-IdM)

vi. Network Domain Security enhancements to support backhaul securityvii. 128 bit encryption for GSM and GPRS (A5/4 – GEA4)

4.2.2 The Third Generation Partnership Project 2-based (3GPP2-based) Mobile Communication SystemsThe 3GPP2 is a collaborative 3G telecommunications specifications-setting project that has defined and published specifications for the Code Division Multiple Access (CDMA2000) technology which represents a family of IMT-2000 (3G) standards providing high-quality voice and broadband data services over wireless networks. Currently, CDMA2000 includes CDMA2000 1X (Single-Carrier) and CDMA2000 EV-DO (EV-DO) standards. [16]

4.2.2.1 The CDMA2000 1x Mobile Communication Systems [17]

CDMA2000 1X (IS-2000) supports circuit-switched voice up to and beyond 35 simultaneous call per sector and high-speed data of up to 153 kbps in both directions.

Along-with the security mechanisms (employing the CAVE algorithm) implemented in cdmaOne, new security enhancements for CDMA2000 networks (Release C onwards), in the form of new algorithms such as Authentication and Key Agreement (AKA) for authentication, Secure Hashing Algorithm-1 (SHA-1) for hashing and integrity and Advanced Encryption Standard (AES) algorithm for message encryption, are introduced.

GISFI


Authentication: The CAVE-based authentication procedure in CDMA2000 is the same as that in cdmaOne. A new form of authentication, based on 3GPP AKA (128-bit authentication key and a stronger standardized and well-studied authentication algorithm) used in UMTS networks, is being introduced in CDMA2000 systems. It is called Enhanced Subscriber Authentication (ESA) (also referred as 3rd generation (3G) authentication). The support for AKA in CDMA2000 networks is included in all releases following CDMA2000 Rev C.

Encryption: In CAVE based security measures, a special Cellular Message Encryption Algorithm (CMEA) (and Enhanced-CMEA (E-CMEA)) for signalling message encryption and a special ORYX algorithm for data encryption are being used on the CDMA channel. Also a Private Long Code Mask (PLCM) is used for Voice Encryption.

The AKA mechanism allows for the generation of new cipher key (CK) and integrity key (IK). These 128-bit keys enable a security association between the device and the serving MSC for supporting advanced security services such as signalling message data integrity, signalling information element encryption and user data encryption.

Security Measures for 1x Packet Data service: In CDMA2000 1X networks, additional security measures exist for the packet data services, in form of service/subscription authentication and ORYX/AKA based encryption measures. Another new security mechanism that is gaining popularity in 3GPP2 (both 1X and EV-DO) packet data networks is EAP-AKA (Extensible Authentication Protocol- Authentication and Key Agreement).

With AKA based encryption procedures applied, a CDMA2000 1X packet data call gets Enhanced Subscriber Privacy (ESP) with encryption on all information bearers and also in multiple layers. At the air interface level, a strong encryption algorithm ‘AES’ with large keys (128-bit) gets applied. Application encryption can also be applied with any standard end-to-end encryption at the application layer level, such as IP security (IPsec) and Pretty Good Privacy (PGP).

4.2.2.2 The CDMA2000 1xEV-DO Mobile Communication Systems [17]

CDMA2000 EV-DO (Evolution-Data Optimized) introduces new high-speed packet-switched transmission techniques that are specifically designed and optimized for a data-centric broadband network that can deliver peak data rates beyond 3 Mbps in a mobile environment.

Figure 2. Air Interface Layering Architecture

In CDMA2000 1xEV-DO systems, a separate layer called “Security Layer” [18] has been defined exclusively to take care of all security related requirements. As shown in Figure 2. the security layer sits in between the MAC and Connection layers of the 1xEV-DO layered architecture. The protocols defined within the security layer are as follows:

Key Exchange protocol: Provides the procedures followed by the access network and by the access terminal to exchange security keys for authentication and encryption. The DH Key Exchange Protocol provides a method for session key exchange based on the Diffie-Hellman (DH) key exchange algorithm.

Authentication protocol: Provides the procedures followed by the access network and the access terminal for authenticating traffic. In CDMA2000 1xEV-DO systems, there are three distinct types of authentication procedures in use and they are:

o RAN Access authentication using the Challenge Handshake Authentication Protocol (CHAP).o IS-856 Air interface authentication for integrity protection using SHA-1 hashing algorithm to

authenticate every Access channel message.o Service/Subscription authentication with the Operator/ISP

With Packet Data Serving Node/ Foreign Agent (PDSN/FA) for Simple IP using CHAP

GISFI


protocol. With Home Agent for Mobile IP using CHAP protocol and additional authentication by the

Home Agent. Encryption protocol: Provides the procedures followed by the access network and the access terminal for

encrypting traffic. The AES (Advanced Encryption System) is used for traffic channel encryption. The IPsec protocol is supported for securing traffic between the Access Terminal and the nodes within the PDN (Packet Data Network)

Femto cell Network Security Measures: The 3GPP2 specifications provide a complete security architecture that allows CDMA2000 femto cell networks to support large numbers of femto cells via standard commercial IPsec/IKEv2-based security gateways.

Security Developments for Machine-to-Machine (M2M) Communications: Enhancements in CDMA2000 1X (Rel C onwards) as well as in 1xEV-DO systems provide end-to-end security by using improved encryption algorithms and other means such as improved authentication, hashing, data protection through integrity and anonymity features.

4.3 Security Provisions in the Fourth Generation (4G [27]) Mobile Communication SystemsBased on the security architecture designed by the 3GPP, which is the same as illustrated in Figure 1. in Section 3 above, the 4G security architecture with further modifications is as follows:

a) LTE-Advanced/ Release 10 description [19] : Release 10 has the following security enhancements:i. Lawful Interception in the 3GPP Rel-10 (LI10)

ii. Security for LTE Relay Nodes (Stage 2)

b) Release 11 description [20] : Release 11 has the following security enhancements:i. EEA3 and EIA3 (new Encryption & Integrity EPS security Algorithms)

ii. Specification of Protection against Unsolicited Communication for IMS (PUCI)iii. Home e-node B (H(e)NB) security features for User Equipment (UE) mobility scenarios (Stage2)iv. Security enhancements for usage of Generic Bootstrapping Architecture (GBA) from the

browser

v. Generic Bootstrapping Architecture (GBA) extensions for re-use of SIP Digest credentialsvi. Lawful Interception in the 3GPP Rel-11

c) Release 12 description [21] : Release 12 includes Security aspects of Public Warning System (PWS_Sec).

GISFI


5 Security Issues in Mobile Communication Systems

5.1 Security Issues in the Second Generation (2G) and Second Generation - Transitional (2.5G/ 2.75G [3]) Mobile Communication Systems

5.1.1 The GSM Evolution

5.1.1.1 The 2G Global System for Mobile Communication (GSM) [28]

a) Unilateral authentication and vulnerability to the man-in-the-middle attack [28]: This means that only the GSM network authenticates the mobile station (MS). The MS does not authenticate network so the attacker can use a false Base Station Transceiver (BTS) with the same mobile network code as the subscriber's legitimate network to impersonate, both the network and a user, and perform a man-in-the-middle attack. The attacker can then perform several scenarios to modify or fabricate the exchanged data. Impersonation of a user is the capability whereby the intruder sends signalling and/or user data to the network, in an attempt to make the network believe they originate from the target user. The required equipment is a modified Mobile Station (MS). Impersonation of the network (false BTS) is the capability whereby the intruder sends signalling and/or user data to the target user, in an attempt to make the target user believe they originate from a genuine network. [29]

b) Flaws in implementation of A3/A8 algorithms [28]: Although the GSM architecture allows operator to choose any algorithm for A3 and A8, many operators used COMP128 (or COMP128-1) that was secretly developed by the GSM association, to achieve ‘Security through Obscurity’ [30]. The structure of COMP128 was finally discovered by reverse engineering and some revealed documentations, and many security flaws were subsequently discovered. In addition to the fact that COMP128 makes revealing Ki possible especially when specific challenges are introduced, it deliberately sets ten rightmost bits of Kc equal to zero that makes the deployed cryptographic algorithms 1024 times weaker and more vulnerable, due to the decreased keyspace. Some GSM network operators tried another new algorithm for the A3/A8, called COMP128-2. COMP128-2 was also secretly designed and inherited the problem of decreased keyspace.

c) Subscriber Identity Module (SIM) card cloning [28]: Another important challenge is to derive the root key Ki from the subscriber's SIM. In April 1998, the Smartcard Developer Association (SDA) and the ISAAC research group could find an important vulnerability in the COMP128 algorithm that helped them to extract Ki in eight hours by sending many challenges to the SIM. Ultimately, a side-channel attack, called partitioning attack, was proposed by the IBM researchers that makes attacker capable of extracting Ki if he could access the subscriber's SIM just for one minute. The attacker can then clone the SIM and use it for his fraudulent purposes.

d) Over-the-air cracking [28]: It is feasible to misuse the vulnerability of COMP128 for extracting the Ki of the target user without any physical access to the SIM. This can be accomplished by sending several challenges over the air to the SIM and analyzing the responses. However, this approach may take several hours. The attacker can also extract International Mobile Subscriber Identity (IMSI) using an approach explained in point (h). After finding Ki and IMSI of the target subscriber, the attacker can clone the SIM and make and receive calls and other services such as SMS in the name of the victim subscriber.

e) Flaws in cryptographic algorithms [28]: Both A5/1 and A5/2 algorithms were developed in secret. The output of A5/1 is the XOR of three Linear Feedback Shift Registers (LFSRs). An efficient attack to A5/1 can be used for a real-time cryptanalysis on a PC. A5/2 is the deliberately weakened variant of A5/1.

f) Short range of protection [28]: The encryption is only accomplished over the airway path between MS and BTS. There is not any protection over other parts of network and the information is clearly sent over the fixed parts. This is a major exposure for the GSM, especially when the communication between BTS and Base Station Controller (BSC) is performed over the wireless links that have potential vulnerabilities for interception. In some countries, the encryption facility of the air interface

GISFI


is not activated at all. There are also security problems on the GSM backbone. The deployed Signaling System no.7 (SS7) has also several security vulnerabilities. SS7 incorporates very limited authentication procedures since it was originally designed for the closed telecommunication communities. The interconnection with Internet can also have its potential vulnerabilities.

g) Lack of user visibility [28]: The ciphering is controlled by the BTS. The user is not alerted when the ciphering mode is deactivated. A false BTS can also deactivate the ciphering mode and force MS to send data in an unencrypted manner.

h) Leaking the user anonymity [28]: Whenever a subscriber enters a location area for the first time or when the mapping table between the subscriber's Temporary Mobile Subscriber Identity (TMSI) and IMSI is lost, the network requests the subscriber to clearly declare the IMSI. This can be misused to fail the user's anonymity and can be accomplished by sending an IDENTITY REQUEST command from a false BTS to the MS of the target user to find the corresponding IMSI.

i) Vulnerability to the Denial of Service (DoS) attack [28]: A single attacker is capable of disabling an entire GSM cell via a DoS attack. The attacker can send the CHANNEL REQUEST message to the BSC for several times but he/she does not complete the protocol and requests another signaling channel. Since the number of signaling channels is limited, this leads to a DoS attack. It is feasible since the call setup protocol performs the resource allocations without adequate authentication.

j) Absence of integrity protection [28]: Although the GSM security architecture considers authentication and confidentiality, there is no provision for any integrity protection of information. Therefore, the recipient cannot verify that a certain message was not tampered with.

k) Vulnerability to replay attacks [28]: The attacker can misuse the previously exchanged messages between the subscriber and network in order to perform the replay attacks.

l) Increased redundancy due to the coding preference [28] [45]: The Forward Error Correcting (FEC) is performed prior to the ciphering so there is a redundancy, the pattern of which can be known, such that attackers know part of the plaintext and the full ciphertext. That increases the security vulnerabilities of deployed cryptographic algorithms.

5.1.1.2 The General Packet Radio Service (GPRS) and subsequent Enhanced Data Rates for GSM Evolution (EDGE) [31] [32]

Based on the architecture of GPRS and the employed security measures, there are five critical areas where the GPRS security is exposed and security attacks may be carried out, are as:

Figure 1. Attack points in the GPRS network[6]

GISFI


a) The mobile station and the SIM-card [31] [32]: Authentication algorithms on the SIM card being identical to those of the GSM, attacks similar to those described in section 5.1.1.1. can still be initiated. A new vector of attack on the GPRS network has its roots in mobile terminals interacting with computer systems and also, through GPRS, with the Internet. Therefore attacks from computer viruses or worms that are very common on the Internet can also affect mobile stations and/or SIM-cards.

b) The Access Network [31] [32]: interface between the Mobile Station (MS) and the Serving GPRS Support Node (SGSN): The GPRS system protects this part of the network by employing a set of security mechanisms that ensure authentication of mobile users (unilateral, as in the case of GSM), confidentiality of user’ identity, and ciphering of users data and signalling information exchanged through it. However, exploiting some weaknesses (to mention, an unauthorized BTS introduction due to unilateral authentication, eavesdropping and interception possibility on (GPRS Encryption Algorithm) GEA3 encryption, weak confidentiality due to a limited 64 bits of encryption key length (Kc)) that these mechanisms present, an adversary may perform the following attacks, which may result in the system breakdown or the compromise of end-user security, such as Denial of Service and Man-in-the-Middle attack, similar to the GSM network security issues.

c) The GPRS backbone network [31] [32]: The Gn interface: Like the GSM network, the GPRS core network infrastructure is very vulnerable. Partly based on SS7, it unfortunately inherits all its weaknesses. The IP-based GPRS Tunelling Protocol (GTP) protocol being unsecured, eavesdropping or interception of messages exchanged between SGSNs and Gateway GPRS Support Nodes (GGSNs) is conceivable. An intruder may also initiate denial-of service (DoS) attacks on the signaling or may try to obtain information from a Home Location Register (HLR) or the Authentication Center (AuC).

d) The packet network that connects different operators [31] [32]: The Gp interface: The Gp Interface, which provides connectivity between GPRS networks that belong to different operators, is also vulnerable to malicious actions. The security threats to the Gp interface mainly concern with the availability of resources and services, the authentication and authorization of users and actions, and the integrity and confidentiality of the data transferred. A vital security issue of the Gp interface is the lack of security measures in the GTP protocol. This allows an attacker to cause denial of service to users by (i) flooding GPRS nodes with useless and unwanted traffic that consumes the majority of processing and communication resources, (ii) performing attacks that target the GTP protocol, such as deleting or updating Packet Data Protocol (PDP) contexts. These actions remove or modify the GTP tunnels between the SGSN and the GGSN (of an operator under attack) that are used for user data transfer. A malicious operator or an attacker with access to the Gp Interface may create a bogus SGSN to obtain unauthorized Internet access, and also to intercept the user data exchanged by the sessions, compromising end-user security.

e) The public Internet [31] [32]: The Gi interface: exposes the GPRS network to multiple classes of Internet-specific attacks such as worms and other viruses whose objectives are usually a denial of service. Another form of potential attack is spam. Subscribers are charged based on the amount of megabytes transferred on the GPRS network and thus a spam attack can cause overbilling for the user. Denial of service attacks represent the largest threat to the Gi interface. Attackers may be able to flood the links that connect the GPRS network to external packet data networks with useless traffic, thereby, prohibiting legitimate traffic to pass. Apart from harm to the network availability, the GPRS data are conveyed unprotected over the public Internet enabling anyone to read and/or manipulate them, and, thus, compromising user data confidentiality and integrity.

The EDGE network is subject to the same vulnerabilities as the GPRS network. [33]

5.1.2 The Code Division Multiple Access (CDMA)-based 2G/2.5G evolution [34]Voice privacy of IS-95 CDMA cellular system is provided by means of the long code mask. The long code mask is not transmitted through any channel; it is constructed by the base station and the mobile station. To recover the long code sequence, the eavesdropper may exhaustively search the 42-bit long code mask, with a time complexity of O (242) [35]

GISFI


On the downlink channel, to recover the long code sequence, the eavesdropper intercepts the downlink traffic channel, demodulates the intercepted data frames, and dispreads the data frames using the Walsh code specific to the channel. [35]

By exploiting information redundancy on the downlink traffic channel, it is shown that an eavesdropper can recover the voice privacy mask after eaves-dropping the transmission on the downlink traffic channel for about one second. Thus, IS-95 CDMA voice privacy is vulnerable under ciphertext-only attacks. [34]

The vulnerability of the voice privacy may have an effect on the security of the authentication process since the long code mask is generated during the authentication process. [35]

cdmaOne/ IS-95 CDMA systems had the following security weaknesses [36]:

Extensive cryptanalysis of algorithms used that results in weak authentication, data protection and user anonymity.

64-bit keys used, are found to be too short for strong encryption.

Unilateral authentication of the user by the network; lack of mutual authentication. In the context of CAVE, the term authentication refers to primarily unilateral mechanisms that allow the network to validate the authenticity of the roaming mobile station (MS) [46]. This can lead to false base station attacks [47].

5.2 Security Issues in the Third Generation (3G) and Third Generation Transitional (3.5G [25]/ 3.95G [26]) Mobile Communication Systems

5.2.1 The Third Generation Partnership Project-based (3GPP-based) Mobile Communication Systems3G security features counteract many security threats in 2G system. The 3G security architecture is much secure than 2G system.

However, with the introduction of higher data rates and a subsequent growing usage of Internet-related services by users, which is achieved by the opening-up of earlier closed telecom networks connecting to external data networks and non-3GPP networks (in the case of roaming), all this opens up the 3G system to vulnerabilities that are similar to those of data networks.

In such scenarios, attacks on 3G networks can be classified as follows [38]:

a) Interception [38]: The attacker intercepts information, for example, reads signaling messages on a cable (connecting to 3G Core Network Entities), but does not modify or delete them. This is a passive attack. This affects the privacy of the subscriber and the network operator. The attacker may use the data obtained from interception to analyze traffic and eliminate the competition provided by the network operator.

b) Fabrication/Replay [38]: In this case the attacker may insert spurious objects into the system. These objects depend on the level of the attackers physical access to the system. For example, in a 3G Core Network Entity cable attack, the attacker may insert fake signaling messages. In a 3G Core Network Entity Access attack, the attacker may insert fake service logic or fake subscriber data into this system. The effects could result in the attacker masquerading as an authority figure.

c) Modification of Resources [38]: The attacker causes damage by modifying system resources. For example, in a 3G Core Network Entity cable attack, the attacker may modify signaling messages in and out of the cable. In a 3G Core Network Entity Access attack, the attacker may modify service logic or modify subscriber data in the entity.

d) Denial Of Service [38]: The attacker causes an overload or a disruption in the system such that network functions in an abnormal manner. The abnormal behaviour could be legitimate subscribers not receiving service, illegitimate subscribers receiving service or the entire network may be disabled as a result of the attack. For example, Denial of Service may be caused by the changing of the Call

GISFI


Forwarding (CF) number since the victim does not gain access to the voice message or the call itself. Sending two or three call forward numbers to the Session Control Agent at the MSC may cause confusion and the call may not be handled properly.

e) Interruption [38]: The attacker caused an Interruption by destroying resources. For example, in a 3G Core Network Entity cable attack, the attacker may delete signaling messages in and out of the cable. In a 3G Core Network Entity Access attack, the attacker may delete a subscriber data in the entity such as an HLR and the attacker may not receive service. For example, in the CF case, In the Interruption attack, the attacker may delete certain target subscriber profiles in the data sources so that they may not receive CF service. At the Mail server, the emails in the Post office data store may be deleted. Service logic of certain entities may be completely deleted such as the CFS Filtering Agent so that they may be unable to provide any service.

5.2.2. The Third Generation Partnership Project 2-based (3GPP2-based) Mobile Communication Systems

5.2.2.1 The CDMA2000 1x Mobile Communication Systems [39] [40]

CDMA uses the CAVE algorithm for authentication along with encryption algorithms like Cellular Message Encryption Algorithm (CMEA) and ORYX for privacy and integrity of data. These algorithms were considered to be secure till recent times. But it is now known that there are possible cryptanalytic attacks possible on these algorithms as documented in [41] [42]. The attacks are similar to those conducted on GSM system namely known plaintext and known cipher text attacks. As with GSM-based systems, CDMA2000 1x systems are vulnerable to rogue networks because of the lack of authentication on the network side.

Voice traffic in CDMA2000 1x systems is not encrypted, but is scrambled using spread spectrum techniques. This makes it difficult to eavesdrop on voice traffic, but not impossible; specialized equipment for this purpose does exist. However, both the spread spectrum scrambling and the data encryption algorithms (E-CMEA and ORYX) only protect the traffic between the mobile station and the core network infrastructure. Once traffic reaches the core network, it is decrypted and remains in the clear to the other end of the call. If the other end of the call is also a CDMA 2000 1x mobile station, the traffic will be re-encrypted only for the wireless portion between the core network and the end mobile station. [40]

5.2.2.2 The CDMA2000 1xEV-DO Mobile Communication Systems [43]

The CDMA2000 1xEV-DO (Revision 0) addresses some of the vulnerabilities present in CDMA2000 1x. The cryptographic algorithms that are used in 1xEV-DO are well known and have been fully analyzed for weaknesses. However, encryption is applied only to the air interface as in the case of CDMA2000 1x; it is not end-to-end. If an operator uses 1xEV-DO with the older algorithms, that implementation will be subject to the same vulnerabilities as CDMA2000 1x. Without Enhanced Subscriber Authentication (ESA) and Enhanced Subscriber Privacy (ESP), mutual authentication is not supported and voice traffic is scrambled but not encrypted. No vulnerability information was found concerning Revision A of 1xEV-DO.

5.2.3 Security Issues (perceived) in the 3GPP Fourth Generation (4G [27]) Mobile Communication SystemsUnlike existing networks, which are partially IP-based, LTE networks are all-IP networks. When devices are connected to IP networks, with their own IP addresses, they become vulnerable to attack in much the same way as personal computers: devices can be hacked, spoofed or infected with viruses. [44]

Also with the significant processing capability improvements on the end-user device types, these devices now operate using full-fledged Operating Systems (OSs), similar to those of Personal Computers. Recent examples of such end-user device and computer convergence are that of the announcements of the same OS working on computers, tablets and smartphones. Smartphones and connected tablets are suddenly very more capable to run botnets and viruses, especially

GISFI


as new services such as file-sharing and more advanced messaging services will emerge for smartphones and tablets.

One paper that presents/analyzes possible security challenges with LTE systems can be found at [48].

6 List of Mandatory and Optional Security Features derived from 3GPP (33-series) Security Technical Specifications

6.1 From 3GPP TS 33.102, V11.3.0, (2012-06) (Release 11) [49]:Title: 3G Security; Security Architecture[49]

Document

Section/ Sub-section No.

Security Mechanism Mandatory Optional

6.4.3 Cipher Key and Integrity key lifetime – at call-set-up

6.4.5

Security mode set-up procedure: Initiation of integrity protection of signalling messages at each new signalling connection establishment between MS and VLR/SGSN

6.4.5

Exception case: Security mode set-up procedure: Signalling connection establishment and the only result is periodic location registration, i.e. no change of any registration information

6.4.5

Exception case: Security mode set-up procedure: There is no MS-VLR/SGSN signalling after the initial L3 signalling message sent from MS to VLR/SGSN, i.e. in the case of deactivation indication sent from the MS followed by connection release

6.4.5

Exception case: Security mode set-up procedure: The only MS-VLR/SGSN signalling after the initial L3 signalling message sent from MS to VLR/SGSN, and possible user identity request and authentication (see below), is a reject signalling message followed by a connection release

6.4.5

Exception case: Security mode set-up procedure: VLR/SGSN to start integrity protection before sending a reject signalling message that causes the CSG list on the UE to be modified

6.4.5

Exception case: Security mode set-up procedure: If the call is an emergency call teleservice as defined in TS 22.003, also see section 6.4.9.2 of this TS (TS 33.102)

6.4.5 Exception case: Security mode set-up procedure: If the PS connection establishment is for an

GISFI


emergency session, see clause 6.4.9.2 of this TS (TS 33.102)

6.6 Access link data confidentiality (as mentioned in Annex J. Change History section)

6.8.10.2

Interoperation and handover between UMTS and GSM: SRVCC from circuit switched UTRAN/GERAN to HSPA: CS to PS HO command (sent from source BSC/RNC to ME) is integrity protected for UTRAN

6.8.10.2

Interoperation and handover between UMTS and GSM: SRVCC from circuit switched UTRAN/GERAN to HSPA: CS to PS HO command (sent from source BSC/RNC to ME) is ciphered for UTRAN and GERAN

Annex C: C.3 Sequence number management profiles: Age limit for sequence numbers

Annex I: I.3Security mechanisms for interfaces with RNCs in exposed locations: For Iu and Iur, tunnel mode IPsec implementation

Annex I: I.3Security mechanisms for interfaces with RNCs in exposed locations: Transport mode IPsec implementation on Iu and Iur

Sub-section 6.4.9.2: Emergency Call handling [49]:

Security procedures (Integrity Protection and Ciphering) not applied:

As a serving network option, emergency calls, or PS connections for emergency sessions, may be established without the network having to apply the security mode procedure as defined in TS 24.008.

The following are the only cases where the "security procedure not applied" option may be used:

a) Authentication is impossible because the (U)SIM is absent;

b) Authentication is impossible because the serving network cannot obtain authentication vectors due to a network failure;

c) Authentication is impossible because the (U)SIM is not permitted to receive non-emergency services from the serving network (e.g. there is no roaming agreement or the IMSI is barred);

Authentication is possible but the serving network cannot successfully authenticate the (U)SIM.

GISFI


6.2 From 3GPP TS 33.401, V11.4.0, (2012-06) (Release 11) [50]:Title: 3GPP System Architecture Evolution (SAE); Security architecture [50]

Document



5.1.3.1User-to-Network security: User data and signalling data confidentiality: Ciphering requirements: RRC signalling confidentiality

5.1.3.1User-to-Network security: User data and signalling data confidentiality: Ciphering requirements: NAS signalling confidentiality

5.1.3.1User-to-Network security: User data and signalling data confidentiality: Ciphering requirements: User plane confidentiality protection done at PDCP layer

7.5Security Procedures between UE and EPS Access Network Elements: Signalling procedure for periodic local authentication

9.2.2

Security interworking between E-UTRAN and UTRAN: Handover Procedure from UTRAN to EUTRAN: A) Handover signalling in case of successful handover: The UTRAN HO command is integrity protected

9.2.2

Security interworking between E-UTRAN and UTRAN: Handover Procedure from UTRAN to EUTRAN: A) Handover signalling in case of successful handover: The UTRAN HO command is ciphered

9.2.2

Security interworking between E-UTRAN and UTRAN: Handover Procedure from UTRAN to EUTRAN: B) Subsequent NAS signalling: A Tracking Area Update (TAU) procedure following handover from UTRAN to E-UTRAN is mandatory if the Tracking Area has changed (TS 23.401)

9.2.2

Security interworking between E-UTRAN and UTRAN: Handover Procedure from UTRAN to EUTRAN: B) Subsequent NAS signalling: A Tracking Area Update (TAU) procedure following handover from UTRAN to E-UTRAN is mandatory if the Tracking Area has not changed (TS 23.401)

11

Network Domain Control Plane protection: Integrity protection of IP based control plane signalling for EPS and E-UTRAN shall be done according to NDS/IP

11Network Domain Control Plane protection: For S1-MME and X2-C, tunnel mode IPsec is mandatory to implement on the eNB

GISFI


11

Network Domain Control Plane protection: In case control plane interfaces are trusted (e.g. physically protected), protection according to TS 33.210 and TS 33.310

11Network Domain Control Plane protection: Transport mode IPsec for implementation on the X2-C and S1-MME

12 Backhaul link user plane protection: On the X2-U and S1-U, transport mode IPsec implementation

12Backhaul link user plane protection: Tunnel mode IPsec implementation on the eNB for X2-U and S1-U

14.3.1

SRVCC between E-UTRAN and Circuit Switched UTRAN/GERAN: SRVCC from circuit switched UTRAN/GERAN to E-UTRAN: Handover signalling in case of successful handover: Integrity Protection of the CS to PS HO command, sent from the RNC/BSC to the UE, in the UTRAN

14.3.1

SRVCC between E-UTRAN and Circuit Switched UTRAN/GERAN: SRVCC from circuit switched UTRAN/GERAN to E-UTRAN: Handover signalling in case of successful handover: Ciphering of the CS to PS HO command, sent from the RNC/BSC to the UE, in the UTRAN or in GERAN (TS 33.102)

Annex D: D.2.1

Security for Relay Node Architectures: Solution: General: In the case of a USIM-RN binding solution realized using certificates, the support for certificate-based procedures detailed in TS 33.401 (Annex D)

Annex D: D.2.1

Security for Relay Node Architectures: Solution: General: In the case of a USIM-RN binding solution realized using symmetric pre-shared keys, the support for pre-shared-key-based procedures detailed in TS 33.401 (Annex D)

Annex D: D.3.2

Secure Channel Profiles: APDU secure channel profile: For encryption, AES-CBC support as specified in ETSI TS 102 484

Annex D: D.3.2

Secure Channel Profiles: APDU secure channel profile: Other encryption algorithms support, specified in ETSI TS 102 484

Annex D: D.3.2

Secure Channel Profiles: APDU secure channel profile: For integrity protection, AES-CMAC support as specified in ETSI TS 102 484

Annex D: D.3.3.2

Secure Channel Profiles: Key agreement based on certificate exchange: Common profile for RN and UICC certificate: The subject name format support with "(C=<country>), O=<Organization Name>, CN=<Some distinguishing name>"

Annex D: D.3.3.3

Secure Channel Profiles: Key agreement based on certificate exchange: RN certificate profile: The

GISFI


support of the countryName (C) and serialNumber attributes in the subject name

6.3 From 3GPP TS 33.210, V12.0.0, (2012-06) (Release 12) [51]:Title: 3G security; Network Domain Security (NDS); IP network layer security [51]

Document



5.1Key management and distribution architecture for NDS/IP: Security services afforded to the protocols: Data integrity protection

5.1Key management and distribution architecture for NDS/IP: Security services afforded to the protocols: Data origin authentication

5.1Key management and distribution architecture for NDS/IP: Security services afforded to the protocols: Anti-replay protection

5.1

Key management and distribution architecture for NDS/IP: Security services afforded to the protocols: Confidentiality (with limited protection against traffic flow analysis)

5.4.1

Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-1 (IKEv1): For IKEv1 phase-1 (ISAKMP SA): Support of 3DES in CBC mode for confidentiality

5.4.1

Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-1 (IKEv1): For IKEv1 phase-1 (ISAKMP SA): Support of AES in CBC mode (RFC 3602) for confidentiality

5.4.1

Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-1 (IKEv1): For IKEv1 phase-1 (ISAKMP SA): Support of SHA-1 for integrity/message authentication

5.4.1

Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-1 (IKEv1): For IKEv1 phase-1 (ISAKMP SA): Support of Diffie-Hellman group 2 for Diffie-Hellman exchange

5.4.1

Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-1 (IKEv1): For IKEv1 phase-2 (IPsec SA): Perfect Forward Secrecy

5.4.1 Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-1

GISFI


(IKEv1): For IKEv1 phase-2 (IPsec SA): Only IP addresses or subnet identity types (address types)

5.4.1

Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-1 (IKEv1): For IKEv1 phase-2 (IPsec SA): Support of Notifications

5.4.1

Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-1 (IKEv1): For IKEv1 phase-2 (IPsec SA): Support of Diffie-Hellman group 2 for Diffie-Hellman exchange

5.4.2

Key management and distribution architecture for NDS/IP: Profiling of Internet Key Exchange-2 (IKEv2): For the CREATE_CHILD_SA exchange: Perfect Forward Secrecy

5.6.2

Key management and distribution architecture for NDS/IP: Network domain security key management and distribution architecture for native IP based protocols: Interface description: Za-interface (SEG-SEG): Authentication/integrity protection on the Za-interface

5.6.2

Key management and distribution architecture for NDS/IP: Network domain security key management and distribution architecture for native IP based protocols: Interface description: Za-interface (SEG-SEG): Encryption on the Za-interface

5.6.2

Key management and distribution architecture for NDS/IP: Network domain security key management and distribution architecture for native IP based protocols: Interface description: Implementation of the Zb interface (NE-SEG/ NE-NE)

5.6.2

Key management and distribution architecture for NDS/IP: Network domain security key management and distribution architecture for native IP based protocols: Interface description: If Zb interface is implemented, use of encryption on this interface

Annex B: B.2Security Protection for GTP: Policy discrimination of GTP-C and GTP-U: NDS/IP support for pre-R99 versions of GTP

Annex D: D.2

Security protection of UTRAN/GERAN IP transport protocols: Protection of UTRAN/GERAN IP transport protocols and interfaces: Transport mode IPsec implementation and use on the Iur/Iurh interface, if a UTRAN node has implemented SEG functionality within the same physical entity

3GPP TS 33.210: Section 5.6.1: Network domain security architecture outline [51]:

The NDS/IP key management and distribution architecture is based on the IKEv1 protocol (RFC 2401, RFC 2407, RFC 2408, RFC 2409) or IKEv2 (RFC-5996) protocol. A number of options available in the full IETF IPsec protocol suite

GISFI


have been considered to be unnecessary for NDS/IP. Furthermore, some features that are optional in IETF IPsec have been mandated for NDS/IP and lastly a few required features in IETF IPsec have been deprecated for use within NDS/IP scope.

Additional guidelines on how to apply IPsec in SCTP are specified in RFC3554. This RFC is optional for implementation unless otherwise explicitly indicated per reference point.

6.4 From 3GPP TS 33.310, V11.0.1, (2012-07) (Release 11) [52]:Title: Network Domain Security (NDS); Authentication Framework (AF) [52]

Document



1 Scope: Implementation of Za interface according to TS 33 210

1 Scope: Implementation of Zb interface according to TS 33 210

5.2.2.2

Architecture and use cases of the NDS/AF: Use cases: Establishment of secure communications: TLS case: During connection initiation, ‘CertificateRequest message’ from TLSb to TLSa

5.2.2.2

Architecture and use cases of the NDS/AF: Use cases: Establishment of secure communications: TLS case: Verification of “CertificateVerify message” by TLSb, using TLSa’s public key

6.1.1Profiling: Certificate Profiles: Common rules to all certificates: Hash algorithm for use before signing certificate: SHA-1 and SHA-256 support

6.1.1

Profiling: Certificate Profiles: Common rules to all certificates: Country field (C) in Subject and issuer name format ((C=<country>), O=<Organization Name>, CN=<Some distinguishing name>)

6.1.1

Profiling: Certificate Profiles: Common rules to all certificates: Server field (ou) in Subject and issuer name format (cn=<hostname>, (ou=<servers>), dc=<domain>, dc=<domain>)

6.1.1

Profiling: Certificate Profiles: Common rules to all certificates: Implementation of Certificate extensions which are not mandated by TS 33 310 but which are mentioned within RFC5280

6.1.2Profiling: Certificate Profiles: Interconnection CA Certificate profile: Extensions: Non-critical authority key identifier

6.1.2Profiling: Certificate Profiles: Interconnection CA Certificate profile: Extensions: Non-critical subject key identifier

GISFI


6.1.2Profiling: Certificate Profiles: Interconnection CA Certificate profile: Extensions: Critical key usage (as specified in TS 33 310)

6.1.2Profiling: Certificate Profiles: Interconnection CA Certificate profile: Extensions: critical basic constraints (as specified in TS 33 310)

6.1.3Profiling: Certificate Profiles: SEG Certificate profile: Extensions: Non-critical authority key identifier

6.1.3Profiling: Certificate Profiles: SEG Certificate profile: Extensions: Non-critical subject key identifier

6.1.3 Profiling: Certificate Profiles: SEG Certificate profile: Extensions: Non-critical subjectAltName

6.1.3Profiling: Certificate Profiles: SEG Certificate profile: Extensions: critical key usage, (as specified in TS 33 310)

6.1.3Profiling: Certificate Profiles: SEG Certificate profile: Extensions: Non-critical Distribution points (as specified in TS 33 310)

6.1.3aProfiling: Certificate Profiles: TLS entity certificate profile: Extensions: non critical authority key identifier

6.1.3aProfiling: Certificate Profiles: TLS entity certificate profile: Extensions: non critical subject key identifier

6.1.3aProfiling: Certificate Profiles: TLS entity certificate profile: Extensions: critical key usage (as specified in TS 33 310)

6.1.3a Profiling: Certificate Profiles: TLS entity certificate profile: Extensions: non-critical extended key usage

6.1.3a Profiling: Certificate Profiles: TLS entity certificate profile: Extensions: non-critical Distribution points

6.1.4Profiling: Certificate Profiles: SEG CA certificate profile: Extensions: non critical authority key identifier

6.1.4Profiling: Certificate Profiles: SEG CA certificate profile: Extensions: non critical subject key identifier

6.1.4Profiling: Certificate Profiles: SEG CA certificate profile: Extensions: critical key usage (as specified in TS 33 310)

6.1.4Profiling: Certificate Profiles: SEG CA certificate profile: Extensions: critical basic constraints (as specified in TS 33 310)

6.1.4a Profiling: Certificate Profiles: TLS client/server CA certificate profile: Extensions: non critical authority

GISFI


key identifier

6.1.4aProfiling: Certificate Profiles: TLS client/server CA certificate profile: Extensions: non critical subject key identifier

6.1.4aProfiling: Certificate Profiles: TLS client/server CA certificate profile: Extensions: critical key usage (as specified in TS 33 310)

6.1.4aProfiling: Certificate Profiles: TLS client/server CA certificate profile: Extensions: critical basic constraints (as specified in TS 33 310)

6.1aProfiling: CRL Profile: Hash algorithm for use before signing CRL: SHA-1 (except for newly created CRLs) and SHA-256 support

6.2a.1Profiling: TLS Profiling: TLS Profile: The TLS server always sends its own end entity certificate in the Server Certificate message

6.2a.1Profiling: TLS Profiling: TLS Profile: The TLS client sends its own end entity certificate in the Certificate message if requested by the TLS server

6.2a.1

Profiling: TLS Profiling: TLS Profile: Cross-certificates shall not be sent by the TLS entities in the TLS handshake as they are available locally to the TLS entities

9.4.3Certificate Enrolment for Base Stations: Certificate Profiles: Vendor CA Certificate: the CRL distribution point extension in the certificate

9.5.3

Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIHeader Field: The field “protection” of PKIMessage and the field “protectionAlg” of PKIHeader

9.5.3Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIHeader Field: The usage of the transactionID field

9.5.3Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIHeader Field: The usage of the senderNonce and the recipNonce fields

9.5.4.2

Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIBody Field: Initialization Request: The publicKey field of the CertTemplate which shall contain the public key of the base station to be certified by the RA/CA

9.5.4.2

Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIBody Field: Initialization Request: If the poposkInput field of type POPOSigningKeyInput within POPOSigningKey field is used, the (usage of) sender field within POPOSigningKeyInput

9.5.4.2 Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIBody Field: Initialization Request: If either the subject field or

GISFI


the publicKey field of the CertTemplate field is omitted, according to IETF RFC 4211, the poposkInput field (usage)

9.5.4.2

Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIBody Field: Initialization Request: The extraCerts field of the PKIMessage carrying the initialization request which shall contain the base station certificate provided by the vendor

9.5.4.3

Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIBody Field: Initialization Response: the certificate field in CertorEncCert (the transfer shall not be encrypted)

9.5.4.3

Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIBody Field: Initialization Response: The extraCerts field of the PKIMessage carrying the initialization response which shall contain the operator root certificate and the RA/CA certificate (or certificates if separate private keys are used for signing of certificates and CMP messages)

9.5.4.4

Certificate Enrolment for Base Stations: CMPv2 Profiling: Profile for the PKIBody Field: Key Update Request and Key Update Response: The extraCertsField which shall contain the base station certificate related to the private key used for signing the PKIMessage

9.6

Certificate Enrolment for Base Stations: CMPv2 Transport: Support for transport of CMPv2 messages between end entities (network elements) and RA/CA, using HTTP-based protocol as specified in draft-ietf-pkix-cmp-transport-protocols, for communication initiated by the end entities where every CMP request triggers a CMP response message from the CA or RA

9.6

Certificate Enrolment for Base Stations: CMPv2 Transport: Support for transport of CMPv2 messages between end entities (network elements) and RA/CA, using HTTP-based protocol as specified in draft-ietf-pkix-cmp-transport-protocols, for RA/CA initiated HTTP requests (i.e. announcements)

Annex ETLS Protocol Profile: For TLS compression, CompressionMethod.null support as specified in TLS 1.2 (RFC 5246)

Annex E TLS Protocol Profile: Support of compression methods as specified in RFC 3749

Annex ETLS Protocol Profile: Support of the cipher suite TLS_PSK_WITH_AES_128_CBC_SHA256 specified in RFC 5487

Section 8: Backward compatibility for NDS/IP NE's and SEGs [52]:

GISFI


NDS/IP describes an authentication framework whereby the initial IKEv1/IKEv2 authentication is based on the Pre-shared Secret Key (PSK) authentication method. NDS/AF describes an optional authentication framework which enables NDS/IP end entities (NEs and SEGs) to perform the initial IKEv1/IKEv2 authentication based on the RSA Signatures authentication method. An NDS/AF compliant end entity shall also contain NDS/IP functionality. However, an NDS/IP compliant end entity need not contain NDS/AF functionality unless specifically mandated by TS 33.210 or any other 3GPP specification.

Annex A: Critical and non-critical Certificate Extensions [52]:

A receiving SEG or TLS entity shall be able to process an extension marked as critical that is mandatory to support in NDS/AF. When optional to support, a received extension marked as critical shall lead to an error according to RFC 5280

Annex E: TLS Protocol Profile [52]:

The rules on allowed and mandatory cipher suites given in TLS 1.2 (RFC 5246) shall be followed. In addition, the mandatory cipher suite of TLS 1.1 (RFC 4346) shall be supported.

6.5 From 3GPP TS 33.402, V11.4.0, (2012-06) (Release 11) [53]:Title: 3GPP System Architecture Evolution (SAE); Security aspects of non-3GPP accesses [53]

Document



5.2

Security Features Provided by EPS for non-3GPP Accesses: User data and signalling data confidentiality: Provision of User data confidentiality between the UE and the PDN GW as defined in clause 9.2.2 of TS 33 402 when DS-MIPv6 is used

5.3

Security Features Provided by EPS for non-3GPP Accesses: User data and signalling data integrity: Provision of user data integrity between the UE and the PDN GW as defined in clause 9.2.2 of TS 33 402 when DS-MIPv6 is used

6.3

Authentication and key agreement procedures: Fast re-authentication procedure for trusted access: Usage of UE and 3GPP AAA server implementation of fast re-authentication for EAP-AKA'

8.2.3

Establishment of security between UE and ePDG: Mechanisms for the set up of UE-initiated IPsec tunnels: Tunnel fast re-authentication and authorization: Usage of UE and 3GPP AAA server implementation of fast re-authentication for EAP-AKA'

9.2.1.1

Security for IP based mobility signalling: Host based Mobility: MIPv4: General: The MIPv4 signalling messages protection between the UE and the node acting as FA (non-3GPP access specific)

9.2.1.2.1 Security for IP based mobility signalling: Host

GISFI


based Mobility: MIPv4: Bootstrapping of MIPv4 FACoA parameters: Procedures: Inclusion of the MN-FA Authentication Extension (AE) as specified in RFC 3344, in UE Registration Request (RRQ) message to the FA as specified in TS 23.402

9.2.2.2.2

Security for IP based mobility signalling: Host based Mobility: DS-MIPv6: Bootstrapping of DSMIPv6 parameters: Fast re-authentication and authorization: Usage of UE and 3GPP AAA server implementation of fast re-authentication for the use of EAP-AKA with DSMIPv6

9.3.1.2

Security for IP based mobility signalling: Network based Mobility: Proxy Mobile IP: PMIP security requirements: Confidentiality Protection for protecting PMIP messages

9.3.1.3

Security for IP based mobility signalling: Network based Mobility: Proxy Mobile IP: PMIP security mechanisms: For the case of an interface between two entities in the same security domain, the protection of the interface by means of IPsec, according to TS 33.210

11

Network Domain Security: For the case of an interface between two entities in the same security domain, the protection of the interface by means of IPsec, according to TS 33.210

6.6 From 3GPP TS 33.320, V11.6.0, (2012-06) (Release 11) [54]:Title: Security of Home Node B (HNB) / Home evolved Node B (HeNB) [54]

Document



4.1

Overview of Security Architecture and Requirements: System architecture of H(e)NB: UE access control by HNB-GW, in the case of non-CSG capable UEs or non-CSG capable HNBs

4.1

Overview of Security Architecture and Requirements: System architecture of H(e)NB: UE access control by HNB, in the case of non-CSG capable UEs or non-CSG capable HNBs

4.1Overview of Security Architecture and Requirements: System architecture of H(e)NB: Deployment of HeNB-GW

4.1Overview of Security Architecture and Requirements: System architecture of H(e)NB: Deployment of Local Gateway (L-GW)

4.4.2 Overview of Security Architecture and Requirements: Security Requirements and

GISFI


Principles: Requirements on H(e)NB: Authentication of the hosting party of the H(e)NB by the SeGW in cooperation with the AAA server using EAP-AKA as specified in RFC 4187

4.4.5

Overview of Security Architecture and Requirements: Security Requirements and Principles: Requirements on Backhaul Link: Implementation of IPsec for the backhaul link

4.4.5

Overview of Security Architecture and Requirements: Security Requirements and Principles: Requirements on Backhaul Link: Use of IPsec for the backhaul link (based on operator policy)

4.4.5

Overview of Security Architecture and Requirements: Security Requirements and Principles: Requirements on Backhaul Link: Hosting Party Module (HPM) authentication

4.4.5

Overview of Security Architecture and Requirements: Security Requirements and Principles: Requirements on Backhaul Link: Support of a suitable layer 2 protection mechanism for backhaul link protection, if the H(e)NB is configurable not to use IPsec

4.4.7

Overview of Security Architecture and Requirements: Security Requirements and Principles: Requirements on Local Gateway (L-GW): Local Gateway (L-GW), from a security point of view

4.4.8

Overview of Security Architecture and Requirements: Security Requirements and Principles: Requirements on the Direct Link between H(e)NBs: The support of direct links between two H(e)NBs as specified in clause 4.3.4 (Interface between H(e)NBs)

4.4.8

Overview of Security Architecture and Requirements: Security Requirements and Principles: Requirements on the Direct Link between H(e)NBs: Usage of the security procedures with IKEv2/IPsec on the direct links

5.2Security Features: Device Mutual Authentication: For/In H(e)NB, the device mutual authentication support between H(e)NB and SeGW

5.3

Security Features: Hosting Party Mutual Authentication: Performing the hosting party mutual authentication by the operator’s network, following successful device mutual authentication between H(e)NB and SeGW.

6.3.1

Security Procedures in H(e)NB: Measures for Clock Protection: Clock Synchronization Security Mechanisms for H(e)NB: Use of other secure clock servers, which do not use the secure backhaul link

7.2.1 Security Procedures between H(e)NB and SeGW:

GISFI


Device Authentication: General: Support of an appropriate authentication mechanism for mutual authentication of H(e)NB and SeGW, if the H(e)NB is configurable not to use IPsec

7.2.2

Security Procedures between H(e)NB and SeGW: Device Authentication: SeGW and Device Mutual Authentication Procedure: Support of the SHA-1 and SHA-256 hash functions, if H(e)NB checks the revocation status of the SeGW certificate using OCSP as specified in RFC 2560 and OMA-WAP-OCSP (Open Mobile Alliance OMA-WAP-OCSP V1.0: "Online Certificate Status Protocol Mobile Profile")

7.2.2

Security Procedures between H(e)NB and SeGW: Device Authentication: SeGW and Device Mutual Authentication Procedure: Support for OCSP for the operator network

7.2.2

Security Procedures between H(e)NB and SeGW: Device Authentication: SeGW and Device Mutual Authentication Procedure: Support for the extension to IKEv2 in H(e)NB and SeGW, for the SeGW to include OCSP response within IKEv2 according to RFC 4806 when OCSP communication between H(e)NB and OCSP server may use the in-band signaling of certificate revocation status in IKEv2

7.2.2

Security Procedures between H(e)NB and SeGW: Device Authentication: SeGW and Device Mutual Authentication Procedure: Support of the SHA-1 and SHA-256 hash functions, if SeGW checks the revocation status of the H(e)NB certificate using CRLs according to TS 33.310 or OCSP as specified in RFC 2560 and OMA-WAP-OCSP (Open Mobile Alliance OMA-WAP-OCSP V1.0: "Online Certificate Status Protocol Mobile Profile")

7.2.4

Security Procedures between H(e)NB and SeGW: Device Authentication: SeGW/IKEv2 Processing Requirements for H(e)NB Certificates: Certificate status checking by SeGW, due to the existence of a CRL or OCSP server information in the H(e)NB certificate

7.2.5.2.1

Security Procedures between H(e)NB and SeGW: Device Authentication: Security Profiles: IKEv2 Certificate Profile: IKEv2 Entity Certificates: OCSP server information in the SeGW certificate, if OCSP extension according to RFC 4806 is used

7.3

Security Procedures between H(e)NB and SeGW: Hosting Party Authentication: Performing an EAP-AKA-based hosting party authentication exchange by SeGW, after Device Authentication of the H(e)NB by the SeGW

7.5 Security Procedures between H(e)NB and SeGW: Device Authorization: Use of a AAA server to verify the authorization of the H(e)NB to connect to the operator’s network based on the authenticated

GISFI


device identity extracted from the H(e)NB certificate

8.1.1

Security Aspects of H(e)NB Management: Location Verification: General: Storage of one or more types of location information of H(e)NB in the verifying node by operators for location verification.

8.1.6

Security Aspects of H(e)NB Management: Location Verification: Requirements: Storage of ancillary information by the verifying node to perform location verification such as geo-coordinates of surrounding macrocells, postal address of H(e)NB as claimed by H(e)NB hosting party, IP address location information, etc.

8.3.2.1

Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: Connection to H(e)MS accessible on public Internet: General: Support of the SHA-1 and SHA-256 hash functions, if H(e)NB checks the revocation status of the H(e)MS certificate using OCSP as specified in RFC 2560 and OMA-WAP-OCSP (Open Mobile Alliance OMA-WAP-OCSP V1.0: "Online Certificate Status Protocol Mobile Profile")

8.3.2.1

Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: Connection to H(e)MS accessible on public Internet: General: Support for OCSP for the operator network

8.3.2.1

Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: Connection to H(e)MS accessible on public Internet: General: Support for the extension to TLS in H(e)NB and H(e)MS, if OCSP communication between H(e)NB and OCSP server may use the in-band signaling of certificate revocation status in TLS according to TLS Extensions as specified in Annex E of TS 33.310

8.3.2.1

Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: Connection to H(e)MS accessible on public Internet: General: Support of the SHA-1 and SHA-256 hash functions, if the H(e)MS checks the revocation status of the H(e)NB certificate using CRLs according to TS 33.310 or OCSP as specified in RFC 2560 and OMA-WAP-OCSP (Open Mobile Alliance OMA-WAP-OCSP V1.0: "Online Certificate Status Protocol Mobile Profile")

8.3.3.1

Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: TLS certificate profile: TLS entity certificates: OCSP server information in the H(e)MS certificate, if OCSP extension to TLS according to TLS Extensions as specified in Annex E of TS 33.310 is used

GISFI


8.3.4

Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: TR-069 protocol profile: Use of TLS to transport the CPE WAN Management Protocol, in case that the H(e)MS is accessible on public internet or when TLS is used within the IPsec tunnel

8.3.4

Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: TR-069 protocol profile: The support of TLS cipher suite RSA_WITH_RC4_128_SHA

8.3.4

Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: TR-069 protocol profile: The support for H(e)NB authentication using client-side (CPE side) certificates

8.5.1

Security Aspects of H(e)NB Management: Enrolment of H(e)NB to an Operator PKI: General: Support and usage of enrolment of a H(e)NB to an operator PKI

8.5.1

Security Aspects of H(e)NB Management: Enrolment of H(e)NB to an Operator PKI: General: According to TS 33 320, support of enrolment according to the clause 8.5, if the establishment of direct links between H(e)NBs according to clause 4.3.4 is supported

11.1

Security Procedures for Direct Interfaces between Base Stations: General: Due to requirement of the usage of operator certificates for all security features specified in clause 11, according to TS 33 320, the support of enrolment according to clause 8.5 of the same TS

11.2

Security Procedures for Direct Interfaces between Base Stations: Direct Link between two H(e)NBs: Support of the security procedures specified in the subclause 11.2 of TS 33 320, if direct links for Iurh or X2 interfaces as specified in clause 4.3.4 of the same TS are supported

Annex A: A.1

Authentication Call Flows: Device Authentication Call-flow Example: Inclusion of a Notify Payload in H(e)NB containing integrity information of H(e)NB with a Notification Type of INTEGRITY_INFO in the IKE_AUTH request

Annex A: A.2

Authentication Call Flows: Combined Device and HP Authentication Call-flow Example: processing of the whole EAP challenge message, including verification of the received MAC with the newly derived keying material may be performed within the H(e)NB’s HPM

Annex A: A.2

Authentication Call Flows: Combined Device and HP Authentication Call-flow Example: The computation of the AUTH parameter is performed within the H(e)NB’s HPM

GISFI


Section 7.2.2: Security Procedures between H(e)NB and SeGW: Device Authentication: SeGW and Device Mutual Authentication Procedure [54]:

NOTE 2: It is strongly recommended to support OCSP in the H(e)NB, as this feature may become mandatory for H(e)NB in future releases.

Section 8.3.2.1: Security Aspects of H(e)NB Management: Protection of H(e)MS traffic between H(e)MS and H(e)NB: Connection to H(e)MS accessible on public Internet: General [54]:

NOTE 2: It is strongly recommended to support OCSP in the H(e)NB, as this feature may become mandatory for H(e)NB in future releases.

6.7 From 3GPP TS 33.328, V10.0.0, (2011-03) (Release 10) [55]:Title: IP Multimedia Subsystem (IMS) media plane security [55]

Document



5.1IMS media plane security features: General: The support for IMS media plane security mechanisms and procedures in IMS UEs

5.1IMS media plane security features: General: The support for IMS media plane security mechanisms and procedures in IMS core network

5.2

IMS media plane security features: Media Integrity protection: The support for IMS media integrity protection in an IMS UE supporting IMS media plane security

5.2

IMS media plane security features: Media Integrity protection: The support for IMS media integrity protection in IMS core network elements (i.e., IMS Access Gateway) supporting SDES based e2ae IMS media plane security

5.2

IMS media plane security features: Media Integrity protection: The use of IMS media integrity protection, except that RTCP shall be integrity protected using SRTCP, in accordance with RFC 3711

5.3

IMS media plane security features: Media Confidentiality protection: The support for IMS media confidentiality protection in an IMS UE supporting IMS media plane security

5.3

IMS media plane security features: Media Confidentiality protection: The support for IMS media confidentiality protection in IMS core network elements (i.e., IMS Access Gateway) supporting SDES based e2ae IMS media plane security

GISFI


6.2.1.3

Security mechanisms: Key management mechanisms for media protection: Key management mechanisms for e2ae protection: Functional extension of the Iq interface for e2ae protection: Support of Cryptographic protection by NDS/IP if the P-CSCF (IMS-ALG) and IMS Access GW are located in the same security domain

6.2.1.3

Security mechanisms: Key management mechanisms for media protection: Key management mechanisms for e2ae protection: Functional extension of the Iq interface for e2ae protection: Implementation of Zb interface according to TS 33.210

6.2.1.3

Security mechanisms: Key management mechanisms for media protection: Key management mechanisms for e2ae protection: Functional extension of the Iq interface for e2ae protection: Encryption support over Za (and optional Zb) interface according to TS 33.210

6.2.2

Security mechanisms: Key management mechanisms for media protection: Key management mechanisms for e2e protection using SDES: Use of TLS, in TS 33.203

Annex B: B.2: B.2.3.1

KMS based key management: UE terminating procedures: Procedures for the case with two KMS domains: Preconditions: Confidentiality protection (over Za) because keys are transported in the clear over Zk

Annex C

SRTP profiling for IMS media plane security: Support for all mandatory features, by an IMS UE and IMS core network entity capable of supporting IMS media plane security (SDES and/or KMS based), defined in RFC 3711 except that it does not have to support key derivation rates different from zero (KDR <> 0)

Annex D: D.3: D.3.1

MIKEY-TICKET profile for IMS media plane security: Exchanges: Ticket Request: IDRkms: URI for target KMS

Annex D: D.3: D.3.1

MIKEY-TICKET profile for IMS media plane security: Exchanges: Ticket Request: IDRkms: URI for responding KMS

Annex D: D.3: D.3.3

MIKEY-TICKET profile for IMS media plane security: Exchanges: Ticket Resolve: IDRkms: URI (for populating payloads in RESOLVE_INIT_PSK as defined in TS 33 328)

Annex D: D.3: D.3.3

MIKEY-TICKET profile for IMS media plane security: Exchanges: Ticket Resolve: IDRkms: URI (for populating payloads in RESOLVE_RESP_PSK as defined in TS 33 328)

Annex E Profiling of SDES: CRYPTOGRAPHIC ALGORITHMS: cryptosuite: support and use

Annex E Profiling of SDES: CRYPTOGRAPHIC

GISFI


ALGORITHMS: cryptosuite: Additionally, support of the cryptosuite “AES_CM_128_HMAC_SHA1_80”, as defined in RFC 4568

Annex EProfiling of SDES: "KEY PARAMETERS" (ONE OR MORE TIMES):

key: support and use

Annex E

Profiling of SDES: "KEY PARAMETERS" (ONE OR MORE TIMES):

salt: support and use


Key lifetime: support and use for e2e security

Annex E


Master Key Index (MKI): Support

Annex E


Master Key Index (MKI): Use (if more than one set of key parameters is contained in the crypto attribute)

Annex E


Master Key Index (MKI): Use (if only one master key parameter is contained in the crypto attribute)

Annex E


Length of MKI field: Support


Length of MKI field: Support, if MKI is supported

Annex E


Length of MKI field: Use, if MKI is used

Annex E Profiling of SDES: “SESSION PARAMETERS” key derivation rate: support and use

Annex E Profiling of SDES: UNENCRYPTED_SRTP: Support

Annex E Profiling of SDES: UNENCRYPTED_SRTP: Use

Annex E Profiling of SDES: UNENCRYPTED_SRTCP: Support

Annex E Profiling of SDES: UNENCRYPTED_SRTCP: Use

GISFI


Annex E Profiling of SDES: UNAUTHENTICATED_SRTP: Support

Annex E Profiling of SDES: UNAUTHENTICATED_SRTP: Use

Annex EProfiling of SDES: UNAUTHENTICATED_SRTP: key parameters for the FEC stream: Support and Use

Annex E Profiling of SDES: UNAUTHENTICATED_SRTP: window size hint: Support and Use

Annex F Change History: RFC 4771 for KMS based media plane security

Annex E (normative): Profiling of SDES [55]:

This Annex contains a complete list of parameters that may be contained in an SDES crypto attribute, according to RFC 4568.

The following short-hand notation is used: “mandatory / optional to support / use” means: “This parameter shall / may be supported / used in implementations conforming to 3GPP specifications.”

The default use is that the sender omits the parameters that are optional to use.

6.8 From 3GPP TS 33.234, V11.4.0, (2012-06) (Release 11) [56]:Title: 3G security; Wireless Local Area Network (WLAN) interworking security [56]

Document



4.1.5

Security Requirements for 3GPP-WLAN Interworking: Reference points description: Implementation of reference point D’/Gr’ located between 3GPP AAA Server and pre-R6 HLR/HSS

4.2.5

Security Requirements for 3GPP-WLAN Interworking: Security Requirements: Link layer security requirements: Provision by most WLAN technologies of link-layer protection of user data

5.1.3

Security features: Authentication of the subscriber and the network and Security Association Management: Transport of WLAN Access authentication signalling between the WLAN access network and the 3GPP AAA proxy server: The support of IPsec for Diameter as stated in (IETF RFC 3588, September 2003: "Diameter base protocol")

5.1.6 Security features: Authentication of the subscriber and the network and Security Association Management: User Identity Privacy in WLAN Access: Support of the User Identity Privacy

GISFI


(Anonymity) feature for implementation in the network

5.1.6

Security features: Authentication of the subscriber and the network and Security Association Management: User Identity Privacy in WLAN Access: Support of the User Identity Privacy (Anonymity) feature for implementation in the WLAN UE

5.1.6

Security features: Authentication of the subscriber and the network and Security Association Management: User Identity Privacy in WLAN Access: Use of the User Identity Privacy (Anonymity) feature in the network

5.1.6

Security features: Authentication of the subscriber and the network and Security Association Management: User Identity Privacy in WLAN Access: Use of the User Identity Privacy (Anonymity) feature in the WLAN UE

5.1.7

Security features: Authentication of the subscriber and the network and Security Association Management: Re-authentication in WLAN Access: The use of EAP/SIM/AKA for fast re-authentication in the network, depending on operator's policies

6.1.3.1

Security mechanisms: Authentication and key agreement: EAP support in Smart Cards: EAP-AKA procedure: Implementation to have the termination of EAP in the UICC

6.1.3.2

Security mechanisms: Authentication and key agreement: EAP support in Smart Cards: EAP-SIM procedure: Implementation to have the termination of EAP in the UICC

6.1.4.1

Security mechanisms: Authentication and key agreement: Fast re-authentication mechanisms in WLAN Access: EAP/AKA procedure: The implementation of EAP/AKA including the fast re-authentication mechanism described in sub-clause 6.1.4.1. of TS 33 234

6.1.4.1

Security mechanisms: Authentication and key agreement: Fast re-authentication mechanisms in WLAN Access: EAP/AKA procedure: The use of EAP/AKA including the fast re-authentication mechanism described in sub-clause 6.1.4.1. of TS 33 234, depending on operator’s policies

6.1.4.2

Security mechanisms: Authentication and key agreement: Fast re-authentication mechanisms in WLAN Access: EAP/SIM procedure: The implementation of EAP/SIM including the fast re-authentication mechanism described in sub-clause 6.1.4.2. of TS 33 234

6.1.4.2 Security mechanisms: Authentication and key agreement: Fast re-authentication mechanisms in WLAN Access: EAP/SIM procedure: The use of

GISFI


EAP/SIM including the fast re-authentication mechanism described in sub-clause 6.1.4.2. of TS 33 234, depending on operator’s policies

6.6ASecurity mechanisms: Profile for PDG certificates: Certificate processing requirements: Support for CRLs in the UE

6.6ASecurity mechanisms: Profile for PDG certificates: Certificate processing requirements: Support for OCSP in the UE

Annex A: A.2.1.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: HIPERLAN/2 Security architecture: Confidentiality protection: Defined algorithm for confidentiality protection: Triple-DES

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Use of the Unicast encryption

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Implementation of DES algorithm (defined for confidentiality protection) for AP/CC and MT

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Implementation of Triple-DES (EDE mode) algorithm (defined for confidentiality protection) for AP/CC and MT

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: DES: Implementation of DES

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Triple-DES: Implementation of Triple-DES

Annex A: A.2.2.2

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Authentication: Implementation of Authentication with a pre-shared key

Annex A: A.2.2.2

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Authentication: Implementation of Authentication with RSA based signatures

Annex A: A.2.2.2

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Authentication: Implementation of one out of six different key identifiers

6.9 From 3GPP TS 33.105, V10.0.0, (2011-03) (Release 10) [57]:Title: 3G Security; Cryptographic Algorithm Requirements [57]

GISFI


Document



5.1.1.1

Functional algorithm requirements: Authentication and key agreement: Overview: Generation of quintets in the AuC: Concealment of the sequence number (SQN xor AK), generated by the HLR/AuC along-with the anonymity key (AK)

5.1.6.7Functional algorithm requirements: Authentication and key agreement: Type of algorithm: f5: The use of f5

5.1.6.8Functional algorithm requirements: Authentication and key agreement: Type of algorithm: f5*: The use of f5*

6.10 From 3GPP TS 33.110, V10.1.0, (2011-06) (Release 10) [58]:Title: Key establishment between a Universal Integrated Circuit Card (UICC) and a terminal [58]

Document



Annex F: F.1.1

TLS profiles: TLS profile for certificate based mutual authentication between Terminal and NAF Key Center: Introduction: Implementation of all other TLS extensions (except the server_name TLS extension) as specified in RFC 3546

Annex F: F.1.2

TLS profiles: TLS profile for certificate based mutual authentication between Terminal and NAF Key Center: Protection mechanisms: Terminal implementation of all other Cipher Suites (except CipherSuite TLS_RSA_ WITH_3DES_EDE_CBC_SHA and the CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA) as defined in RFC 2246 and RFC 3268

Annex F: F.1.2

TLS profiles: TLS profile for certificate based mutual authentication between Terminal and NAF Key Center: Protection mechanisms: NAF Key center implementation of all other Cipher Suites (except CipherSuite TLS_RSA_ WITH_3DES_EDE_CBC_SHA and the CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA) as defined in RFC 2246 and RFC 3268

Annex F: F.2.1

TLS profiles: TLS profile for Shared key-based mutual authentication between Terminal and NAF

GISFI


Key Center: Introduction: Implementation of all other TLS extensions (except the server_name TLS extension) as specified in RFC 3546

Annex F: F.2.1

TLS profiles: TLS profile for Shared key-based mutual authentication between Terminal and NAF Key Center: Protection mechanisms: Terminal implementation of all other Cipher Suites (except CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA and the CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA) as defined in PSK TLS

Annex F: F.2.1

TLS profiles: TLS profile for Shared key-based mutual authentication between Terminal and NAF Key Center: Protection mechanisms: NAF Key Centre implementation of all other Cipher Suites (except CipherSuite TLS_PSK_WITH_3DES_EDE_CBC_SHA and the CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA) as defined in PSK TLS

6.11 From 3GPP TS 33.141, V12.0.0, (2012-06) (Release 12) [59]:Title: Presence service; Security [59]

Document



4.1

Security Architecture: Overview of the security architecture: Depending on the implementation, the Presence Server may authenticate an anonymous watcher depending on the Subscription Authorization Policy

Annex DGPRS-IMS-Bundled Authentication for Ut interface security: Support of TLS in the UE and in the AS/AP in the present TS document

6.12 From 3GPP TS 33.203, V12.0.0, (2012-06) (Release 12) [60]:Title: 3G Security; Access security for IP-based services [60]

Document



5.1.4 Security features: Secure access to IMS: Integrity protection: Note 1: Support of TLS by SIP proxies

GISFI


according to RFC 3261

5.1.4 Security features: Secure access to IMS: Integrity protection: Note 1: The intra-domain Zb interface

6.4 Security mechanisms: Hiding mechanisms: Implementation of the Hiding Mechanism

7.1

Security association set-up procedure: Security association parameters: Note 6: An already existing TCP connection may be reused by both the P-CSCF or the UE

7.1

Security association set-up procedure: Security association parameters: Note 9: An already existing TCP connection may be reused by both the P-CSCF or the UE

Annex H

The use of "Security Mechanism Agreement for SIP Sessions" for security mode set-up: The Algorithm parameter (Defines the authentication algorithm)

Annex L: L.2

Application to fixed broadband access: Application of clause 4: In 3GPP IMS, the ISIM to be present on UICC which is usually inserted within the MT component of the UE

Annex M: M.7.1

Enhancements to the access security for IP based services to enable NAT traversal for signaling messages: Security association set-up procedure: Security association parameters: Note: An already existing TCP connection may be reused by both the P-CSCF or the UE

Annex N: N.1Enhancements to the access security to enable SIP Digest: SIP Digest: Implementation of the provisions in Annex N

Annex N: N.1Enhancements to the access security to enable SIP Digest: SIP Digest: Use of the provisions in Annex N

Annex N: N.1

Enhancements to the access security to enable SIP Digest: SIP Digest: The use of one of the authentication mechanisms in the present TS document

Annex N: N.2.1.1

Enhancements to the access security to enable SIP Digest: Authentication: Authentication Requirements: Authentication Requirements for Registrations: If “IMPI*” in SIP Message-1 (SM1), the inclusion of the IP Multimedia Private Identity (IMPI) in SM1

Annex N: N.2.1.1

Enhancements to the access security to enable SIP Digest: Authentication: Authentication Requirements: Authentication Requirements for Registrations: The inclusion of the IMPI and an Authorization header in SM7

Annex O: O.1.1

Enhancements to the access security to enable TLS: TLS: TLS Access Security: Implementation of the

GISFI


provisions in Annex O

Annex O: O.1.1

Enhancements to the access security to enable TLS: TLS: TLS Access Security: Use of the provisions in Annex O

Annex O: O.5.1

Enhancements to the access security to enable TLS: TLS Certificate Profile and Validation: TLS Certificate: CRL distribution point in the certificates

Annex O: O.5.3

Enhancements to the access security to enable TLS: TLS Certificate Profile and Validation: Certificate Revocation: Implementation of CRL infrastructure

Annex P: P.3

Co-existence of authentication schemes IMS AKA, GPRS-IMS-Bundled Authentication, NASS-IMS-bundled authentication, SIP Digest and Trusted Node Authentication: P CSCF procedure selection: For NASS-IMS-bundled authentication (NBA), the inclusion of an Authorization header in a REGISTER request

Annex P: P.3

Co-existence of authentication schemes IMS AKA, GPRS-IMS-Bundled Authentication, NASS-IMS-bundled authentication, SIP Digest and Trusted Node Authentication: P CSCF procedure selection: For Session Initiation Protocol (SIP) Digest, the inclusion of an Authorization header in a REGISTER request

Annex P: P.3

Co-existence of authentication schemes IMS AKA, GPRS-IMS-Bundled Authentication, NASS-IMS-bundled authentication, SIP Digest and Trusted Node Authentication: P CSCF procedure selection: The P CSCF to insert a P-Access-Network-Info header containing the "network-provided" parameter, under the additional conditions that the REGISTER request contains no Authorization header and was received over an access network other than TISPAN NASS or 3GPP

Annex P: P.3

Co-existence of authentication schemes IMS AKA, GPRS-IMS-Bundled Authentication, NASS-IMS-bundled authentication, SIP Digest and Trusted Node Authentication: P-CSCF procedure selection: The removal of a P-Access-Network-Info header with the "network-provided" parameter for PANI-aware P-CSCFs even when the access network is not a TISPAN NASS

Annex P: P.6

Co-existence of authentication schemes IMS AKA, GPRS-IMS-Bundled Authentication, NASS-IMS-bundled authentication, SIP Digest and Trusted Node Authentication: Considerations on the Cx interface: For NASS-IMS-bundled authentication (NBA) the inclusion of an Authorization header in a registration request

Annex Q: Q.1Usage of the authentication mechanisms for non-registration messages in Annexes N and O: General: TLS, according to Annex O

GISFI


Annex Q: Q.1

Usage of the authentication mechanisms for non-registration messages in Annexes N and O: General: The IP address check, according to Annex N

Annex Q: Q.1

Usage of the authentication mechanisms for non-registration messages in Annexes N and O: General: The SIP Digest proxy-authentication, according to Annex N

Annex S: S.2Application to 3GPP2 Access: Application of clause 4: For the purposes of this Annex, the presence of the UICC in the UE

Annex S: S.5.4.2.1

Application to 3GPP2 Access: Network Domain Security for IMS: Profiles of Network Domain Security Methods: Support of IPsec ESP: General: The Confidentiality security service provided by network domain security

Annex S: S.5.4.2.2

Application to 3GPP2 Access: Network Domain Security for IMS: Profiles of Network Domain Security Methods: Support of IPsec ESP: Support of ESP authentication and encryption: Support of the ESP_3DES algorithm as default

Annex S: S.5.4.2.2

Application to 3GPP2 Access: Network Domain Security for IMS: Profiles of Network Domain Security Methods: Support of IPsec ESP: Support of ESP authentication and encryption: Support for the AES CBC cipher algorithm (RFC 3602)

Annex T: T.4

GPRS-IMS-Bundled Authentication (GIBA) for Gm interface: GIBA Security Mechanism: When using IPv6, stateless autoconfiguration is the only IP address allocation method supported by the terminal in GPRS

6.13 From 3GPP TS, 33.220, V11.3.0, (2012-06) (Release 11) [61]:Title: Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) [61]

Document



4.1Generic Bootstrapping Architecture: Reference Model: Support of the reference point Zh’ for/by the BSF

4.2.3

Generic Bootstrapping Architecture: Network elements: HSS: Note 2: GBA User Security Settings (GUSS) shall be able to contain the timestamp indicating the time when the GUSS has been last modified by the HSS

GISFI


4.2.3

Generic Bootstrapping Architecture: Network elements: HSS: Note 3: These parameters (mentioned in sub-section 4.2.3). And if these parameters are missing from subscriber's GUSS or subscriber does not have GUSS then the BSF will use the default values in the BSF local policy defined by the particular MNO

4.4.4

Generic Bootstrapping Architecture: Requirements and principles for bootstrapping: Requirements on reference point Ub: Note 3: Protection of IMPI by TLS tunnel

4.4.5

Generic Bootstrapping Architecture: Requirements and principles for bootstrapping: Requirements on reference point Zh: Note 1: The BSF may have the capability able to send the timestamp of subscriber's GBA user security settings to the HSS (timestamp option)

4.4.5

Generic Bootstrapping Architecture: Requirements and principles for bootstrapping: Requirements on reference point Zh: Note 1: The HSS may have the capability to indicate to the BSF whether the BSF already has the latest copy of the GUSS based on the GUSS timestamp (timestamp option)

4.4.12

Generic Bootstrapping Architecture: Requirements and principles for bootstrapping: Requirements on reference point Zh’: Support of the reference point Zh’ for/by the BSF

4.5.2

Generic Bootstrapping Architecture: Procedures: Bootstrapping procedures: Note 4: Ua uses a protocol which transfers the host name (FQDN of NAF as used by UE) to NAF (e.g. HTTP/1.1 with Host request header field)

Annex I: I.02G GBA: Introduction: This annex specifies the implementation to allow the use of SIM cards or SIMs on UICC for GBA.

Annex I: I.2.3

2G GBA: Network Elements: HSS: Note 2: Requirements on HSS are: GUSS shall be able to contain the timestamp indicating the time when the GUSS has been last modified by the HSS

Annex I: I.2.3

2G GBA: Network Elements: HSS: Note 3: These parameters (mentioned in sub-Annex I.2.3). And if these parameters are missing from subscriber's GUSS or subscriber does not have GUSS then the BSF will use the default values in the BSF local policy defined by the particular MNO

Annex I: I.4.5

2G GBA: Requirements and principles for bootstrapping: Requirements on reference point Zh: Note 1: The BSF may have the capability able to send the timestamp of subscriber's GBA user security settings to the HSS (timestamp option)

Annex I: I.4.5 2G GBA: Requirements and principles for bootstrapping: Requirements on reference point Zh: Note 1: The HSS may have the capability to

GISFI


indicate to the BSF whether the BSF already has the latest copy of the GUSS based on the GUSS timestamp (timestamp option)

Annex I: I.5.2

2G GBA: Procedures: Bootstrapping procedures: Note 4: Ua uses a protocol which transfers the host name (FQDN of NAF as used by UE) to NAF (e.g. HTTP/1.1 with Host request header field)

Annex I: I.6 2G GBA: TLS Profile: Support of certificate revocation and of the related fields in certificates

Annex J: J.1

Usage of USS with local policy enforcement in BSF: General: 1) Access control within NAF for Ua requests: Upon receiving the B-TID from the UE, the NAF fetches the USSs, which typically contain NAF specific persistent user identities, and authorization flags

Annex M: M.3.4

GBA_Digest: Network Elements: HSS: Note 2: GUSS shall be able to contain the timestamp indicating the time when the GUSS has been last modified by the HSS

Annex M: M.3.4

GBA_Digest: Network Elements: HSS: Note 3: These parameters (mentioned in Annex M.3.4). And if these parameters are missing from subscriber's GUSS or subscriber does not have GUSS then the BSF will use the default values in the BSF local policy defined by the particular MNO

Annex M: M.5.6

GBA_Digest: Requirements and principles for bootstrapping: Requirements on reference point Zh: Note 1: The BSF may have the capability able to send the timestamp of subscriber's GBA user security settings to the HSS (timestamp option)

Annex M: M.5.6

GBA_Digest: Requirements and principles for bootstrapping: Requirements on reference point Zh: Note 1: The HSS may have the capability to indicate to the BSF whether the BSF already has the latest copy of the GUSS based on the GUSS timestamp (timestamp option)

Annex M: M.6.3

GBA_Digest: Procedures: Bootstrapping procedures: Step 0: The use of TLS message integrity

Annex M: M.6.3

GBA_Digest: Procedures: Bootstrapping procedures: Step 0: The use of TLS encryption

Annex M: M.7.1

TLS Profile: General: Support of certificate revocation and of the related fields in certificates

6.14 From 3GPP TS 33.234, V11.4.0, (2012-06) (Release 11) [62]:Title: 3G Security; Wireless Local Area Network (WLAN) interworking security [62]

Document Security Mechanism Mandatory Optional

GISFI



4.2.5

Security Requirements for 3GPP-WLAN Interworking: Security Requirements: Link layer security requirements: WLAN technologies provide link-layer protection of user data

5.1.3

Security Features: Authentication of the subscriber and the network and Security Association Management: Transport of WLAN Access authentication signalling between the WLAN access network and the 3GPP AAA proxy server: The support of IPsec for Diameter, as stated in IETF RFC 3588(‘Diameter base protocol’, September 2003)

5.1.6

Security Features: Authentication of the subscriber and the network and Security Association Management: User Identity Privacy in WLAN Access: Implementation support of the User Identity Privacy feature in the network

5.1.6

Security Features: Authentication of the subscriber and the network and Security Association Management: User Identity Privacy in WLAN Access: Implementation support of the User Identity Privacy feature in the WLAN UE

5.1.6

Security Features: Authentication of the subscriber and the network and Security Association Management: User Identity Privacy in WLAN Access: Use of the User Identity Privacy feature in the network

5.1.6

Security Features: Authentication of the subscriber and the network and Security Association Management: User Identity Privacy in WLAN Access: Use of the User Identity Privacy feature in the WLAN UE

5.1.7

Security Features: Authentication of the subscriber and the network and Security Association Management: Re-authentication in WLAN Access: Use of EAP/SIM/AKA for fast re-authentication in the network, depending on operator's policies

6.1.4.1

Security mechanisms: Authentication and key agreement: Fast re-authentication mechanisms in WLAN Access: EAP/AKA procedure: Use of the EAP/AKA, depending on operator’s policies

6.1.4.2

Security mechanisms: Authentication and key agreement: Fast re-authentication mechanisms in WLAN Access: EAP/SIM procedure: Use of the EAP/SIM, depending on operator’s policies

6.6ASecurity Mechanisms: Profile for PDG certificates: Certificate Processing Requirements: k) Support for CRLs in the UE

GISFI


6.6ASecurity Mechanisms: Profile for PDG certificates: Certificate Processing Requirements: k) Support for OCSP in the UE

Annex A: A.2.1.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: HIPERLAN/2 Security architecture: Confidentiality protection: Triple-DES

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Use of the Unicast encryption

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Implementation of DES algorithm for confidentiality protection in AP/ CC

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Implementation of DES algorithm for confidentiality protection in MT

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Implementation of Triple-DES (EDE mode) algorithm for confidentiality protection in AP/ CC

Annex A: A.2.2.1

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Confidentiality: Implementation of Triple-DES (EDE mode) algorithm for confidentiality protection in MT

Annex A: A.2.2.2

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Authentication: Implementation of Authentication with a pre-shared key

Annex A: A.2.2.2

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Authentication: Implementation of Authentication with RSA based signatures

Annex A: A.2.2.2

Review of the security of existing WLAN-related technologies: ETSI/BRAN: Security mechanisms: Authentication: Implementation of one out of six available, different key identifiers

6.15 From 3GPP TS 33.246, V10.0.0, 2010-12 (Release 10) [63]:Title: 3G Security; Security of Multimedia Broadcast/Multicast Service (MBMS) [63]

Document



GISFI


4.2

MBMS security overview: Key management overview: Support for master key lengths of 128, 192 and 256 bits for SRTP, according to RFC 3711 (Secure Real-time Transport Protocol) it is mandatory

6.3.2.1A

Security mechanisms: Key management procedures: MSK procedures: MBMS User Service Registration procedure: Implementation of the Back off mode in the BM-SC

6.3.2.1A

Security mechanisms: Key management procedures: MSK procedures: MBMS User Service Registration procedure: Implementation of the Back off mode in the UE

6.4.5.1

Security mechanisms: MIKEY message creation and processing in the ME: MIKEY message structure: MSK message structure: Inclusion of the SP payload into MSK delivery messages by the BM-SC, when the MSK delivery was not triggered by the UE using the MSK request procedure or the MBMS User Service Registration procedure

6.6.2.1ASecurity mechanisms: Protection of the transmitted traffic: Protection of streaming data: Usage of SRTCP: Encryption of SRTCP packets

Annex B: B.1

Security threats: Threats associated with attacks on the radio interface: Encryption of the MBMS service announcement at RAN level, in case it is transferred over HTTP

Annex C: C.5MBMS security requirements: Requirements on integrity protection of MBMS User Service data: R6a: Use of integrity

Annex L Multicasting MBMS user data on Iub: The use of confidentiality protection

7 Void

8 Void

9 ConclusionsTo be prepared

GISFI


Annex A: Change history

Change historyDate TSG # TSG Doc. CR Rev Subject/Comment Old New2012- 09- 13

Initial Release

2012- 11-13

Added contents to Section 4 – 6 from GISFI Input documents GISFI_SP_201206261, GISFI_SP_201209282 and GISFI_SP_201209286

GISFI


GISFI


Documents

GISFI GICT.105 - Global ICT Standardisation Forum · Web view. [34] IS-95 security issue: Abstract: . [35] Muxiang Zhang, Christopher Carroll and Agnes