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]
