From one secret on a SIM card to every key on the air
“There is exactly one secret in your subscription. Everything else is mathematics performed on it — and the mathematics is designed so that stealing a leaf never gives you the root.”
— THE WHOLE CHAPTER IN ONE SENTENCE
5G never reuses the long-term key K for actual traffic. Instead it grows a tree of derived keys, each one step further from the root, each one protecting a narrower thing for a shorter time. This is the chapter that ties the whole book together: authentication (Chapters 5–6) produces the anchor; NAS, AS, and handover security (Chapters 8, 9, 16) consume the branches. Learn the tree and you can place any 5G key in seconds.
🎯 Learning objectives
Draw the complete 5G key hierarchy from K to the AS keys.
Explain each key: K, CK/IK, KAUSF, KSEAF, KAMF, NAS keys, KgNB, RRC/UP keys.
Describe KDF mechanics — HMAC-SHA-256, FC codes, input strings.
Explain NH/NCC, and horizontal vs vertical derivation.
Map key distribution, lifetime, refresh and re-keying across the network.
Checked June 2026. KDF input strings and FC values live in Annex A — verify exact values against your TS 33.501 version.
7.1 The Whole Tree in One Picture
Here is the entire hierarchy. Spend time on it — every other diagram in this chapter is a zoom into one branch.
FIGURE 7.1The Complete 5G Key Hierarchy
Purpose: the master map of every 5G key. Read top-down as “further from the root, narrower in scope, shorter in life.” Memorize this and Chapters 8, 9 and 16 become lookups.
💡 Key idea — the one-way property
Every arrow in the tree is a one-way key derivation function. Given a child key you cannot compute the parent; given a sibling you cannot compute another sibling. That single property is why compromising one gNB, or one bearer’s key, cannot unravel the subscription — the damage stays at the leaf.
7.2 The Root: K and CK/IK
K is the only permanent secret, stored in exactly two places — the USIM and the home ARPF (Chapter 3). It is never used to encrypt traffic and never transmitted. During authentication the AKA functions produce CK and IK (cipher key, integrity key) from K and RAND; for EAP-AKA′ these become CK′/IK′ with the serving network name folded in. CK/IK are the bridge from the permanent root into the 5G-specific tree.
FIGURE 7.2The Twin Roots — K in USIM and ARPF
Purpose: the symmetric root. The same K exists at both ends and produces the same CK/IK without ever crossing the network — the foundation of the whole tree.
FIGURE 7.3CK/IK → KAUSF — and the EAP-AKA′ Variant
Purpose: two roads, same destination. The serving-network binding happens at different steps in the two methods, but KAUSF is network-bound either way.
7.3 KAUSF, KSEAF, KAMF — the Control Keys
FIGURE 7.4KAUSF → KSEAF → KAMF — the Control-Plane Spine
Purpose: the control-plane spine and what each derivation binds. ABBA at the KAMF step is the anti-bidding-down anchor — it ties the context to the security features both sides agreed on.
FIGURE 7.5KAMF and the ABBA Parameter — Anti-Bidding-Down
Purpose: the parameter that makes downgrade attacks fail loudly. Tamper with the negotiated feature set and the keys simply won’t match.
FIGURE 7.6NAS Keys — KNASint and KNASenc
Purpose: the NAS branch consumed by Chapter 8. Note the algorithm ID is a KDF input — keys are algorithm-specific by construction, blocking cross-algorithm misuse.
7.4 KgNB and the Access-Stratum Keys
When the UE goes connected, the AMF derives KgNB from KAMF using the uplink NAS COUNT as a freshness input, and hands it to the gNB over N2. The gNB then derives four AS keys, each algorithm-bound, all consumed in PDCP (Chapter 9).
FIGURE 7.7KgNB and the AS Key Set
Purpose: the access-stratum branch — the keys that actually scramble your radio bits. The UL NAS COUNT input guarantees a fresh KgNB each time the UE transitions to connected.
7.5 KDF Mechanics: How a Derivation Actually Works
Every arrow in the tree is the same function: the 3GPP generic KDF (TS 33.220), an HMAC-SHA-256 keyed by the parent key, over an input string assembled from an FC byte (which derivation this is) plus parameters (P0,L0,P1,L1…) — each value followed by its length. Different FC + parameters = different, independent child key.
FIGURE 7.8The 3GPP KDF — HMAC-SHA-256 With an FC-Tagged Input String
Purpose: the engine behind every arrow. The FC byte is the “which derivation am I” tag; combined with length-prefixed parameters it guarantees that two derivations never collide.
7.6 NH and NCC: Keys Built for Mobility
Handovers need fresh keys without re-running authentication each time. 5G solves this with the NH (Next Hop key) and its counter NCC (Next-hop Chaining Counter). The AMF pre-computes a chain of NH values from KAMF; each handover advances the chain, giving the target gNB a key the source gNB cannot predict. Full handover flows are Chapter 16; here is the key machinery.
FIGURE 7.9The NH/NCC Chain
Purpose: the mobility key engine. The NCC in a handover command tells the UE which NH to use — and whether it’s getting a strong (vertical) or weaker (horizontal) derivation.
FIGURE 7.10Horizontal vs Vertical — the Forward-Security Difference
Purpose: why 3GPP prefers vertical derivation. The fresh NH comes from the AMF (via path switch / N2), an entity the source gNB cannot impersonate — breaking the compromise chain. Chapter 16 shows exactly when each is used.
7.7 Where Every Key Lives
FIGURE 7.11Key Distribution Map — Which NF Holds Which Key
Purpose: the operational view of the tree — who must protect what. Maps directly onto Chapter 3’s blast-radius ranking and your patch/monitoring priorities.
7.8 Lifetime, Refresh, and Re-keying
FIGURE 7.12Key Lifetimes — From Permanent to Per-Bearer
Purpose: the time dimension of the tree. Leaf keys churn constantly; the root is effectively forever — which is exactly the security goal.
FIGURE 7.13Re-keying Without Re-authentication — Key Change On-the-Fly
Purpose: how the network refreshes keys cheaply. When you don’t need a new authentication but do need new keys (e.g., COUNT nearing wrap), key change on-the-fly re-roots KAMF via a NAS SMC.
FIGURE 7.14Key Handling at Xn Handover (Preview of Chapter 16)
Purpose: the key story behind a handover — the part Chapter 16 expands. The NH refresh on path switch is how 5G keeps re-establishing forward security as the UE moves.
FIGURE 7.15Key Handling at Idle Mobility and Registration Update
Purpose: how keys move when the UE does — without paying for authentication every time. Native contexts are strongest; mapped contexts (from 4G) carry the source system’s ceiling, which Chapter 17 examines.
7.9 The Full Walkthrough: From K to a Ciphered Packet
FIGURE 7.16From the Long-Term Key to a Single Encrypted Byte
Purpose: the chapter’s thesis made concrete. Trace the path of one encrypted user byte all the way back to K — and see why no leaf ever endangers the root.
FIGURE 7.17LTE vs 5G Key Hierarchy — What 5G Added
Purpose: the upgrade in one frame. 5G inserts a home-anchored layer (KAUSF), adds a user-plane integrity key (the aLTEr fix, Chapter 9), and binds keys to the network and feature set.
FIGURE 7.18Key-Management Pitfalls — and Which Key They Endanger
Purpose: a forward pointer to the operational chapters. The mathematics rarely breaks; the management around it does. Each pitfall links to where the book treats it.
7.10 The Practical Operator View
Treat COUNT discipline as sacred: the entire confidentiality of a stream-cipher bearer depends on never reusing (key, COUNT). Configure key refresh well before COUNT wrap.
Set a re-key policy (key change on-the-fly and/or periodic re-authentication) — don’t let a KAMF live for weeks of continuous connection.
Watch native vs mapped contexts at the 4G/5G boundary (Chapter 17) — a mapped context silently caps your security at the source system’s level.
Verify NH refresh actually happens on path switch — a vendor that always derives horizontally never re-establishes forward security.
Protect K and operator constants in HSMs at the ARPF; everything else is recoverable by re-authentication, K is not.
Common misconfiguration risks
KAMF never refreshed on long-lived connections → COUNT exhaustion risk.
HMAC-SHA-256 key derivation / the function-code byte tagging each derivation
ABBA
Anti-bidding-down parameter bound into K_AMF
horizontal / vertical derivation
Next K_gNB from current K_gNB / from a fresh NH (forward-secure)
Real network example. An operator running fixed-wireless-access CPEs — devices that stay RRC-connected for days — began seeing sporadic ciphering errors on high-throughput bearers. Root cause: those sessions approached PDCP COUNT exhaustion, a condition normal handsets never hit because they idle and re-key constantly. The stationary CPEs never handed over and never re-authenticated, so KgNB (and its AS keys) lived far too long. Fix: an operator policy to force key change on-the-fly (fresh KAMF → fresh KgNB) on a timer for long-lived connections. The tree was perfect; the refresh policy assumed mobility that these devices didn’t have.
Confirm a key-refresh policy exists for long-lived/stationary connections (COUNT-wrap protection).
Verify NH is refreshed on path switch (forward security actually re-established).
Check whether mapped EPS contexts are policy-gated at interworking.
Confirm K and operator constants are HSM-resident and non-exportable at the ARPF.
Verify algorithm selection cannot pair a strong key tree with NEA0/NIA0 outside emergency.
Trace one connection: confirm K_gNB changes on handover and on re-key.
★ Chapter Summary
5G grows a tree of derived keys from one root K; every derivation is a one-way KDF, so a stolen leaf never reveals the root.
Control-plane spine: K → CK/IK → K_AUSF → K_SEAF → K_AMF; branches to NAS keys and K_gNB → RRC/UP keys.
The KDF is HMAC-SHA-256 over an FC-tagged input string; algorithm IDs, SN name, COUNT, ABBA are inputs that bind keys to context.
Lifetimes ladder from permanent (K) to per-bearer (AS keys); COUNT discipline and refresh policy are where real networks fail.
vs LTE, 5G adds K_AUSF, a user-plane integrity key, and SN-name/ABBA binding.
? Review Questions
Draw the full key hierarchy from memory. For each key, state where it lives on the network side.
Explain the one-way property and why it means a compromised gNB cannot decrypt a neighbor cell’s past traffic.
What four kinds of input does the KDF use to make derived keys context-specific? Give an example of each.
Distinguish horizontal from vertical key derivation at handover, and explain which provides forward security and why.
Why is the uplink NAS COUNT an input to K_gNB derivation? What would go wrong if K_gNB were derived from K_AMF alone?
What is ABBA, where is it bound, and what attack does it defeat?
A stationary device stays connected for days. Which key is at risk, of what, and what policy fixes it?
Name the three things 5G’s key hierarchy adds over LTE’s, and the chapter where each pays off.
🧪 Mini lab — derive a key by hand (almost)
Using TS 33.501 Annex A and a scripting language: (1) implement the generic KDF (HMAC-SHA-256 over FC ∥ P0 ∥ L0 ∥ …). (2) From a chosen KAMF (any 32-byte test value) and the KgNB FC with an uplink NAS COUNT, compute KgNB; change the COUNT by one and confirm a completely different key. (3) From that KgNB, derive KUPenc with the AS-key FC and a NEA algorithm ID; change the algorithm ID and confirm, again, a different key. You have now reproduced the exact mechanism that binds every 5G key to its context — and proven to yourself why the tree’s one-way derivations contain damage to a single leaf.