5G Security

This is an application that implements all the security procedures for 5G according to Annex A and Annex D of 3GPP 33.501. The ciphering and integrity algorithms are the same for LTE, and key derivation function is also the same, using different FCs.

The next image shows the key hierarchy in 5G:

The key distribution and key derivation scheme for 5G network nodes is shown in the next image:

The key distribution and key derivation scheme for 5G UE is shown in the next image:

5G Algorithms:

• Ciphering algorithm 128-NEA-1 and Integrity algortihm 128-NIA-1 are based on SNOW 3G and UEA2 defined in 3GPP (identical to 128-EEA-1 and EIA1)
• Ciphering algorithm 128-NEA-2 and Integrity algortihm 128-NIA-2 are based on AES defined in NIST specifications (identical to 128-EEA-2 and EIA2) 
• Ciphering algorithm 128-NEA-3 and Integrity algortihm 128-NIA-3 are based on ZUC defined in 3GPP specifications (identical to 128-EEA-3 and EIA3)

The Key derivation function that is needed for every key derivation in 5G 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.501 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 D Algorithms.

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

• N-NAS encryption
• N-NAS integrity
• N-RRC encryption
• N-RRC integrity
• N-UP encryption
• N-UP integrity

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

For Annex D, 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. 

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

If you want to download this application, please contact me through email (fasferraz@gmail.com), since this app will not be available for free. A small donation is required.

Untrusted Non-3GPP IP Access - SWu IKEv2 UE Emulator

This is an application that I’ve done in 2015 to emulate the UE in SWu interface for non-3GPP accesses.

SWu is the interface between UE and the ePDG as defined by the 3GPP, and is an IKEv2 based protocol with some minor modifications that can be found in 3GPP 33.402. The IKEv2 control plane is used to perform authentication, session creation and also to negotiate the IPSec sessions parameters to be used at the user plane level.

This application is focused on the IKEv2 control plane, just like the MME/SGW Emulator. The IPSec packets carrying user plane packets coming from the ePDG towards the UE are just ignored.

This application can use any network type (Wifi, Fixed, Mobile) to establish an IKEv2 Tunnel towards the ePDG and can be used in a more broader way than just the VoWifi scenario, since any APN can be requested. I personally think that corporate APNs can also be a big driver for these non-3GPP accesses, and not only VoWifi/VoLTE/IMS. The current obstacle for this to happen is the lack of non-3GPP IKEv2/IPSec dialers or applications for smartphones/laptops. Currently, If SWu is supported by a smartphone, it is built only for VoWifi/VoLTE/IMS, and the end-user is not aware or able to easily modify any setting.

This application takes the untrusted non-3GPP access to next level in a very deep way. We can check every single KEY used in the IKEv2 process, which allow us to decode any IKEv2 trace in wireshark. 

Since this application is built inside the MME/SGW emulator application that I’ve done previously, it can also emulate very easily handovers from non-3GPP to 3GPP and from 3GPP to non-3GPP.

The next picture shows a resume of the IKEv2 implementation, which parameters are sent in each message, and how the different keys are generated and used.

Only the first two messages are unencrypted. After the Diffie-Helman exchange, everything is encrypted and integrity protected with keys derived from this exchange.

We need to send the NAI and APN information to the ePDG, so that it can request authentication and subscription information from the AAA/HSS for the correct IMSI. This uses the IDi and IDr IKEv2 payload types that are sent in the third message.

Some IKEv2 configuration payload were also defined by IANA for 3GPP usage like the P-CSCF IPv4 or P-CSCF IPv6 used in VoWifi.

This applications supports the following RFCs and options:

•       IKEv2 RFC 5996
•      EAP-AKA Authentication RFC 4187
•      IKEv2 Encryption: AES-CBC-128
•      IKEv2 Pseudo Random Function: PRF-HMAC-SHA1
•      IKEv2 Integrity: HMAC-SHA1-96
•      Diffie-Helman Group 1, 2, 5 and 14 (group 2 by default)
•      No Certificates
•      NAT-T
•      IKEv2 over UDP port 500 or 4500

So, how can this application handle the IKEv2 authentication phase defined in 3GPP 33.402?

It needs to run the AKA algorithm in the USIM when receiving a RAND/AUTN from the ePDG in the EAP payload to get the CK and IK from the USIM, since they are needed to calculate the Master Sesssion Key. To accomplish this we need a USB modem that supports the AT Commands +CRSM and +CSIM. 

[In my LTE security post I already explained how to run the AKA procedure in the USIM using these commands].

In the application we just need to set the COM port. The application can also retrieve the IMSI from the SIM Card using the AT+CIMI command, and build the NAI automatically.

In the test phase, while building this application, and before I have implemented the USIM card interaction through the modem, I needed to have some dummy SIM card information to be retrieved from the ePDG from the AAA/HSS. Since this was not possible with the real AAA/HLR I was using, I had to build a very simple SWm and S6b Diameter Server in my OCS/PCRF/EIR Diameter Server application, that would have a dummy data base with the APNs I was going to use and some authentication information that could match the one being sent from this application. This allowed me to complete the IKEv2 flows with the ePDG more easily.

The last phase of development was just the modem integration to get the IMSI and to run the AKA procedure in the USIM.

So let’s see the application in use.

We will perform the following actions:

• Activate a session in ePDG
• Simulate an handover to LTE
• Simulate an handover back to the ePDG
• Disconnect the session to the ePDG

The next picture shows the complete flow:

So when we activate the session in the ePDG we have this result:

When we go to the SGW emulator tab and perform handover we get this output:

When we go back to the UE emulator and perform Start IKE Handover we get this output:

The traces for this session can be downloaded.

• This one done in the ePDG and PGW, where IKEv2 packets are already decoded
• This one done in the UE (that was also the SGW emulator and the SWm/S6b Diameter Server). IKEv2 packets are not decoded. We need to use the Wireshark ISAKMP IKEv2 Decryption Table in Edit->Preferences->Protocols->ISAKMP and fill it with the corresponding keys shown in the application screenshots below, to properly decode the IKEv2 packets.

Note: Please configure TCP port 3869 (Gx), 3870 (SWm) and 3871 (S6b) as Diameter protocol.

UMTS Security Algorithm – TUAK

This application implements the TUAK algorithm defined in 3GPP 35.231, that is the new algorithm proposed to replace Milenage as the AKA algorithm.

There are a few differences from the inputs and outputs to Milenage:

• The K key can be 128 or 256 bits

• MAC-A and MAC-S can be 64, 128 or 256 bits

• RES can be 32, 64, 128 or 256 bits

• CK and IK can be 128 or 256 bits.

Existing 3GPP specifications do not support all of these possibilities, but they were included in TUAK for future flexibility in case future releases of these specifications want to support them.

TUAK uses the Keccak-f permutation with 1600 bits as input/output.

Milenage uses a 128 bits OP that is used with K key to derive OPc. For TUAK a 256 bits TOP key is specified, and a 256 bits TOPc is derived using TOP and K.

As stated before, the lengths of K, MAC-A/MAC-S, RES, CK and IK can be chosen by the operator, although they have to be fixed for a particular implementation of TUAK.

For compatibility with current 3GPP specifications the length of K must be 128 bits, the length of RES must be between 32 and 128 bits, the length of MAC-A/MAC-S must be 64 bits, and the length of CK and IK must be 128 bits.

If a more secure version of this algorithm is required, this could be done by adding extra Keccak permutations before extracting the output.

This can be set in the application in the dropbox “keccak iterations”.

The application was tested with all test vectors from 3GPP 35.232 specification.

You can download it for free here.

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

UMTS Security Algorithm – Milenage

I’ve done this application in 2004, in the beginning of the UMTS rollout.

In this application I’ve implemented the MILENAGE algorithm defined in 3GPP 35.206, that is one example of the AKA algorithm that runs in the HLR and in the USIM as specified in 3GPP 33.102: 

Generation of authentication vectors in HLR:

 

User authentication function in the USIM:

Construction of the parameter AUTS:

The MILENAGE algorithm framework is the following:

With this application every parameter used in the MILENAGE algorithm can be changed, and the corresponding f1 to f5 functions generated.

I’ve added also the conversion functions for inter-operation and handover between UMTS and GSM defined in 3GPP 33.102.

I’ve tested it successfully using the “Implementers’ Test Data” examples provided in 3GPP 35.207, and also with real examples.

This application can be used to detect erroneous behaviors of the ME, USIM or Network Elements (HLR, SGSN and RNC) in terms of security procedures.

This application can be downloaded for free. You can get it here. 
Note: This installation includes a test file (teste.dat that can be found inside the installation directory).