LTE Security | Standards, Protocols, and Functions

What are the new security functions in the E-UTRAN? This question can briefly be answered as follows.

The first feature we see is a completely new ciphering mechanism and integrity protection for NAS signaling messages that was never seen in any 2G or 3G radio access network. On the radio interface this new NAS security leads to situations with double ciphering. On top of the protocol stack the NAS messages exchanged between the UE and MME are encrypted and the underlying RRC that acts as the transport layer for NAS is secured by ciphering mechanisms as well, so that the ciphered NAS message is ciphered together with its RRC transport message a second time.

The second new security feature is the option to secure the complete IP-based transport of the control plane and user plane on the S1 reference point using Secure IP (IPsec). There is no way to decipher IPsec by just monitoring the data that is exchanged between two endpoints of an IPsec connection. To decipher IPsec requires the monitoring software to be informed about which IPsec ciphering parameters (which can be changed frequently) are currently used in each of the involved endpoints of the IP connection. In a typical case these endpoints are the eNB and the MME or S-GW. To allow deciphering, there must be a dedicated Application Programming Interface (API) installed that allows the monitoring software to access IPsec-relevant parameters for deciphering. To design such an API requires close cooperation between the NEMs of eNB and MME/S-GW and the manufacturers of the monitoring software. The conclusion related to this fact is that free-of-charge monitoring software like WireShark will not be able to decipher IPsec. However, to obtain statistics of S1 control plane and user plane performance it is crucial to have metrics for E-UTRAN QoS and QoE (Quality of Experience). Consequently, IPsec deciphering will become one of the key differentiators for E-UTRAN monitoring software.

Besides these new security features, all the security elements from previous standards such as mutual authentication and masking of subscriber identity by using temporary identities can be found in the E-UTRAN. There is only a minor change here: the TMSI will be replaced by the new GUTI parameter.

To understand how the overall LTE security concept works, it is crucial to understand the hierarchy of LTE security keys first. This LTE security key hierarchy, shown in Figure 1, includes the following keys: K_eNB, K_NASint, K_NASenc, K_UPenc, K_RRCint, and K_RRCenc:

• K_eNB is a key derived by the UE and MME from K_ASME or by the UE and target eNB from Ke_NB* during eNB handover. K_eNB should only be used for the derivation of keys for RRC traffic and the derivation of keys for UP (User Plane) traffic, or to derive a transition key K_eNB* during an eNB handover.
  
  

Figure 1: LTE security key hierarchy (according to 3GPP 33.401). Reproduced with permission from © 3GPP™

Keys for NAS traffic:

• KNASint is a key which should only be used for the protection of NAS traffic with a particular integrity algorithm. This key is derived by the UE and MME from Kasme, as well as an identifier for the integrity algorithm.
• KNASenc is a key which should only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by the UE and MME from Kasme, as well as an identifier for the encryption algorithm.

Keys for UP traffic:

• K_UPenc is a key which should only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by the UE and eNB from K_eNB, as well as an identifier for the encryption algorithm.

Keys for RRC traffic:

• K_RRCint is a key which should only be used for the protection of RRC traffic with a particular integrity algorithm. K_RRCint is derived by the UE and eNB from K_eNB, as well as an identifier for the integrity algorithm.
• K_RRCenc is a key which should only be used for the protection of RRC traffic with a particular encryption algorithm. K_RRCenc is derived by the UE and eNB from K_eNB as well as an identifier for the encryption algorithm.

Now, whenever a call is established the security functions will work as shown in Figures 2–4. The start trigger of the security functions is when an initial NAS signaling message sent by the UE that contains UE security capability information arrives at the MME. The security capability list informs the MME for instance about which ciphering and integrity protection algorithms are supported by this UE.

Figure 2: Subscriber authentication

Figure 3: NAS security initiation and RRC security initiation

Figure 4: RRC security completion

After the MME has received the initial NAS message and it has not been in contact with this subscriber before, or if all previously received security tokens sent by the HSS have been used, the MME must contact the HSS to receive new tokens. Thus, the MME sends a DIAMETER authentication information request message to the HSS that contains the subscriber's identity. The HSS holds the secret network key "K" that is also stored on the USIM card of each subscriber. "K" is unique to every network operator.

From "K" and the subscriber's identity the HSS derives three of the four parameters found inside the DIAMETER authentication information response message: the security key K_ASME, the Authentication Token (AUTN), and the Expected Response (XRES) parameter. The random number parameter RAND is truly just a random number.

After the MME has received these four parameters, it produces three more derivatives from K_ASME. These derivatives are the NAS encryption key K_NASenc, the NAS integrity protection key K_NASint, and the security key for the eNB K_eNB.

What follows is the authentication procedure between the MME and the UE. The MME sends the unciphered NAS authentication request message that includes the random number RAND and the AUTN. Now the UE must use its secret key "K" from the USIM card to calculate another number based on "K," AUTN, and RAND. The number is the UE's authentication response number RES.

RES is sent back to the MME by using the authentication response message, and in the last step of the authentication procedure the MME compares the value of RES to the value of XRES, which is the XRES value computed previously by the HSS. If RES and XRES have the same value the UE has successfully authenticated itself to the network and the NAS signaling connection can proceed.

At this point, after successful authentication, it is time to activate the NAS security functions: namely, NAS ciphering and NAS integrity protection. Thus, the MME sends the NAS security mode command message to the UE including the security key Kasme received previously from the HSS, and the algorithms for EPS encryption and EPS integrity protection that have been selected from the UE capability list and will be used to secure this NAS signaling connection.

After the UE has received the NAS security command, it computes on behalf of the assigned EPS encryption/integrity algorithms and the Kasme key the keys for NAS encryption and NAS integrity protection that are identical to those already stored in the MME. Now NAS security is in service the UE sends back the NAS security mode complete message, which is the encrypted and integrity protected NAS message. It is not mandatory to use NAS encryption and integrity protection. It is always up to the operator to decide what is required to secure the network.

After the NAS security functions are in service, the underlying RRC connection and the ciphering for user plane traffic need to be activated. For this purpose, first a so-called security context is installed between the MME and eNB. Since security is not the only context-related information to be exchanged between these two network elements, the S1AP initial context setup message will also contain other parameters besides the UE security capabilities and the eNB's security key K_eNB. Note that the UE security capabilities so far are unknown to the eNB.

Now the eNB derives the keys for RRC encryption (K_RRCenc), RRC integrity protection (K_RRCint), and user plane encryption (K_UPenc) from K_ASME. Then the eNB sends the RRC security mode command message to the UE. This message contains the AS encryption algorithm and AS integrity protection algorithm bundled with the START parameters for the AS security activation procedure.

The UE computes the keys for RRC encryption (K_RRCenc), RRC integrity protection (K_RRCint), and user plane encryption (K_UPenc) from the K_ASME together with the received keys and activates the requested security functions using these parameters. After successful activation, the UE sends the RRC security mode complete message (i.e., ciphered and/or integrity protected) back to the eNB. And the eNB confirms the successful establishment of the security context to the MME by sending the S1AP successful outcome message for the procedure code "Initial Context Setup."