On the (In)Security of 4G - Part XI: Non Access Stratum and Access Stratum Security

Table of Contents

Non Access Stratum Security

After step 5a in the initial attachment procedure (please refer to Part VII), the User Equipment (UE) “has arrived” in a cell. Thus the network knows of its existence, UE and network have mutually authenticated and share a key. Now the next layer in the protocol stack of 4G is the Non Access Stratum (NAS) and in this post we look at how this layer is protected.

Requirements for Non Access Stratum Security

In the last post Part X, we talked about the Authentication and Key Agreement (AKA) procedure, with the result, that User Equipment (UE) and Mobility Management Entity (MME) were mutually authenticated via the proof of knowledge of the shared Master Key (MK) $K$ and have agreed on a shared key $K_{ASME}$. In Part IX, we talked about the key hierarchy in 4G and this is our starting point for today’s blog. With key $K_{ASME}$ in place and key derivation in mind NAS security establishment can commence.

Purpose of NAS Security

“The purpose of NAS security is to securely deliver NAS signaling messages between a UE and an MME in the control plane using NAS security keys.” [TS 33.401] Thus we want to protect signalling messages sent between UE and MME from being changed and thus making transport of user data impossible (kinda Denial-of-Service scenario). NAS security keys are derived from $K_{ASME}$ and generated every time an AKA is performed (thus for every new $K_{ASME}$). Once that NAS security setup is complete, UE and MME share a NAS encryption key ($K_{{NAS}_{enc}}$) and a NAS integrity key ($K_{{NAS}_{int}}$) for encryption and integrity protection of NAS messages.

NAS Security Key Derivation

The NAS Security Mode Command (SMC) procedure consists of a roundtrip of messages between MME and UE

1. [MME] The MME selects ciphering and integrity algorithms, applicable to NAS message, based on the previously transmitted UE NW capabilities (transmitted via the Attach Request message). Examples are EEA1 and EIA1 (for reference please refer to the previous post Part X).
2. [MME] The MME now derives $K_{{NAS}_{enc}}$ and $K_{{NAS}_{int}}$. According to TS 33.401 (Technical Specification (TS)) the Key Derivation Function (KDF) for that is defined in clause A.7. Here the following parameters are defined as input: (1) FC = 0x15 (Function (FC)), (2) P0 = algorithm type distinguisher (NAS-enc-alg = 0x01, NAS-int-alg = 0x02,RRC-enc-alg = 0x03, RRC-int-alg = 0x04, UP-enc-alg = 0x05, UP-int-alg = 0x06) (Radio Resource Control (RRC), User Plane (UP)), (3) L0 = length of algorithm type distinguisher (i.e. 0x00 0x01), (4) P1 = algorithm identity (128-EEA0: Null ciphering algorithm = 0000, 128-EEA1: SNOW 3G = 0001, 128-EEA2: AES = 0010, 128-EEA3: ZUC (optional) = 0011, 128-EIA1: SNOW 3G = 0001, 128-EIA2: AES = 0010, 128-EIA3: ZUC (optional) = 0011), (5) L1 = length of algorithm identity (i.e. 0x00 0x01). P0 is defined as either NAS-enc-alg = 0x01 or NAS-int-alg = 0x02 here depending on the purpose of the derived key and P1 depending on the network provider and UE capabilities. As input key, the 256 bit long $K_{ASME}$ is used. Please note, “For an algorithm key of length n bits, where n is less or equal to 256, the n least significant bits of the 256 bits of the KDF output shall be used as the algorithm key.” [TS 33.401].
   $K_{{NAS}_{enc}}$ = KDF($K_{ASME}$, FC, P0(=0x01), L0, P1, L1)
   $K_{{NAS}_{int}}$ = KDF($K_{ASME}$, FC, P0(=0x02), L0, P1, L1)
3. [MME] The MME now wants to inform the UE about the need for NAS security and forms a Security Mode Command. To protect the integrity of that message a NAS-MAC (Message Authentication Code (MAC)) is calculated. The 32-bit long NAS-MAC code is calculated using (1) a 128-bit integrity key $K_{{NAS}_{int}}$, (2) a 32-bit COUNT, (3) a 5-bit bearer identity called BEARER, (4) the 1-bit direction of the transmission i.e. DIRECTION, and (5) the message itself i.e MESSAGE. The DIRECTION bit shall be 0 for uplink and 1 for downlink. The bit length of the MESSAGE is LENGTH.

   

4. [UE <– MME] The MME sends the Security Mode Command to the UE. Content is: (1) $KSI_{ASME}$, (2) Replayed UE Security Capabilities, (3) NAS Ciphering Algorithm (e.g. EEA1), (4) NAS Integrity Algorithm (e.g. EIA1), (5) $NONCE_{UE}$, (6) $NONCE_{MME}$, (7) NAS-MAC. In the case of sending a NAS Security Mode Command during an Attach or TAU procedure (i.e. after receiving the Attach/TAU Request but before sending a response to that message) where the relevant Request message either did not have an integrity protection or did not successfully pass its integrity protection, the MME shall calculate a $HASH_{MME}$ of the entire plain Request message and include the $HASH_{MME}$ in the NAS security mode command message. Please note, the message is integrity protected but not ciphered.
5. [UE] Once the UE receives that message, it sets $KSI_{ASME}$ as the identifier of its current key $K_{ASME}$.
6. [UE] Now the UE can derive $K_{{NAS}_{enc}}$ and $K_{{NAS}_{int}}$ as it now knows the P0 = algorithm type distinguisher and P1 = algorithm identity to do so.
7. [UE] As the UE now has derived $K_{{NAS}_{enc}}$ and $K_{{NAS}_{int}}$, the integrity of the previous message can be verified, by verifying NAS-MAC. To do so, the UE calculates XNAS-MAC:

   

   Once that is done it can compare NAS-MAC and XNAS-MAC. If they match, the message was integer.
8. [UE] The UE now needs to inform the MME, that everything went as planned. Thus it forms a Security Mode Complete message. The NAS Security Mode Complete message shall include the IMEISV (IMEI Software Version (IMEISV)) in case MME requested it in the NAS Security Mode Command message. In addition if $HASH_{MME}$ was included in the MME Security Mode Command message, the UE also calculates a $HASH_{UE}$ according to the KDF in described in TS 33.220 in Annes B.2.0 with parameters defined in TS 33.401 Annex I.2. If $HASH_{UE}$ and $HASH_{MME}$ are different, the UE shall include the complete Attach/TAU Request message (that the UE previously sent) in the NAS Security Mode Complete message. This Security Mode Complete (plain text blocks) is then ciphered using by xoring the plain text blocks together with the key stream block. The input parameters to the ciphering algorithm are a 128-bit cipher key (here $K_{{NAS}_{enc}}$), a 32-bit COUNT, a 5-bit bearer identity BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the length of the keystream required i.e. LENGTH. The DIRECTION bit shall be 0 for uplink and 1 for downlink.

   

   After this step we have a ciphered Security Mode Complete message.
9. [UE] Now the UE calculates the NAS-MAC with the ciphered Security Mode Complete message and $K_{{NAS}_{int}}$. This works exactly as shown in figure 1.
10. [UE –> MME] The UE attaches the NAS-MAC to the Security Mode Complete message and sends it to the MME. Here the message is integrity protected and ciphered, and all the NAS messages that the UE sends to the MME hereafter are securely delivered.
11. [MME] Similar as seen in figure 2, the MME can now calculate a XNAS-MAC and verify the integrity of the Security Mode Complete message by checking NAS-MAC==XNAS-MAC.
12. [MME] If that is the case the MME can decipher the Security Mode Complete message (as seen in figure 3) and the NAS security setup is done.

All these steps are summarized in figure 4:

After NAS Security Setup

All further NAS messages between UE and MME can be en- and decrypted with $K_{{NAS}_{enc}}$ and integrity protected via the NAS-MAC and “verify with XNAS-MAC” method via $K_{{NAS}_{int}}$ as in the described in the previous 12 steps. At sender side, a NAS message is encrypted first and then integrity protected before being sent. On receiver side, the integrity is verified first and then the actual message is decrypted.

Access Stratum Security

Access Stratum (AS) Security plays an important role to ensure keeping the datalink via the air-gap alive. After NAS security capabilities have been negotiated between UE and MME, security between UE and eNB (evolved NodeB (eNB)), via the air-gap, is established. This works by completing a roundtrip of messages between eNB and UE. Similarly to figure 4, the AS Security Mode Command procedure only has two messages:

Access Stratum Security Setup Steps

Following these steps, we will see that they are quite similar to the one described in the chapter about NAS security setup. However, as they differ slightly, we will go over them briefly and highlight differences:

1. [MME] The eNB key is derived from $K_{ASME}$. This is done as described in Part IX.
2. [eNB <– MME] The MME sends the Attach Accept message to the eNB informing the eNB about the UE Security Capabilities and the Security Key 256-bit $K_{eNB}$.
3. [eNB] Based on UE security capabilities, the eNB selects ciphering and integrity algorithms to be applied to RRC messages and IP packets. Possibilities are again: 128-EEA0: Null ciphering algorithm = 0000, 128-EEA1: SNOW 3G = 0001, 128-EEA2: AES = 0010, 128-EEA3: ZUC (optional) = 0011, 128-EIA1: SNOW 3G = 0001, 128-EIA2: AES = 0010, 128-EIA3: ZUC (optional) = 0011
4. [eNB] Following the same KDF used in step 2 of the NAS security setup, the eNB derives $K_{{RRC}_{int}}$, $K_{{RRC}_{enc}}$ and $K_{{UP}_{enc}}$ from $K_{eNB}$.
   $K_{{RRC}_{enc}}$ = KDF($K_{eNB}$, FC, P0(=0x03), L0, P1, L1)
   $K_{{RRC}_{int}}$ = KDF($K_{eNB}$, FC, P0(=0x04), L0, P1, L1)
   $K_{{UP}_{enc}}$ = KDF($K_{eNB}$, FC, P0(=0x05), L0, P1, L1)\
5. [eNB] Now the eNB forms a Security Mode Command message (f.c. see figure 5) and calculates MAC-I:

   

   The input parameters to the integrity algorithm are a 128-bit integrity key $K_{{RRC}_{int}}$, a 32-bit COUNT, a 5-bit bearer identity called BEARER, the 1-bit direction of the transmission i.e. DIRECTION, and the message itself i.e MESSAGE. The DIRECTION bit shall be 0 for uplink and 1 for downlink. The bit length of the MESSAGE is LENGTH.
6. [eNB –> UE] The eNB attaches the MAC-I to the Security Mode Command message and sends it to the UE. With that the UE knows (1) AS Ciphering Algorithm selected by eNB, (2) AS Integrity Algorithm selected by eNB, (3) MAC-I.
7. [UE] The UE identifies the used security algorithms, looks up the corresponding $K_{ASME}i$ from $KSI_{ASME}$ from the NAS Security Mode Command message, derives $K_{eNB}$ from that and then from here $K_{{RRC}_{int}}$, $K_{{RRC}_{enc}}$ and $K_{{UP}_{enc}}$.
8. [UE] Now the UE calculates the XMAC-I (c.f. figure 2, 6) and compares MAC-I to XMAC-I. If they match the Security Mode Command message remained integer.
9. [UE] The UE generates the Security Mode Complete message and generates a MAC-I with the $K_{{RRC}_{int}}$ as key (c.f. figure 2, 6).
10. [UE –> eNB] The UE sends the integrity protected Security Mode Complete message to the eNB.
11. [eNB] The eNB can now calculate the XMAC-I of that message and compare it to MAC-I. If they match, the AS Security setup was completed successfully.

After AS Security Setup

When RRC messages are being sent, they are integrity protected first and then encrypted before being sent, unlike NAS messages were. The original RRC messages are first integrity protected including MAC-I calculated using the integrity key ($K_{{RRC}_{int}}$) and then they are encrypted using the encryption key ($K_{{RRC}_{enc}}$).
When received, however, RRC messages are decrypted first and then integrity verified. Thus the messages are decrypted first using $K_{{RRC}_{enc}}$ to get the integrity protected RRC messages, and then the integrity of the RRC messages is verified by calculating XMAC-I and then comparing XMAC-I to the MAC-I.
Please note: User packets are encrypted, but not integrity protected!

Summary

in this part about 4G security, we went into great detail about control data is protected between UE and MME and especially over the air-gap between UE and eNB. We explained the setup steps of NAS and AS security and how each key is derived and used. In the next parts, we want to go deeper into the bit sizes used for integrity protection and overall packets structure.

Here you can read Part X

Stay tuned! :)

Abbreviations

• Access Stratum (AS)
• Authentication and Key Agreement Procedure (AKA)
• evolved NodeB (eNB))
• Key Derivation Function (KDF)
• International Mobile Equipment Identity (IMEI)
• IMEI Software Version (IMEISV)
• Master Key (MK)
• Mobility Management Entity (MME)
• Non Access Stratum (NAS)
• Security Mode Command (SMC)
• User Equipment (UE)
• User Plane (UP)
• Message Authentication Code (MAC)
• Radio Resource Control (RRC)
• Technical Specification (TS)
• Function (FC)