Improved User Identity Confidentiality for UMTS Mobile ... - CiteSeerX

Improved User Identity Confidentiality for UMTS Mobile Networks Behnam Sattarzadeh, Mahdi Asadpour, and Rasool Jalili Computer Engineering Department, Sharif University of Technology, Tehran, Iran Emails: sattarzadeh@ce., asadpur@ce., jalili@
sharif.edu Abstract In UMTS mobile networks, there are some circumstances that the International Mobile Subscriber Identity (IMSI) of a user is conveyed in clear-text over the radio interface. Such situations violate the anonymity of users. In this paper, we introduce an Improved User Identity Confidentiality (IUIC) mechanism which attempts to avoid the drawback and makes users more anonymous. We give the role of IMSI to anonymous tickets in such a way that IMSI is never exposed on the radio interface or over any other link. Our IUIC mechanism employs symmetric cryptography based on the existing network access security features of UMTS. Its implementation, security, and performance issues are also considered.

1 Introduction The Universal Mobile Telecommunication System (UMTS) is one of the most popular third generation (3G) mobile communication systems being standardized by the 3rd Generation Partnership Project (3GPP) [1]. Compared to its predecessor, the Global System for Mobile Communication (GSM), UMTS supports higher data transmission rate with enhanced security and cost effectiveness. The security mechanisms of UMTS are discussed in many resources [2, 3, 4]. Generally speaking, there are three parties communicating in these mechanisms: the Home Environment (HE), the Serving Network (SN), and the Mobile Station (MS) which represents the user. Network access security, a key component of UMTS security architecture [5], provides users with secure access to UMTS services, while it assumes that the wireline links (e.g. between SN and HE, or between two SNs) are adequately secure. One of the network access security features is UMTS Authentication and Key Agreement (UMTS-AKA) procedure. UMTS-AKA performs mutual authentication and key agreement between an MS and the network, and consists of two phases. The first phase involves distribution of

MS

SN TMSI

HE IMSI

Figure 1. Overall view of UMTS identification.

some authentication vectors as security credentials from HE to SN, while HE trusts that SN securely handles the vectors. The second phase consumes one authentication vector to perform mutual authentication through a challengeresponse mechanism, and also establish a new pair of cipher and integrity keys between MS and SN. The established keys will be used to protect confidentiality and integrity of data transmitted on the radio link. Another feature of network access security is provision of user identity confidentiality against sniffers on radio links with the following requirements: 1-The International Mobile Subscriber Identity (IMSI) of a user as its permanent identity cannot be eavesdropped (identity confidentiality), 2-The presence or arrival of a user in a certain area cannot be determined (location confidentiality), and 3-Delivery of different services to the same user cannot be deduced (untraceability). Actually, these properties are considered as anonymity of users [6], in identification mechanism of UMTS network. To achieve these objectives, IMSI identifies MS only in the wireline parts of the network. SN issues a local temporary identity called TMSI to the visiting MS and keeps the association between TMSI and IMSI in its database. TMSI is normally used for identification on the radio link between MS and SN (see Figure 1). It is occasionally reallocated by SN not to be used for a long period of time, and should be transferred in protected mode (using the cipher key established by UMTS-AKA), whenever possible. An MS when roams into a new SN, identifies itself with TMSI assigned by the old SN. The new SN, which has no knowledge about IMSI, requests it from the old SN using

TMSI. The old SN searches MS data in its database and if found, sends back a response including IMSI. Finally, a fresh TMSI will be allocated to MS by the new SN. In the current specification of UMTS, there are some circumstances where IMSI is revealed on the radio link [5]. In particular, it occurs when: MS registers for the first time in an SN and has not received a valid TMSI yet; Because of a database failure in SN, IMSI cannot be retrieved from TMSI; or After roaming to a new SN, the old SN cannot be contacted or cannot retrieve IMSI. In all of the above cases, in which TMSI fails to identify MS, SN requests it to send IMSI. The response of MS contains IMSI in clear-text which represents a flaw in the protection of user identity confidentiality and should be avoided. On the other hand, SN always knows users’ IMSI while they prefer to hide this identity from anyone except HE. In this paper, we improve the identification mechanism of UMTS to overcome the mentioned drawback in providing user anonymity. We propose an improved user identity confidentiality mechanism, called IUIC, which employs anonymous tickets instead of IMSI. In this manner, a plain IMSI is never exposed over any interface including wireline path, and SN has no knowledge about IMSI. IUIC performs symmetric encryption and utilizes existing network access security features of UMTS. The rest of this paper is organized as follows. In the following section, we give an overview of related work. Our improved mechanism is introduced in section 3 followed by implementation details in section 4. Sections 5 and 6 assess security and performance aspects regarding IUIC mechanism and its components. Finally, we have a conclusion in section 7.

2 Related Work Anonymity can be provided to the mobile users through encrypting IMSI or assigning some kind of alias(es) [7]. Either symmetric or asymmetric cryptography can be employed for encryption; while asymmetric methods charge heavy computation cost to the mobile station with limited computational capabilities. In the case of alias assignment, each alias should not have an unlimited life time, there should be no direct relationship among aliases to make them untraceable, and serving networks should not discover the real identity of users [8]. To the best of our knowledge, there is no much research work attempting to overcome the anonymity weakness of UMTS.

In 1999, Vinch et al. [9] presented a security architecture for UMTS, based on research work conducted by the USECA project [10]. In their architecture, each MS belongs to a group and keeps the group key shared among members of that group and HE. Whenever TMSI fails to identify MS, confidentiality is achieved through symmetric encryption of IMSI using the group key. Subsequently, encrypted IMSI and group identity are transmitted over the radio link. Determining the exact size of the group is a critical point in Vinch et al.’s scheme. If the group size is too small, group identity will reveal significant information about MSs. Moreover, extracting the group key from HE or through cryptanalysis methods is worth the effort for large groups [9]. Koien [11], 2005, proposed a beyond-3G authentication and key agreement protocol. In his protocol, an MS generates a random temporary identity as an alias and provides the new alias along with IMSI to HE, encrypted with an asymmetric cryptography method. Then HE identifies MS and informs SN about that alias. Recently, in 2006, Godor et al. [12] proposed an authentication algorithm based on public-key cryptography to solve that weakness of UMTS. The main disadvantage of both schemes of Koien and Godor et al. is that they employ asymmetric cryptosystem which is not suitable for a mobile station with low computational power.

3 Improved User Identity Confidentiality Mechanism

Improved User Identity Confidentiality (IUIC) mechanism is proposed to overcome the weakness of UMTS in protecting user anonymity. In order to identify users without disclosure of their permanent identity, IUIC employs anonymous tickets as aliases of IMSI, and uses UMTS symmetric cryptography algorithms to insure the anonymity of tickets. In the following subsection, we explain a module which manages anonymous tickets and corresponding IMSIs. Next in subsection 3.2, needed modifications of UMTS identification mechanism, in order to use anonymous tickets in place of IMSI, are described. Subsection 3.3 brings the procedure of exchanging anonymous tickets that is performed whenever a plain format of user identity is required. At the last part, a summary (subsection 3.4) covers the main idea of this section, as well.


       

MS

Anonymous Ticket Manager Module (ATMM) is proposed to handle ticket related functions in HE1 . It stores/manages two tickets for each MS: one ticket with
  status and another with    status, that both of them are associated with IMSI of MS. This module responds to the following requests:



The assigned tickets should be unique and hence not be allocated to more than one MS, simultaneously. There should be no logical relationship between two anonymous tickets of an MS and its IMSI, and among different tickets assigned to an MS (chain of tickets). We make use of the above facilities of ATMM, hereafter. Our implementation of this module will be described in section 4.


          We modify UMTS identification mechanism by giving the role of IMSI to anonymous tickets. So, wherever IMSI is used in the original, now should be changed to use an anonymous ticket. TMSI still plays the same role as before, for the identification between MS and SN. Next subsection will deal with the scenarios that TMSI fails to do this duty. From ATMM we know that belong to each MS there are two anonymous tickets, say  with InUse and 
with FutUse status, in such a way that using each of which could retrieve IMSI. These assumptions are satisfied for a new registered MS, too. These tickets are stored in both MS and HE along with IMSI. SN knows only the ticket with InUse status ( ), and keeps the relation between TMSI and  in its database. As summarized in Figure 2, TMSI identifies MS for SN, and  is used between SN and HE. For retrieving IMSI, HE employs IMSI request facility of ATMM on the submitted  . Having IMSI in hand, HE can deal with its expected tasks. To clarify the application of anonymous tickets in the modified version, let us investigate on two specific cases: 1 In fact, ATMM is integrated into Authentication Center (AuC) of HE, [13].

InUse

HE




TMSI

 
FutUse

 ATMM

IMSI

Figure 2. Modified UMTS identification mechanism.

1. IMSI request: Returning IMSI of an MS using one of its tickets. 2. next ticket request: assigning a new ticket to MS, releasing one of its tickets, and updating status of each ticket respectively. This request also fulfils the following requirements:

SN TMSI

1. In the first phase of original UMTS-AKA procedure [5], SN sends an authentication data request including IMSI to HE. Utilizing IMSI, HE generates some authentication vectors, and sends them back to SN. In the modified version, the request of SN includes  instead of IMSI, and HE first retrieves IMSI from  then continues with its operations. 2. In the original UMTS, when MS roams into a new SN, IMSI is requested by this SN from the old one. But, in the modified version,  gotten the role of IMSI is included in the response received from old SN. In this manner, SNs have no knowledge about IMSI and this is one of the main motivations of our IUIC mechanism: hiding IMSI from any adversary including SNs.




       

 

SN initiates Anonymous Ticket Exchange Procedure (ATEP), whenever a TMSI cannot identify its owner or the relation between TMSI and associated ticket of MS is lost. We here explain that how ATEP identifies MS, and restores the lost relation. In the design of ATEP, we get some of our ideas from the UMTS-AKA procedure (refer to section 6.3 of 3GPP Specification [5]) that deals with authentication vectors. ATEP uses a secret key shared between MS and HE2 . It also employs MAC functions (f1, f2) and key derivation functions (f3, f4, f5) of UMTS cryptographic algorithms (see [14]). For security reasons, should never have been compromised during its lifetime. Again assume that MS has two anonymous tickets,  with InUse and 
with FutUse status. With these assumptions in mind, exchange procedure involves the following steps (also represented in Figure 3): Step 1: Visited SN generates a random number   and sends it along with a ticket request to MS. 2 Precisely, HE [5].


is a secret key shared between USIM at MS and AuC at

MS   
 


 



SN 1- ticket request (  ) 2-



   


  3-



 



    

4- 

  
 

HE


 
 


  
 
 

ATMM

 

 

 

 

 5- 



















6- 

     



7- ciphered

 

 


 

  

Figure 3. Steps of ATEP.

Step 2: Upon receipt of the request, MS generates a random number   and computes:

 
 




  

 
 

 
 




MS sends a response to SN which includes 
(that with FutUse status), and   as authentication token of MS. Step 3: SN temporary stores 
, then passes the message accompanied with   to HE. Step 4: HE sends an IMSI request with parameter 
to ATMM, acquiring related IMSI. Using this IMSI, HE gets the corresponding secret key of 
 

this MS and computes   


 
  . If the comparison between this and  
in   succeeds, then MS is authenticated by HE, because only the true MS has and can generate this term. HE acquires an anonymous ticket   from ATMM through next ticket request, with 
as input. In section 4, we will see that ATMM makes  free, and updates the status of 
and   to InUse and FutUse, respectively. HE generates a random number   and com-

putes:


                        

   
 
 

     



   
 
 

 

  is the expected response,  and are cipher and integrity keys, and  is the anonymity key.

All of them are calculated in the same way as UMTSAKA does (refer to section 6.3.2 of 3GPP Specification [5]). Finally, HE sends   as ENcrypted TicKet accompanied with   ,  and to SN. Step 5: SN stores   ,  and , then forwards the received   to MS. Since HE secures   by embedding it in   using , SN or anyone else cannot discover it. Step 6: Upon receipt of      


 
  , MS first extracts   and computes the following equations (   was sent before, in Step 1): 

 

   



 

      

MS

SN

and   

 


                  

   
 
 



MS compares    with   extracted from   . If equals, network is authenticated by MS. MS further deletes  , and saves   to be used in the next round of ATEP. It also stores  and keys. Finally, MS sends  back to SN. Step 7: SN compares the received  with the stored   . If matches, SN authenticates MS and the transmission of encrypted ticket is successfully done. If doesn’t match, SN re-sends   to MS. The stored  and initiate ciphering in both MS and SN. Then, SN performs the TMSI reallocation procedure (refer to section 6.1.2 of 3GPP Specification [5]) to assign and transfer a new TMSI (   ) to MS. SN stores the association of 
and this new    in its database. At the end, the new pair of tickets (
,  ), currently have InUse and FutUse statuses respectively, substitute the old one ( , 
) in both MS and HE. 
is stored in the database of SN to be used hereafter as the identification factor of MS in communication between SN and HE.


!  In the following, we make a summary of all materials described in IUIC section, in order to provide a clearer explanation of the main idea. Initially, let the state of the system be (see Figure 4a): MS has two anonymous tickets:  with InUse status and 
with FutUse status. SN associates TMSI with  in its database. TMSI identifies MS for SN, and  is used in communication between SN and HE. Typically, SN communicates with MS through TMSI. SN also communicates with HE through  to indicate which MS it refers to, however SN does not know anything about IMSI of this MS. If relation between TMSI and  is lost, and TMSI cannot be further used to identify MS, ATEP is invoked. During the execution of ATEP,  is freed and a new ticket   is assigned to this MS by ATMM. In the sequel, SN allocates a new TMSI (   )





InUse

HE


TMSI



TMSI

 
FutUse

InUse

IMSI

 
FutUse IMSI   FREE

(a)

MS

SN 

HE



 
 

 
InUse

–

  FutUse



FREE

–

 
InUse

(b)

IMSI

  FutUse IMSI

Figure 4. States of the system: (a) Initial (b) Final.

and saves this along with 
in its database to revive the missed relationship. Finally, the state of the system will be (see Figure 4b): Two anonymous tickets of MS: 
with InUse status and   with FutUse status.    and 
in database of SN.

MS is identified for SN by    , and SN uses 
in communication with HE.

4 Implementation of ATMM ATMM is designed and implemented to manage anonymous tickets in HE. As mentioned in subsection 3.1, ATMM should respond to two requests: IMSI request (returning IMSI using a ticket) and next ticket request (returning a new ticket and updating the status of tickets, respectively). In this regard, two tables and one utility function are incorporated into ATMM, as the following.

!
   " The first table is denoted by



         



and contains all available tickets in the system.  is a ticket used as an index for the table,  is the user’s IMSI,  indicates the status of the related  , and   provides a direct access to another ticket with the same IMSI. In addition,  accepts one of the
 ,

  , and   statuses. Briefly, this table stores

   

two tickets for each MS: one with InUse status and another with FutUse status; they refer to each other through PairTK fields. The remaining tickets have FREE status which means that they are not assigned to any MS, yet. The second table, which contains all FREE tickets of TicketTable, is represented by

   

   






   

This table specially contributes to (efficiently) manage ticket assignment process of next ticket request. In other words, this table can be seen as a pool of tickets that speeds up finding of a ticket with FREE status.





 

  

  

       

       



IMSI

InUse

 
IMSI FutUse  

–

FREE

 






 
IMSI InUse

 

  IMSI FutUse

 


–

–

FREE

–

!
 # $   #%  Once an IMSI request with parameter e.g.  is submitted to ATMM, it can easily retrieve the corresponding IMSI from TicketTable, because  is the index of this table. Algorithm 1 GetNextTicket(Ticket: 
) 1:  = status of 
from TicketTable 2: if  = FutUse then 3: Generate a random number  4:   = FreeTicketTable(  ) 5: FreeTicketTable(  ) =  6: ( ,IMSI,InUse,
)  ( ,-,FREE,-) 7: (
,IMSI,FutUse, )(
,IMSI,InUse, ) 8: ( ,-,FREE,-)  ( ,IMSI,FutUse,
) 9: return   10: else if  = InUse then 11: return PairTK field of 
12: else if  = FREE then 13: return error 14: end if When ATMM receives a next ticket request with a parameter e.g. 
, it calls    function. According to the Algorithm 1, GetNextTicket first finds the status of 
from TicketTable (line 1). If it is FutUse, this function generates a random number  , uses this number as an index to acquire a new ticket   from FreeTicketTable, and releases TempTicket field of 
( ) to this table (lines 3, 4, 5). In the sequel it updates TicketTable: changing the status of the row belongs to 
to InUse, and   to FutUse. Since  has been freed and added to FreeTicketTable, its status should be changed into FREE. For the other fields, due to the relation between 
and  , they should have the same IMSI and link to each other through PairTK fields. ATMM finally returns   (lines 6-9. See also Figure 5). If the status of 
is InUse (line 10), that should be a repeated request. In this case, ATMM just sends back

Figure 5. Ticket tables, before and after of running GetNextTicket on 
.

the corresponding PairTK field, which is the last ticket assigned to this user. This case usually happens when previously assigned ticket has not been successfully received by MS. Otherwise, if its status is FREE (line 12), so it must be an error. The first requirement of next ticket request was guaranteeing the uniqueness of tickets assigned to MSs. Suppose that initially we have two unique tickets for each MS assigned at the registration time. Through updating in GetNextTicket function (if any), an unused ticket is selected from free tickets and replaced with one of the tickets of MS; means that MS does not own the ticket which is assigned to another one. These sort of operations do not breach the ticket uniqueness. Applying induction, this requirement is preserved. The other requirement of next ticket request is independency between two tickets of an MS and IMSI, as well as among its chain of tickets. It is obvious that randomly selected ticket   does not have any logical relationship with IMSI. On the other hand, performing this random mechanism for several times, won’t make a relation among chain of tickets (e.g.   
   ) of a specific MS, too.

5 Security Analysis Security of IUIC is based on the security algorithms of UMTS, 
   [14, 15], and shared secret key between MS and HE. In the following, we first demonstrate that how the proposed mechanism can improve anonymity of users, then explain some security capabilities of ATEP.

&
    ' Functionality and confidentiality of IMSI, TMSI, and anonymous tickets are investigated here.

Therefore, it’s infeasible for an attacker (who eavesdrops on the radio link), not only to discover the new ticket currently assigned to an MS, but also to track it and find out this MS with this ticket uses which ticket(s), previously.

5.1.1 Confidentiality of IMSI is preserved

&
 

An anonymous ticket plays the role of IMSI, thus IMSI is never transmitted over communication links (wireless or wireline). In addition, ATMM guarantees that there is no logical relationship between that anonymous ticket and IMSI. This concludes the fact that SN or any else has no way to find IMSI and hence the confidentiality of IMSI is maintained. 5.1.2 TMSI plays the same role as in the original UMTS Similar to the identification mechanism of the original UMTS, TMSI provides anonymity of an MS in its communication with SN, whenever possible. 5.1.3 Tickets are anonymous and untraceable Once SN cannot recognize TMSI, an anonymous ticket is employed for identification. IUIC guarantees anonymity and untraceability of these tickets as: Each ticket has a restricted life time. Assume that tickets  and 
are owned by MS. When ATEP is executed with FutUse ticket 
, a new ticket   is assigned/transferred to MS, and  is freed. That means the life time of  for this MS is expired, also one ATEP execution equals to one ticket expiration. The exposure of tickets on the radio link is limited. In IUIC, the plain format of each ticket, normally, appears in the radio link just one time (at the beginning of ATEP procedure) not more. Only true MS can find out the new ticket. HE generates   that securely protects a new ticket   (Step 4 of ATEP) as:   

 

   



   
 
 

Since  part of   is just known to MS and HE through shared secret key , it’s not feasible for others to obtain that ticket except the true MS. There is no logical relationship among different tickets assigned to a specific MS. We repeat that ATMM returns free tickets randomly in response to the next ticket request. In this manner, a link or direct relation among different tickets is avoided.

 

In ATEP, integrity of transmitted messages is verified through the employment of Message Authentication Codes (MAC) based on algorithm 
. For this purpose,  
and   were calculated during Steps 2 and 4 as:


  
  
 
     

 
 

 


 

guarantee the integrity of tickets and random numbers as well. Specially, in Step 6 of ATEP, MS can check integrity/correctness of new ticket   via   , which is computed originally by HE at Step 4.

&


#$

 

The challenge-response mechanism realized by incorporating random numbers into responses, makes the replaying of corresponding messages impossible:

  of SN in response of MS:  
  

 
  , Step 2 of ATEP.






  of MS in response of HE:      
 
  , Step 4 of ATEP.






  of HE in response of MS:      , Step 6 of ATEP.

 



&
!    Is Step 4 of ATEP, HE computes   
and compares it with  
included in the received   . Because of , HE can authenticate MS as the only one that is able to generate this term. Similarly, in Step 6, MS verifies validity of   included in the received   , which results in authentication of the network (both HE and SN). In Step 7, SN compares  generated by MS with   received from HE, which leads to authentication of MS by SN. Indeed, mutual authentication is established among the entities of the ATEP procedure: MS by HE and SN, and vice versa.

&
& '$$ (  A pair of cipher and integrity keys ( and ) are established between MS and SN, during Step 7 of ATEP. Using these keys, the radio link between MS and SN is ready for secure communication, specially for transferring the new allocated TMSI (  ) to MS.

Table 1. Computational cost of ATEP procedure. Steps 1,2,3,4 MS SN HE

Steps 5,6



 




!  
!

 
       



 

 



-


      

 : random number generation time.

!  : ATMM response time for IMSI request.

! : ATMM response time for next ticket request.  : execution time of  algorithm.       : parallel execution time of       algo-



rithms.



6 Performance Analysis Performance of IUIC depends on the cost of symmetric cryptography, and managing anonymous tickets. In its evaluation, response time of ATMM, computational cost of ATEP, and needed data storage of network entities are examined.

)
 # $   *   In response to IMSI request, ATMM selects a row of TicketTable using an incoming ticket as the index, and returns the related IMSI. Since this operation is applied to the index field or primary key in database literature, it can be effectively handled by ATMM. And in response to next ticket request, ATMM calls GetNextTicket function that performs select and/or update operations on the index of TicketTable. FreeTicketTable also helps that the execution of this function becomes more efficient (see section 4). Likewise, such operations do not impose much cost to ATMM, at all.

)
 '$ '  *   Computational cost of ATEP contains random number generation (   ,   ,   ), calculation of MAC and key derivation function (  
,   ,

 ,  , ,  ), and some other low computation cost operations such as XOR () and concatenation (
). These computations can be adequately handled in MS, SN and HE. Table 1 shows the computational cost of each network entity for running ATEP procedure. The cost of TMSI reallocation process (Step 7) is not included.

)


+  * ,- 

Entities MS, SN and HE need to store the following data in relation to IUIC mechanism: MS stores two anonymous tickets, SN replaces user’s IMSI with an anonymous ticket in its database, and HE involves two additional tables,    and    , which are managed by ATMM. The number of rows of    are equal to two times of the number of users (due to two unique tickets for each user) plus the number of rows of    . Although the number of rows of     could be at least one, for making the anonymity of users stronger, it should be greater than a certain number specified by the system.

7 Conclusion In this paper, we have presented an improved user identity confidentiality mechanism called IUIC, which attempts to solve the anonymity drawback of UMTS identification mechanism. It makes use of the existing network access security features of UMTS and takes advantage of its symmetric cryptography algorithms. To avoid the exposure of IMSI on the radio link, we give the role of IMSI to anonymous tickets. TMSI still identifies MS for SN and whenever it fails, an anonymous ticket is employed. We described implementation of a ticket manager module called ATMM as a main component of IUIC, responding IMSI request and next ticket request. This module is introduced to manage and handle anonymous tickets, efficiently. Another main component is a ticket exchange procedure called ATEP, which revives the relation between TMSI and an anonymous ticket, whenever it is lost. We further modify the original identification mechanism of UMTS to use an anonymous ticket instead of IMSI. Security and performance analyses of the proposed mechanism, have also been discussed. Regarding security issues, user anonymity and provision of some security services have been investigated. Performance issues cover response time of ATMM, computational cost of ATEP, and needed data storage of network entities. Totally, IUIC promises a practical solution to improve the user identity confidentiality of UMTS, and attempts to solve its anonymity weakness, as well.

References [1] 3rd Generation Partnership Project (3GPP). [Online]. Available: http://www.3gpp.org/. [Accessed Sep. 1, 2006]. [2] K. Boman, G. Horn, P. Howard, and V. Niemi, “UMTS security,” Electronic & Communications Engineering Journal, vol. 14, no. 5, pp. 191–204, Oct. 2002. [3] G.M. Koien, “An introduction to access security in UMTS,” IEEE Wireless Communications, vol. 11, no. 1, pp. 8–18, Feb. 2004. [4] C. Xenakis and L. Merakos, “Security in third generation mobile networks.” Computer Communications, vol. 27, no. 7, pp. 638–650, May 2004. [5] 3rd Generation Partnership Project (3GPP), “TS 33.102 - 3G security; security architecture V7.0.0 (Release 7),” Dec. 2005. [6] D. Kesdogan and C. Palmer, “Technical challenges of network anonymity,” Computer Communications, vol. 29, no. 3, pp. 306–324, Feb. 2006. [7] C. -S. Park, “Authentication protocol providing user anonymity and untraceability in wireless mobile communication systems,” Computer Networks, vol. 44, no. 2, pp. 267–273, Feb. 2004. [8] D. Samfat, R. Molva and N. Asokan, “Untraceability in mobile networks,” in Proc. the 1st Annual International Conference on Mobile Computing and Networking, Berkeley, California, United States, 1995, pp. 26– 36. [9] B. Vinck, G. Horn and K. Muller, “A viable security architecture for UMTS,” in ACTS Mobile Summit, Sorrento, Italy, Jun. 1999. [10] USECA, “UMTS security architecture AC336/ATEA/WP23/DS/P/08/1,” USECA project, Deliverable 08, Mar. 2002. [Online]. Available: http://www.isrc.rhul.ac.uk/useca/Deliverables/D08.PDF. [Accessed: Sep. 1, 2006]. [11] G. M. Koien, “Privacy enhanced cellular access security,” in International Conference on Mobile Computing and Networking, Proceedings of the 4th ACM workshop on Wireless security, Cologne, Germany, 2005, pp. 57–66. [12] G. Godor, B. Varadi and S. Imre, “Novel authentication algorithm of future networks,” in International Conference on Networking, International Conference on Systems and International Conference

on Mobile Communications and Learning Technologies (ICN/ICONS/MCL’06), IEEE Computer Society, 2006, pp. 80. [13] 3rd Generation Partnership Project (3GPP), “TS 23.002 - network architecture V7.1.0 (Release 7),” Mar. 2006. [14] 3rd Generation Partnership Project (3GPP), “TS 35.105 - 3G security; cryptographic algorithm requirements V6.0.0 (Release 6),” Jun. 2004. [15] 3rd Generation Partnership Project (3GPP), “TS 35.205 - 3G security; specification of the MILENAGE algorithm set: an example algorithm set for the 3GPP authentication and key generation functions f1, f1*, f2, f3, f4, f5 and f5*; Document 1: General V6.0.0 (Release 6),” Dec. 2004.