Network Working Group S. Zhang Internet-Draft J. Huang Intended status: Experimental Southeast University Expires: January 05, 2014 July 04, 2013 A privacy protection scheme for AKA agreement in 3rd Generation Partnership Project(3GPP) standard draft-zhang-aka-privacy-3gpp-00 Abstract This document contains a privacy protection scheme for the AKA agreement in the 3GPP standards. Specifically, this document RECOMMENDS that each user owns a encryption key updated in real time, with which to encrypt the user identity. Comparing with the asymmetric encryption and alias assignment, the symmetric encryption scheme proposed in this document not only reduce the computation burden, but also prevent the legal user from being located and tracked. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 05, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Zhang & Huang Expires January 05, 2014 [Page 1] Internet-Draft Abbreviated-Title July 2013 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. What is the User Identity Confidentiality . . . . . . . . 3 1.2. Overview of the AKA Agreement . . . . . . . . . . . . . . 3 2. Related Work about the Privacy Protection . . . . . . . . . . 5 3. The AKA Agreement with Privacy Protection . . . . . . . . . . 5 3.1. Format of the Key Library . . . . . . . . . . . . . . . 5 3.2. The Improved AKA Flow . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 5.1. Normative References . . . . . . . . . . . . . . . . . . 9 5.2. Informative References . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction In the 3gpp standard, the element in core network exchanges authentication information of AKA protocol with user to achieve mutual authentication and key negotiation. Although AKA agreement has overcome the security vulnerabilities of GSM system effectively, many security issues still can't be resolved such as the disclosure of user identity. So, a new scheme is proposed in this document to achieve user identity confidentiality. Zhang & Huang Expires January 05, 2014 [Page 2] Internet-Draft Abbreviated-Title July 2013 1.1. What is the User Identity Confidentiality The following security features related to user identity confidentiality are provided[TS_25.331_3GPP]: user identity confidentiality: the property that the permanent user identity (IMSI) of a user to whom a service is delivered cannot be eavesdropped on the radio access link; user location confidentiality: the property that the presence or the arrival of a user in a certain area cannot be determined by eavesdropping on the radio access link; user untraceability: the property that an intruder cannot deduce whether different services are delivered to the same user by eavesdropping on the radio access link. +--------------------------------------------------------------------+ | Mobile Country | Mobile Network | Mobile Subscriber Identification | | Code(MCC) | Code (MNC) | Number (MSIN) | +--------------------------------------------------------------------+ | |<---National Mobile Subscriber Identification----->| | | (NMSI) | |<----------International Mobile Subscriber Iedntity(IMSI)---------->| Figure 1 IMSI structure As figure 1, the permanent user identity (IMSI) of a user is composed of MCC, MNC and MSIN. MSIN identifies a user uniquely, while MCC and MNC are used to provide the routing information of its HLR. To realize the user identity confidentiality, the MSIN is protected to avoid the attacker obtaining this information. Therefore, this document proposes a new IMSI protection method, that is, to assign a real-time updated encryption key for each user and encrypt the MSIN with it, which not only protects the user identity privacy, but also prevents the user from being illegally loacted and tracked. 1.2. Overview of the AKA Agreement AKA is an acronym of the Authentication and Key Agreement protocol in third generation mobile communication network[TS_25.331_3GPP]. The protocol is a safety specification proposed by the International Mobile Telecommunications Organization 3GPP( The Third Generation Partnership Project ) according to the security demand in 3G access domain, based on the security vulnerability of 2G network. Using the challenge-response mechanism, AKA agreement completes the authentication and the key negotiation between the user and the network. The main flow of AKA agreement is as follows: Zhang & Huang Expires January 05, 2014 [Page 3] Internet-Draft Abbreviated-Title July 2013 MS VLR/SGSN HLR | USER IDENTITY REQUEST | | |<---------------------------| | | USER IDENTITY RESPONSE | | | [IMSI] | AUTHENTICATION DATA REQUEST | |--------------------------->| [IMSI] | | |----------------------------------->| | | AUTHENTICATION DATA RESPONSE | |USER AUTHENTICATION REQUEST | [AVs] | | [RAND(i)||AUTN(i) |<-----------------------------------| |<---------------------------| +------------------------------+ | |USER AUTHENTICATION RESPONSE| | AV=RAND||XRES||CK||IK||AUTN | | | [RES(i)] | | AUTN=(SQN xor AK)||AMF||MAC | | |--------------------------->| | MAC=f1(k,SQN||RAND||AMF) | | | | | XRES=f2(k,RAND) AK=f5(k,RAND)| | | | | CK=f3(k,RAND) IK=f4(k,RAND) | | | | +------------------------------+ | Figure 2 The standard process of AKA agreement (1) Upon receipt of the service request, the VLR/SGSN will send the authentication data request message to the HLR, but the IMSI message is in plaintext form. (2) Upon receipt of the authentication data request message, the HLR will retrieve a key K shared with MS according to the IMSI message. Then, HLR will send the response message with the authentication vector array AVs to the VLR/SGSN. (3) After receiving the AVs, the VLR/SGSN will store them in the database and retrieve an unused vector when authenticate a user. Then, he will sent a user authentication request messages to the MS, including RAND and AUTN. (4 )After receiving the authentication data RAND||AUTN from the VLR/ SGSN, the MS verifies the network identity. If succeed, the MS will calculate the response value RES=f2(k,RAND) and sent it to the VLR/ SGSN, getting the encryption key IK and integrity key CK. (5) After receiving the RES value, the VLR/SGSN verifies the user identity. If succeed, he will retrieve a CK and a IK from a database as the encryption key and the integrity key. Otherwise, the VLR/SGSN will send a failure report to the MS. From the AKA agreement flow, some facts can be noticed that although the core network can achieve mutual authentication between the user and the network and complete the negotiation of communication key, but the IMSI message is transmitted in plaintext form, which will Zhang & Huang Expires January 05, 2014 [Page 4] Internet-Draft Abbreviated-Title July 2013 lead to leakage of user privacy. The user MAY suffer from being located and tracked. 2. Related Work about the Privacy Protection In the 3GPP specification[TS_25.331_3GPP], a temporary mobile subscriber identity(TMSI) is used to protect the user identity. But in some cases, such as, when the user initially registers in network, or when the serving network cannot retrieve the IMSI from the TMSI, the user will response the IMSI information in plaintext form, which will threaten the safety of the user identity. Therefore, some researchers use encryption or alias allocation to achieve IMSI protection, and encryption method is divided into symmetric encryption and asymmetric encryption. The literature[MobSeUseconf][EnConfAKA] use HLR public key to encrypt IMSI information, and the literature[ResImpro] adds a public key update measure based on the literature[MobSeUseconf], but the asymmetric encryption will increase large computation overhead for mobile devices. In the literature[KerImpiden], a HLR and all of his clients share a key. When the user submits IMSI information, he will use a encryption key generated by the sharing key to encrypt IMSI information. However, the method has a risk of sharing key exposure, once the sharing key is leaked, all users belonged to the HLR MAY be attacked. Therefore, the literature[EnhIdnAKA] suggests that each user uses their own root key Ki to encrypt IMSI information, and the HLR traverses the stored (IMSI, Ki) records and decrypts. Encrypting with the root key, we can avoid the disadvantages of the sharing key, but a large amount of calculation will be in the network terminal and the efficiency will be low. The method that replaces the IMSI with updated identification[ImpIdncon][EtoEIdnConf][EnhIdnPri] can guarantee the confidentiality and untraceability of the user identity, but the network terminal needs to maintain a large identification library because the corresponding user identity will frequently changed. 3. The AKA Agreement with Privacy Protection 3.1. Format of the Key Library +--------+--------+--------+--------+ | KEY_ID | KEY | STATUS | TIME | +--------+--------+--------+--------+ | K_ID1 | K1 | USED | T1 | | K_ID2 | K2 | FREE | T2 | | ...... | ...... | ...... | ...... | | K_IDn | Kn | USED | Tn | +--------+--------+--------+--------+ Zhang & Huang Expires January 05, 2014 [Page 5] Internet-Draft Abbreviated-Title July 2013 Table 1 structure of key library in HLR Table 1 shows the structure of key library in HLR. The key library is composed of multiple records, each record includes four properties, that is, the key identification number KEY_ID, encryption key KEY, operating situation STATUS and the update time TIME. Operating situation indicates whether the key has been assigned to the user. If not, the mark will be FREE, otherwise the mark will be USED. The time mark of this record is immediately updated. Upon receipt of the authentication request, HLR extracts the decryption key corresponding to K_IDold and updates the STATUS to FREE. Then from those records whose state is FREE, the HLR allocates a key identification and the corresponding key to the user, and update the STATUS of this record to USED. But in the allocation process, the user movement or transmission error and other reasons MAY lead to failure in identification allocation, thus multiple users MAY use a same key. In this case, the security of IMSI information will not be affected because of its encryption transmission. In addition, if a key_ID cannot be allocated successfully, this key_ID will keep USED state for a long time and present a dead phenomenon, which means that this key can not be allocated again. For such kind of condition, this document utilizes the time stamp to judge whether the record is in the working state. For a certain record, if his status is USED and Tupdate>Tdied , the system can determine that this record have already been dead. So the STATUS of this record will be updated to FREE, and the system releases this key_ID. 3.2. The Improved AKA Flow MS VLR/SGSN HLR | USER IDENTITY REQUEST | | |<--------------------------------| | | USER IDENTITY RESPONSE | | |[HLR_ID||K_IDold||f11(Kold,MSIN)]| AUTHENTICATION DATA REQUEST | |-------------------------------->| [HLR_ID||K_IDold||f11(Kold,MSIN)] | | |------------------------------------>| | | AUTHENTICATION DATA RESPONSE | | USER AUTHENTICATION REQUEST | [AVs||IMSI] | | [RAND(i)||AUTN(i)] |<------------------------------------| |<--------------------------------| +---------------------------------+ | | USER AUTHENTICATION RESPONSE | | AVin=RANDin||XRES||CK||IK||AUTN | | | [RES(i)] | | AUTN=(SQN xor AK)||AMF||MAC | | |-------------------------------->| | RANDin=F(Ki,Knew||K_IDnew||RAND)| | | | +---------------------------------+ | Zhang & Huang Expires January 05, 2014 [Page 6] Internet-Draft Abbreviated-Title July 2013 Note:HLR_ID=MCC||MNC, which is used to provide routing information of HLR. K_IDold and Kold refer to the key identification and encryption key currently used; K_IDnew and Knew refer to the key identification and encryption key newly allocated. Figure 3 AKA protocol flow with protected user privacy The improved AKA agreement flow with enhanced privacy confidentiality is described below: (1) The VLR/SGSN launches a user identity request message to the MS, which requests the MS' IMSI information. (2) The MS responses the encrypted MSIN information, combining with HLR_ID to be the encrypted IMSI information. Meanwhile, the MS submits the key identification K_IDold, which indicats the current encryption key. The encrypted IMSI information is HLR_ID||K_IDold||f11(Kold,MSIN). The USIM card will store a key identification and the corresponding encryption key, and the initial value is randomly distributed by the key library of the HLR while the USIM card is generated. (3) Upon receipt of the response messages from the MS, the VLR/SGSN will send the authentication data request message to HLR according to the routing information provided by HLR_ID. This message includes the encrypted IMSI information and the encryption key identification K_IDold. (4) According to the received K_IDold, the HLR extracts the corresponding decryption key to retrieve the MS' IMSI and changes the corresponding state to FREE. After that, HLR will produce the authentication vectors for this user: AV=RAND||XRES||CK||IK||AUTN AUTN=(SQN xor AK)||AMF||MAC MAC=f1(k,SQN||RAND||AMF) XRES=f2(k,RAND) AK=f5(k,RAND) CK=f3(k,RAND) IK=f4(k,RAND) Then the HLR distributes a new key identification K_IDnew and an encryption key Knew to the user, and embeds them into the RAND of AVs with the embedding function F, as figure 4 shows. Zhang & Huang Expires January 05, 2014 [Page 7] Internet-Draft Abbreviated-Title July 2013 Ki----------->--------+ +-------|------+ RAND---------->| F |----->RANDin +-------|------+ K_IDnew||Knew--->------+ Figure 4 Produce process of RANDin So, we will obtain the authentication vector AVin=RANDin||XRES||CK||IK||AUTN. Finally, the HLR will send the new authentication vectors and IMSI information to the VLR/SGSN: AVs||IMSI. (5) The VLR/SGSN stores the authentication vectors AVs and IMSI information transmitted from the HLR. When a user is authenticated, the VLR/ SGSN selects an unused authentication vector and sends the authentication request message to the MS, including the RAND(i)||AUTN(i) in authentication vector. (6) The MS uses the inverse function F' of embedding function F to extract K_IDnew||Knew and random number RAND, as figure 5 shows. Ki----------->--------+ +-------|------+ RANDin-------->| F' |----->RAND and K_IDnew||Knew +-------|------+ Figure 5 Extraction process with extracting function F' With the data in AUTN(i)=(SQN xor AK)||AMF||MAC and the retrieved random number RAND, we computer below data: AK=f5(K,RAND) SQN=(SQN xor AK) xor AK XMAC=f1(K,SQN||RAND||AMF) To compare the XMAC with the MAC, we continue to verify whether SQN belongs to the normal range if they match. If the sequence number is not fresh, the VLR/SGSN will send synchronous failure message to the user and end the authentication process, otherwise the authentication of network identity is successful. Next, the MS calculates the response value RES=f2(K,RAND) and sends it to the VLR/SGSN, then calculates the encryption key CK=f3(K,RAND) and the integrity key IK=f4(K,RAND) for network communication. At the same time, the MS stores K_IDnew and Knew as the new key identification and new encryption key to protect IMSI. (7) Upon receipt of the RES, the VLR/SGSN will compare the XRES with the RES, the authentication of the user is successful if they match, and the VLR/SGSN will select CK and IK from authentication vector as Zhang & Huang Expires January 05, 2014 [Page 8] Internet-Draft Abbreviated-Title July 2013 the encryption key and the integrity key for communication, respectively. Otherwise, the user authentication is failed. 4. Security Considerations IMSI information is the only identification of a user, if this message is intercepted by the attacker, it is easy to loacte and track the user. In this document, we use the timing updated encryption key to protect the confidentiality of the user identity. The user always provides encrypted IMSI information to HLR, thus the attacker cannot obtain plaintext IMSI. What's more, the HLR will constantly update the encryption key assigned to the user, which means that the form of each encrypted IMSI information is different from each other. Thus the improved method can prevents the user from being located and tracked. 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2. Informative References [EnConfAKA] Jacques, B., Hakima, C., and A. Mohammad, "Ensured confidentiality authentication and key agreement protocol for EPS", 2012. [EnhIdnAKA] Daniel, C. and S. Charles, "UMTS security: Enhancement of identification, authentication and key agreement protocols", 2011. [EnhIdnPri] Hiten, C., Basav, R., and K. Dilip, "Enhancing User Identity Privacy in LTE", 2012. [EtoEIdnConf] Hiten, C., Basav, R., and K. Dilip, "End-to-End User Identity Confidentiality for UMTS Networks", 2010. [ImpIdncon] Behnam, S., Mahdi , A., and J. Rasool, "Improved user identity confidentiality for UMTS mobile networks", 2007. [KerImpiden] Zhang & Huang Expires January 05, 2014 [Page 9] Internet-Draft Abbreviated-Title July 2013 Anish, P. and J. Kyu, "Kerberos based authentication protocol with improved identity protection in 3G network", 2009. [MobSeUseconf] Saraireh, J., Yousef, S., and M. Nabhan, "Enhancement Mobile Security and User Confidentiality for UMTS", 2006. [ResImpro] Wang, L. and Z. Gao, "Research On An Improved Proposal Of 3G Security", 2011. [TS_25.331_3GPP] 3rd Generation Partnership Project, "Technical Specification Group Services and System Aspects;3G Security;Security architecture (Release 11)", December 2012. Authors' Addresses Sha Zhang Southeast University N0.9, Mo Zhoudong street Nan Jing, Jiang Su Province 210096 RPC China Phone: 15251864199 Email: ShaZhangjs@aliyun.com Jie Huang Southeast University N0.9, Mo Zhoudong street Nan Jing, Jiang Su Province 210096 RPC China Phone: 13675178016 Email: jhuang@seu.edu.cn Zhang & Huang Expires January 05, 2014 [Page 10]