5G Security vs 4G Security — 3GPP Technical Analysis...

3GPP Security Architecture Overview

The evolution from 4G (LTE/EPS) to 5G represents the most significant security architecture redesign in mobile telecommunications history. While 4G security (TS 33.401) was built around a hierarchical, perimeter-based model, 5G security (TS 33.501) introduces a service-based security framework that addresses cloud-native deployments, network slicing, and edge computing.

Key 3GPP Specifications Referenced

TS 33.501 5G System Security

TS 33.401 EPS Security Architecture

TS 33.102 3G Security Architecture

TS 33.210 Network Domain Security

TS 33.310 Authentication Framework

TS 23.501 System Architecture

Classical Telecom Security

SIM-based identity (USIM), AKA protocols, symmetric key cryptography, integrity & ciphering

Cloud-Native Security

Zero trust, API security, OAuth 2.0 tokens, TLS/mTLS, container hardening

Multi-Tenant Governance

Slice isolation, NSSAI-based policies, inter-slice security, edge deployment protection

4G/EPS Security Architecture (TS 33.401)

The Evolved Packet System (EPS) security architecture, defined in 3GPP TS 33.401, established the foundation for modern mobile network security. Understanding this baseline is essential for appreciating the 5G security evolution.

TS 33.401 EPS Security Architecture

The EPS security architecture defines five security feature groups:

Network Access Security (I) — Secure access to services via E-UTRAN
Network Domain Security (II) — Secure signaling and user data between nodes
User Domain Security (III) — Secure access to mobile stations
Application Domain Security (IV) — Secure messaging between applications
Visibility & Configurability (V) — User awareness of security features

4G/EPS Key Hierarchy (TS 33.401 Section 6.2)

Permanent Key (USIM)

K_ASME

Access Security Management Entity Key

K_NAS-enc

NAS Encryption

K_NAS-int

NAS Integrity

K_eNB

eNodeB Key

K_UP-enc

User Plane Enc

K_RRC-enc

RRC Encryption

K_RRC-int

RRC Integrity

4G Security Strengths

Proven mutual authentication (EPS-AKA), strong key derivation (KDF based on HMAC-SHA-256), mandatory integrity protection for NAS signaling, well-defined trust boundaries.

5G Security Architecture (TS 33.501)

3GPP TS 33.501 defines a comprehensive security framework that addresses the unique challenges of 5G, including service-based architecture, network slicing, and edge deployments.

TS 33.501 5G Security Features

Key security enhancements in 5G System:

SUPI/SUCI — Subscription identifier privacy using ECIES
5G-AKA & EAP-AKA' — Enhanced authentication with home network control
SEAF/AUSF/UDM — Distributed authentication architecture
SBA Security — OAuth 2.0, TLS 1.3 for NF communication
SEPP — Security Edge Protection Proxy for roaming
User Plane Integrity — Optional UP integrity protection

5G Key Hierarchy (TS 33.501 Section 6.2)

Permanent Key (USIM)

K_AUSF

AUSF Key (Home Network)

K_SEAF

SEAF Key (Serving Network)

K_AMF

AMF Key

K_NAS-enc

NAS Enc

K_NAS-int

NAS Int

K_gNB

gNB Key

K_N3IWF

Non-3GPP

Key Difference: K_AUSF and K_SEAF

Unlike 4G where K_ASME is derived and used in the serving network, 5G introduces K_AUSF (anchored in home network) and K_SEAF (for serving network), enabling better roaming security and home network control.

Subscriber Identity Privacy: SUPI/SUCI

One of the most significant security improvements in 5G is the protection of subscriber permanent identity through encryption, addressing a long-standing vulnerability in previous generations.

SUCI Generation & Deconealment (TS 33.501 Section 6.12)

User Equipment

SEAF/AMF

Serving Network

AUSF

Home Network

UDM/SIDF

ID Function

4G: IMSI

TS 33.401

IMSI sent in cleartext during initial attach
Vulnerable to IMSI catchers (passive attack)
GUTI provides temporary identity after attach
Identity paging can reveal IMSI
No cryptographic protection of permanent ID

5G: SUPI/SUCI

TS 33.501 §6.12

SUPI — Subscription Permanent Identifier
SUCI — ECIES-encrypted SUPI (Profile A/B)
Curve25519 or secp256r1 for encryption
SIDF in home network decrypts SUCI
Passive attacks cannot reveal SUPI

// SUCI Structure (TS 33.501 Section 6.12.2)
SUCI = {
    SUPI Type: "IMSI" | "NAI",
    Home Network ID: "MCC-MNC",
    Routing Indicator: "0-9999",
    Protection Scheme: "ECIES Profile A/B" | "null",
    Home Network Public Key ID: "0-255",
    Scheme Output: {
        ECC Ephemeral PK: 32/33 bytes,
        Ciphertext: encrypted MSIN,
        MAC: 8 bytes
    }
}
                        

Authentication: 5G-AKA vs EPS-AKA

5G authentication introduces home network control and enhanced key confirmation, addressing known vulnerabilities in the EPS-AKA protocol.

TS 33.501 §6.1 5G Authentication Methods

5G supports two primary authentication methods:

5G-AKA — Native 5G authentication based on EPS-AKA with enhancements
EAP-AKA' — EAP framework authentication (RFC 5448) with 5G binding

Both methods provide:

Mutual authentication between UE and network
Home network control over authentication
Serving network authentication confirmation
Key agreement for K_SEAF

EPS-AKA

TS 33.401 §6.1

Auth Vector: RAND, AUTN, XRES, K_ASME
HSS generates authentication vectors
MME stores XRES, compares with RES
No home network confirmation of auth
Sequence number synchronization (SQN)

5G-AKA

TS 33.501 §6.1.3

Auth Vector: RAND, AUTN, HXRES*, K_SEAF
AUSF controls authentication
HXRES* = SHA256(RES*) for privacy
Home network confirms via RES*
SN binding: SN name in key derivation

Critical Enhancement: HXRES* and RES*

In 5G-AKA, the serving network receives HXRES* (hashed expected response), not XRES. The AUSF verifies RES* from UE, providing home network control over authentication success. This prevents a compromised serving network from falsely confirming authentication.

Service-Based Architecture (SBA) Security

The 5G Core introduces a revolutionary Service-Based Architecture where Network Functions communicate via HTTP/2 APIs. This requires a fundamentally different security approach.

TS 33.501 §13 SBA Security Requirements

TLS 1.2/1.3 — Mandatory for all NF communication
OAuth 2.0 — Token-based NF authorization (NRF as authorization server)
Mutual TLS (mTLS) — Certificate-based NF authentication
Service-based Interface (SBI) — HTTP/2 with JSON payloads

5G Core Network Functions (TS 23.501)

AUSF

Authentication Server Function

UDM

Unified Data Management

AMF

Access & Mobility Function

SMF

Session Management Function

NRF

Network Repository Function

PCF

Policy Control Function

NSSF

Slice Selection Function

NEF

Network Exposure Function

UPF

User Plane Function

// OAuth 2.0 Token Request (TS 33.501 §13.4.1)
POST /oauth2/token HTTP/2
Host: nrf.5gc.mnc001.mcc001.3gppnetwork.org
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials
nfInstanceId=6a3f4b1c-2d5e-4f6a-8b9c-0d1e2f3a4b5c
nfType=AMF
targetNfType=UDM
scope=nudm-sdm nudm-uecm

// Response
{
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1...",
    "token_type": "Bearer",
    "expires_in": 3600,
    "scope": "nudm-sdm nudm-uecm"
}
                        

Expanded Attack Surface

SBA security requires: proper TLS certificate management, OAuth token validation, API rate limiting, input validation on all service endpoints, and continuous vulnerability management for HTTP/2 stack and JSON parsers.

Network Slicing Security (TS 33.501 §16)

Network slicing enables multiple logical networks on shared infrastructure. Security isolation between slices is critical for enterprise and vertical deployments.

TS 33.501 §16 Slice Security Requirements

S-NSSAI — Single Network Slice Selection Assistance Information (SST + SD)
Slice-specific Authentication — Secondary authentication per slice (EAP)
Isolation — Traffic, resource, and security context separation
NSSF — Slice selection based on NSSAI and subscription

Network Slice Architecture (3D Visualization)

eMBB Slice (SST=1)

High throughput, 10ms latency

URLLC Slice (SST=2)

Ultra-reliable, 1ms latency

mMTC Slice (SST=3)

Massive IoT, 1M devices/km²

Enterprise Slice (SST=4)

Private network, custom SLA

// S-NSSAI Structure (TS 23.501 §5.15.2)
S-NSSAI = {
    SST: uint8,     // Slice/Service Type (1-255)
    SD:  uint24     // Slice Differentiator (optional)
}

// Standard SST Values
SST=1: eMBB      // Enhanced Mobile Broadband
SST=2: URLLC     // Ultra-Reliable Low Latency
SST=3: MIoT      // Massive IoT
SST=4: V2X       // Vehicle-to-Everything
                        

Slice Isolation Risks

Weak slice isolation can lead to: cross-slice data leakage, resource exhaustion attacks affecting other slices, unauthorized slice access, and lateral movement between slices. Proper isolation requires security enforcement at RAN, transport, and core layers.

Roaming Security: SEPP (TS 33.501 §9)

The Security Edge Protection Proxy (SEPP) is a mandatory network function for 5G roaming, providing secure interconnection between operator networks.

TS 33.501 §9.9 SEPP Functions

N32-c — Control plane interface (TLS handshake, capability exchange)
N32-f — Forwarding interface (protected HTTP/2 messages)
PRINS — Protection of Roaming Interconnect Signaling
Message Filtering — IEs protection, topology hiding
JWE/JWS — JSON Web Encryption/Signature for message protection

// N32-f Message Protection (TS 33.501 §9.9.3)
Protected Message = {
    "n32fContextId": "ctx-123-456",
    "protectedPayload": {
        // JWE Protected (AES-256-GCM)
        "ciphertext": "Base64url(encrypted_http_message)",
        "iv": "Base64url(initialization_vector)",
        "tag": "Base64url(auth_tag)"
    },
    "modificationsBlock": [
        // IEs modified for topology hiding
        { "path": "/nfInstanceId", "action": "replaced" }
    ]
}
                        

SEPP Security Benefits

Unlike SS7/Diameter-based roaming, SEPP provides: end-to-end message encryption, message integrity verification, topology hiding from partner networks, and standardized security policy enforcement.

The Verdict: Is 5G More Secure?

The Nuanced Technical Answer

Protocol-Level Improvements

SUPI/SUCI eliminates passive identity attacks
Home network control over authentication (HXRES*)
SEPP provides secure roaming interconnect
Mandatory TLS 1.2+ for all NF communication
User plane integrity protection (optional)

Operational Challenges

Larger API attack surface (SBA)
Cloud-native security dependencies
Certificate/PKI management complexity
Slice isolation implementation challenges
OAuth token security requirements

Bottom Line

5G security is more comprehensive by design, addressing known 4G vulnerabilities. However, the cloud-native architecture introduces new attack vectors that require mature DevSecOps practices, zero-trust implementation, and continuous security monitoring. A well-operated 4G network may be more secure than a poorly-operated 5G network.

Abhijeet Kumar

Telecom Security Expert & 5G Network Architect with deep expertise in 3GPP security specifications, protocol analysis, and cloud-native telecom deployments. Specializing in TS 33.501 implementation and security architecture design.

5G Security vs 4G Security
Complete 3GPP Analysis