Description
MAC-I (Message Authentication Code for Integrity) is a cryptographic checksum appended to protocol data units (PDUs) in 3GPP radio access and core network protocols to guarantee their integrity. Unlike MAC-A, which is used for initial authentication, MAC-I is employed for ongoing integrity protection of signaling messages after security contexts are established. It is generated using a dedicated integrity key (IK), a freshness parameter (COUNT), a direction bit, the message itself, and a bearer identity. The most commonly referenced algorithms for its computation are the 128-EEA/128-EIA suites defined for LTE and NR, such as SNOW 3G, AES, and ZUC.
In the protocol stack, MAC-I is primarily associated with the Radio Resource Control (RRC) and Non-Access Stratum (NAS) signaling layers. For example, in LTE (TS 36.323), the PDCP (Packet Data Convergence Protocol) layer is responsible for integrity protection and verification of RRC messages using MAC-I. The transmitting entity (UE or eNodeB) calculates the MAC-I over the RRC PDU and includes it in the packet. The receiving entity independently recalculates the MAC-I using the same inputs and keys. If the calculated value matches the received MAC-I, the message is considered intact and authentic. A mismatch triggers a security failure, typically leading to the release of the radio connection.
The process involves a stateful counter (COUNT) to prevent replay attacks, ensuring that even identical messages sent at different times yield different MAC-I values. The direction bit distinguishes between uplink and downlink traffic, preventing reflection attacks. Architecturally, the integrity key (IK) used for MAC-I is derived during the AKA procedure from the root key K. In EPS, IK is part of the Kasme derivation; in 5GS, it is derived from the KAMF. This creates a cryptographically separated key hierarchy where compromise of traffic keys does not affect authentication keys.
MAC-I's role extends beyond RRC. In the core network, integrity protection for NAS messages between the UE and the MME (in EPS) or AMF (in 5GS) also utilizes a MAC-I mechanism, though the specific algorithm and key may differ (using KNASint). It is a mandatory security feature for all control plane signaling in modern 3GPP networks, forming a vital defense against tampering, message injection, and replay attacks on the air interface and within the network trust boundaries.
Purpose & Motivation
MAC-I was introduced to address the critical need for integrity and origin authentication of control signaling in packet-switched mobile networks. Earlier circuit-switched systems like GSM provided limited signaling protection, primarily focused on radio interface ciphering, leaving control channels vulnerable to manipulation. As networks evolved towards all-IP architectures with LTE and 5G, the risk of attackers modifying or forging signaling messages (e.g., handover commands, bearer setup requests, or paging messages) to disrupt service, cause denial-of-service, or redirect traffic became a paramount concern.
Its creation was motivated by the requirement for a robust, standardized integrity protection mechanism that could be applied hop-by-hop (e.g., over the Uu air interface) and end-to-end (e.g., for NAS). The problem it solves is ensuring that critical network control commands cannot be tampered with without detection. Without MAC-I, an attacker could alter a handover command to force a UE to camp on a malicious cell, or modify a paging message to track a user's location.
Furthermore, MAC-I enables the secure establishment of other security contexts. For instance, the integrity-protected RRC signaling is used to securely transport the ciphering algorithm configuration and the encrypted user plane security mode command. It forms an essential layer in the defense-in-depth strategy for 3GPP networks, working in conjunction with ciphering for confidentiality (using ENC algorithms) and AKA for initial authentication. Its stateful design with counters also addresses the limitation of static message authentication codes by providing replay protection, a crucial feature for time-sensitive mobility procedures.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (48 CRs across 5 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-8, normative work from Rel-15.
In Release 15, the specification introduced a clarification on the ciphering of the MAC-I for integrity protection. This change provided explicit details on how the Message Authentication Code for Integrity is handled within the Packet Data Convergence Protocol (PDCP) layer. The update was part of broader enhancements to PDCP, including procedures for duplication and re-establishment.
- Introduction of PDCP duplication TS 38.323CR0009
- User Plane Integrity Protection for EDT TS 33.401CR0699
- Deliver stored PDCP SDUs for UM DRB at PDCP re-establishment TS 36.323CR0241
- CR on supporting of the ROHC for PDCP duplication TS 36.323CR0243
- Correction on PDCP for eV2X TS 36.323CR0249
- Correction on PDCP duplication TS 36.323CR0255
+ 10 more changes
In Release 16, specific corrections were introduced for the PDCP layer concerning integrity and security operations in both LTE and NR contexts, particularly for Industrial IoT scenarios. The changes addressed PDCP security issues related to duplicate detection and detailed the PDCP entity's behavior when associated with an AM RLC entity. Furthermore, the release specified PDCP operational procedures, including re-establishment when t-Reordering is used and corrections for the PDCP status report, to ensure robust integrity protection.
- Introducing EHC in LTE PDCP TS 36.323CR0278
- LTE PDCP corrections for NR IIOT TS 36.323CR0286
- Correction for PDCP status report TS 36.323CR0287
- CR on LTE PDCP re-establishment when t-Reordering is used TS 36.323CR0290
- CR on LTE PDCP re-establishment for UM DRB when t-Reordering is used TS 36.323CR0291
- CR for LTE PDCP operation after DAPS release TS 36.323CR0296
+ 6 more changes
In Release 17, specific enhancements to the MAC-I function's context were introduced through PDCP layer corrections and clarifications for new relay and multicast services. These included integrity-related PDCP corrections for Layer 2 UE-to-Network (L2 U2N) Relay and for NR-based sidelink (SL) relay operations. Furthermore, the release provided PDCP corrections for Multicast/Broadcast Services (MBS), ensuring the integrity protection mechanisms are correctly applied in these expanded scenarios.
- Addition of a USIM file for configuration of warning messages reception in SNPNs. TS 31.102CR0951
- Introducing support of UP IP for EPC connected architectures using NR PDCP TS 38.323CR0085
- UP IP: mapping of EPS integrity algorithm to NR integrity algorithm TS 33.401CR0707
- Correction on PDCP Control PDU for UDC feedback TS 36.323CR0304
- Correction on PDCP for SL relay TS 38.323CR0093
- PDCP Corrections for MBS TS 38.323CR0096
+ 8 more changes
In Release 18, specific enhancements to the MAC-I function are not detailed within the provided grounding context or the listed Change Request titles. The titles focus on PDCP layer procedures such as NR sidelink PDCP duplication and PDCP SN gap reporting, but do not mention any modifications to the underlying integrity or authentication mechanisms like MAC-I. Therefore, based solely on the given materials, no new developments for the MAC-I function in Release 18 can be described.
In Release 19, the enhancements for MAC-I are specifically tied to XR (Extended Reality) PDCP layer improvements, as indicated by the CR titles focusing on XR. The changes involve corrections and enhancements to the PDCP specification to support the integrity and authentication requirements for XR services, ensuring the secure and reliable transfer of application messages for these demanding use cases.
Explore further
Broader topics and technologies where MAC-I plays a role.
Defining Specifications
3GPP specifications that define or reference MAC-I, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 31.102 vj40 | USIM Application Specification | Rel-19 |
| TS 33.105 vj00 | 3G Security: Cryptographic Algorithm Requirements | Rel-19 |
| TS 33.401 vj10 | EPS Security Architecture | Rel-19 |
| TS 36.323 vj00 | PDCP Protocol Specification | Rel-19 |
| TS 38.323 vj00 | Packet Data Convergence Protocol (PDCP) | Rel-19 |