AEAD

Authenticated Encryption with Associated Data

Security →
Introduced in Rel-15

AEAD is a cryptographic method that simultaneously provides confidentiality, integrity, and authenticity by encrypting a payload and generating an authentication tag for both the ciphertext and any associated unencrypted data.

Category
Security
Introduced
Rel-15
Where
Security
Specifications
2 specs
AEAD Description Purpose Detected Changes Specifications

Description

Authenticated Encryption with Associated Data (AEAD) is a symmetric-key cryptographic operation that combines encryption and authentication into a single, secure mode. In 3GPP systems, it is specified as the primary mechanism for protecting user plane and control plane traffic, particularly within the 5G security architecture defined in TS 33.501. The core function takes four inputs: a secret key, a nonce (number used once), the plaintext message to be encrypted, and the Associated Data (AD) which requires authentication but not encryption. It produces two outputs: the ciphertext (encrypted version of the plaintext) and an authentication tag.

The algorithm works by processing both the plaintext and the associated data through a cryptographic construction that provides indistinguishability under chosen plaintext attacks (IND-CPA) for confidentiality and existential unforgeability under chosen message attacks (EUF-CMA) for integrity. The associated data, which can include packet headers, sequence numbers, or other metadata critical for protocol operation, is authenticated but transmitted in clear text. This allows intermediate network nodes (like gNBs or UPFs) to inspect necessary header information without compromising the security of the encrypted payload.

In 3GPP implementations, specific AEAD algorithms like AES-GCM (Galois/Counter Mode) and ChaCha20-Poly1305 are mandated. For 5G, the 128-bit AES-GCM is the primary algorithm for NAS and RRC signaling protection, as well as for user plane integrity protection when enabled. The nonce must be unique for each invocation with the same key, typically constructed from parameters like the COUNT value (for signaling) or the PDCP SN and bearer identity (for user plane). The authentication tag length is typically 16 bytes (128 bits) for AES-GCM, providing a high level of assurance against forgery attempts.

AEAD's role in the network is pervasive. It secures the N1 (UE-AMF) and N2 (RAN-AMF) interfaces for control plane signaling. For the user plane, it can provide both confidentiality and integrity protection (as per the 'integrity protected' indication) on the Uu (UE-gNB) and N3 (gNB-UPF) interfaces. Its efficiency—requiring only a single pass over the data for both encryption and authentication—reduces latency and computational overhead compared to using separate encryption and MAC algorithms, which is crucial for high-throughput 5G applications.

Purpose & Motivation

AEAD was introduced to address the limitations of previous 3GPP security mechanisms that often used separate, composition-based approaches for encryption and integrity. In 4G (EPS), confidentiality and integrity were provided by distinct algorithms (e.g., SNOW 3G or AES for encryption, and a separate MAC for integrity). This compositional approach, while secure if implemented correctly, is more complex, less efficient, and prone to implementation errors. The move to AEAD in 5G aligns with modern cryptographic best practices, simplifying protocol design and reducing the attack surface.

The primary motivation was to enhance security assurance and performance for 5G's diverse service requirements, including enhanced Mobile Broadband (eMBB), Ultra-Reliable Low-Latency Communications (URLLC), and massive IoT. AEAD algorithms are provably secure under standard assumptions, offering robust protection against both passive eavesdropping and active tampering. Their single-pass nature is critical for meeting the low-latency targets of URLLC services and for handling the high data rates of eMBB without introducing significant processing delays.

Furthermore, AEAD supports the authentication of associated data, which is essential for 3GPP protocols. Packet headers, sequence numbers, and QoS flow identifiers often need to be authenticated to prevent protocol-level attacks (like replay or reordering) but do not require encryption for network functionality. AEAD elegantly solves this by allowing this metadata to be included in the authentication calculation without being encrypted, enabling efficient network operation while maintaining a strong security guarantee.

Detected Changes Across Releases

from 3GPP Change Requests

Specific changes extracted from the „Change history“ tables of 3GPP specifications (7 CRs across 3 releases). Complements the general historical overview above with the evidence-based evolution of this function.

Rel-15 3 changes

In Release 15, the specification for the AEAD function was updated to correct the encryption key in the confidentiality clause. Additionally, the release involved the deletion of the EN (Encryption) parameter for authenticated IMS emergency sessions as specified in Clause 10.2.1. It also introduced subscriber privacy test data for ECIES-based encryption procedures in the User Equipment (UE).

  • Correct the encryption key in confidentiality clause TS 33.501CR0259
  • Deletion of EN in Caluse 10.2.1 Authenticated IMS Emergency Sessions TS 33.501CR0262
  • Subscriber privacy: test data for ECIES-based encryption in the UE TS 33.501CR0565
Rel-17 2 changes

In Release 17, the primary enhancement for AEAD functionality was the resolution of encryption policy mismatches between SEPPs (Security Edge Protection Proxies). This included aligning the JSON format for encryption information elements (IEs) specifically for the CT4 interface within that release.

  • Resolving editor's note on encryption policy mismatch between SEPPs TS 33.501CR1019
  • Mirror: align the JSON format on encryption IE with CT4 in Rel17 TS 33.501CR1048
Rel-18 2 changes

In Release 18, the AEAD function was updated with a clarification on the Data-type Encryption Policy for the SEPP, specifying which attributes require confidentiality protection. Furthermore, the release provided a formal clarification on the use and handling of the NULL encryption algorithm (NEA0) within the system's ciphering framework.

  • Clarification on data-type encryption policy TS 33.501CR1634
  • NULL encryption clarification TS 33.501CR1795

Explore further

Broader topics and technologies where AEAD plays a role.

Defining Specifications

3GPP specifications that define or reference AEAD, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TS 33.501 vk00 5G Security Architecture and Procedures Rel-20
TR 33.938 vj10 3GPP Cryptographic Inventory for 5G Rel-19