LTE Security

This is an application that I’ve done recently that implements all the security procedures for LTE referred in Annex A and Annex B of 3GPP 33.401. The reason to start doing this application was the fact that I was analysing some S1AP traces and due to the ciphering I was unable to see the NAS messages. Since the trace also included authentication information retrieved from the HSS through s6a Diameter interface, I had all the information I needed to decrypt the message. Since in that specific trace the chosen algorithm was the 128-EEA1, after some reading I start implementing the 3G SNOW algorithm, since that was the algorithm that 128-EEA1 is based on. 

After that I decided to implement also the integrity algorithms and the other ciphering algorithm that are in Annex B.

In resume:

• Ciphering algorithm 128-EEA-1 and Integrity algortihm 128-EIA-1 are based on SNOW 3G and UEA2 defined in 3GPP
• Ciphering algorithm 128-EEA-2 and Integrity algortihm 128-EIA-2 are based on AES defined in NIST specifications
• Ciphering algorithm 128-EEA-3 and Integrity algortihm 128-EIA-3 are based on ZUC defined in 3GPP specifications

The key derivation from KASME needed for the NAS decryption is defined in Annex A and is based on HMAC-SHA-256. 

The Key derivation function that is needed for every key derivation in LTE is explained in 33.220, and is the following:

“The input parameters and their lengths shall be concatenated into a string S as follows:

1. The length of each input parameter measured in octets shall be encoded into a two octet-long string:

a) express the number of octets in input parameter Pi as a number k in the range [0, 65535].

b) Li is then a 16-bit long encoding of the number k, encoded as described in clause B.2.1.

2. String S shall be constructed from n+1 input parameters as follows:

S = FC || P0 || L0 || P1 || L1 || P2 || L2 || P3 || L3 ||... || Pn || Ln

where

FC is single octet used to distinguish between different instances of the algorithm,

P0 ... Pn are the n+1 input parameter encodings, and

L0 ... Ln are the two-octet representations of the length of the corresponding input parameter encodings P0.. Pn.

In this specification the following restriction applies to P0:  P0 is a static ASCII-encoded string.

This restriction is not part of the KDF definition and does not apply to the KDF when used by other 3GPP specifications unless explicitly stated so in those specifications.

3. The final output, i.e. the derived key is equal to the KDF computed on the string S using the key, denoted Key. The present document defines the following KDF:

derived key = HMAC-SHA-256 ( Key , S )

as specified in [22] and [23].”

In Annex A of 3GPP 33.401 we have for each Key Derivation the FC, Pn and Ln values to apply.

The app has several tabs and is divided between Annex A functions and Annex B Algorithms.

For Annex A, there is a tab for each chapter of this Annex. For example Annex A.7 is for deriving the algorithm keys for each one of these situations:

• Nas encryption
• Nas integrity
• Rrc encryption
• Rrc integrity
• User encryption
• User integrity

For NAS algorithm key derivations, the input key shall be the 256-bit K_ASME, and for UP and RRC algorithm key derivations, the input key shall be the 256-bit K_eNB.

For Annex B, there are two tabs, one for the ciphering and another one for the integrity.

In the ciphering tab is possible after doing the decryption of the message, to replace the bytes in the pcap file, in order to properly see the decoded message. 

This was the major goal of this app, since in this way I can use the wireshark decoding capabilities.

The other tab, is just to confirm that the mac is correctly calculated in a given message, since this is always in clear text.

Lets see an example of a real use of this application:

In this image we can see the KASME generated in the HSS:

With this KASME, and since in the trace I saw that the chosen encryption and integrity algorithm were respectively the 128-EEA1 and 128-EIA, I used the tab for annex A.7 to calculate the keys for encryption and integrity:

With theses keys, I can then use the tab Annex.B to decrypt and check the integrity of the NAS message.

For encryption, I need to get the following information from the S1AP:

• Ciphered message
• Sequence number
• Bearer ID
• Direction (i.e. Uplink/downlink)

One of the ciphered NAS messages was this one:

Applying this ciphered message in the app we get the following result:

The resulted decrypted message was then used to replace the bytes in pcap file.

The new file is then loaded in wireshark, and the previously ciphered bytes become decoded:

In terms of integrity, the parameters needed for the input of the algorithm are the same, but in this case the complete message to hash also includes the sequence number along with the NAS message.

The result confirms the MAC present in the trace:

Another use for this application, is the derivation of the KASME it self, from the CK, IK, AUTN, and SNid, which is mainly the MCC/MNC of the MME network in which the UE is registering. This way we can obtain the Authentication vector for LTE (quartet) from the quintuplet generated from the Milenage algorithm. 
So this is app is also a clear complement of another application that i have made in 2004:

So for the example above, the generated KASME for a "imaginary" MCC/MNC network like 12345, is the following:

But let's use a real example to see if the application is calculating the KASME correctly.

The next trace shows a LTE vector from a USIM:

My application needs the CK, IK, AUTN and MCC/MNC.
The AUTN is present in the vector.
The MCC/MNC of the registering network is also known.

So, how can i get the CK and IK from the RAND present in the vector?

Solution: I need to run the AUTHENTICATE algorithm in the USIM!
To do this I need a modem that supports the following AT Commands:

AT+CRSM
AT+CSIM

I used a ZTE dongle, which supports these AT commands.

Next i need to know the AID from the USIM 3G application that is inside the EFdir file (ID=H2F00, Application Directory EF):

AT+CRSM=178,12032,1,4,0 (I'm reading record 1 of the EFdir)
+CRSM: 144,0,"61214F10A0000000871002FFFFFFFF8903050001...."

Next, I will go through the USIM directory till the USIM Application:


AT+CSIM=16,"00A40000023F0000" (I'm selecting the Master File)
AT+CSIM=16,"00A40000022F0000" (I'm selecting the EFdir)
AT+CSIM=42,"00A4040010A0000000871002FFFFFFFF8903050001" (I'm activating the USIM 3G Application AID)

After this steps i can run the Milenage Algorithm in the USIM using the command AUTHENTICATE with the RAND and AUTN from the trace above:

AT+CSIM=80,"008800812210D6BA0C396BCE3189EF8B49FAF3F6746210B46F17E0F84F8000E6693AE37446963E00"

+CSIM: 4,"6135"

The "61" means success, and the "35" is the length of the answer, that we need to get using the GET RESPONSE command:


AT+CSIM=10,"00C0000035"
+CSIM: 110,"DB08FCCB24ADFBA66882105AFF52E6AAC652024111C33D3F8867861026D77E75251C7DA4BB5645367115E4A808866FAA98C147AC889000"

This answer can be decomposed in the following parts:

DB - Sucess

08 - Length of RES

FCCB24ADFBA66882 - RES

10 - Length of CK
5AFF52E6AAC652024111C33D3F886786 - CK

10 - Length of IK
26D77E75251C7DA4BB5645367115E4A8 - IK

08 - Length of Kc
866FAA98C147AC88 - Kc


As we can see the RES matches the XRES in the LTE vector in the trace above.

So let's use the application to calculate the KASME using the CK, IK, AUTN and MCC/MNC:

As we can see the resulting KASME is the same as the KASME present in the trace, so the app is working properly!

This app can be downloaded here.
The 2004 app can also be downloaded for free in a previous post.

Update (September/2013): A new version with support for 128-EEA-3 and 128-EIA-3 can be downloaded here

Update (February/2020): A new version with support for A.15 up to A.19 can be downloaded here

Update (August/2020): A new version with a bug correction for 128-EIA-3 algorithm can be downloaded here