X-MAC

Computed MAC-I

Security →
Introduced in Rel-8

X-MAC is the expected Message Authentication Code computed by the receiving entity to verify the integrity and origin of signaling messages by comparison against the received MAC-I.

Category
Security
Introduced
Rel-8
Where
Radio Access Network › NG-RAN (5G)
Specifications
2 specs
X-MAC Description Purpose Related Classification Detected Changes Specifications

Description

X-MAC is a cryptographic value computed during integrity protection verification in the Radio Resource Control (RRC) and Non-Access Stratum (NAS) protocols of LTE (E-UTRAN) and NR (NG-RAN). It is not a transmitted field but an internal calculated value. When a secured message is sent, the transmitting entity (e.g., the gNB or AMF) calculates a Message Authentication Code for Integrity (MAC-I) using a cryptographic integrity algorithm (like 128-EIA1, EIA2, or EIA3), a secret integrity key (K_{RRCint}, K_{RRCint} for NR, or K_{NASint}), a COUNT value (a counter preventing replay attacks), a bearer identifier, a direction bit, and the message itself. This MAC-I is appended to the message.

Upon receipt, the receiving entity (e.g., the UE or the network node) performs the same calculation on the received message data before the MAC-I is verified. The result of this local computation is the X-MAC. The receiver then compares the computed X-MAC with the MAC-I received in the message. If they match exactly, it confirms that the message has not been altered in transit (integrity) and that it originated from an entity possessing the correct secret key (authentication). If they do not match, the message is discarded, and the failure is logged, potentially triggering security recovery procedures.

The computation is specified in detail in 3GPP TS 33.401 (for LTE) and TS 33.501 (for 5G). The integrity keys are derived during the Authentication and Key Agreement (AKA) procedure and are specific to the UE, session, and protocol layer. The COUNT is systematically incremented, and its synchronization between sender and receiver is critical; a mismatch will cause an X-MAC vs. MAC-I verification failure. This mechanism protects critical signaling commands like handover instructions, connection reconfigurations, and service requests from tampering or forgery.

Purpose & Motivation

X-MAC verification exists to fulfill the fundamental security requirements of integrity and data origin authentication for control plane signaling. Without it, an attacker could modify or spoof signaling messages, leading to service disruption, forced handovers to rogue cells, denial of service, or privacy breaches. Prior to 3G and the full implementation of cryptographic integrity in LTE/5G, some signaling messages had weaker or no integrity protection, making networks vulnerable to certain attacks.

The introduction of mandatory integrity protection with strong algorithms in LTE Rel-8, and its continuation in NR, was a direct response to the evolving threat landscape for mobile networks. The X-MAC comparison is the operational heart of this protection. It allows the receiver to autonomously and efficiently verify every secured message without further network interaction. The design using a computed value (X-MAC) versus a received one (MAC-I) provides a clear procedural separation between the calculation and the verification step, which is important for secure software implementation and testing.

Classification

Part ofMAC-I

Detected Changes Across Releases

from 3GPP Change Requests

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

Studied in Rel-8, normative work from Rel-15.

Rel-15 1 change

In Release 15, the specification introduced clarification regarding the ciphering of the MAC-I field used for integrity protection in PDCP. It explicitly states that ciphering is not applicable to PDCP Control PDUs, and it details the procedure for computing and verifying the X-MAC for integrity protection. Furthermore, it specifies that for control plane data without integrity protection, the MAC-I field must still be present and padded with zeros.

  • Clarification on ciphering MAC-I TS 38.323CR0024

Explore further

Broader topics and technologies where X-MAC plays a role.

Defining Specifications

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

SpecificationTitleRelease
TS 36.323 vj00 PDCP Protocol Specification Rel-19
TS 38.323 vj00 Packet Data Convergence Protocol (PDCP) Rel-19