Evolution of 3GPP over-the-air security
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
- GPRS
- UMTS
- LTE
- LTE D2D ProSe (Device to Device Proximity Services)
- EC-GSM-IoT (Extended Coverage GSM for IoT)
- 5G-NR
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 encryptionA5/1
: LFSR-based stream cipher, 64-bit key, brokenA5/2
: LFSR-based stream cipher, 64-bit key, broken, prohibited useA5/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 asA5/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 encryptionGEA1
: undocumented, LFSR-based stream cipher, 64-bit key, broken, prohibited useGEA2
: undocumented, LFSR-based stream cipher, 64-bit keyGEA3
: KASUMI in OFB mode, 64-bit key extended to 128 bits, similar toA5/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 asGEA3
, 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)
- 48-bit
- 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
, verifiesSQN
, and aborts by sending Synchronization Failure if it is incorrect - MS ⟶ NodeB : Authentication Response (
RES = f2(K, RAND)
) - MS ⟵ NodeB : Authentication Failure if
RES
andXRES
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 encryptionUEA1
: KASUMI in OFB mode, 128-bit key, similar toA5/3
(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 integrityUIA1
: 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 fromCK
,IK
, as wellSQN
,AK
(from theAUTN
token) and the SN id (serving network identity)K
eNB
: derived fromK
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 messagesK
RRCenc
for Access Stratum messagesK
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.
EEA0
: no encryption128-EEA1
: same asUEA2
(3GPP TS 33.401)128-EEA2
: AES in CTR mode, 128-bit key (3GPP TS 33.401)128-EEA3
: ZUC, 128-bit key (3GPP TS 35.222)
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 fromK
ASME
K
RRCint
for Access Stratum messages derived fromK
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 calls128-EIA1
: similar toUIA2
(3GPP TS 33.401)128-EIA2
: 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) andSAKKE
(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:
- UE1 ⟶ UE2 : Direct Communication Request (
LTK
id,K
D
id, algorithms,Nonce_1
) - UE1 ⟺ UE2 : Authentication and
K
D
negociation (optional) - UE2 generates
Nonce_2
and computesK
D-sess
= KDF(K
D
, Nonce_1, Nonce_2)
, as well asPIK
andPEK
- UE1 ⟵ UE2 : Direct Security Mode Command (
Nonce_2
, chosen algorithms,MAC-I
) - UE1 computes
K
D-sess
,PIK
,PEK
and verifiesMAC-I
withPIK
- UE1 ⟶ UE2 : Direct Security Mode Complete (
MAC-I
) - UE2 verifies
MAC-I
withPIK
. 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 verifiesMAC-GMM
- MS ⟶ BTS : Authentication and Ciphering Response (
SRES
,MAC-GMM
) - Network verifies
MAC-GMM
and verifiesSRES
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 encryptionGEA4
: same asGEA3
, 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)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
intoSRES* = KDF(CK || IK, RES, RAND)
- MS ⟶ gNB : Authentication Response (
RES*
) - MS ⟵ gNB : Authentication Failure if
RES*
andXRES*
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 encryption128-NEA1
: identical to128-EEA1
(SNOW 3G)128-NEA2
: identical to128-EEA2
(AES-128 CTR)128-NEA3
: identical to128-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.
NIA0
: no integrity128-NIA1
: identical to128-EIA1
(based on SNOW 3G)128-NIA2
: identical to128-EIA2
(AES-128 CMAC)128-NIA3
: identical to128-EIA3
(based on ZUC)
Comments