AS Security Mode in LTE 4G

Introduction

AS Security Mode is the short RRC handshake that turns the abstract EPS key tree into live protection on the air interface. It runs once per RRC connection, right after the MME hands the AS base key KeNB to the eNB in the S1AP Initial Context Setup Request, and it must complete before the eNB is allowed to open SRB2 or any DRB. Its whole job is to activate integrity protection and ciphering for the Access Stratum — the RRC signalling and user-plane data between UE and eNB.

It sits at a very specific point in the UE lifecycle: after RRCConnectionSetup, after the first NAS message (Attach or Service Request), after EPS-AKA authentication and NAS Security Mode, and immediately before bearer establishment. That ordering — security first, bearers second — is the entire point of the procedure, and it is a perennial interview favourite.

It matters because the alternative is catastrophic: without AS security, an on-path attacker could read your RRC signalling, forge handover commands, or eavesdrop on user data. Because the procedure is itself integrity-protected, the strongest an attacker can do is cause a failure — never a silent downgrade. Getting the message ordering, the key derivation, and the algorithm negotiation right is what makes the radio link trustworthy.

Why AS security is needed

Concretely, NAS security only protects the UE↔MME dialogue — Attach, Tracking Area Update, Service Request. But RRC reconfigurations, handover commands and measurement reports travel between UE and eNB, and user data rides the radio bearers. All of that is unprotected until AS security runs. AS Security Mode makes RRC both integrity-protected (so it cannot be forged) and ciphered (so it cannot be read), and it ciphers the user-plane data. It is the gate that must be passed before any real data bearer is allowed to carry traffic.

What AS Security Mode does

By the time the eNB runs this procedure, a great deal has already happened up at the NAS layer: the MME and UE ran EPS-AKA authentication, agreed on the master session key KASME, and completed the NAS Security Mode Command so that NAS signalling is already ciphered and integrity-protected. What is not yet protected is the Access Stratum — the RRC messages between UE and eNB, and the user-plane data on the radio bearers. AS Security Mode closes that gap, and it does so before any real signalling radio bearer (SRB2) or data radio bearer (DRB) is allowed to carry traffic.

The procedure sits inside the larger connection-setup story. After the UE completes RRCConnectionSetup and sends its first NAS message (an Attach or Service Request), the MME authenticates it and runs NAS security. The MME then triggers Initial Context Setup towards the eNB over S1AP, handing down the AS base key. Only at that point does the eNB run AS Security Mode — and only after it succeeds does the eNB send the RRCConnectionReconfiguration that establishes SRB2 and the default/dedicated DRBs. Security first, bearers second: that ordering is the whole point.

Two Layers of Security: NAS and AS

EPS security is built in two independent layers, and confusing them is the most common interview stumble. The NAS layer protects the signalling between the UE and the MME — messages like Attach, Tracking Area Update and Service Request that never stop at the eNB. The AS layer protects the signalling and data between the UE and the eNB. Each layer has its own Security Mode Command procedure, its own keys, and its own algorithm selection, and they run at different times and between different endpoints.

Both layers reuse the same algorithm identifiers (the EIA/EEA numbering), but each side negotiates independently against the UE's declared capabilities, so the NAS and AS layers can end up choosing different algorithms. The keys are entirely separate: KNASint/KNASenc are derived from KASME and stay in the MME, whereas the AS keys are derived from KeNB and stay in the eNB. This separation is deliberate — a compromised eNB should not expose NAS security, and the AS keys can be refreshed at handover without touching the NAS layer.

KeNB and the AS Keys It Feeds

All AS protection hangs off a single base key, KeNB. From it the eNB locally derives three working keys, one per protection job, each produced by the same HMAC-SHA-256 key derivation function (KDF) defined in TS 33.401 but with a distinct input string (an algorithm distinguisher plus the algorithm identity), so the three outputs are cryptographically independent.

Notice what is missing: there is no KUPint in base LTE. User-plane integrity was simply not part of the original EPS design, so DRB integrity is never applied in classic LTE — data bearers are ciphered only. This is the sharpest contrast with 5G NR, where a KUPint exists and user-plane integrity can be turned on per-DRB. SRB integrity, by contrast, is mandatory: once AS security is on, every RRC message is integrity-protected, and EIA0 (the null integrity algorithm) is permitted only for unauthenticated emergency calls.

The keys live in the PDCP layer, which is where ciphering and integrity are actually applied. The MAC-I that integrity protection produces is a 32-bit tag carried in the PDCP header of signalling PDUs; ciphering XORs a keystream over the PDCP payload. Because both operations depend on a per-PDU COUNT (a hyperframe number plus PDCP sequence number), replaying an old PDU fails the integrity check — the COUNT would not match.

The Algorithm Identifiers: EEA and EIA

LTE names its cryptographic algorithms in two families. EEA = EPS Encryption Algorithm (ciphering); EIA = EPS Integrity Algorithm. Each family is numbered 0–3, and the same number denotes the same underlying core algorithm in both families. The eNB signals its chosen pair in SecurityModeCommand, and its choice is constrained by the UE's declared UE-EUTRA-Capability security capabilities, which the MME relays to the eNB (the eNB also enforces its own configured priority list).

The algorithms are carried in the SecurityModeCommand inside securityConfigSMC → securityAlgorithmConfig, which has exactly two fields: cipheringAlgorithm (an EEA) and integrityProtAlgorithm (an EIA). There is only one integrity and one ciphering algorithm for the whole AS layer — the same pair covers SRBs and DRBs alike. That is why KRRCenc and KUPenc are both derived with the same ciphering algorithm ID: there is only one to choose.

The Procedure, Step by Step

The whole exchange is two RRC messages on SRB1, but the ordering of when each protection turns on is the subtle part and a perennial interview favourite. Both messages ride SRB1 on DCCH, scheduled on PDSCH/PUSCH by a PDCCH whose CRC is scrambled with the UE's C-RNTI in the UE-specific search space — the same transport as any other dedicated RRC message; what changes is the PDCP-layer protection applied to each.

1. eNB derives keys and selects algorithms. Holding KeNB, the eNB derives KRRCint, KRRCenc and KUPenc and picks the EIA/EEA pair. 2. eNB sends SecurityModeCommand. It carries the chosen algorithms in securityAlgorithmConfig. This message is integrity-protected with the new KRRCint — it carries a MAC-I in its PDCP header — but it is deliberately not ciphered, because the UE must be able to read which algorithms to use before ciphering can begin. 3. UE verifies. The UE derives the same keys from its own copy of KeNB, recomputes the MAC-I over the received message, and compares. A match proves the eNB holds the correct key and the message was not tampered with. 4. UE replies SecurityModeComplete. From the UE's side this message is both integrity-protected and ciphered — it is the first uplink message to which the new ciphering applies. 5. From here on, every subsequent RRC message in both directions is integrity-protected and ciphered, and the DRBs set up by the following RRCConnectionReconfiguration are ciphered.

One detail worth stressing: the direction of first ciphering. The SecurityModeCommand (downlink) is not ciphered; the SecurityModeComplete (uplink) is. So the first ciphered PDU on the link is the uplink complete, and the first ciphered downlink message is the RRCConnectionReconfiguration (or any RRC message the eNB sends after receiving the complete).

Reading the exchange in the logs

On an eNB or UE RRC trace the whole procedure is three lines: the downlink command with its selected algorithms and its MAC-I present-but-unciphered marker, the uplink complete that is the first ciphered/integrity-protected PDU, and the reconfiguration that follows. The fields to line up are the algorithm IDs and the security-activation flags on each PDU.

Representative eNB/UE RRC log — illustrative, values vary by vendor/build:

When It Fails: SecurityModeFailure

If the UE cannot verify the SecurityModeCommand — the MAC-I check fails, or the eNB proposes an algorithm the UE did not advertise — it does not silently drop the connection. It replies with SecurityModeFailure instead of SecurityModeComplete.

Crucially, SecurityModeFailure is sent without the new AS security applied: it is neither ciphered nor integrity-protected with the new keys, because by definition security could not be established. The previous configuration continues — effectively unprotected AS at this point — and the UE keeps SRB1 alive so the network can decide what to do. It is then up to the eNB and network policy whether to retry (perhaps with a different algorithm) or to release the connection.

A failed MAC-I is a strong signal of one of two things: a key mismatch — the UE and eNB derived different KeNB, usually because their NAS COUNT or KASME were out of step — or an active attacker injecting a forged command. Either way the network treats it seriously. Because the command was integrity-protected, an attacker cannot fabricate a valid SecurityModeCommand without KRRCint, so the procedure itself is the defence: an on-path attacker can only cause a failure, never a silent downgrade.

Re-keying at Handover: KeNB*, NCC and NH

AS keys are bound to a specific eNB. When the UE moves to a new cell, the target eNB must not inherit the source's keys unchanged — otherwise a single compromised eNB could read traffic in every cell the UE later visits. LTE solves this with key chaining: at each handover the KeNB is refreshed into a new KeNB* that the target uses as its base key, deriving fresh KRRCint/KRRCenc/KUPenc. The refresh comes in two flavours, horizontal and vertical, distinguished by the Next Hop Chaining Counter (NCC).

The machinery is a pair of values managed jointly by the MME and the source eNB: the NH (Next Hop) parameter and its associated NCC. The MME computes a chain of NH values from KASME, each one step deeper, and increments the NCC with each step. At handover:

The distinction shows up in the handover signalling as the NCC value carried in the RRCConnectionReconfiguration (mobilityControlInfo) handover command. If the NCC the target sends equals the NCC the UE currently holds, the UE performs a horizontal derivation (chaining from its current KeNB). If the NCC has advanced, the UE performs a vertical derivation, first computing the new NH by iterating the chain up to that NCC, then deriving KeNB* from it. Either way the UE and target arrive at the same KeNB*, from which the AS keys are re-derived — there is no separate Security Mode Command at handover; the re-keying is implicit in the reconfiguration.

The two handover types differ in who supplies the fresh NH. In an X2 handover (source eNB talks directly to target eNB), the source often has no unused NH, so the first hop is typically horizontal; the MME then delivers a fresh {NH, NCC} in the S1AP Path Switch that follows, so the next handover can be vertical. In an S1 handover (routed through the MME), the MME is in the path and can always provide a fresh vertical {NH, NCC}. This is why an X2 handover chain periodically "heals" back to vertical secrecy via path switch.

Summary

AS Security Mode is the two-message RRC handshake that turns the EPS key tree into live radio-link protection. Walk it in order: the eNB derives KRRCint/KRRCenc/KUPenc from KeNB, picks an EIA/EEA pair, and sends SecurityModeCommand integrity-protected (MAC-I, KRRCint) but unciphered so the UE can read it; the UE verifies, then answers with SecurityModeComplete as the first fully ciphered-and-integrity-protected PDU; every message after that is protected, and only then are SRB2 and the DRBs opened.

The three things worth memorising: integrity before ciphering; three AS keys in LTE (no KUPint, so DRBs are ciphered only); and a failed MAC-I means a KeNB mismatch or an attacker — never a silent downgrade, because the command itself is authenticated. At handover the same keys are refreshed into KeNB* via horizontal/vertical chaining driven by the NCC, with no separate Security Mode Command.

Used log-in-hand, the debugging is mechanical: confirm KeNB arrived, check the algorithm pair against UE capabilities, verify the protection flags on each PDU, and if the MAC-I fails, chase the KeNB derivation inputs.

Interview Corner