← Book home
Part 4 · RAN, Mobility, and Roaming Security
17

Interworking Security with LTE/EPS

Where 5G meets 4G — and security can quietly step down a generation

“A 5G subscriber who drifts onto 4G keeps moving — but their security context may have just dropped a generation. The handoff is seamless; the security difference is not.” — THE INTERWORKING RISK

For years, 5G and 4G coexist. Subscribers move between 5GS and EPS constantly — onto LTE for coverage, back to NR for capacity. Each move transfers a security context across the boundary, and a context "mapped" from 4G carries 4G's security ceiling. This chapter covers the N26 interface, context mapping in both directions, key conversion, and the LTE-vs-5G security comparison that explains what's at stake.

🎯 Learning objectives
📘 Standards reference box — Chapter 17
SpecificationTitleRelease / version verified
TS 33.5015G security — interworking with EPS (clause 8)Rel-18, v18.11.0 (2026-04)
TS 33.401EPS security architectureRel-18 edition
TS 23.501 / 23.5025GS-EPS interworking architecture & proceduresRel-19 edition

Checked June 2026 — verify against the latest 3GPP version.

17.1 Why Interworking Exists, and N26

FIGURE 17.15GS ↔ EPS Interworking Architecture (N26)
5GS (5G) AMF gNB EPS (4G) MME eNB N26 (AMF ↔ MME) N26 carries the security context across the boundary → seamless moves. Without N26, moves work but are less seamless (re-auth/re-attach).
Purpose: the interworking picture. N26 is the bridge between the 5G AMF and the 4G MME that carries security context, enabling seamless mobility — and the path along which a context can be mapped/downgraded.
FIGURE 17.2Native vs Mapped Security Context
NATIVE context created by an authentication run in THAT system (5G auth → 5G context) full security level of that generation e.g. real 5G-AKA → native 5G keys MAPPED context CONVERTED from the other system's context at the boundary (no fresh auth) carries the SOURCE system's ceiling e.g. EPS context → mapped 5G keys
Purpose: the distinction that drives the whole chapter. A 5G context mapped from 4G is mathematically 5G-shaped but security-wise inherits 4G's properties — no SUCI freshness, no UP integrity origin, etc.

17.2 Context Transfer in Both Directions

FIGURE 17.35GS → EPS Idle Mobility — Context Mapping
UE (→LTE) MME (4G) AMF (5G) ① TAU (with 5G-GUTI mapped) ② Context Request (N26) ③ K_ASME' = KDF(K_AMF, …)map 5G→EPS keys ④ mapped EPS context → MME serves UE on LTE
Purpose: a 5G subscriber drifting onto LTE. The AMF maps its 5G context down to an EPS context for the MME — seamless, but now running at LTE's security level (mapped).
FIGURE 17.45GS → EPS Connected Handover
gNB eNB active session moves NR → LTEAMF↔MME via N26: map keys, forward data, no session drop connected handover keeps the call/data alive — keys mapped K_AMF → K_ASME' during the procedure
Purpose: the in-call version. A voice call or active data session survives the move to LTE (relevant to EPS Fallback, §17.6), with keys mapped on the fly.
FIGURE 17.5EPS → 5GS Idle Mobility
UE (→NR) AMF (5G) MME (4G) ① Registration (mapped from LTE) ② Context Request (N26) ③ EPS context → AMF maps to 5G context ④ POLICY: run a fresh 5G-AKA now to get a NATIVE context? (recommended)
Purpose: coming up to 5G. The AMF can accept the mapped context — but the security-best practice is to trigger a fresh 5G authentication so the subscriber gets a native 5G context with full 5G properties.
FIGURE 17.6EPS → 5GS Connected Handover
eNB gNB active session LTE → NRmapped context first; re-authenticate when possible to reach native 5G security
Purpose: the in-call upgrade path. The session survives the move to NR on a mapped context; a subsequent re-authentication promotes it to native 5G security.

17.3 Key Mapping

FIGURE 17.7Key Mapping — KAMF ↔ KASME
K_AMF (5G)native or mapped KDF (5GS→EPS) K_ASME' (4G)mapped EPS context K_ASME (4G) KDF (EPS→5GS) K_AMF' (5G)mapped 5G context key insightmapping is a one-way KDFbut the RESULT inherits thesource's security properties
Purpose: the conversion math. Keys cross the boundary via one-way KDFs — but cryptographic freshness doesn't appear from nowhere; a mapped key is only as fresh/strong as its source.
FIGURE 17.8NAS COUNT Handling Across Systems
the risk careless COUNT handling at the boundary could reuse (key, COUNT) → cipher break the rule each system manages its own COUNTs; mapping ensures freshness inputs so no (key,COUNT) pair repeats across the move
Purpose: a subtle correctness/security requirement. The boundary must never produce a repeated (key, COUNT) — the same keystream-reuse danger as Chapter 7, now at the interworking seam.

17.4 LTE vs 5G Security — the Master Comparison

FIGURE 17.9LTE vs 5G Security Feature Comparison
feature LTE / EPS 5G identity privacyIMSI in clearSUCI (concealed) authenticationEPS-AKA5G-AKA / EAP-AKA′ home controlvisited decidesAUSF verdict user-plane integritynoneyes (K_UPint) core interface securityNDS/IPSBA mTLS+OAuth roaming securityDiameter (open)SEPP / N32 key hierarchyK_ASME-rooted+K_AUSF, SN-binding EVERY row is why a MAPPED (4G-origin) context is a security step-down — it lacks the 5G column's properties until a native 5G auth runs
Purpose: the comparison that quantifies the downgrade. Each green-vs-red row is a property a mapped context lacks — so "subscriber on a mapped context" means "subscriber missing these protections."
FIGURE 17.10Downgrade Risk at the 4G/5G Boundary
the attack attacker degrades 5G coverage (jamming) → UE falls back to LTE → loses SUCI freshness, UP integrity, SBA/SEPP-era protections a generation-downgrade attack mitigations ✓ re-authenticate to native 5G when back on NR ✓ policy: limit/monitor fallback frequency ✓ for critical slices, restrict or forbid fallback ✓ track % subscribers on mapped contexts (KPI) don't let "seamless" hide "downgraded"
Purpose: the interworking attack and its defenses. Forcing fallback is a way to strip 5G protections; policy (re-auth, restricted fallback, monitoring) keeps the downgrade from being silent or permanent.
FIGURE 17.11N26-less Interworking — Security Implications
with N26 context transferred → seamless but mapped context = downgrade risk smooth, needs re-auth policy without N26 no transfer → UE re-attaches re-authenticates each move always native, but less seamless
Purpose: a security/UX trade-off. N26-less interworking forfeits seamlessness but guarantees a native context (fresh auth) on each move — a legitimate choice for security-sensitive deployments.
FIGURE 17.12Voice Continuity (EPS Fallback) Security Path
VoNR call attempton 5G NR VoNR not available EPS Fallbackhandover to LTE for VoLTE call on LTEmapped/native EPS ctx EPS Fallback is a deliberate, common move to LTE for voice — its security follows the 5GS→EPS connected-handover path (§17.2)
Purpose: the most frequent real-world interworking event. Many networks still fall back to LTE for voice (EPS Fallback) — so the 5GS→EPS handover security applies to a huge share of calls.

17.5 The Practical Operator View

Common misconfiguration risks

17.6 Threats and Mitigations

ThreatVectorDefense
Generation downgradeforce fallback to LTEre-auth on return, restrict fallback for critical slices
Persistent weak securityindefinite mapped contextre-authentication policy, mapped-context KPI
N26 interception/injectionunprotected N26IPsec (NDS/IP)
Keystream reuse at boundarycareless COUNT handlingcorrect COUNT freshness on mapping
Voice-path exposureEPS Fallback to LTEsecure handover path, monitor

17.7 Terminology, Example, Checklist

TermMeaning
N26AMF↔MME interface carrying security context across 5GS/EPS
native / mapped contextFrom a fresh auth in that system / converted from the other system
K_AMF / K_ASME5G AMF-level key / LTE anchor key (mapped to one another)
EPS FallbackMoving a voice call from NR to LTE (VoLTE) when VoNR is unavailable

Real network example. An operator with patchy 5G SA coverage and no VoNR relied heavily on EPS Fallback for voice. A security review discovered that subscribers, once fallen back to LTE for a call, stayed on the mapped (4G-level) context even after returning to good 5G coverage — because no re-authentication was triggered on return. Effectively, frequent callers spent much of their day at 4G security: no user-plane integrity, identity privacy reduced. Fix: a policy to trigger a fresh 5G-AKA (promoting to a native context) when a UE returns to NR after a fallback, plus a KPI tracking the mapped-context population. "Seamless" mobility had quietly become "permanently downgraded" for the network's most active users.

Chapter Summary

? Review Questions

  1. What does N26 carry, and how does its absence change interworking security?
  2. Distinguish native and mapped contexts and why the difference matters.
  3. Explain key mapping and why a mapped key can't be "fresher" than its source.
  4. List four security properties a mapped (4G-origin) context lacks compared to a native 5G context.
  5. Describe the generation-downgrade attack and three defenses.
  6. Why does EPS Fallback make 5GS→EPS handover security broadly relevant?
  7. What COUNT-handling danger exists at the boundary, and how is it avoided?
  8. A frequent caller stays on a mapped context all day. Diagnose and fix.
🧪 Mini lab — measure the downgrade

On paper or in a lab with both 5G and LTE: (1) Trace a UE moving from NR to LTE and back, noting whether the 5G context is native or mapped after return. (2) For each state, list which of these are active: SUCI privacy, UP integrity, AUSF home control, SBA-era core security. (3) Design the re-authentication policy that would promote a mapped context to native on return, and the KPI that would tell you how many subscribers are currently on mapped contexts. (4) Decide which of your slices (e.g., an enterprise/IoT slice) should forbid LTE fallback entirely and why. You've now turned "seamless mobility" into a measurable security property.