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.