5G Security Key Hierarchy in 5G NR

Introduction

The 5G security key hierarchy (TS 33.501) is the layered structure of cryptographic keys that protects everything a UE and the network exchange — from the initial authentication handshake down to the ciphering and integrity of every RRC message and user-data packet on the air. It is a strict tree: a single permanent secret at the root, and a cascade of derived keys beneath it, each produced by a one-way function from its parent.

You encounter this hierarchy at every security-relevant moment in the UE lifecycle. It is built during primary authentication at registration, activated by the NAS and AS Security Mode Command procedures, exercised again at handover (fresh RAN keys per cell), reactivated from a stored context on idle-to-connected transitions, and even re-keyed on the fly to stop a PDCP counter from wrapping. Every one of those events is really a set of KDF calls somewhere in this tree.

It matters because the layering is what contains damage. A key handed to a serving network, or to one specific gNB, can be refreshed or revoked without ever touching the root secret, and a compromised gNB never sees the keys that protect the core-facing signalling. Understanding which key lives where — and what freshness input separates it from its neighbours — is the difference between reasoning about a security design and merely memorising acronyms.

Why a key hierarchy is needed

Concretely, three properties force this design. First, the root must never travel: the permanent subscriber secret exists in only two places and is never sent over any interface, so no interception can ever expose it. Second, blast-radius isolation: a visited network, or one AMF, or one gNB, should get only the key material it needs and no more, so a breach anywhere is contained — refreshable and revocable without re-touching the root. Third, forward and backward separation: because every step is a one-way function keyed by its parent, holding a child key tells an attacker nothing about the parent or its siblings. The tree is the mechanism that delivers all three at once.

The Root of Trust and the Anchor Key

At the very top is K, the permanent subscriber key. It exists in exactly two places and is never sent over any interface: the tamper-resistant USIM in the device and the UDM/ARPF (Unified Data Management / Authentication credential Repository and Processing Function) in the home network. Everything below K is produced by key derivation functions, and because those functions are one-way, holding a child key tells an attacker nothing about its parent.

Primary authentication is orchestrated by three network functions. The AUSF (Authentication Server Function) sits in the home network and holds K_AUSF. The UDM/ARPF generates the authentication vector from K. The SEAF (Security Anchor Function), co-located with the AMF in the serving network, receives the anchor key. In 5G-AKA the home network derives K_AUSF from CK, IK and the serving-network name, and computes an expected response HXRES*; the visited network only ever sees K_SEAF once the UE's response is confirmed. In EAP-AKA' the same CK, IK are first transformed into CK', IK' bound to the serving-network name, an EAP exchange runs to completion, and the EAP master session key yields K_AUSF. Either way the important property is identical: the anchor K_SEAF is cryptographically bound to this serving network, so a key stolen in one visited network cannot be replayed to authenticate the subscriber in another.

How Keys Are Derived — KDF, HMAC-SHA256 and FC codes

Every arrow in the hierarchy is one call to the same 3GPP key derivation function. The KDF defined in TS 33.220 (Annex B) is HMAC-SHA256: a keyed hash that takes the parent key as the HMAC key and a carefully constructed input string S as the message, and returns 256 bits of pseudo-random output used as the child key.

The input string S always begins with a one-byte FC (Function Code) that names which derivation this is — a different FC for K_AUSF, for K_SEAF, for K_AMF, for K_gNB, and so on — so that even if two derivations shared the same parent and parameters they could never collide. After the FC come parameter blocks, each a value Pn immediately followed by its two-byte length Ln. The parameters are the freshness and binding inputs: the serving-network name, the SUPI, NAS COUNT values, the target cell's PCI and frequency, and so on. Because the parent key is the HMAC key, you cannot run the function backwards, and because every input is length-prefixed, no two different parameter sets can ever produce the same input string.

The K_AMF Fork — NAS Keys and the RAN Key

K_AMF is the fork in the tree, and it stays inside the AMF. From it two completely independent branches grow.

• The NAS security keys protect signalling between the UE and the AMF: K_NASenc (ciphering) and K_NASint (integrity). These cover NAS messages such as Registration, Service Request, and PDU-session signalling. They are derived with an algorithm-type distinguisher and the negotiated NIA/NEA identity as inputs, so changing the NAS algorithm re-derives the key.
• The RAN key K_gNB is the root of the entire Access Stratum branch. The AMF derives it from K_AMF using the current uplink NAS COUNT as the freshness input and hands only K_gNB to the serving gNB.

This split is the heart of 5G key separation. NAS keys live in the AMF and never reach the RAN; AS keys live in the gNB and never reach the core. A gNB that is compromised — a real concern with distributed and small-cell deployments — therefore cannot read or forge NAS signalling, and it never sees K_AMF, only its child K_gNB. From K_gNB the gNB derives four leaf keys, split by plane and by function, all applied inside PDCP.

The Key-Derivation Tree

Reading top to bottom, each arrow is one HMAC-SHA256 call. The chain runs K → CK/IK → K_AUSF → K_SEAF → K_AMF, then forks: the left branch is NAS, the right branch is AS via K_gNB. The side labels name the key freshness input mixed into each step.

Handover Key Handling — NH, NCC and K_gNB*

When the UE moves between gNBs, the target must receive a fresh K_gNB the source cannot predict — otherwise a compromised source gNB could keep eavesdropping on the UE at its new cell. 5G solves this with a chain of Next Hop values counted by an NH Chaining Counter.

Both derivations also mix in the target cell's PCI (Physical Cell Identity) and downlink frequency ARFCN-DL, binding K_gNB* to the specific target cell. The chosen NCC is echoed to the UE in the handover command (RRCReconfiguration with reconfigurationWithSync) so the UE derives the identical K_gNB*. If the received NCC equals the UE's stored value, a horizontal derivation happened; if it is greater, the UE knows a vertical derivation occurred and iterates the NH chain forward (each iteration a fresh HMAC-SHA256 over the previous NH) until its counter matches, then derives K_gNB* from that NH.

The same machinery covers a key change on the fly in connected mode. If the network wants to refresh K_gNB without a real handover — for example to recover from a PDCP COUNT that is about to wrap and repeat — it runs an intra-cell handover, deriving a new K_gNB exactly as above so the counters restart from a fresh key. A full refresh of K_AMF and the NAS keys, by contrast, requires re-running primary authentication and then a NAS Security Mode Command to activate the new context. See Xn Handover for where K_gNB* and NCC travel in the HANDOVER REQUEST.

Identity Privacy — SUPI, SUCI and ECIES

Keys protect traffic, but the subscriber's identity needs protecting too. In 4G the permanent IMSI was occasionally sent in the clear, enabling IMSI-catchers. 5G closes that hole: the permanent identifier, the SUPI (Subscription Permanent Identifier), is never sent over the air in the clear. Instead the UE sends a SUCI (Subscription Concealed Identifier) — the SUPI encrypted with the home network's public key.

The home network public key is provisioned in the USIM together with a Home Network Public Key Identifier, so the operator can rotate keys and the UE can tell the network which key it used. Because the UE picks a fresh ephemeral key for every concealment, two SUCI values for the same subscriber look unrelated on the air — there is no linkability. The SUCI also carries a Protection Scheme Identifier (0 for null-scheme, used only for unauthenticated emergency registration or test USIMs; 1/2 for ECIES profiles A/B). De-concealment happens at the UDM/SIDF (Subscription Identifier De-concealing Function) in the home network, the only place the private key exists.

Security Contexts, ngKSI and the NEA/NIA Algorithms

All these keys are grouped into a 5G security context: the key set (K_AMF plus derived NAS keys), the selected algorithms, the NAS COUNT values, and a key-set identifier. A context comes in two flavours. A native context is created directly by a 5G primary authentication run. A mapped context is derived from an EPS (4G) context during interworking — for example when a UE moves from LTE to NR, K_AMF is mapped from the LTE K_ASME. The UE and network can hold a native and a mapped context at once and switch between them.

Each context is tagged by an ngKSI (Key Set Identifier in 5G), a small value carried in NAS signalling so the UE and AMF can refer to "the context we already share" without transmitting any key. The ngKSI includes a type flag distinguishing native from mapped, plus a 3-bit value; the reserved value 111 means "no key available". This is how, after an idle period, a Service Request can reactivate an existing context instead of re-authenticating — the ngKSI names the context both sides kept.

Keys are useless without an algorithm to apply them. 5G negotiates one ciphering algorithm and one integrity algorithm, separately for NAS (in the NAS Security Mode Command) and for AS (in the AS Security Mode Command). Each is identified by a 4-bit code: the NEA family for enciphering and the NIA family for integrity.

All keys today are 128 bits, though the hierarchy already carries 256-bit key material (the KDF output) so that 256-bit algorithm variants can be introduced without redesign. The algorithm identity is itself an input to the leaf-key derivation (the "algorithm type distinguisher" plus the 4-bit ID), which is why re-negotiating an algorithm re-derives its key — the same K_gNB with a different NIA gives a different K_RRCint.

Summary

5G security is one strict tree defined in TS 33.501. The permanent root K lives only in the USIM and UDM/ARPF and is never transmitted; primary authentication (5G-AKA or EAP-AKA') turns it into CK/IK → K_AUSF → the serving-network-bound anchor K_SEAF → K_AMF. Every arrow is one HMAC-SHA256 KDF call whose input string starts with a distinguishing FC and carries length-prefixed freshness inputs, so derivations are one-way and collision-free.

K_AMF forks into the NAS branch (K_NASenc/K_NASint, staying in the AMF) and the AS branch via K_gNB (derived with the uplink NAS COUNT, handed to the gNB), which fans out into the PDCP leaf keys K_RRCenc/K_RRCint and K_UPenc/K_UPint. Key separation keeps core secrets out of the RAN, so a compromised gNB never sees K_AMF. Mobility re-keys the AS branch through the NH/NCC chain and K_gNB* (horizontal vs vertical, bound to target PCI/ARFCN-DL), giving two-hop forward security.

Around the key tree sit three more mechanisms: identity privacy (SUPI concealed as a SUCI via ECIES, de-concealed only at the home SIDF), security contexts tagged by ngKSI (native vs mapped, reactivated without re-authentication), and the negotiated NEA/NIA algorithm families. The single idea to carry away: every key that touches real traffic is disposable and derived, so a leaf compromise never climbs back to the root.