Ciphering & Integrity (EEA/EIA) in LTE 4G

Introduction

PDCP security is the access-stratum (AS) protection that LTE applies at the PDCP layer — ciphering for confidentiality and integrity protection for authenticity and replay defence. It is defined jointly by TS 36.323, which fixes where in the PDCP PDU the transforms apply and in what order, and TS 33.401, which defines the algorithms, the key hierarchy, and the exact inputs to each computation.

It comes to life partway through connection setup. The first RRC messages travel unprotected because no access-stratum key exists yet; once authentication has produced KeNB and the eNB has chosen an encryption and an integrity algorithm, the AS Security Mode Command procedure switches protection on. From that point every RRC message is ciphered and integrity-protected, and every user-data packet on a DRB is ciphered.

It matters because radio is a broadcast medium: without ciphering anyone nearby reads your traffic, and without integrity an attacker can forge or replay the very signalling that reconfigures your connection. The whole scheme rests on one counter, COUNT, that must never repeat under a key — understand that and the rest of PDCP security follows.

Why PDCP security is needed

Two independent threats drive the design. First, confidentiality: because anything transmitted can be captured by any nearby receiver, the payload must be unreadable to anyone without the key. Second, authenticity and freshness: an attacker who cannot read a message might still try to alter it, forge a new one, or replay an old valid one — especially dangerous for signalling that changes bearers, keys or handover targets. Ciphering answers the first threat; integrity protection with a per-packet counter answers the second. LTE applies both at PDCP because that is the one layer that sees every user- and control-plane packet after sequence numbering but before RLC.

What PDCP Security Does

Radio is a broadcast medium: anything you transmit, anyone with a receiver nearby can capture. LTE closes that hole at the PDCP layer, which sits between RRC/IP above and RLC below. As each packet passes through PDCP on its way down, two independent transforms can be applied — encryption so the contents are unreadable, and an authentication tag so the receiver can prove the packet was neither altered nor fabricated. On the way up the same transforms are undone and verified.

The division of labour is the single most important fact to hold onto. Ciphering is applied to both SRB (signalling radio bearers, which carry RRC and NAS) and DRB (data radio bearers, which carry user traffic). Integrity protection, in classic LTE, is applied to SRB only. There is no user-plane integrity in the original LTE design — a DRB is enciphered but not integrity-protected. So signalling gets encrypt-plus-integrity, while user data gets encrypt-only.

The Algorithms — EEA and EIA

3GPP deliberately does not bolt LTE to one cipher. It defines families of interchangeable algorithms, negotiated at connection setup, so that a future weakness in any one algorithm does not collapse the whole system — the network simply selects a different member of the family. The encryption family is EEA (EPS Encryption Algorithm) and the integrity family is EIA (EPS Integrity Algorithm). Each algorithm carries a 4-bit identity that the UE advertises in its UE EPS security capabilities and the network selects during the Security Mode procedure.

Encryption options are EEA0 (the null algorithm — no ciphering at all), EEA1 (built on the SNOW 3G stream cipher), EEA2 (built on AES in counter mode), and EEA3 (built on the ZUC stream cipher). Integrity options mirror them one-for-one: EIA1 (SNOW 3G), EIA2 (AES in CMAC mode), and EIA3 (ZUC). There is an EIA0 (null integrity), but it is permitted only for emergency calls placed by an unauthenticated UE — ordinary traffic must always select a real integrity algorithm, because signalling with no integrity is trivially forgeable.

All LTE AS keys are 128 bits, which is why the algorithms are also written as 128-EEA1, 128-EIA2, and so on — the leading 128 names the key length. Notice that the same base cipher can serve both jobs: EEA2 and EIA2 are both AES, but EEA2 runs it in a counter mode to generate a keystream for encryption, while EIA2 runs it in CMAC mode to generate a message authentication tag. Same primitive, different construction, different purpose.

COUNT = HFN ‖ PDCP SN, and Why It Must Not Repeat

The heart of the whole scheme is a 32-bit counter called COUNT. Every ciphering and every integrity computation consumes it, and the entire security guarantee rests on one rule: a given COUNT value must never be reused with the same key on the same bearer in the same direction. Break that rule and the mathematics falls apart.

The lower bits of COUNT are the PDCP SN that actually travels in each PDU header. Because the SN field is short (5, 7, 12, 15, or 18 bits depending on bearer type and configuration), it wraps around quickly — a 12-bit SN, for example, repeats every 4096 packets. The upper bits are the HFN, whose width is 32 minus the SN length (so 20 bits for a 12-bit SN, 27 bits for a 5-bit SN) — a counter that both sides keep locally and increment by one every time the PDCP SN rolls over from all-ones back to zero. The HFN is never transmitted; each side infers it from watching the SN wrap. Concatenated, HFN and SN form a value that climbs monotonically across the whole life of the bearer, giving every single PDU a unique COUNT.

Why does reuse destroy security? A stream cipher produces ciphertext as plaintext XOR keystream, and the keystream is a deterministic function of (key, COUNT, BEARER, DIRECTION). If two different plaintexts are ever enciphered with the same keystream, an attacker who XORs the two ciphertexts cancels the keystream entirely and is left with the XOR of the two plaintexts — often enough to recover both. So COUNT is not a nicety; it is the safety interlock that keeps each keystream one-time. This is also precisely why LTE mandates a key change / key refresh before COUNT can wrap all the way around: when the PDCP COUNT is about to exhaust, the eNB triggers an intra-cell handover or key re-keying so a fresh KeNB resets the counters.

The Five Inputs and the 32-bit MAC-I

Both EEA and EIA are functions of the same handful of inputs. Getting them exactly right is the whole game — the inputs are what guarantee keystream uniqueness for ciphering and message binding for integrity. TS 33.401 fixes them as follows.

For ciphering, the EEA takes KEY, COUNT, BEARER, DIRECTION, and a LENGTH telling it how many keystream bits to produce, and outputs a keystream block of exactly that length. For integrity, the EIA takes KEY, COUNT, BEARER, DIRECTION, and the MESSAGE itself (header plus data), and outputs a fixed 32-bit tag. That tag is the MAC-I — the Message Authentication Code for Integrity. It is always 32 bits regardless of message length, and it is appended to the PDCP Data PDU on SRBs.

On reception the receiver runs the identical EIA over the received message with its own copy of the key and inputs, producing a value called XMAC-I (the expected MAC-I). If XMAC-I equals the received MAC-I, the message is authentic and unmodified and is accepted; if they differ — even by one bit — the PDU has been tampered with or corrupted, and PDCP discards it and reports an integrity failure to RRC.

How the Engine Runs: Keystream vs MAC-I

Ciphering and integrity are the same shape — pour the inputs plus the key into the algorithm and take the output — but what you do with the output differs completely.

Ciphering. The chosen EEA (say EEA2) uses KEY, COUNT, BEARER, DIRECTION and LENGTH to generate a pseudo-random keystream block the same length as the payload. The sender computes ciphertext = plaintext XOR keystream. The receiver regenerates the identical keystream (it holds every input independently) and computes plaintext = ciphertext XOR keystream. Because XOR is its own inverse, the exact same operation both enciphers and deciphers — there is no separate decrypt algorithm. Only the data part of the PDCP PDU is ciphered; the PDCP header is not, because the receiver needs the PDCP SN in clear to reconstruct COUNT before it can decipher anything.

Integrity. The chosen EIA (say EIA2) takes KEY, COUNT, BEARER, DIRECTION and the whole MESSAGE (the PDCP header plus the data), and produces the 32-bit MAC-I, which is appended to the PDU. Crucially the header is covered by integrity even though it is not ciphered, so an attacker cannot rewrite the SN without breaking the tag.

The order of operations inside PDCP matters and is fixed by TS 36.323. On transmit, integrity is applied first (compute MAC-I over header + data), then ciphering is applied over the data part (and, on SRB, over the appended MAC-I). On receive the order is reversed: decipher first, then verify MAC-I. That way the integrity check always runs over exactly the plaintext the sender protected. Informally: on the way out, integrity-then-cipher; on the way in, decipher-then-check.

The AS Keys — KRRCenc, KRRCint, KUPenc

LTE never uses one key for everything. The Access-Stratum keys all descend from KeNB, the base-station key that the eNB and the UE both hold after authentication. From KeNB, three keys are derived by a Key Derivation Function (an HMAC-SHA-256 construction), each with exactly one job — and, importantly, the identity of the selected algorithm is mixed into the derivation, so a key is cryptographically bound to the one algorithm it is used with.

Notice what is missing: there is no KUPint in the classic LTE set, precisely because user-plane integrity is not used. All three keys trace back to KeNB, which itself sits inside the wider EPS key hierarchy: the master key K in the USIM and the HSS/AuC produces CK/IK during authentication; those yield KASME at the MME; KASME plus an uplink NAS COUNT yields KeNB; and KeNB yields the three AS keys above. When KeNB changes — at handover (via a horizontal or vertical key derivation using the NH/NCC chain) or on a re-key — all three AS keys are refreshed with it and the PDCP COUNTs reset.

Activation, Replay Protection and MAC-I Failure

Security is not on from the first message. The earliest RRC messages (up to and including the RRCConnectionSetup and the initial NAS exchange) travel unprotected because no KeNB yet exists. Protection is switched on explicitly by the AS Security Mode Command procedure, run by RRC once authentication has produced KeNB and the eNB has chosen an EEA and an EIA.

The eNB sends SecurityModeCommand, which carries the selected cipheringAlgorithm and integrityProtAlgorithm. This message is a special hinge: it is integrity-protected but not yet ciphered. The UE verifies its MAC-I using the freshly derived KRRCint; if the check passes, the UE knows the network holds the same key, activates both integrity and ciphering, and replies with a SecurityModeComplete that is itself integrity-protected and ciphered. From that point on, all RRC signalling is ciphered and integrity-protected, and once DRBs are set up their user data is ciphered. If the UE cannot verify the command's MAC-I, it responds with SecurityModeFailure and keeps the old (unprotected) configuration.

Replay protection is a direct consequence of COUNT. Because the integrity tag is computed over the message together with the ever-increasing COUNT, an attacker who captures a valid PDCP PDU and re-injects it later cannot make it verify: the receiver has already advanced its COUNT past that value, so recomputing XMAC-I at the current COUNT yields a different tag, and the stale COUNT is recognised as out-of-window. A replayed packet therefore fails the integrity check or is discarded as a duplicate.

MAC-I failure is treated as a security event, not a mere transmission error. When PDCP integrity verification fails on an SRB, the PDU is discarded and the failure is indicated to RRC, which may trigger re-establishment or connection release. Persistent integrity failures are a signal of tampering or a man-in-the-middle attempt, so the stack fails closed rather than passing the suspect message up.

Summary

LTE access-stratum security lives in PDCP (TS 36.323, TS 33.401) as two independent transforms: ciphering for confidentiality on both SRB and DRB, and integrity protection for authenticity and replay defence on SRB only — which is why the classic AS key set is KRRCenc, KRRCint, KUPenc with no KUPint. The algorithm families are EEA (encryption) and EIA (integrity), each a 4-bit-identified member built on the null algorithm, SNOW 3G, AES or ZUC, all with 128-bit keys. Both engines consume five inputs — the 128-bit KEY, the 32-bit COUNT = HFN ‖ SN, a 5-bit BEARER, a 1-bit DIRECTION, and either a keystream LENGTH (cipher) or the MESSAGE (integrity) — producing either a keystream that is XORed onto the payload or a fixed 32-bit MAC-I. The one unbreakable rule is that COUNT must never repeat under a key, which forces a re-key before wrap. Security is switched on by the AS SecurityModeCommand (integrity-protected but not yet ciphered), and any MAC-I mismatch is treated as a security event, not a transmission glitch.