Introduction:
Security is one of the most important feature of the Third Generation Wireless System. At the same time it is one of the least understood topics. The aim of this primer is to provide some information about this feature. Interested reader can refer to the documents provided in the references for detailed understanding.
The 3G security is built on the 2G (GSM) Security architecture. The 2G architecture has been proved to be robust and effective. It was hence decided that the 3G security architecture will be based on this. At the same time it was decided that the shortcomings present in the second generation systems will have to be removed. Also it was planned that new features will need to be added and the voice and data services will have to be treated the same way.
[4] provides a long list of shortcomings in the second generation security architecture. The main among them are:
- active attacks using false BTS are possible
- cipher keys and authentication data are transmitted in clear between and within networks
[3] provides a list of objectives that need to be acheived with the security architecture. It also provides with list of Security threats, etc that makes an interesting reading for the theoretical minded people.
Before we move onto the details, one last point to remember is that the security in 3G systems comprises of two things. One is the "Data Integrity" and other is "Ciphering". "Data Integrity" is the feature that makes sure that no rogue Network will be able to send unnecessary signalling messages with the intention or causing any undesired effect in an ongoing call. "Ciphering" is the feature that makes sure that all Signalling and Data messages are ciphered over the air interface so that no one can eavesdrop on them. In case of UMTS Integrity Protection is mandatory while Ciphering is optional. Integrity protection is done only on Signalling Radio Bearers whereas Ciphering is done on Signalling as well as Data Radio Bearers. They will be detailed in later sections.
Overview of Security Architecture:
There are five security feature groups that are defined. Each of these feature groups meets certain threats and accomplishes certain security objectives:
- Network access security: The set of security features that provide users with secure access to 3G services, and which in particular protect against attacks on the (radio) access link
- Network domain security: The set of security features that enable nodes in the provider domain to securely exchange signalling data, and protect against attacks on the wireline network
- User domain security: The set of security features that secure access to mobile stations
- Application domain security: The set of security features that enable applications in the user and in the provider domain to securely exchange messages
- Visibility and configurability of security: The set of features that enables the user to inform himself whether a security feature is in operation or not and whether the use and provision of services should depend on the security feature
In this primer we will discuss only about Network Access Security. Readers interested in other features can refer [5].
Figure 1: Overview of the ME registration and connection principles within UMTS for the separate CS and PS CN. (Taken from [7])
Figure 1 gives an overview of the ME registration and connection principles within UMTS with a CS service domain and a PS service domain. As in GSM/GPRS, user (temporary) identification, authentication and key agreement will take place independently in each service domain. User plane traffic will be ciphered using the cipher key agreed for the corresponding service domain while control plane data will be ciphered and integrity protected using the cipher and integrity keys from either one of the service domains.
User Confidentiality
Every user provided with a USIM is also provided with a IMSI (International Mobile Subscriber Identity). It should be possible that not one should be able to eavesdrop what services is being used by which IMSI on the radio link (air interface). Along with User identity confidentiality, it should be possible that user location confidentiality is also maintained. Nobody should be able to trace the movements of a particular user and also which users are arriving or leaving a particular area. The user should also be untraceable. By this we mean that it should not be able for anybody to find out what services are being used by a particular user.
To achieve these objectives, the following steps are taken:
- The user is allocated a temporary identity (TMSI or P-TMSI) and is identified by that.
- After a small duration, this temporary identity is changed.
- In addition to this, the user data that might reveal the user's identity is ciphered.
The Temporary Mobile Subscriber Identity (TMSI) or Packet TMSI (P-TMSI) has local significance only in the location area or the routing area in which user is registered. Outside that area it should be accompanied by appropriate LAI (Location Area Identification) or RAI (Routing Area Identification). Whenever the TMSI/P-TMSI is available, it is used to identify the user for Paging Requests, Location Update Requests, Attach Requests, Service Requests, Connection Re-Establishment and Detach Requests.
TMSI Reallocation procedure is performed to allocate new TMSI/LAI pair to a user by which he mnay subsequently be identified over the radio link. This procedure is performed after ciphering has been started (discussed in later sections). The allocation can be explained with the MSC below:
UE RNC VLR/SGSN ------ --------- ---------- | | | | | Direct Transfer | | |<------------------------------| | Downlink Direct Transfer | (TMUI Allocation Command, | |<---------------------------------| TMUIn, LAIn ) | | (TMUI Allocation Command) | | | | | | Uplink Direct Transfer | | |--------------------------------->| | | (TMUI Allocation Complete) | Direct Transfer | | |------------------------------>| | | (TMUI Allocation Complete) | | | |
Before VLR initiates this procedure, it generates new TMSI and stores the association between IMSI and TMSI in the database. It then sends the new TMSI using the Temporary Mobile User Identification (TMUI) Allocation Command. Once the mobile receives this message, it deletes the old TMSI and sends a response back to the VLR. Upon reception of TMUI Allocation Complete, VLR removes the associatino between the IMSI and the old TMSI
Sometimes it might be necessary to allow user identification on a radio path by means of the permanant subscriber identity (IMSI). This is only ever done if the user cannot be identified by temporary identity. The mechanism is shown in the MSC below.
UE RNC VLR/SGSN ------ --------- ---------- | | | | | Direct Transfer | | |<------------------------------| | Downlink Direct Transfer | (User identity request) | |<---------------------------------| | | (User Identity Request) | | | | | | Uplink Direct Transfer | | |--------------------------------->| | | (User Identity Response) | Direct Transfer | | IMSI |------------------------------>| | | (User Identity Response) | | | |
This mechanism is initiated by the VLR/SGSN that requests the user to send its permanant identity. The user's response contains the IMSI in cleartext. This mechanism is a breach in provision of user confidentiality.
Authentication and Key Agreement (AKA)
It is very important that the Serving Network is able to verify the user identity or the user. At the same time, the user should be able to verify the authenticity of the network it is connected to. To achieve these, it is assumed that entity authentication should occur at each connection set-up between the user and the network. Two mechanisms have been included:
- An Authentication mechanism using an authentication vector delivered by user's HE to the serving network.
- A local Authentication mechanism using the integrity key established between the user and serving network during the previous execution of authentication and key establishment procedure.
The AKA mechanism achieves mutual authentication by the user and the network showing knowledge of secret key K that is shared between and available only to the USIM and the AuC (Authentication Centre) in the user's HE. In addition the USIM and the HE keep track of counters SQNMS and SQNHE respectively to support network authentication. The sequence number SQNHE is an individual counter for each user and the sequence number SQNMS denotes the highest sequence number the USIM has accepted.
The exact place where this AKA procedure is performed can be seen from the sequence chart below.
UE RNC VLR/SGSN ------ --------- ---------- | | | ---------------------------------------------------------------------------- | | | RRC Connection Setup and Initial Direct Transfer | | | ---------------------------------------------------------------------------- | | | | | | ---------------------------------------------------------------------------- | | | Authentication and Key Agreement Procedure | | | ---------------------------------------------------------------------------- | | | | | RANAP Security Mode Command | | |<------------------------------| | RRC Security Mode Command | | |<---------------------------------| | | | | | | | | RRC Security Mode Complete | | |--------------------------------->| | | | RANAP Security Mode Complete | | |------------------------------>| | | | | | |
Figure 2 (taken from [5]) below shows the Authentication and Key Agreement Procedure
Figure 2: Auhentication and Key Agreement Procedure (taken from [5])
- VLR requests the HE/HLR to send ordered array of n authentication vectors. The authentication vectors are ordered based on sequence number.
- Each Authentication Vector consists of:
- A random number RAND
- An expected response XRES
- A cipher key CK
- An integrity key IK
- An authentication token AUTN
- When VLR wants to perform AKA with the UE, it selects the next Authentication Vector from the stored ordered array and sends the parameters RAND and AUTN to the user.
- The UE checks if the AUTN is valid and if it is then produces a response RES that is sent back to VLR/SGSN.
- The procedure has been successful for the UE. It will retrieve the CK and IK from the USIM and transfer it to the entities that perform Ciphering (RLC and MAC) and Integrity (RRC) functions.
- When the VLR/SGSN receives the response RES, it compares it with the expected response XRES. If they match then the procedure is successful according to the VLR/SGSN. It will transfer the CK and IK to the entities that will perform ciphering and integrity protection.
Basic Concepts of Ciphering and Integrity Protection
It is extremely important that the UE and the CN negotiate the keys before the security procedures are started. There is a seperate Ciphering Key (2 keys; one for each domain) and a seperate Integrity Key that is used during the security procedures. The Keys should be chosen securely in such a way that the UE and CN can use the keys as soon as the security procedure starts. Also this key should not be transferred over the air interface because it can be compromised. The Key setting procedure as described in the earlier sections can be initiated by the network as often as the network wishes.
Generally speaking, in practice the Authentication procedure will be performed only once. That is after the Signalling Connection is established with a domain and before the RAB is established. In this case when the Security Procedure (described in later sections) starts , the new Cipher Key CK and the new integrity key IK shall be taken in use in both the RNC and the ME as part of security mode setup procedure.
During RRC Connection Establishment when UE sends RRC Connection Setup complete message, it transfers the UE capability as a part of this message. In this the UE Classmark information contains the Ciphering and Integrity Protection algorithms that are supported by the UE. This information itself is integrity protected. Since Integrity Protection has not been started, the RNC stores this Classmark information for future use without doing anything else with it for the time being.
During AKA procedure, CN decides which UE Integrity Algorithm (UIA) and which UE Encryption Algorithm (UEA) should be used. If there are any common algorithms between UE and the CN they will be used. If there are no common algorithms, then the call will be released. When the common algorithms are found then one of them will be used.
At present there is only one Integrity Algorithm, UIA1. At present, there are two Ciphering Algorithms, UEA0 and UEA1. UEA0 is the same as no ciphering. If no Ciphering Algorithm information is present, UE can assume Ciphering with UEA0. In case of UE's connection with more than one CN domain, the second domain will have the same Ciphering Algorithm as the first one. At present Ciphering of both the domains with different Ciphering Algorithms is not supported.
The AKA mechanism described in the earlier sections is not mandatory at the call setup. In that case the keys that existed during the last will be used. This can compromise the keys. To avoid the keys being used for an unlimited amount of time; whenever the call is released, the START values fromk both the domains are compared with the THRESHOLD values. If the START for a CN domain is greater than THRESHOLD then the START for that domain is set to THRESHOLD, the Cipher and Integrity Key is deleted and the Key Set Identifier (KSI) on the USIM is set to invalid.
The KSI is a number that is associated with Cipher and Integrity Keys during authentication. The KSI is allocated by the network and sent with the authentication request message to the mobile station where it is stored together with the calculated CK and IK. The purpose of KSI is to make it possible for the network without invoking the authentication procedure.
Security Mode set-up procedure
The security mode setup procedure can be explained using the MSC below:
UE RNC VLR/SGSN ------ --------- ---------- | | | ---------------------------------------------------------------------------- | | | 1 - RRC Connection Setup procedure. The Start Values, HFNs and | | the security Capability is stored | | | ---------------------------------------------------------------------------- | | | | | | | 2 - Initial L3 message with user identity, KSI, etc. | |----------------------------------------------------------------->| | | | | 3 - Authentication and Key Agreement Procedure | |----------------------------------------------------------------->| |<-----------------------------------------------------------------| | | | | | 4 - Decide allowed UIAs and UEAs | | 5-Security Mode Command | | |<------------------------------| | | (UIAs, IK, UEAs, CK, etc) | | 6 - Select UIA and UEA, generate FRESH | | Start Integrity | | | | |7-Security Mode Command | | |<---------------------------------| | | (CN domain, UIA, UEA, FRESH, Security Capability, etc) | | | | 8- Start Integrity Protection | | |9-Security Mode Complete | | |--------------------------------->| | | 10 - Verify Received message | | | | | |11-Security Mode Complete | | |------------------------------>| | | (Selected UIA and UEA) | | | | | | |
- When RRC Connection Establishment procedure is started, the last message, RRC Connection Setup Complete includes the UE Capability information. The UE Security capability informs the network about the UEAs and the UIAs that the UE supports. The GSM classmark information is also important and it provides along with other stuff, the GSM security algorithms supported. This message also has the START list that contains the START value for the CS and the PS domain.
- The Initial Direct Transfer message (this is the first NAS message and could be Location Update Request, CM service request, Routing Area Update request, attach request, Paging Response, etc). user identity and the KSI. The included Key Set Identifier (KSI) is the KSI allocated by the CS or PS service domain at the last authentication for this CN domain.
- The Authentication and Key Agreement procedure is optional and if it is performed than new KSI will be allocated.
- The VLR/SGSN decides which UEA and UIA to use in the order of preference.
- When RANAP decides to initiate Ciphering and Integrity Protection, it sends the Security Mode Command message to RNC. This message contains an ordered list of allowed UIAs in order of preference, and the IK to be used. If ciphering has to be started, it contains the ordered list of allowed UEAs in order of preference, and the CK to be used. If AKA has been performed this will be indicated to RNC so the START values shall be reset when new keys are started to be used.
- The RNC decides which algorithms to use, generates a random value FRESH and starts Integrity Protection
- The RNC generates the RRC message Security mode command. The message includes the UE security capability, the GSM ciphering capability (if received during RRC Connection establishment), the UIA and FRESH to be used and if ciphering shall be started also the UEA to be used. Additional information (start of ciphering) may also be included. Because of that the MS can have two ciphering and integrity key sets, the network must indicate which key set to use. This is obtained by including a CN type indicator information in the Security mode command message. Before sending this message to the MS, the RNC generates the MAC-I (Message Authentication Code for Integrity) and attaches this information to the message.
- At reception of the Security mode command message, the UE verifies that the Security Capability for UMTS (and GSM is present) is the same as that send in the RRC Connection Setup Complete message. The MS computes XMAC-I on the message received by using the indicated UIA, the stored COUNT-I and the received FRESH parameter. The MS verifies the integrity of the message by comparing the received MAC-I with the generated XMAC-I.
- If all checks are successful then RRC sends Security Mode Complete message and generates the MAC-I for this message. If the checks were not successful then Security Mode Reject message would have been sent.
- When RNC receives this message it verifies the Integrity of the message by generating XMAC-I and comparing it with MAC-I.
- RANAP Security Mode Complete is sent from RNC to VLR/SGSN indicating the algorithms selected for integrity and ciphering.
The Security mode command to the UE starts the downlink integrity protection, i.e. this and all following downlink messages sent to the UE are integrity protected using the new integrity configuration. The Security mode complete from UE starts the uplink integrity protection, i.e. this and all following messages sent from the UE are integrity protected using the new integrity configuration. When ciphering shall be started, the Ciphering Activation time information that is exchanged between SRNC and MS during the Security mode set-up procedure sets the RLC Sequence Number/Connection Frame Number when to start ciphering in Downlink respective Uplink using the new ciphering configuration.
Integrity Protection of Signalling Radio Bearers
Integrity Protection is Mandatory and most of the messages are integrity protected. The following RRC messages are not integrity protected:
- HANDOVER TO UTRAN COMPLETE
- PAGING TYPE 1
- PUSCH CAPACITY REQUEST
- PHYSICAL SHARED CHANNEL ALLOCATION
- RRC CONNECTION REQUEST
- RRC CONNECTION SETUP
- RRC CONNECTION SETUP COMPLETE
- RRC CONNECTION REJECT
- RRC CONNECTION RELEASE (CCCH only)
- SYSTEM INFORMATION (BROADCAST INFORMATION)
- SYSTEM INFORMATION CHANGE INDICATION
- TRANSPORT FORMAT COMBINATION CONTROL (TM DCCH only)
Integrity Protection is applied at RRC Layer only. Only the Signalling messages are Integrity Protected. The Data Radio bearers are not integrity protected.
Ciphering of Signalling and Data Radio Bearers
Ciphering is optional and is done for Signalling as well as Data Radio Bearers. For RB's using AM or UM mode of operation, ciphering is done in RLC layer. For RB's using TM mode of operation, ciphering is done in the MAC layer.
There is one Ciphering Key for CS connection and one Ciphering Key for PS connection. The DRB's for CS connection are ciphered using CS domain Cipher Key and vice versa. The SRB's are ciphered using the key from the last domain that received the Security Mode Command message. Note that both the domains need to use the same Ciphering Algorithm otherwise Security Mode procedure for the second domain will result in failure while the call with the first domain will continue normally.
References:
[1] 3GPP TS 25.331: RRC Protocol Specification
[2] 3GPP TS 25.304: UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected mode
[3] 3GPP TS 21.133: 3G Security; Security Threats and Requirements
[4] 3GPP TS 33.120: 3G Security; Security Principles and Objectives
[5] 3GPP TS 33.102: 3G Security; Security Architecture
[6] 3GPP TS 25.413: UTRAN Iu Interface RANAP Signalling
[7] 3GPP TS 23.121: Architectural Requirements for Release 99