HSC welcomes all external visitors to this site, especially students and members of the academic community. Please use the comments box at the bottom of each page to record any comments or suggestions for improvement.
Introduction
From its very inception LTE has been designed to be a more evolved and refined system then any of the existing 3GPP networks. One such very important area in which imporovements have been sought is Security. The basic guiding priciple of LTE security architecture has been that all the security mechanisms must provide features that are atleast at par with existing 3GPP security features if not better.
The high level requirements of LTE security architecture have been captured in 3GPP specifications [22.278] and [33.401]. Given below is a list of these high level requirements:
- LTE security should provide protection against threats and attacks including those present in the internet.
- LTE security shall support information authenticity between the terminal and the network elements.
- Security policy should be under the control of the home operator.
- The security mechanism should not interfere with service delivery or 3GPP inter-access handover in a way that is noticable to end-users or service providers.
- Appropriate traffic protection meaasures should be provided.
- Appropriate mechanisms should be provided for lawful interception.
- No unauthorized user should be allowed to obtain a legitimate IP address that can be used to establish communication or enable malicious attacks.
- R99 or later releases' USIM application is required to authenticate a user in LTE network and hence allow the user to get services as per his/her subscription.
- Once authenticated via 3GPP or LTE system, the USIM shall not be required to re-authenticate upon changing between systems.
- The system shall provide appropriate levels of user privacy including communication confidentiality, location privacy, and identity protection.
- Content, origin or destination of a communication shall be protected from disclosure to unauthorised parties.
- Identity of the user shall not be disclosed to unauthorized third party.
Security Features
The requirements listed above are met by various security features in the LTE system. The overall security features are divided into five groups, each of which address a specific set of requirements.
Figure 1: LTE Security FeaturesNetwork Access Security (I): Allows secure access to services and protects against attacks on Radio link
Network Domain Security (II): Allows nodes to securely exchange signaling and user data and protect against attacks on wireline link.
User Domain Security (III): Secures access to mobile stations
Application Domain Security (IV): Allows applications on user and network side to securely exchange data
Visibility and Configurability of Security (V): Allows user to get information about whether security features are in force or not and whether provision of a service depends on the activation of a service or not.
Of all the features mentioned above, the current document will focus only on Network Access Security feature. The document will talk specifically about the mechanisms used to achieve secure transmission of data over the air.
Network Access Security Features
User Identity Confidentiality
This feature ensures that the user identity cannot be learned by an intruder by eavesdropping on the radio link. This is achieved by ensuring that the permanent user identities (such as IMSI or IMEI) are, almost, never sent to network before activation of appropriate security mechanisms at Access Stratum (AS) and Non Access Stratum (NAS) protocol layers.
Entity Authentication
This feature ensures that both the user and network authenticate each other’s identity. This is achieved by demonstrating the knowledge of a secret key that is available with both the parties.
Data Confidentiality and Integrity
This feature ensures that the user data and signaling data that is transmitted over the radio link is ciphered as well as integrity protected. This is achieved by using ciphering and integrity keys that are derived from a secret key that is known to both the user and the network. The algorithms that are required for applying the ciphering and integrity keys are negotiated by protocol procedures defined at AS and NAS level.
Ciphering is applied to all signaling messages (both AS and NAS messages) that are exchanged between user and network. Ciphering of signaling messages is an Operator option and its activation is controlled by network. While ciphering is an optional feature for signaling messages but integrity protection is mandatory. Therefore all AS (RRC layer messages) and NAS messages are necessarily integrity protected. There are few signaling messages that are exempt from integrity protection. The list of all such messages is explicitly mentioned in the relevant specifications.
User Plane messages are not integrity protected but they can be ciphered if the operator chooses the option to activate ciphering for User plane data.
Network Access Security Procedures
Initial establishment of security context and activation of Security Procedures between UE and EPC elements can be broadly categorised into three parts as depicted in the figure below:
Figure 2: Network Access Security ProceduresActivation of security starts with both UE and EPC mutually authenticating each other's identity. Once UE and EPC have authenticated each other an initial security context is established in both the entities. This security context is used by both for deriving and generating other security related parameters. Using these parameters actual application of the security is then activated by UE and EPC by exchanging multiple protocol signalling messages. Details of these procedures are noted in the subsequent sections.
Security Procedures at Non Access Stratum Layers
Security Key Generation
Security keys that are used by UE and Network nodes are generated by Authentication-and-Key-Agreement (AKA) procedure. These keys are used for ciphering of User Plane, RRC and NAS data as well as integrity protection of RRC and NAS messages. Besides generation of keys AKA procedure is also used by both UE and EPS to mutually authenticate each other's identity.
AKA procedure is always initiated and controlled by the network. EPC sends an authentication challenge, in form of a random number RAND, to the USIM. It also sends an authentication token AUTN and a keyset identifier KSIASME to enable USIM to authenticate the network and derive keying material for ciphering and integrity protection.
Figure 3: Authentication and Key Agreement ProcedureOn receiving the authentication challenge from network USIM verifies AUTN and if found acceptable, it computes a response RES and sends it back to network. USIM also computes ciphering and integrity keys, CK and IK and passes them on to NAS. Network tries to authenticate the UE by matching the response RES with a calculated expected response XRES. If the two response values are found to be matching network declares the UE to be an authentic subscriber and allows UE to enter the network.
Security procedure at NAS layer is responsible for Mutual authentication of UE and Network, Generation of Security and Integrity keys and Ciphering and Integrity protection of NAS signaling data.
Security context in the NAS layers consists of parameters for authentication, integrity protection and ciphering of signaling data. These parameters are grouped together into distinct sets, each of which can be identified by an identifier known as a Key-Set Identifier (eKSI).
NAS Security Activation
The first step towards activation of security at NAS layers involves establishment of security context at UE and MME. Security context is created either by Authentication procedure or during an inter-system handover from Iu mode or A/Gb mode to S1 mode. During Authentication procedure the Key-Set Identifier eKSI is assigned by MME to UE whereas during Handover procedure eKSI is derived from the existing UMTS or GPRS security context. eKSI consists of a value and a type of security context parameter indicating whether eKSI has been directly assigned by MME or whether it has been derived from UMTS/GPRS security context.
Once security context is established the next step for activation of NAS security is achieved by executing the Security Mode control procedure. This procedure is initiated by MME by sending SECURITY MODE COMMAND message to UE. This message is sent unciphered by MME but it is integrity protected. On receiving the message UE validates this message, and if the message can be accepted, it sends SECURITY MODE COMPLETE message back to MME. SECURITY MODE COMPLETE message is integrity protected and is also encrypted, if the operator chooses to activate ciphering.
After the successful exchange of these two messages, security procedure is activated at NAS and any subsequent uplink or downlink NAS messages are integrity protected and ciphered.
The general structure of a security protected NAS message is as follows:
Figure 4: NAS Message StructureThe protocol message to be transfered is ciphered (if applicable) and populated in the NAS Message portion of the message. For Integrity protection a sequence number is attached to the NAS Message and the Message Authentication Code (MAC) is computed and populated in the message. On the receiving side Integrity validation is performed prior to deciphering of the embedded NAS message.
Security Procedures at Access Stratum Layers
Security procedure at AS layers involves confidentiality protection as well as integrity protection of data. Confidentiality protection is applicable to both User Plane data and Signaling data whereas Integrity protection is applicable to only Signaling data.
Security is activated in AS by RRC layer using the Security Mode procedure. This procedure is initiated when eNB sends Security Mode Command message to UE. This message contains the integrity and ciphering algorithm to be used for applying security. Selection of these algorithms is dependent on the UE capability.
Security Mode Command message itself is integrity protected but is not ciphered. Same is the case with response message (Security Mode Complete) sent by UE. Ciphering of messages is activated, both in Uplink and downlink direction, only after the completion of the security mode procedure.
Configuration of Security parameters is handled by RRC layer. Security configuration information includes integrity protection algorithm, ciphering protection algorithm, keyChangeIndicator parameter and nextHopChainingCount parameter. The last two parameters are used by UE to determine the AS security keys upon handover and/or connection reestablishment.
Actual ciphering/deciphering and integrity protection of messages is done by the PDCP layer. PDCP uses three different keys for this purpose. K
RRCint is used for integrity protection of RRC messages, K
RRCenc is used for ciphering/deciphering of RRC messages and K
UPenc is used for ciphering/deciphering of User Plane data. All three keys are derived from K
eNB key, which in turn is derived from K
ASME. K
ASME is generated by NAS layers and is supplied to AS after NAS completes its own Security Mode procedure. In the subsequent sections the heriarchial relation between these different keys has been described in greater details.
Security keys are renewed whenever there is a RRC Connection Reestablishment or a Handover. The KeyChangeIndicator parameter is used upon handover to decide if the latest KASME can be used to generate new keys. The nextHopChainingCount parameter is used upon Handover and reestablishment for deriving new KeNB.
Security Key Management
Key Derivation Function
In LTE security keys CK and IK are not directly used for ciphering and integrity protection of the data transmitted on air. CK and IK are used as base keys from which further keys are derived using a Key Derivation Function (KDF). All the keys that are derived using KDF are hierarchically related to each other as shown in the figure below:
Figure 5: Security Key HierarchyThe multiple keys derived from KDF are:
K : Subscriber specific secret key that is stored in USIM and Authentication Center (AuC).
CK,IK : Ciphering and Integrity Keys generated as a result of AKA procedure.
KASME : Intermediate key derived from CK and IK. This key is uniquely identified by eKSI parameter which is sent by MME to eNB.
KNASint: This key is derived from KASME. It is used for integrity protection of NAS messages.
KNASenc: This key is derived from KASME. It is used for encryption of NAS messages.
KeNB: This is an intermediate key derived from KASME.
KRRCint: This key is derived from KeNB. It is used for integrity protection of RRC messages.
KRRCenc: This key is derived from KeNB. It is used for encryption of RRC messages.
KUPenc: This key is derived from KeNB. It is used for encryption of User Plane traffic.
NH (Next Hop): Intermediate key derived from KASME to provide forward security. This key is derived by both ME and MME.
KeNB*: Intermediate key derived from KASME during handover. This key is derived by both ME and eNB.
Generic Key Derivation Function
LTE uses Hash-based Message Authentication Code (HMAC) function for deriving various security keys described above. Details of this function can be found in IETF RFC 2104. This function (henceforth known as KDF) is defined as:
derivedkey =
HMAC-SHA-256(Key, S)
where
Key is the base key
S is the input string which is constrcuted based on
input parameters as follows:
S = FC || P0 || L0 || P1 || L1 ||....||
Pn || Ln
where
FC is single octet used to distinguish between different
instances of algorithm
P0...Pn as n+1 input parameter encodings, and
L0...Ln are length of corresponding encoding
parameters P0...Pn
Every Security Key is derived from this Generic KDF on the basis of varying input parameter
S and a base key
Key. As depicted in the diagram above derivation of various security keys starts with the genration of
CK and
IK keys using the AKA procedure. AKA procedure, in turn, generates
CK and
IK on the basis of a subscriber specific secret key
K. The identity of this secret key is known to both UE and network and it is never transmited on air. On the UE side the key is stored in the SIM card and on the network side it stored in the Authentication Center (AuC).
Given below are the mechanisms for construction of the input string S for every distinct usage of KDF algorithm.
KASME Derivation Function
The following parameters are used to form input S when deriving KASME from CK and IK:
FC = 0x10,
P0 = SN id (SN id is created using MCC and MNC)
L0 = length of SN id
P1 = SQN xor AK
L1 = length of "SQN xor AK"
The exclusive or of Sequence Number (SQN) and Anonimity Key (AK) is sent to the UE as a part of Authentication token (AUTN) during AKA procedure. If AK is not used, its value is taken as zero. The input key "Key" is equal to the concatenation of CK and IK.
KeNB Derivation Function
KeNB is derived from the key KASME and the uplink NAS COUNT in the UE and MME. The input parameter S is constructed as follows:
FC = 0x11
P0 = Uplink NAS COUNT
L0 = Length of uplink NAS COUNT
The input key "Key" is equal to KASME.
NH Derivation Function
NH is derived from the key KASME. The input parameter S is constructed as follows:
FC = 0x12
P0 = SYNC-input
L0 = length of SYNC-input
The SYNC-input parameter shall be the newly derived KeNB for the initial NH derivation, and the previous NH for all subsequent derivations. This results in a NH chain, where the next NH is always fresh and derived from the previous NH.
NAS and AS Security Key Derivation Function
The input parameter S is constructed as follows while deriving ciphering and integrity keys used by NAS and AS protocol layers:
FC = 0x15
P0 = algorithm type distinguisher
L0 = Length of algorithm type distinguisher
P1 = algorithm identity
L1 = Length of algorithm identity
The algorithm type distinguisher parameter is generated from the table given below:
| Algorithm Distinguisher | Value |
|---|
| NAS-enc-alg | 0x01 |
| NAS-int-alg | 0x02 |
| RRC-enc-alg | 0x03 |
| RRC-int-alg | 0x04 |
| UP-enc-alg | 0x05 |
The 4-bit algorithm identity (as specified in next section) shall be put in the four least significant bits of the octet. The entire four most significant bits shall be set to all zeros. For NAS algorithm key derivations, the input key shall be the KASME, and for UP and RRC algorithm key derivations, the input key shall be the KeNB.
Security Algorithms
LTE uses two different sets of Ciphering and Integrity algorithms for security. One set is based on SNOW 3G specification [7] and the other is based on AES (Advanced Encryption Standard) specification [8]. SNOW 3G is a word-oriented stream cipher that generates a sequence of 32-bit words under the control of a ciphering key. These 32-bit words can then be used to mask the plaintext. AES algorrithm, on the other hand, is a symmetric block cipher algorithm that can process data blocks of 128 bits using the given ciphering keys. The ciphering key length for both sets of algorithms is currently restricted to 128 bits, with the possibility to introduce 256-bit keys in future if required. The encryption algorithms are signaled between UE and Network by using 4-bit identifier as given below:
EEA0 : 0000 (Null Ciphering Algorithm)
EEA1 : 0001 (SNOW 3G)
EEA2 : 0010 (AES)
Similarly integrity algorithms are also identified by a 4-bit number:
EIA1 : 0001 (SNOW 3G)
EIA2 : 0010 (AES)
Ciphering Algorithms
Input and Output
The input parameters to the ciphering algorithm are a 128-bit cipher key named KEY, 32-bit COUNT, 5-bit bearer identity BEARER, 1-bit direction of the transmission DIRECTION and length of the keystream LENGTH. The figure given below illustrates the use of ciphering algorithm to encrypt plaintext by applying a keystream using a bit per bit binary addition of the plaintext and the keystream.
Figure 6: Integrity AlgorithmEEA0
EEA0 is a NULL Ciphering algorithm i.e. it does not provide any security. The algorithm is implemented such that it genrates KEYSTREAM of all zeroes. The length of the KEYSTREAM is equal to LENGTH input parameter. It does not require any input parameter other then LENGTH.
EEA1
EEA1 is based on SNOW 3G [7] and is identical to the traditional UMTS algorithm UEA2 [6].
EEA2
EEA2 is based on AES algorithm operating in CTR mode
[9]. The sequence of 128-bit counter blocks needed for CTR mode T
1, T
2,...T
i,... shall be constructed as follows:
The most significant 64 bits of T1 consist of COUNT[0]...COUNT[31] | BEARER[0]...BEARER[4] | DIRECTION | 026(ie 26 0 bits). These are written from most significant on the left to the least significant on the right. Subsequent counter blocks are then obtained by applying the standard integer incrementing function mod 264 to the least significant 64 bits of the previous counter block.
Integrity Algorithms
Input and Output
The input parameters to the integrity algorithm are 128-bit integrity key named KEY, a 32-bit COUNT, 5-bit BEARER, the 1-bit direction of transmission DIRECTION and the message itself i.e MESSAGE. The bit length of MESSAGE is LENGTH. The figure given below illustrates the use of integrity algorithm EIA to authenticate integrity of messages:
Figure 7: Integrity AlgorithmBased on these input parameters the sender computes a 32-bit message authentication code (MAC-I/NAS-MAC) using the integrity algorithm EIA. The message authentication code is then appended to the message when sent. The receiver computes the expected message authentication code (XMAC-I/XNAS-MAC) on the message received in the same way as the sender computed its message authentication code on the message sent and verifies the data integrity of the message by comparing it to the received message authentication code, i.e. MAC-I/NAS-MAC.
EIA1
EIA1 is based on SNOW 3G [7] and is identical to the traditional UMTS algorithm UIA2 [6].
EIA2
EIA2 is based on AES algorithm operating in CMAC mode
[10]. The bit length of MESSAGE is BLENGTH. The input to CMAC is a bit string M of length Mlen. M is constructed as follows:
M0...M31 = COUNT[0]...COUNT[31]
M32...M36 = BEARER[0]...BEARER[4]
M37 = DIRECTION
M38...M63 = 027
M64...MBLENGTH+63 = MESSAGE[0]...MESSAGE[BLENGTH-1]
and so Mlen = BLENGTH + 64
End-to-End security procedure
Figure given below shows the end-to-end procedure used for activation of security at AS and NAS layers on both eNB and UE side:
Figure 8: End to End Security ProcedureReferences
[1] 3GPP TS 22.278: "Service Requirements for the Evolved Packet System (v8.10.0)"
[2] 3GPP TS 33.401: "3GPP System Architecture Evolution; Security Architecture (v8.7.0)"
[3] 3GPP TS 33.102: "3G Security; Security Architecture (v8.6.0)"
[4] 3GPP TS 24.301: "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3 (v8.9.0)"
[5] 3GPP TS 36.331: "Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification (v8.12.0)"
[6] ETSI Specification: "Document 1- UEA2 and UIA2 Specification (v2.1)"
[7] ETSI Specification: "Document 2- SNOW 3G Specification (v1.1)"
[8] NIST : "Specification for Advanced Encryption Standard (FIPS PUB 197)"
[9] NIST Special Publication 800-38A (2001): "Recommendation for Block Cipher Modes of Operation"
[10] NIST Special Publication 800-38B (2001): "Recommendation for Block Cipher Modes of Operation: The CMAC Mode for Authentication
Maintainer : Prateek Bidwalkar
Categories LTE Security
Comments
#comment1
adfadfd — 19 May 2011, 12:42
Good article. Very informative.
