Internet DRAFT - draft-zhang-aka-privacy-3gpp

draft-zhang-aka-privacy-3gpp







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]