5G-EA0 Null Ciphering in 5G Security
- Null ciphering (5G-EA0) is a standardized confidentiality method in 5G that performs no encryption, transmitting data in cleartext as per negotiated protocols.
- It is negotiated via NAS and AS security mode commands during authentication and registration, ensuring protocol consistency across network layers.
- Its use introduces security edge cases such as downgrade attacks and rogue cell exploits, prompting calls for tighter operator policies and future deprecation.
Null ciphering, formally designated as 5G-EA0 within 3GPP specifications, denotes a confidentiality algorithm that performs no cryptographic transformation on data; all payloads are transmitted in cleartext at the protocol layer for which EA0 is negotiated. Its definition, registration, and potential negotiation are explicitly specified in both the Non-Access Stratum (NAS) and Access Stratum (AS) security procedures of 5G Release 15. Despite the overall enhancement of 5G security compared to prior generations, the continued support for EA0 (and its integrity counterpart NIA0) introduces security edge cases with notable protocol and configuration consequences (Jover et al., 2018).
1. Formal Specification and Negotiation Mechanisms
EA0 is registered in TS 33.501 Annex A (Algorithm Identifiers) as confidentiality algorithm identifier “000” (algorithm ID=0), with NIA0 (also ID=0) as its integrity-null counterpart. These definitions apply across both NAS and AS:
- NAS Algorithms (TS 33.501, Annex A.2): EA0 appears as the first entry under the confidentiality column.
- AS Algorithms (TS 33.501, Annex A.3): EA0 is the first entry in the equivalent section.
Negotiation of EA0 proceeds according to authenticated security mode procedures:
- NAS Security Mode Command (NAS-SMC): Per TS 24.501 § 5.7.8.1, following successful 5G-AKA or EAP-AKA, the AMF/SEAF includes the selected NAS ciphering algorithm. If EA0 is selected, the relevant field is set to 0x00. The UE echoes acceptance in the Security Mode Complete message (TS 24.501 § 5.7.8.2).
- AS Security Mode Command (RRC-SMC): The gNB sends the RRC Security Mode Command (TS 38.331 § 5.7.2) that includes the selected AS ciphering algorithm; EA0 is communicated with code 0x00.
2. Protocol Flows and Message Exchanges Leading to EA0
The high-level sequence for arriving at EA0 in a registration scenario is as follows:
- The UE initiates registration (containing SUCI or 5G-GUTI), which propagates through gNB and AMF/SEAF to AUSF/UDM.
- 5G-AKA or EAP-AKA is executed, generating authentication vectors.
- Upon authentication success, the AMF/SEAF determines algorithm choices based on UE capabilities and SN policy, populating the NAS Security Mode Command accordingly. EA0 is selected if and only if the UE supports it and the SN allows null encryption.
- The NAS security mode is acknowledged, after which the gNB may initiate RRC setup and subsequent RRC Security Mode Command, echoing the same algorithm selection for AS security.
| Step | Message Direction | Cipher Alg Value (EA0) |
|---|---|---|
| NAS Security Mode Cmd | AMF/SEAF → UE | 0x00 |
| NAS Security Mode Comp. | UE → AMF/SEAF | 0x00 (acceptance) |
| RRC Security Mode Cmd | gNB → UE | 0x00 |
| RRC Security Mode Comp. | UE → gNB | 0x00 (acceptance) |
At the AMF logic level, the algorithm selection pseudocode after 5G-AKA success is:
1 2 3 4 5 |
if (UE.capabilities.includes("EA0") and SN.policy.allowsNullEncryption): selected_CiphAlg = 0x00 # EA0 else: selected_CiphAlg = bestCommon(UE.list, SN.list) send_NAS_Security_Mode_Command(selected_CiphAlg, ...) |
3. Key Derivation, Algorithm ID Semantics, and Null Operation
5G derives keying material for both NAS and AS confidentiality/integrity using a KDF from the root key K_AMF, as specified in TS 33.501 § 5.2. The relevant computations are:
where itself is derived from with .
Upon establishment, the cipher and MAC engines check the algorithm identifier:
- If ID=0 (EA0): The cipher operation becomes a pass-through; data is transmitted unaltered.
- If NIA0 active: No MAC-I is computed or checked; the integrity operation is null.
This choice is determined solely by the algorithm identifier—key derivation proceeds identically regardless of subsequent ciphering operations.
4. Operator Configurations, Roaming, and Emergency Scenarios
EA0’s applicability is dictated by explicit operator and system policy decisions, with critical contexts including:
- Operator Policy: The 3GPP security specifications declare “Null encryption supported. Confidentiality protection optional to use.” Each operator configures their Serving Network (SN) to include or exclude EA0/NIA0 as per operational requirements. If not explicitly disabled, devices supporting EA0 may negotiate unprotected modes.
- Roaming Agreements: In scenarios where the UE’s USIM does not possess a public key for the SN’s Home Network (typically when roaming into an unprovisioned SN), the UE must fall back to EA0, as the PKI-dependent Subscription Permanent Identifier (SUPI) privacy protection cannot be guaranteed.
- Emergency and Lawful Intercept: Specifications require support for null cipher/integrity in specific cases: unauthenticated emergency call establishment and IP-based lawful intercept, where confidentiality and integrity protection are explicitly optional or unsupported.
5. Security Implications and Protocol Exploits
Multiple security edge cases arise directly from EA0’s availability:
- Bidding-Down Attacks: A rogue gNB or AMF advertising only EA0 as the common algorithm can downgrade the protection level of the connection—UEs will accept this unless carrier policy suppresses null options, as per Sec 5.7.8 (TS 24.501) and Sec 5.7.2 (TS 38.331).
- Rogue Base Station Data Exposure: Attackers running rogue cells may negotiate RRC/NAS sessions with null ciphering, capturing or altering both signalling and user data.
- SUPI/SUCI Edge Cases: If a suppliant lacks the required public key due to unprovisioned HN entries, EA0 is mandated (“shall be used when public key not provisioned by HN”). Adversaries may exploit this by simulating a legitimate SN for which the UE must fall back to null encryption.
6. Mitigations and Recommendations
The current threat landscape and protocol design admit the following mitigations, as explicitly recommended in the analysis:
- Operator Policy Restriction: SNs are advised to exclude EA0/NIA0 from supported algorithms except where mandated (e.g., emergency service). This enforces actual ciphering and integrity protection.
- Deprecation in Future Releases: Complete removal of EA0/NIA0 for general use is advocated within future 3GPP releases; if null protection remains for emergency, the use should be isolated through dedicated frequencies or network slices.
- Certificate-Based Authentication: Adoption of a global PKI (or 5G Certificate Authority) would enable digital signatures for all pre-authentication messages, mitigating protocol downgrade and SUPI privacy exploits by providing robust authentication prior to security mode establishment.
7. Conclusion and Contemporary Perspective
5G-EA0 remains a fully standardized and legitimate algorithm choice in Release 15, systematically negotiated in both NAS and AS layers via Security Mode Commands that reference algorithm ID “0x00”. While key derivation proceeds identically to standard cipher suites, the cipher and integrity processes themselves perform no transformation when EA0/NIA0 are in use. The security analysis of Piqueras Jover & Marojevic (Jover et al., 2018) emphasizes that the presence of null ciphering immediately exposes 5G systems to classical LTE pre-authentication and downgrade attacks if not disabled operationally. Robust security thus depends not only on protocol correctness, but on strict operator policy enforcement, planned standards evolution, and the eventual deployment of universal certificate-based key management infrastructure.