idnits 2.17.1 draft-naresh-3gpp-security-for-5g-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 15, 2018) is 2080 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Naresh Kumar 3 Intended Status: Standards Track NIT Delhi 4 Expires: February 15, 2019 K.Verma 5 NIT Delhi 7 August 15, 2018 9 Security for 5G 10 draft-naresh-3gpp-security-for-5g-00.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html 33 Copyright and License Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Abstract 50 This document proposes a new method which provides the capability to 51 resolve issue of attack over Mobile Communication System. This 52 document assumes that the reader is familiar with some concepts and 53 details regarding Authentication and Encryption in generations of 54 Mobile Telephony. 56 Table of Contents 58 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2 Vulnerability Desription . . . . . . . . . . . . . . . . . . . . 3 60 3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 4 General Scenario . . . . . . . . . . . . . . . . . . . . . 3 62 5 Solutions of these issues . . . . . . . . . . . . . . . . . . . 4 63 6 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 64 7 Security Considerations. . . . . . . . . . . . . . . . . . . . . 5 65 8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 9 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 10 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 70 1 Introduction 71 In Mobile Communication,IMSI catching is the major issue today. 72 In order to encrypt or decrypt data between Mobile Station and Base 73 Station,various algorithms are implemented by generating keys required 74 to provide confidentiality and integrity. 76 2 Vulnerability 77 Initially whenever UE attaches for the first time[3], it sends the IMSI 78 to MME in clear text which is sent from MME to eNodeBs and from eNodeBs 79 to UEs.An attacker can request without awareness of the user by using 80 various social engineering tools and then trace messages between eNodeB 81 and UE to decode them and fetch the IMSI . There is also another Fault 82 that occurs whenever re-synchronisation occurs at the time of handover 83 because at that time also, IMSI is sent in plaintext that can easily 84 be sniffed by attacker. 86 +------------+ +----------------------+ +--------+ 87 +------+ |Fake Station| | Base Station(Actual) | |Network | 88 | | +------------+ +----------------------+ +--------+ 89 |Mobile| IMSI | IMSI | IMSI | 90 |Statio| --------> |------------> |-------------> | 91 |n | AUTN,RAND | | | 92 | |<--------- | | AUTN,RAND | 93 | | RES | RES |<-------------- 94 +------+-------> |------------> | 96 3 Terminology 97 Refer 9.2[2] for better visualisation 98 3.1 IMSI: An international mobile subscriber identity is a unique number 99 usually fifteen digits, associated with Global System for Mobile 100 Communications i.e GSM and Universal Mobile Telecommunications System 101 UMTS network mobile phone users. The IMSI is a unique number identifying 102 a subscriber 103 3.2 AUTN: Authentication Token 104 3.3 MME : Mobility Management Entity,Handling all management like 105 handover etc 106 3.4 HSS : Home Subscriber Server-User USIM Company 107 3.5 AAA :Authentication,Authorisation,accounting 108 3.6 C1,C2 : Ciphertexts 110 4 General Scenario 111 Normally in all advanced generations,excluding 1G/2G of Mobile 112 Communications "AUTHENTICATION AND KEY AGREEMENT(AKA)PROTOCOL" steps 113 are applied for Mutual Authentication: 114 1. Mutual authentication between the network and UE. 115 2. Deriving keys for confidentiality and integrity protection. 116 3. confidentiality, integrity among various Entities like core network 117 4. Temporary identity like GUTI are used to hide IMSI 119 Now there are various Algorithms like in 9.1[1],[2] that can be applied 120 in SIM and MME to generate the RES(Response),AUTN that includes sequence 121 number etc in order to get the keys that help to verify each other 122 identity and thus are required to encrypt the data for secure 123 communication.This same procedure can be applied to 5G system. 125 5 Solutions of these issues 127 Now there are two methods to achieve protection against the attacker 128 regarding IMSI catching: 130 5.1 We can use Public key Cryptosystem in order to encrypt IMSI to 131 reduce problem of IMSI Catching and that particular algorithm which has 132 been used to encrypt is confidential only to the UE and gNodeB Mobile 133 station for 5G 135 5.2 Every time a mobile SIM try to connect Base Station, it should use a 136 pseudonym IMSI that will be updated in both the station(Home Server as 137 well as Mobile SIM) and there will be checking for all updations that 138 will lead to provide Both Authenticity and Confidentiality. So each time 139 user will get the new updated IMSI and will be identified by this 140 Identity only. 141 Now coming to the main Method(Public key Cryptosystem)we have 142 implemented various algorithms based on following scheme keeping the 143 message constant: 145 +--------+ +----------+ +------+ 146 | | | Message |----> | MAC | 147 | Sender | +----------+ +------+ 148 | side | | | 149 | | | key1(Algo) | 150 | | v v 151 +--------+ C1 -----> +----------+ key2(Algo) 152 | C1||MAC |---------->C2 153 +----------+ | 154 +------------------------------------------+ 155 | (Channel) 156 | 157 +--------+ +----+---+ key2(Algo) +---------+ +--------+ 158 | | | C2 |----------->| C1||MAC |-->| MAC |----| 159 |Reciever| +--------+ +---------+ +--------+ | 160 | side | | | 161 | | | +------------+ 162 | | v | MAC==XMAC??| 163 +--------+ +-------+ +------------+ 164 | C1 |-----+ | 165 +-------+ | +--------+ 166 | +------> | XMAC | 167 key1(Algo) +--------+ 168 v 169 +--------+ 170 |Message | 171 +--------+ 173 According to the diagram, Message confidentiality and Authenticity is 174 achieved using MAC(Message Authentication code)see[RFC 6476]. We have 175 implemented three algorithms(Blowfish[],AES[RFC 3962]) 177 Implemented Algorithms and their results: 179 +------------+-----------------+------------+--------------+ 180 | PARAMETERS | FERNET(AES-128) | AES | BLOWFISH | 181 |------------+-----------------+------------+--------------+ 182 | KEY LENGTH | 128 | 128,192, |Variable key | 183 | (Bits) | | 256 |length(32,448)| 184 |------------+-----------------+------------+--------------+ 185 | ROUNDS | 10,12,14 | 10,12,14 | 16 | 186 |------------+-----------------+------------+--------------+ 187 | LEVEL OF | Medium | Highly | Excellent | 188 | SECURITY | Security | Secure | Security | 189 |------------+-----------------+------------+--------------+ 190 | ENCRYPTION | Moderate | Faster | Very fast | 191 | SPEED | | | | 192 |------------+-----------------+------------+--------------+ 193 | TIME(s) | 0.004000 | 0.004003 | 0.004008 | 194 |------------+-----------------+------------+--------------+ 196 6 IANA Considerations 198 Nil 200 7 Security Considerations 202 For solutions we have already described in section 5 We can use 203 different algorithms at different positions like at the time 204 of generation of cipher C1 or C2 etc. There is no restriction over its 205 sequence. We are considerig that the keys have already been exchanged or 206 already fixed in the center server's database corresponding to the 207 particular SIM. for more details on architecture you can see 9.2[1] 208 8 Conclusions 210 This document is mainly focussed over the major vulnerability of 211 Mobile Generations in the form of IMSI transmission in plaintext. We 212 can not only encrypt this confidential information but other details can 213 also be secured. This can be effective in upcoming 5th Generation also. 215 9 References 217 9.1 Normative References 219 [RFC 6476] Errata Exist,P. Gutmann "Using Message Authentication Code 220 (MAC) Encryption in the Cryptographic Message Syntax (CMS)" 222 [RFC 3962] K.Raeburn "Advanced Encryption Standard (AES) Encryption for 223 Kerberos 5" 225 9.2 Informative References 227 [1] https://portal.3gpp.org/desktopmodules/Specifications/Specification 228 Details.aspx?specificationId=3144. 229 [2] E. Dahlman, S. Parkvall, J. Skold, 4G: LTE/LTE-advanced for mobile 230 broadband, Academic, 2013. 231 [3] https://ieeexplore.ieee.org/document/7397256/ 232 10 Acknowledgements 234 This document is prepared for M. Tech 2nd year Major Project in 235 National Institute of Technology, Delhi. 237 Authors' Addresses 239 Naresh Kumar 240 M. Tech Student 241 Department of Computer Science & Engineering 242 National Institute of Technology, Delhi 243 Narela, Delhi-110040,INDIA 245 Phone: +91- 8839338318 246 EMail: 172211007@nitdelhi.ac.in 248 Karan Verma 249 Assistant Professor 250 Department of Computer Science & Engineering 251 National Institute of Technology, Delhi 252 Narela, Delhi-110040,INDIA 254 Phone: +91-7568169258 255 EMail: karan.verma.phd@gmail.com