I have written this page to have a centralized view of the radio interface security inside 3GPP technologies, from 2G to 5G. Getting a clear view of what is going on can be confusing and discouraging as it often requires to browse through dozens of 3GPP documents at the same time.

The most important security functions are listed for each technology: authentication, confidentiality and integrity. I have tried to keep this as short as possible while keeping the most revelant information, such as which radio layers are involved and links to the specifications.

GSM

In this section, A3 and A8 are derivation functions implemented as part of the COMP128 algorithm. A5 functions are the encryption algorithms.

Authentication

The BTS authenticates the MS using a challenge-response scheme relying on a 128-bit shared secret Ki stored in the SIM card and the core network.

MS ⟵ BTS : Authentication Request (128-bit RAND ) MS ⟶ BTS : Authentication Response (32-bit SRES = A3(Ki, RAND) ) MS ⟵ BTS : Authentication Reject if SRES is incorrect

Encryption

Traffic encryption is initiated by the BTS after authentication by sending a Ciphering Mode Command to the MS. The message contains the encryption algorithm to use. The dedicated channels TCH and DCCH are then encrypted at the physical layer. The encryption 64-bit key Kc is A8(Ki, RAND) .

A5/0 : no encryption

: no encryption A5/1 : LFSR-based stream cipher, 64-bit key, broken

: LFSR-based stream cipher, 64-bit key, broken A5/2 : LFSR-based stream cipher, 64-bit key, broken, prohibited use

: LFSR-based stream cipher, 64-bit key, broken, A5/3 : KASUMI in OFB mode, 64-bit key extended to 128 bits (3GPP TS 55.216)

In the event of a handover from a UTRAN, the mobile can use its UMTS security context to switch to a 128-bit algorithm. The 128-bit encryption key K 128 is HMAC-SHA256(CK || IK, "\x32") truncated to 128 bits (3GPP TS 33.102, 3GPP TS 33.220).

A5/4 : same as A5/3 , 128-bit key (3GPP TS 55.226)

Integrity

Traffic is not integrity protected in GSM.

GPRS

Authentication

GPRS use a challenge-response authentication scheme similar to GSM.

MS ⟵ BTS : Authentication and Ciphering Request ( RAND , algorithm) MS ⟶ BTS : Authentication and Ciphering Response ( SRES = A3(Ki, RAND) ) MS ⟵ BTS : Authentication and Ciphering Reject if SRES is incorrect

Encryption

The traffic is encrypted at the LLC layer. The 64-bit encryption key GPRS-Kc is A8(Ki, RAND) . Contrary to GSM, the traffic is asymmetrically encrypted by using a direction bit. The sequence number of the LLC packet is also used in the computation. Some GPRS encryption algorithms are not publicly documented.

GEA0 : no encryption

: no encryption GEA1 : undocumented, LFSR-based stream cipher, 64-bit key, broken, prohibited use

: undocumented, LFSR-based stream cipher, 64-bit key, broken, GEA2 : undocumented, LFSR-based stream cipher, 64-bit key

: undocumented, LFSR-based stream cipher, 64-bit key GEA3 : KASUMI in OFB mode, 64-bit key extended to 128 bits, similar to A5/3 (3GPP TS 55.216)

As with GSM, the device can use a 128-bit algorithm if it already has a UMTS security context. The 128-bit encryption key K 128 is HMAC-SHA256(CK || IK, "\x32") truncated to 128 bits.

GEA4 : same as GEA3 , 128-bit key (3GPP TS 55.226)

Integrity

Traffic is not integrity protected in GPRS.

UMTS

UMTS uses a set of function f1 to f9 for security purposes. Derivation functions f1 to f5 are not standardized. The specifications provide two example algorithms sets: MILENAGE based on AES (3GPP TS 35.206), and TUAK based on SHA3 (3GPP TS 35.231).

Authentication

UMTS uses a mutual authentication between the mobile and the base station. It relies on a 128 or 256-bit shared secret key K stored in the USIM and the core network. The mobile and the network keep track of a 48-bit sequence number SQN to prevent replay attacks. The authentication scheme also makes use of a 16-bit AMF value that is operator dependent.

Network generates a 128-bit RAND and computes the following values: 48-bit AK = f5(K, RAND)

XRES = f2(K, RAND)

MAC = f1(K, SQN || RAND || AMF) MS ⟵ NodeB : Authentication Request (128-bit RAND , AUTN = SQN ⊕ AK || AMF || MAC ) MS verifies MAC and aborts by sending Authentication Failure if it is incorrect MS computes AK , verifies SQN , and aborts by sending Synchronization Failure if it is incorrect MS ⟶ NodeB : Authentication Response ( RES = f2(K, RAND) ) MS ⟵ NodeB : Authentication Failure if RES and XRES do not match

Encryption

Ciphering is initiated by the network by sending a RRC Security Mode Command through DCCH.

The traffic is encrypted at the RLC layer, or MAC layer in case of bearers in transparent mode. As with GPRS, a direction bit is used in the computation as well as a counter from the RLC or MAC header. Moreover, the traffic of each radio bearer is encrypted separately by using a 4-bit bearer id. The 128-bit encryption key CK is f3(K, RAND) . Encryption algorithms are referred to as f8.

UEA0 : no encryption

: no encryption UEA1 : KASUMI in OFB mode, 128-bit key, similar to A5/3 (3GPP TS 35.201)

: KASUMI in OFB mode, 128-bit key, similar to (3GPP TS 35.201) UEA2 : SNOW 3G, 128-bit key (3GPP TS 35.216)

Integrity

Integrity is initiated by the network by sending a RRC Security Mode Command through DCCH.

The traffic is integrity protected for non-access stratum at the RRC layer. The computation involves a direction bit, the sequence number of the RRC frame, and a 32-bit nonce value sent by the network in the Security Mode Command message. The 128-bit integrity key IK is f4(K, RAND) . Integrity algorithms are referred to as f9.

UIA0 : no integrity

: no integrity UIA1 : 32-bit MAC, KASUMI in CBC-MAC mode (3GPP TS 35.201)

: 32-bit MAC, KASUMI in CBC-MAC mode (3GPP TS 35.201) UIA2 : 32-bit MAC, based on SNOW 3G (3GPP TS 35.216)

LTE

Authentication

LTE uses the same mutual authentication scheme as UMTS.

Whereas in UMTS, the resulting keys CK and IK are used to protect traffic, in LTE they are used to derive a tree of keys. Two intermediary 256 bit keys are derived:

K ASME : derived from CK , IK , as well SQN , AK (from the AUTN token) and the SN id (serving network identity)

: derived from , , as well , (from the token) and the SN id (serving network identity) K eNB : derived from K ASME and the counter of uplink NAS messages

Those keys are then further derived into a set of confidentiality and integrity keys. The final tree hierarchy after authentication is:

K CK , IK K ASME K NASenc K NASint K eNB K UPenc K RRCenc K RRCint



The derivation functions are based on HMAC-SHA256 and are described in 3GPP TS 33.401.

Encryption

Ciphering is initiated by the network by sending RRC and NAS Security Mode Command.

Traffic is encrypted at the PDCP layer. Three different 128-bit keys are used depending whether on the nature of the traffic:

K NASenc for Non-Access Stratum messages

for Non-Access Stratum messages K RRCenc for Access Stratum messages

for Access Stratum messages K UPenc for User Plane messages

K NASenc is derived from K ASME while K RRCenc and K UPenc are derived from K eNB .

The computation involves a direction bit, a direction dependent 32-bit PDCP counter and a 5-bit bearer id.

Integrity

Integrity is initiated by the network by sending RRC and NAS Security Mode Command.

Traffic is integrity protected at the PDCP layer. Control plane traffic must be protected while user plane traffic must not. Two different 128-bit keys are used depending whether on the nature of the traffic:

K NASint for Non-Access Stratum messages derived from K ASME

for Non-Access Stratum messages derived from K RRCint for Access Stratum messages derived from K eNB

A key K UPint to protect user traffic is also computed by the eNodeB, but is only used between an eNodeB and a relay node.

The computation involves a direction bit, a direction dependent 32-bit PDCP counter and a 5-bit bearer id.

EIA0 : no integrity, only for emergency calls

: no integrity, only for emergency calls 128-EIA1 : similar to UIA2 (3GPP TS 33.401)

: similar to (3GPP TS 33.401) 128-EIA2 : 32-bit MAC, 128-bit AES in CMAC mode (3GPP TS 33.401)

: 32-bit MAC, 128-bit AES in CMAC mode (3GPP TS 33.401) 128-EIA3 : 32-bit MAC, based on ZUC (3GPP TS 35.222)

LTE D2D ProSe (Device to Device Proximity Services)

ProSe is a 3GPP technology that appeared during Release 12. It allows LTE user equipments to discover themselves in a geographic area and communicate with one another through a direct communication channel.

It is principally meant to be a competitor of TETRA for Public Safety, but it can also operate on commercial bands, allowing for other potential usages such as Vehicle-to-Vehicle communication.

I am not aware of any real-life uses of ProSe but I am including it for the sake of completeness. Its security aspects are defined in 3GPP TS 33.303.

Authentication

UEs are provisioned with a long term pre-shared key. For communicating with another UE, a 256-bit key K D is negociated. This key is then stored in the UE and can possibly be reused or refreshed at a later point.

Everytime two UEs establish a communication channel, a new 256-bit K D-sess is derived from K D and two nonces exchanged between the UEs.

The key derivation functions are based on HMAC-SHA256 . The key hierarchy upon communication establishment is:

LTK K D K D-sess PEK PIK



K D can be negociated between the two UEs in two ways:

by separately interacting with a key management server (PKMF) located in the network core. by direct communication with each other. The standard mentions the use of ECCSI (Elliptic Curve-based Certificateless Signatures for Identity-based Encryption) and SAKKE (Sakai Kasahara Key Encryption), both defined in RFC 6507 and RFC 6508.

Once two UEs need to communicate with each other, they establish a secure communication channel:

UE 1 ⟶ UE 2 : Direct Communication Request ( LTK id, K D id, algorithms, Nonce_1 ) UE 1 ⟺ UE 2 : Authentication and K D negociation (optional) UE 2 generates Nonce_2 and computes K D-sess = KDF(K D , Nonce_1, Nonce_2) , as well as PIK and PEK UE 1 ⟵ UE 2 : Direct Security Mode Command ( Nonce_2 , chosen algorithms, MAC-I ) UE 1 computes K D-sess , PIK , PEK and verifies MAC-I with PIK UE 1 ⟶ UE 2 : Direct Security Mode Complete ( MAC-I ) UE 2 verifies MAC-I with PIK . Both UEs then have a synchronized security context.

Encryption

The traffic is encrypted at PDCP layer, with the same algorithms as for LTE. The 128-bit encryption key is PEK , derived from K D-sess .

Integrity

The traffic is integrity protected at the PDCP layer, with the same algorithms as for LTE. The 128-bit integrity key is PIK , derived from K D-sess .

EC-GSM-IoT (Extended Coverage GSM for IoT)

The security of EC-GSM-IoT is described in 3GPP TS 43.020, starting from Release 13.

Authentication

The scheme of EC-GSM-IoT is an integrity-protected version of the authentication and key agreement (AKA) of UMTS.

MS ⟵ BTS : Authentication and Ciphering Request ( RAND , AUTN , encryption and integrity algorithms, MAC-GMM ) MS performs UMTS AKA, derives integrity key Ki 128 and verifies MAC-GMM MS ⟶ BTS : Authentication and Ciphering Response ( SRES , MAC-GMM ) Network verifies MAC-GMM and verifies SRES as for UMTS

Encryption

Traffic is encrypted at the LLC layer. The 128-bit encryption key Kc 128 is HMAC-SHA256(CK || IK, "\x32") truncated to 128 bits.

GEA0 : no encryption

: no encryption GEA4 : same as GEA3 , 128-bit key (3GPP TS 55.226)

: same as , 128-bit key (3GPP TS 55.226) GEA5 : undocumented, based on SNOW 3G, 128-bit key (3GPP TS 55.251)

Integrity

Traffic integrity is mandatory for the control plane. Messages are integrity protected at the GMM or LLC layers. The 128-bit integrity key Ki 128 is HMAC-SHA256(CK || IK, "\x38") truncated to 128 bits.

GIA4 : undocumented, 32-bit MAC, based on KASUMI in CBC-MAC mode (3GPP TS 55.241)

: undocumented, 32-bit MAC, based on KASUMI in CBC-MAC mode (3GPP TS 55.241) GIA5 : undocumented, 32-bit MAC, based on SNOW 3G (3GPP TS 55.251)

5G-NR

The information in this section may be subject to change in the future. The security architecture of 5G is described in 3GPP TS 33.501.

Authentication

5G-NR supports two authentication schemes: EAP-AKA’ and 5G AKA.

EAP-AKA’ is described in RFC 5448.

5G AKA is a hardened version of the UMTS authentication scheme. It goes as follows:

MS ⟵ gNB : Authentication Request ( RAND , AUTN ) MS performs UMTS AKA and computes RES MS derives RES into SRES* = KDF(CK || IK, RES, RAND) MS ⟶ gNB : Authentication Response ( RES* ) MS ⟵ gNB : Authentication Failure if RES* and XRES* do not match

Once authentication is performed, a hierarchy of tree is derived for the various network components, until generating the keys used for encryption and integrity.

K CK , IK CK' , IK' (only with EAP-AKA’) K AUSF K SEAF K AMF K NASenc K NASint K gNB K UPenc K UPint K RRCenc K RRCint K N3IWF



K N3IWF is an IKEv2 key that can be used to connect to the network core through a non-3GPP connection.

The derivation functions involved (such as the one used for derivating SRES* ) are based on HMAC-SHA256 and are described in 3GPP TS 33.501.

Encryption

The traffic is encrypted at the PDCP layer. Similarly to LTE, a set of three different 128-bit encryption keys are used for user plane, NAS and AS: K UPenc , K NASenc , K RRCenc . Encryption algorithms are the same as for LTE.

NEA0 : no encryption

: no encryption 128-NEA1 : identical to 128-EEA1 (SNOW 3G)

: identical to (SNOW 3G) 128-NEA2 : identical to 128-EEA2 (AES-128 CTR)

: identical to (AES-128 CTR) 128-NEA3 : identical to 128-EEA3 (ZUC)

Integrity

The traffic is integrity protected at the PDCP layer. As for LTE, AS and NAS are integrity protected using K RRCint and K NASint . However, 5G-NR also allows to optionally protect user plane using K UPint . Integrity algorithms are the same as for LTE.