EPS Security Key Hierarchy in LTE 4G

Introduction

The EPS key hierarchy is the set of keys and one-way derivation functions that LTE uses to authenticate a subscriber and then cipher and integrity-protect everything the UE sends — NAS signalling to the core, RRC signalling to the eNB, and user-plane data over the air. It is defined in TS 33.401, which builds on the AKA machinery inherited from 3G (TS 33.102) and the generic key-derivation function of TS 33.220.

It comes into play the moment you power on and attach. Authentication (EPS-AKA) runs first, proving the UE and the network share the permanent key and seeding an anchor key; the NAS and AS Security Mode Command procedures then install the derived keys before any real data flows. From then on the hierarchy is exercised on every message — and re-exercised at every handover, when a fresh radio key has to be minted for the target eNB.

Why it matters: the shape of the tree is the security policy. Because each node only ever receives the specific short-lived key it needs, and because you can descend the tree but never climb back up, a compromised eNB leaks one cell's traffic and nothing more. Understanding which key lives where, and what each derivation mixes in, is what lets you reason about — and debug — LTE security end to end.

Why a Hierarchy of Keys at All

You could imagine a single secret key protecting everything — but that would be fragile and inflexible. If an eNB were physically compromised, an attacker holding the one key would own the whole subscription. LTE instead spreads trust across a tree: the permanent secret never leaves the USIM and the network's Authentication Centre, and each network element only ever receives the specific, short-lived key it needs to do its job. The MME gets NAS keys, the eNB gets radio keys — and neither can climb back up the tree to reconstruct the other's secrets, or the root.

The tree also gives you cheap, frequent refresh. Because a new lower key can be minted from an existing higher key plus a fresh counter, the network can hand the eNB a brand-new K_eNB at every handover, or re-key the radio side entirely, without dragging the USIM through a full authentication each time. Re-authentication — the expensive round trip to the home network — is needed only when the anchor key itself must change.

The Root: K, and CK/IK via Milenage

At the very top is K, a permanent 128-bit master key. It exists in exactly two places: your USIM and the operator's AuC (Authentication Centre, a function co-located with the HSS). It is never transmitted, never derived, and never leaves either endpoint. Everything below it is disposable; K is not.

When you attach, the network runs EPS-AKA (Authentication and Key Agreement). Using K and a fresh random challenge RAND, both sides run the AKA algorithm set — almost always Milenage (an AES-128 based construction; some operators use the newer TUAK, based on Keccak). Milenage takes K, RAND, a sequence number SQN and the operator variant field, and produces a bundle of outputs: the expected response RES, the Cipher Key CK, the Integrity Key IK, the anonymity key AK, and a message authentication code MAC.

CK and IK are each 128 bits. These are the same CK/IK that 3G/UMTS used — LTE reuses the AKA core but does not use CK/IK directly on the air interface. Instead they are the raw keying material fed into the next, EPS-specific step. This deliberate re-derivation (rather than reusing UMTS keys directly) is what cryptographically separates the LTE security context from a legacy 3G one.

EPS-AKA and the Authentication Vector

EPS-AKA is the mechanism that both proves your identity and seeds the key tree, in one exchange. The HSS builds an EPS authentication vector — a quadruplet — and hands it to the MME; the MME challenges the UE; the UE proves it holds the same K. Crucially, the MME never learns K: it receives only the vector.

Each EPS authentication vector contains four elements:

The AUTN token is where mutual authentication and replay protection live. It carries SQN (the sequence number) concealed by XOR with the anonymity key AK, the Authentication Management Field AMF, and a MAC computed over RAND, SQN and AMF. The UE recomputes the MAC: if it matches, the challenge genuinely came from an entity that knows K (the network is authentic). The UE then checks that SQN is within an acceptable window of its own stored counter — this is what defeats replay of an old, recorded vector. If SQN is out of range the UE triggers a re-synchronisation procedure (AUTS) to bring the home network's counter back into step. The AMF is a 16-bit field whose "separation bit" is set to indicate the vector is for EPS/E-UTRAN, binding the vector to the right access type.

Only when both directions succeed — UE authenticates network via MAC, network authenticates UE via RES = XRES — does the pair commit to the derived K_ASME. From that point the UE and MME share an EPS security context anchored on K_ASME, and no further contact with the HSS is needed until re-authentication.

K_ASME and the Derivation Function

K_ASME (the "Access Security Management Entity" key) is the top of the EPS-specific part of the tree — the local anchor. The HSS derives it from CK/IK, mixing in the serving-network identity (SNID, essentially the PLMN ID) and the value SQN ⊕ AK. That binding to the serving network is deliberate: a K_ASME generated for one operator's network cannot be replayed against another. It is 256 bits.

Every arrow below K_ASME is the same one-way primitive: the generic KDF of TS 33.220, which is HMAC-SHA-256. The KDF is fed a key (the parent) and an input string S assembled from a one-byte function code FC followed by a series of parameters, each preceded by its length: S = FC || P0 || L0 || P1 || L1 || …. Different FC values and parameter sets give cryptographic separation between keys derived from the same parent, so K_NASenc and K_NASint, though both children of K_ASME, are independent.

The parameters carry the context that makes each key unique: an algorithm-type distinguisher and algorithm identifier for the NAS and AS keys, the NAS uplink COUNT for K_eNB, and the target cell's physical identity and frequency for handover keys. Because the parent key is secret and the function is one-way, an attacker who captures a child key and knows every context input still cannot recover the parent.

The HMAC-SHA-256 KDF always emits a 256-bit block, so the leaf keys start life 256 bits wide even though the ciphering and integrity algorithms in LTE consume only 128 bits. The lower keys are therefore truncated to their least-significant 128 bits before use (the algorithm-type and algorithm-identity distinguishers, FC = 0x15, still separate them cryptographically). This is why you will see K_ASME quoted as 256 bits but K_NASenc, K_RRCint and the rest described as 128-bit keys — they are the truncated outputs of a 256-bit derivation.

From K_ASME: NAS Keys and K_eNB

K_ASME branches in two directions. One branch protects the NAS signalling that runs directly between the UE and the MME; the other produces the key the MME hands down to the eNB.

NAS keys. The MME derives K_NASenc (NAS ciphering) and K_NASint (NAS integrity) from K_ASME, each bound to the chosen NAS algorithm identifier via the KDF's FC/parameter inputs. These protect the NAS messages — Attach, Tracking Area Update, Service Request, detach — carried over the MME↔UE link. Although derived as 256-bit outputs, the keys are truncated to the 128 bits the ciphering and integrity algorithms actually consume. NAS security is switched on by the NAS SECURITY MODE COMMAND/SECURITY MODE COMPLETE exchange, which also confirms the selected algorithms.

K_eNB. The MME also derives K_eNB from K_ASME, this time mixing in the current NAS uplink COUNT. Binding to that counter ties each fresh K_eNB to a specific point in the NAS message sequence, so it cannot be silently reused or replayed. The MME sends K_eNB to the eNB inside the S1AP INITIAL CONTEXT SETUP REQUEST when your radio bearers are set up. The eNB now has exactly what it needs to protect the radio link — and nothing more.

From K_eNB: the AS Radio Keys

Inside the eNB, K_eNB is expanded into three Access Stratum keys, each bound to the negotiated AS algorithm identifier through the KDF. This is where the LTE-versus-NR contrast is sharpest, so read the table carefully.

Note the asymmetry on the radio side: RRC signalling gets both ciphering (K_RRCenc) and integrity (K_RRCint), but the user plane in baseline LTE gets ciphering only (K_UPenc). There is no user-plane integrity key in LTE — there is deliberately no K_UPint. Signalling must be tamper-proof because a forged RRC or NAS message could redirect or hijack a UE; bulk user data was judged too costly to integrity-protect on every packet at LTE data rates. This is exactly the point where 5G NR differs: NR adds a fourth AS key, K_UPint, so the user plane can optionally be integrity-protected per DRB — a direct response to the LTE gap. The AS keys are installed by the RRC SecurityModeCommand/SecurityModeComplete exchange.

Handover Keys: K_eNB*, NH and NCC

When you move between eNBs, the target eNB needs its own radio keys — and ideally the source eNB should not be able to compute what the target will use (that property is forward security). LTE achieves this with a re-keying step at each handover that produces a new K_eNB*, which becomes the target's K_eNB. This applies to both X2 handovers (eNB to eNB directly) and S1 handovers (via the MME).

There are two derivation paths for K_eNB*, both computed with the same KDF taking the target's physical cell ID (PCI) and downlink frequency (EARFCN-DL) as context:

• Horizontal key derivation. The new K_eNB* is derived from the current active K_eNB. Simple, but the source eNB knows the current K_eNB, so it could in principle compute the target's key — weaker forward security. Used as the fallback.
• Vertical key derivation. The new K_eNB* is derived from a fresh Next Hop parameter, NH, instead of the current K_eNB. Because NH is itself computed from K_ASME (which the source eNB never holds), the source cannot predict the target's key — giving true forward security.

The two paths are tracked by the Next hop Chaining Counter, NCC. Each NH value is bound to an NCC. The initial NH is derived from K_ASME and the initial K_eNB (call it NCC = 0/1); each subsequent NH is derived from K_ASME and the previous NH, incrementing NCC — a hash chain rooted at the anchor. The MME provides fresh {NH, NCC} pairs to eNBs (in the S1AP handover or path-switch messages). At handover the eNB uses whichever value it has; the target's NCC is signalled to the UE so it can perform the identical derivation.

So the UE's logic is simple: compare the received NCC with the one it stored. If it advanced, a fresh NH was used — do a vertical derivation from NH. If it is the same, the eNB had no fresh NH and fell back to horizontal derivation from the current K_eNB. Over a run of X2 handovers without a path switch you may get several horizontal hops in a row; a path switch to the MME refreshes the NH chain and restores forward security on the next hop.

Re-keying and the EEA/EIA Algorithms

Keys do not have to live forever, and the hierarchy gives the network several ways to refresh them at different depths without a full trip to the HSS:

• K_eNB refresh (intra-cell handover). To renew the radio keys when a PDCP COUNT is about to wrap, the eNB triggers an intra-cell handover that runs the K_eNB* derivation to itself — a brand-new K_eNB and fresh AS keys, no re-authentication.
• K_eNB re-keying from a fresh K_ASME. After a new EPS-AKA run, the MME can take a fresh K_ASME and re-derive K_eNB and all NAS keys, replacing the entire lower tree.
• NAS key re-keying. The MME can re-derive K_NASenc/K_NASint from K_ASME — for example when changing the NAS algorithm — via a new NAS Security Mode Command.

At the bottom, the actual ciphering and integrity are done by standardised algorithm families, selected per layer and identified by 3-bit identifiers. Ciphering algorithms are EEA (EPS Encryption Algorithm) and integrity algorithms are EIA (EPS Integrity Algorithm), all using 128-bit keys:

The chosen algorithms are negotiated and confirmed in the Security Mode Command exchanges — separately for NAS (at the MME) and AS (at the eNB) — and the selected algorithm identifier is one of the KDF inputs, so the key is cryptographically bound to the algorithm it will be used with. This binding prevents a "bidding-down" attack where an attacker tries to force a weaker algorithm: the integrity-protected Security Mode Command echoes back the UE's advertised capabilities, and any tampering breaks the MAC.

EEA0/EIA0 — the null algorithms. EEA0 performs no encryption and EIA0 performs no integrity protection (it produces an all-zero MAC). They exist for exactly one legitimate purpose: unauthenticated emergency calls. A UE without a valid USIM, or one that cannot authenticate, must still be able to reach emergency services, so the standard permits an emergency bearer to run with EEA0 and EIA0 — no security — rather than blocking the call. In any normal, authenticated session the use of EIA0 for signalling is forbidden; NAS and RRC integrity must use a real algorithm.

Summary

The whole EPS key hierarchy is one idea applied repeatedly: keep the permanent secret K locked in the USIM and AuC, and derive everything else with a one-way HMAC-SHA-256 KDF so each node holds only the disposable key it needs. EPS-AKA proves identity and seeds the anchor K_ASME without the MME ever seeing K, CK or IK; the MME derives the NAS keys it keeps and the K_eNB it exports; the eNB expands K_eNB into the RRC and user-plane radio keys.

Two structural facts are worth carrying away. First, there is no user-plane integrity key in LTE — the point where NR later diverges by adding K_UPint. Second, forward security at handover hinges on the NH/NCC chain: a vertical derivation from a fresh NH stops a compromised source eNB from computing the target's keys, while a horizontal derivation is the weaker fallback. Trace any LTE security question to which key, held by which node, derived with which context input, and the answer usually follows directly.