SUCI privacy, 5G-AKA vs EAP-AKA-prime, NDS/IP, zero-trust SBI, SEPP N32, certificate lifecycle, DDoS on HTTP/2 SBI, 3GPP TS 33.501 deep dive
1. What Is 5GC Security — The Simple Version
5GC security is layered differently from 4G. In 4G, the main attack surface was SS7/Diameter — well-documented and widely exploited. In 5G, the SS7 dependency is gone. The control plane runs on HTTP/2 over IP, which is more secure by default but introduces web-style attack vectors: HTTP/2 flood attacks, OAuth2 token abuse, certificate mismanagement. Meanwhile, the classic telecom problems — IMSI harvesting, replay attacks, fake base stations — are addressed architecturally in 5GC through SUCI, 5G-AKA mutual authentication, and NDS/IP.
The definitive reference is 3GPP TS 33.501. This article covers the key mechanisms, common implementation gaps, and the new threat surface that SBA creates.
| 3GPP Reference |
| 3GPP TS 33.501 — Security Architecture and Procedures for 5G System |
| 3GPP TS 33.210 — Network Domain Security (NDS/IP — IPsec for inter-NF) |
| 3GPP TS 29.573 — 5G interconnect security (SEPP and PRINS) |
| GSMA FS.40 — 5G Security Guide for MNOs |
2. Architecture — The 5GC Security Layers
| Security Layer | Mechanism | What It Protects Against |
| UE identity privacy | SUCI (ECIES-encrypted SUPI) sent in Registration Request | IMSI harvesting by IMSI catchers / rogue base stations |
| Mutual authentication | 5G-AKA: AUTN proves network to UE; RES* proves UE to network | Fake base station attacks; replay attacks (SQN prevents replay) |
| NAS security | NAS ciphering + integrity protection using KAMF-derived keys | NAS message eavesdropping; NAS message manipulation |
| RRC/AS security | RRC ciphering + integrity using KgNB-derived keys | Radio interface eavesdropping; RRC message injection |
| SBI security | mTLS (NF identity) + OAuth2 (service authorisation) on all NF-NF calls | Rogue NF impersonation; unauthorised service access |
| Transport security (NDS/IP) | IPsec ESP on inter-domain N3 transport (NF–NF over untrusted network) | N3 GTP-U eavesdropping; data modification in transit |
| Roaming security | SEPP + N32 with PRINS body signing | Inter-PLMN signalling manipulation; subscriber data exposure to IPX |
Table 1 — 5GC security layers. Each layer addresses a specific attack vector. Gaps in any layer represent a real vulnerability.
3. How It Works — Zero-Trust SBI
Traditional telecom security assumed anything inside the operator network was trusted. 5GC SBA introduces zero-trust: every NF must authenticate itself and be authorised for every service call. The mechanism has three components working together:
Component 1 — mTLS (Mutual TLS): when AMF calls SMF on N11, both NFs present their TLS certificates during the handshake. AMF’s certificate says “I am AMF instance abc-123 in PLMN 422-03.” SMF’s certificate says “I am SMF instance xyz-456.” Both certificates are signed by the operator’s internal CA. If either certificate is expired, revoked, or self-signed: the TLS handshake fails before any HTTP request is sent.
Component 2 — OAuth2 authorisation: even after mTLS succeeds (identity verified), AMF must present a JWT access token to SMF. The token, issued by NRF, says: “AMF instance abc-123 is authorised to call nsmf-pdusession:create on SMF instance xyz-456, valid until [timestamp].” SMF validates the token signature (using NRF’s public key) and checks the scope matches the requested operation. A valid certificate but wrong scope = 403 Forbidden.
Component 3 — NRF registration control: before any NF can be discovered, it must register in NRF. NRF validates the registering NF’s certificate before accepting the registration. An unauthorised NF with a self-signed certificate cannot register in NRF — it is invisible to the rest of the core.
4. Key Parameters and Technical Terms
| Term | Definition | Security Significance |
| SUCI | SUPI with MSIN encrypted using home network public key (ECIES x25519 or P-256). | Prevents IMSI harvesting. Ciphertext is ephemeral — two SUCI values from same SUPI are unlinkable. |
| ECIES Profile A/B | Elliptic Curve Integrated Encryption Scheme. Profile A: x25519. Profile B: NIST P-256. | Profile A preferred for low-power IoT devices. Profile B for regulatory environments requiring NIST curves. |
| Home Network Public Key | Operator public key embedded in USIM at manufacturing. Used for SUCI encryption. | If key is compromised: all future SUCI values decryptable. Key rotation requires USIM replacement or OTA update. |
| PRINS | Protection of Inter-PLMN NAS Signalling. JWS (JSON Web Signature) signing of individual JSON fields in N32 HTTP/2 messages. | IPX intermediaries can read routing headers but cannot read PRINS-protected subscriber data fields. |
| N32 SEPP Interface | HTTP/2 TLS connection between home SEPP and visited SEPP, carried via IPX. | TLS protects transport. PRINS protects message body. Both layers required for full N32 security. |
| NDS/IP | Network Domain Security over IP. IPsec ESP for inter-domain signalling and user plane. | 3GPP TS 33.210. Applied to N3 (gNB-UPF) when traversing untrusted transport segments. |
| mTLS | Mutual TLS — both client and server present certificates. Operator internal CA signs all NF certificates. | Without mTLS: rogue NF can call core services. mTLS is the identity layer of zero-trust. |
| OAuth2 scope | Defines which NF service operations the token authorises. Format: {service}:{operation}. | Prevents lateral movement: a compromised AMF with its own token cannot call UDM services it is not scoped for. |
| TLS 1.3 | Current minimum TLS version for SBI (3GPP TS 33.501 mandates TLS 1.2 minimum, recommends 1.3). | TLS 1.3 eliminates weak cipher suites and reduces handshake from 2-RTT to 1-RTT. |
| HTTP/2 RESET Flood (CVE-2023-44487) | Attacker opens HTTP/2 streams and immediately resets them. CPU overhead per stream even when reset. | Affects 5GC SBI endpoints directly. Mitigation: max_concurrent_streams limit + RESET rate limiting at SCP/LB. |
Table 2 — 5GC security parameters. SUCI, mTLS, and OAuth2 are the three pillars of 5GC security. All three must be correctly configured — any gap creates a real attack surface.
5. Common Issues in the Field
| Field Note: SIDF Private Key in Kubernetes ConfigMap — Critical Audit Finding |
| During a 5GC security audit at a GCC operator, the home network private key (used by UDM SIDF to decrypt SUCI) was found stored in a plain Kubernetes ConfigMap. |
| The ConfigMap was readable by any service account with “get configmap” permission in the namespace. |
| No breach confirmed, but classified as critical: if key accessed, all past and future air interface captures can be decoded to recover subscriber identities. |
| Fix: immediate migration to Kubernetes Secret with encryption-at-rest. RBAC restricting access to UDM SIDF pod service account only. |
| Long-term: HSM integration for SIDF key storage. |
| Field Note: HTTP/2 RESET Flood Against AMF SBI — Red Team Exercise |
| During scheduled red team exercise: HTTP/2 RESET flood at 30,000 streams/second against AMF N11 endpoint. |
| AMF SBI thread pool exhausted in 12 seconds. HTTP/2 connection queue backed up. |
| Legitimate SMF N11 calls started timing out. Registration success rate dropped from 99.8% to 88%. |
| No SCP deployed — AMF SBI directly reachable from within the core network. |
| Fix: deploy SCP in front of AMF with per-client concurrent stream limits (max 100 per NF instance). |
| Also: rate limiting on AMF N11 LoadBalancer service; Kubernetes NetworkPolicy restricting N11 to known NF source IPs only. |
6. Troubleshooting
| Symptom | Root Cause | Check | Fix |
| SBI calls return 401 Unauthorized | OAuth2 token expired or wrong scope; or NRF public key changed | Decode JWT (jwt.io): check exp, scope, aud claims; verify NRF signing key in NF config | Refresh token; verify scope in NRF authorisation policy; push updated NRF public key to all NFs |
| SBI TLS handshake failure | NF certificate expired; or CA chain mismatch | openssl s_client -connect <NF-IP>:443 — check cert expiry and chain | Rotate certificate via cert-manager; verify CA chain complete |
| Roaming subscriber cannot authenticate | SEPP N32 TLS failure or PRINS signature error | SEPP logs: N32 TLS alert or JWS signature verification failure; partner SEPP certificate validity | Renew SEPP certificate; coordinate with IPX provider and partner operator |
| New NF pod cannot register in NRF | NF certificate not trusted by NRF; or NRF mTLS policy rejects | NRF logs: mTLS client certificate validation failure; check NF cert CA vs NRF trusted CA | Issue NF certificate from operator internal CA that NRF trusts; verify CA chain |
| SBI performance degradation post-maintenance | HTTP/2 RESET flood or OAuth2 token storm post-restart | SBI error rate in Grafana; NRF CPU; AMF/SMF connection pool exhaustion | Rate limit per-client streams at SCP; add jitter to token refresh on startup |
Table 3 — Security troubleshooting. Certificate expiry and token storms are the two most operationally common security-related failures.
7. Summary — Key Takeaways
| Topic | Key Takeaway |
| SUCI | Protects subscriber identity over the air. Requires 5G USIM with home network public key. The home network private key (SIDF) must be in HSM — never in a ConfigMap or plain Secret. |
| Zero-trust SBI | Three layers: mTLS (identity) + OAuth2 (authorisation) + NRF registration control (discovery). All three required. mTLS without OAuth2 = identity verified but no service authorisation. |
| SEPP for roaming | Deploy before roaming goes live. N32 without SEPP = subscriber auth data exposed to IPX intermediaries. PRINS body signing is non-negotiable. |
| Certificate lifecycle | Monitor ALL NF certificate expiry in Grafana with 30-day advance alert. One expired cert silently breaks all SBI connections for that NF. Automate rotation with cert-manager + Operator. |
| HTTP/2 attack surface | SBI endpoints are HTTP/2 servers — vulnerable to RESET floods (CVE-2023-44487). Deploy SCP with per-client stream limits. Use K8s NetworkPolicy to restrict which pods can reach SBI endpoints. |
| NDS/IP for N3 | Apply IPsec on N3 when transport is untrusted (leased lines, third-party IP/MPLS). Offload to NIC hardware crypto for line-rate. Software IPsec cannot sustain 100 Gbps. |
Table 4 — Post 15 summary. 5GC security is architecturally strong. The gaps are in implementation: key storage, certificate management, and HTTP/2 protection.
Next: Post 16 — Roaming & Inter-PLMN Interconnect