Description
MAC-A is a core cryptographic component of the 3GPP Authentication and Key Agreement (AKA) procedure, standardized from Release 8 onwards. It functions as a Message Authentication Code, a short piece of information generated using a cryptographic algorithm and a secret key to verify both the authenticity and integrity of a message. In the AKA context, MAC-A is specifically generated by the network side (typically the Authentication Centre, AuC, within the Home Subscriber Server, HSS) and included in the authentication vector (AV) sent to the serving network (e.g., MME in EPS, AMF in 5GS). This AV contains parameters like RAND (a random challenge), AUTN (the Authentication Token), XRES (Expected Response), and session keys.
The AUTN (Authentication Token) itself is a constructed parameter that includes, among other fields, the MAC-A. When the UE receives the authentication challenge (RAND and AUTN), it independently computes its own version of MAC-A using the shared secret key K (stored on the USIM and in the AuC), the received RAND, and other parameters like the Sequence Number (SQN). The UE then compares its computed MAC-A with the one extracted from the received AUTN. If they match, the UE has cryptographically verified that the authentication challenge originated from a genuine network entity that possesses the correct shared secret K. This mutual authentication step is fundamental to establishing trust before any user data session begins.
Architecturally, MAC-A generation and verification are distributed between the core network's authentication infrastructure (HSS/AuC) and the USIM application on the UE's UICC card. The algorithm used for computing MAC-A is the MILENAGE algorithm suite, as specified in 3GPP TS 35.205 and 35.909, which is based on the AES (Advanced Encryption Standard) block cipher. The specific input to the MAC-A function includes the secret key K, the random challenge RAND, and the sequence number SQN, ensuring that each authentication attempt produces a unique, non-replayable MAC. Its role is purely for network authentication from the UE's perspective; it does not provide integrity protection for user data traffic, which is handled by separate keys and mechanisms like MAC-I.
The security of the entire AKA protocol hinges on the robustness of MAC-A. A failure in MAC-A verification at the UE side results in authentication rejection, protecting the user from connecting to rogue base stations or networks attempting to intercept communications. It is a critical element in the chain of trust that underpins mobile network security, enabling services from basic voice calls to high-value financial transactions over cellular connections.
Purpose & Motivation
MAC-A was introduced to provide a standardized, cryptographically strong mechanism for the UE to authenticate the network within the 3GPP AKA framework. Prior to 3GPP's unified AKA, earlier cellular systems had various authentication methods, but they often lacked the robust mutual authentication and key derivation procedures needed for evolving packet-switched services and increasing threat landscapes. The primary problem MAC-A solves is network impersonation, where a malicious entity could attempt to pose as a legitimate operator network to harvest user credentials or launch man-in-the-middle attacks.
Its creation was motivated by the need for a clean-slate, algorithm-agile security architecture for EPS (LTE) and subsequent systems, moving away from the COMP128 algorithms used in 2G/3G. The 3GPP TSG SA WG3 (Security group) specified MILENAGE as the example algorithm set, with MAC-A as a core function. This allowed for mutual authentication: while the network authenticates the UE via the RES/XRES check, the UE authenticates the network via the MAC-A check within AUTN. This mutual verification establishes a two-way trust relationship essential for secure service delivery.
Furthermore, MAC-A's design as part of a comprehensive key hierarchy supports the derivation of multiple subsequent cryptographic keys (CK, IK, Kasme) for ciphering and integrity protection of both control plane and user plane traffic. It addresses the limitation of previous approaches by being transparently implementable on USIM cards, enabling backward compatibility and smooth migration, while providing a foundation that was intended to be resistant to cryptographic attacks for the foreseeable future.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (27 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, updates to the USIM management procedures for 5GS were introduced, which encompass the authentication process. These enhancements included allowing the configuration of Mission Critical Services data and Access Identity 2 via the USIM, directly supporting the UE's baseline capability to register with authentication to the network.
- USIM Service Table update for PDU session call control support TS 31.102CR0786
- Allow configuration of MCS (Access Identity 2) via USIM. TS 31.102CR0794
- Mission Critical Services configuration data update to USIM TS 31.102CR0808
- Enhance USIM OPL configuration to support 3 bytes TAC when in NG-RAN. TS 31.102CR0818
- Updates to USIM management procedures for 5GS TS 31.102CR0806
- Clarification about presence of EFIMSConfigData in ISIM and USIM TS 31.102CR0833
In Release 16, the MAC-A function itself was not directly modified; however, enhancements were made to the USIM's authentication and configuration capabilities. These included specifying storage for a potentially separate KSEAF for non-3gpp access and supporting a Trusted non-3GPP access networks list on the USIM. Additionally, the release introduced support for configuring RLOS PLMN and MCC lists directly via the USIM.
- Support for USIM configuration of RLOS PLMN list TS 31.102CR0847
- URSP storage in USIM TS 31.102CR0861
- Specify storage for a potentially separate KSEAF for non-3gpp access on the USIM TS 31.102CR0864
- USIM configuration of RLOS allowed MCC list TS 31.102CR0881
- Support for Trusted non-3GPP access networks list by USIM TS 31.102CR0891
- Dedicated AID for USIM Applications with non-IMSI based SUPI Types TS 31.102CR0897
+ 3 more changes
In Release 17, the MAC-A function itself was not directly modified; instead, the release enhanced the USIM's role in authentication and network access procedures by introducing new storage capabilities. Specifically, the USIM was expanded to store parameters for SOR-CMCI (Steering of Roaming with Consumer Mobile Connection Information) and to hold configuration data for disaster roaming conditions, including wait ranges and applicability indicators. These additions provide the USIM with more pre-configured information that can be utilized during authentication and registration processes with the network.
- Introduce a USIM file to store pre-configured CAG information list TS 31.102CR0904
- SOR-CMCI storage in USIM TS 31.102CR0917
- Addition of USIM files for the indication of whether disaster roaming is enabled in the UE, disaster roaming wait range, disaster return wait range and applicability indicator for disaster roaming PLMNs list provided by VPLMN. TS 31.102CR0938
- Adding eDRX parameters in the USIM for NG-RAN TS 31.102CR0943
- 5G NSWO (Non-Seamless WLAN Offload) configuration support in the USIM compromised proposal. TS 31.102CR0946
- Support of 'No E-UTRA Disabling In 5GS' in USIM TS 31.102CR0947
+ 2 more changes
In Release 18, enhancements to the MAC-A function's ecosystem included mandating that specific USIM services be enabled together to ensure extended storage of 5G security parameters. Furthermore, new Elementary Files (EFs) were introduced on the USIM for Access Control to GBA_U_APIs and for IMS Data Channel configuration, expanding the authentication and service configuration data managed by the USIM application.
In Release 19, a key update for the MAC-A function involved ensuring backward compatibility for USIMs that lack extended security parameter storage, specifically within the EF_5GAuthKeys file. This change addresses authentication procedures by defining how a UE and network negotiate capabilities when such legacy USIMs are present. The enhancement ensures the maintenance of secure registration and authentication baseline capabilities even when the USIM's storage is limited.
- Backward compatibility handling of USIM without extended security parameter storage in EF_5GAuthKeys - Rel19 TS 31.102CR1074
Explore further
Broader topics and technologies where MAC-A plays a role.
Defining Specifications
3GPP specifications that define or reference MAC-A, 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 35.205 vj00 | MILENAGE Algorithm Set: General Overview | Rel-19 |
| TR 35.909 vj00 | 3GPP MILENAGE Algorithm Design Report | Rel-19 |
| TR 35.934 vj00 | Tuak algorithm set for 3GPP auth & key gen | Rel-19 |