Why 5G Needs Its Own Encryption Algorithms

Every packet transmitted over the 5G air interface and signaling planes must be protected against eavesdropping (confidentiality) and tampering (integrity). 3GPP defines two families of security algorithms for this purpose:

• NEA (NR Encryption Algorithm): Provides confidentiality protection by encrypting user-plane and signaling data.
• NIA (NR Integrity Algorithm): Provides integrity protection by appending a Message Authentication Code (MAC-I) to signaling messages and, in 5G for the first time, optionally to user-plane data.

These algorithms are specified in TS 33.501 (Security architecture and procedures for 5G System) and the detailed algorithm specifications in TS 33.401 (which 5G inherits from EPS with extensions). The cryptographic primitives are defined in the EEA/EIA series: TS 35.215--35.218 (SNOW 3G), TS 35.226--35.228 (AES), and TS 35.231--35.233 (ZUC).

Algorithm Suite Overview

NEA Algorithms (Confidentiality)

NIA Algorithms (Integrity)

Key Differences Between NEA and NIA

A critical 5G security enhancement over 4G is mandatory user-plane integrity protection (UPIP) for certain traffic types. In LTE, user-plane integrity was never supported. TS 33.501 Section 6.6.1 specifies that the gNB may activate UPIP per DRB, and it is mandatory for control-plane-like user-plane traffic (e.g., IMS SIP signaling carried over the user plane).

How Encryption Works: The Keystream Model

All three NEA algorithms (NEA1, NEA2, NEA3) use the same operational model: they generate a keystream that is XORed with the plaintext to produce ciphertext.

The inputs to the keystream generator are:

• KEY (128 bits): The encryption key (K_NASenc for NAS, K_RRCenc for RRC, K_UPenc for user plane)
• COUNT (32 bits): The PDCP COUNT value, which increments per packet and prevents replay attacks
• BEARER (5 bits): The bearer/DRB identifier
• DIRECTION (1 bit): Uplink (0) or downlink (1)
• LENGTH: Number of bits to encrypt

The decryption operation is identical -- XOR the ciphertext with the same keystream to recover plaintext. This symmetric property simplifies implementation.

Worked Example 1: NAS Encryption with 128-NEA2 (AES-CTR)

Scenario: The AMF encrypts a NAS Downlink Transport message carrying a PDU Session Establishment Accept. Given:

• K_NASenc = 0x2BD6459F82C5B300952C49104881FF48 (derived from K_AMF via KDF)
• COUNT = 0x00000005 (5th NAS message in this security context)
• BEARER = 0x00 (NAS uses bearer 0)
• DIRECTION = 1 (downlink)
• Plaintext length = 256 bits (32 bytes)

Step 1 -- Construct the AES-CTR initial counter block (T):

The counter block is formed as: COUNT || BEARER || DIRECTION || 0...0

T = 0x00000005 | 00 | 1 | 000...0 = 0x00000005_02800000_00000000_00000000

(BEARER = 0x00 in bits 32-36, DIRECTION = 1 in bit 37, remaining bits zero-padded to 128 bits)

Step 2 -- Generate keystream using AES-128-CTR: Keystream_block_0 = AES_encrypt(K_NASenc, T) Keystream_block_1 = AES_encrypt(K_NASenc, T + 1)

For 256 bits of plaintext, we need 2 AES blocks (128 bits each).

Step 3 -- XOR plaintext with keystream: Ciphertext = Plaintext XOR Keystream

The AMF transmits the ciphertext in the NAS PDU. The UE, possessing the same K_NASenc, generates the identical keystream and recovers the plaintext.

Security properties:

• The COUNT value ensures that even identical messages produce different ciphertext (no keystream reuse)
• The BEARER and DIRECTION fields prevent cross-bearer and cross-direction attacks
• AES-128-CTR provides IND-CPA security with 2^64 block security margin

Worked Example 2: RRC Integrity Check with 128-NIA1 (SNOW 3G)

Scenario: The gNB sends an RRC Reconfiguration message. The UE must verify its integrity before applying the configuration. Given:

• K_RRCint = 0x7E56C8F4A3B901D2E4F6789012345678 (derived from K_gNB)
• COUNT = 0x0000001A (26th RRC message)
• BEARER = 0x01 (SRB1)
• DIRECTION = 1 (downlink)
• MESSAGE = 480 bits of RRC Reconfiguration content

Step 1 -- Initialize SNOW 3G:

Load KEY and IV (derived from COUNT, BEARER, DIRECTION) into the SNOW 3G LFSR and FSM registers. Run 32 initialization clocks.

Step 2 -- Generate MAC:

SNOW 3G produces a keystream. The NIA1 MAC function processes the MESSAGE through a modified CBC-like construction using the keystream:

MAC-I = NIA1(K_RRCint, COUNT, BEARER, DIRECTION, MESSAGE)

Result: MAC-I = 0xA3F7B219 (32 bits)

Step 3 -- Transmit and verify:

The gNB appends MAC-I = 0xA3F7B219 to the PDCP PDU. The UE recomputes the MAC using the same inputs and compares. If they match, the message is authentic. If not, the UE discards the message and may trigger a re-establishment procedure as defined in TS 38.331 Section 5.3.7.

What happens if integrity fails:

• For NAS messages: UE discards the message, may initiate NAS security mode failure
• For RRC messages: UE discards, may trigger RRC re-establishment
• For user plane (if UPIP is active): packet is dropped silently at PDCP layer

Algorithm Negotiation and Selection

NAS Security Mode Command

Algorithm selection occurs during the NAS Security Mode Command procedure (TS 33.501 Section 6.7.2):

1. UE sends Registration Request with UE Security Capabilities IE listing supported algorithms
2. AMF selects the highest-priority algorithm from the UE's capabilities that is also in the AMF's configured priority list
3. AMF sends NAS Security Mode Command with selected NEA and NIA algorithms
4. UE verifies and responds with NAS Security Mode Complete (encrypted and integrity protected with selected algorithms)

AS Security Mode Command

For the radio interface, the gNB performs AS Security Mode Command (TS 33.501 Section 6.7.4):

1. gNB receives UE Security Capabilities from AMF via NGAP Initial Context Setup Request
2. gNB selects AS encryption (NEA) and integrity (NIA) algorithms based on its local policy and UE capabilities
3. gNB sends AS Security Mode Command (integrity protected, not encrypted)
4. UE responds with AS Security Mode Complete (encrypted and integrity protected)

Algorithm Priority Configuration

Operators configure algorithm priority lists on AMF and gNB. A typical priority order:

Operator Algorithm Selection Data

Deutsche Telekom (Germany)

Deutsche Telekom's 5G SA network (launched 2023) uses the following configuration:

• NAS encryption: NEA2 (AES) as primary, NEA1 (SNOW) as fallback
• NAS integrity: NIA2 (AES) mandatory
• AS encryption: NEA2 (AES) for all DRBs
• AS integrity: NIA2 for SRBs; UPIP enabled for IMS bearer (DRB carrying SIP signaling)
• 99.7% of UE connections negotiate NEA2/NIA2 (AES-based), confirming that modern 5G chipsets universally support AES with hardware acceleration

SK Telecom (South Korea)

SK Telecom's deployment data from 2024 shows:

• Primary algorithms: NEA2/NIA2 across all network elements
• NEA3/NIA3 (ZUC) support added in Q3 2024 for roaming interoperability with Chinese operators
• User-plane integrity: enabled for VoNR (Voice over New Radio) bearer with negligible throughput impact (< 0.5% overhead)
• Algorithm negotiation time: < 2 ms in NAS SMC, < 1 ms in AS SMC
• Zero reported algorithm downgrade attacks since 5G SA launch (2022)

Key Derivation Hierarchy

Understanding where encryption keys come from is essential. The 5G key hierarchy, defined in TS 33.501 Annex A, derives all keys from the authentication root key K stored in the USIM and AUSF:

K (USIM) -> K_AUSF -> K_SEAF -> K_AMF -> K_NASenc, K_NASint, K_gNB -> K_RRCenc, K_RRCint, K_UPenc, K_UPint

Each derivation uses HMAC-SHA-256 as the Key Derivation Function (KDF). The input parameters include algorithm distinguishers to ensure that keys for different algorithms are cryptographically independent:

The Algorithm ID in the KDF input ensures that switching from NEA1 to NEA2 produces a completely different key, even if K_AMF is the same. This prevents related-key attacks across algorithm types.

Performance Comparison

AES dominates in software performance due to the ubiquitous AES-NI (Intel) and Cryptographic Extensions (ARM) hardware instructions. This is the primary reason most operators worldwide configure NEA2/NIA2 as their highest-priority algorithms.

Security Considerations and Known Attacks

1. NEA0/NIA0 downgrade attacks: An active attacker (fake base station) could attempt to force the UE to use null encryption. 5G mitigates this because NAS integrity (NIA) is established before encryption, and the Security Mode Command itself is integrity-protected. The UE rejects any NAS SMC requesting NIA0 unless it is an emergency call context.

1. Key reuse (COUNT wrap-around): If the PDCP COUNT (32 bits) wraps around, the same keystream would be reused, enabling a known-plaintext attack. At maximum 5G NR throughput, COUNT wrap-around occurs after approximately 4 billion packets -- operators must trigger a key refresh (intra-cell handover or re-authentication) before this threshold.

1. Algorithm agility: The 5G framework supports adding new algorithms (NEA4, NIA4, etc.) without changing the architecture. This forward-compatibility is critical for the eventual transition to post-quantum algorithms, which 3GPP is studying under TR 33.870 (Study on post-quantum cryptography).

Key Takeaway: 5G defines three encryption algorithms (NEA1/SNOW, NEA2/AES, NEA3/ZUC) and three integrity algorithms (NIA1/NIA2/NIA3), all operating on 128-bit keys derived from the USIM root key K via HMAC-SHA-256. NEA2/NIA2 (AES-based) is the de facto global standard due to 3--5x performance advantage from hardware acceleration. 5G mandates integrity protection on both NAS and RRC signaling, and introduces optional user-plane integrity protection -- a critical security improvement over 4G LTE. Operator data from Deutsche Telekom and SK Telecom confirms 99.7%+ adoption of AES-based algorithms with zero reported downgrade attacks in production 5G SA networks.