Ciphering & Integrity Protection in 5G NR

Introduction

PDCP security is the pair of cryptographic operations — ciphering (confidentiality) and integrity protection (authenticity) — that the Packet Data Convergence Protocol applies to every SRB and, where configured, every DRB. It is the access-stratum (AS) layer of protection: the last thing done to a PDU before it hits the lower layers on transmit, and the first thing undone on receive.

In the UE/network lifecycle it switches on at a precise moment. Immediately after authentication, the gNB runs the AS Security Mode Command / Complete handshake; from that point every RRC message is integrity-protected and ciphered, and user-plane bearers are ciphered (and optionally integrity-protected). Before that handshake, SRBs run effectively in the clear. Every re-key — notably at handover — refreshes the keys and restarts the counters.

Because security is a well-defined chain — negotiate algorithms, derive keys, build COUNT, cipher/verify per PDU — most security faults localise to one link: a de-synchronised HFN, a wrong key derivation input, a bidding-down attempt, or an integrity mismatch on a specific bearer. Walking the chain step by step is what turns "the UE dropped the connection" into a specific, testable cause.

Why PDCP security is needed

Concretely, the air interface is a shared broadcast medium with no physical privacy, so two attacks must be defeated. A passive eavesdropper can record every bit — confidentiality (ciphering) is what stops that from being useful. An active attacker can inject, modify, or replay messages — integrity protection is what detects that, and it is why signalling must never be forgeable: a forged RRCReconfiguration could redirect a UE to a rogue cell. PDCP is the natural home for both because it is the top of the AS user/control-plane stack, above RLC/MAC, so it protects the whole PDU end-to-end across the radio.

Two Distinct Security Jobs

People routinely conflate them, but ciphering and integrity protection are separate operations, with separate algorithm identities, separate keys, and separate consequences when they fail. Ciphering answers "can an eavesdropper read this?"; integrity answers "was this message forged, modified, or replayed?" A packet can be ciphered but not integrity-protected (typical for user data), or integrity-protected but not ciphered (rare but legal), or — on signalling — both at once.

The Algorithm Families: NEA and NIA

NR defines two algorithm families, each with four members. The NEA family (NR Encryption Algorithm) does confidentiality — the "E"; the NIA family (NR Integrity Algorithm) does integrity — the "I". The trailing digit selects the underlying cryptographic core, and the two families deliberately share those cores so that a device only implements one crypto primitive per number and reuses it for both roles.

All defined algorithms use a 128-bit key. (The security architecture reserves headroom for 256-bit variants in future releases, but the Release-15/16 AS algorithms are 128-bit.) The gNB and UE negotiate which pair to use during the AS Security Mode Command / Complete exchange, picking the most preferred algorithm that both endpoints support, drawn from the UE's UE Security Capabilities. The null members are special: NEA0 is legitimate for any bearer when confidentiality is not required, whereas NIA0 is tightly restricted — using a null integrity algorithm on ordinary signalling would defeat the entire point of integrity protection, so it is confined to unauthenticated emergency scenarios.

COUNT = HFN + PDCP SN, and the Golden Rule

The single most important input to both functions is COUNT, a 32-bit value that must be different for every PDCP PDU sent on a given bearer in a given direction under a given key. It is built by concatenating two fields: the Hyper Frame Number (HFN) in the most-significant bits, and the PDCP Sequence Number (SN) in the least-significant bits.

The SN is what actually travels in the PDCP header — either 12 or 18 bits, configured per bearer via pdcp-SN-SizeUL / pdcp-SN-SizeDL. The HFN is never transmitted: it is a counter each side maintains locally that increments by one every time the SN wraps around from its maximum back to zero. With a 12-bit SN the HFN is 20 bits wide; with an 18-bit SN the HFN is 14 bits wide — in both cases the pair totals exactly 32 bits.

Why does this matter so much? For a stream cipher, the keystream is a deterministic function of the key and the inputs. If two different plaintexts are ever XORed with the same keystream, an attacker who XORs the two ciphertexts together cancels the keystream and recovers the XOR of the two plaintexts — a catastrophic break. So the golden rule is: COUNT must never repeat under the same key on the same bearer and direction. Because COUNT is 32 bits, roughly four billion PDUs can be protected before it would wrap. Long before that point the network triggers a re-key (a fresh K_gNB), and the sending PDCP entity is required to detect the impending wrap and stop rather than let COUNT roll over and reuse a keystream.

Inputs to the Security Functions

Both ciphering and integrity are functions of the same core inputs. Vary any one of them and the keystream (or the tag) changes completely — which is exactly how a single key safely protects billions of packets across both directions of multiple bearers without ever reusing a keystream.

Note the elegant division of labour: COUNT ensures uniqueness over time, BEARER ensures uniqueness across bearers, and DIRECTION ensures uniqueness across the two directions. Together they guarantee that the (key, input) tuple — and therefore the keystream — is unique for every single protected PDU in the whole connection.

How Ciphering and Integrity Actually Run

On transmit, PDCP applies the two operations in a fixed order: integrity first, then ciphering. The integrity algorithm (NIA) runs over the PDCP SDU plus the input parameters and produces a 32-bit MAC-I (Message Authentication Code for Integrity), which is appended to the data. Ciphering (NEA) then generates a keystream of the required LENGTH and XORs it onto the data part — including the appended MAC-I — while the PDCP header itself is left in the clear so the receiver can read the SN before deciphering. This is the "integrity then cipher" ordering: the tag is computed over the plaintext, then encrypted along with it.

On receive, the order reverses: the entity deciphers first, then verifies integrity. It uses the received SN plus its locally maintained HFN to reconstruct COUNT, regenerates the keystream, XORs to recover the plaintext (which restores the MAC-I), then recomputes the tag over the recovered message to obtain an expected value called XMAC-I. If XMAC-I equals the received MAC-I, the message is authentic. If they differ, the PDU has been altered, injected, or deciphered against the wrong COUNT.

Because ciphering is a symmetric XOR, exactly the same operation enciphers and deciphers — the sender XORs plaintext with keystream to get ciphertext, the receiver XORs ciphertext with the identical keystream to get plaintext back. This is why COUNT synchronisation is everything: if the receiver reconstructs the wrong COUNT (a wrong HFN), it generates the wrong keystream, deciphering produces garbage, and the integrity check then fails on top — two symptoms of one root cause.

Reading a security event in the logs

Security shows up in the trace at two moments: the activation handshake (algorithms selected, keys derived) and any per-PDU integrity failure. The block below stitches both together so you can see the fields that matter.

Representative UE/gNB PDCP-security log — illustrative, values vary by vendor/build:

Where Each Applies, and the Four AS Keys

Ciphering and integrity are not applied uniformly — they follow the bearer type and the network's configuration. The table below summarises the NR rules from TS 33.501.

All four AS security keys derive from K_gNB, which itself descends from the NAS key hierarchy (K_AMF and above). From K_gNB the gNB and UE each derive four separate keys so that confidentiality and integrity, and control plane and user plane, are cryptographically isolated from one another.

Each of the four keys is derived from K_gNB using the selected algorithm identity as a derivation input — so changing the negotiated NEA/NIA changes the keys, and every re-key at handover (via a fresh K_gNB*) automatically refreshes all four, which is also what resets COUNT and keeps it from ever wrapping under one key. The full chain from K_AMF down to these four keys is covered in the Security Key Hierarchy.

Activation, Selection, and Replay Protection

Security does not switch on silently and it does not switch on by guesswork. The AS Security Mode Command / Complete handshake is where the gNB tells the UE exactly which NEA and NIA to use, chosen as the most-preferred algorithms both support from the reported UE Security Capabilities. Crucially, that first SecurityModeCommand message is itself integrity-protected with the newly derived K_RRCint and the chosen NIA — so the UE validates the command before acting on it, which prevents a bidding-down attack where an attacker tries to force weak or null algorithms. Until the handshake completes, SRBs run effectively unprotected (conceptually NEA0/NIA0); afterwards the negotiated algorithms and the four derived keys are in force for the rest of the connection unless a re-key occurs.

Replay protection is the third pillar alongside confidentiality and integrity. An attacker who cannot read or modify a message can still try to re-send a captured valid message to cause an unwanted action. NR defeats this by binding the MAC-I to the COUNT: because COUNT increases monotonically and never repeats under a key, a replayed PDU carries an old COUNT that the receiver has already moved past. The recomputed XMAC-I either fails to match (the receiver is now using a higher COUNT) or the PDU falls outside the PDCP reordering/duplicate-detection window and is discarded. In other words, integrity + the monotonic COUNT together give replay protection for free — which is precisely why integrity must be mandatory on signalling.

Summary

PDCP security is two independent keyed operations — ciphering (NEA0–NEA3) for confidentiality and integrity protection (NIA0–NIA3) for authenticity — both driven by the same inputs: KEY, COUNT (HFN‖SN), BEARER, DIRECTION, and LENGTH/MESSAGE. The golden rule is that COUNT must never repeat under one key on a bearer/direction, which is why the network re-keys long before the 32-bit counter can wrap and why an HFN de-sync breaks everything at once.

To root-cause a security fault, walk the chain: did the SecurityModeCommand's own integrity check pass; were the negotiated NEA/NIA in the UE's capabilities; do both ends agree on HFN (so COUNT reconstructs correctly); is the right one of the four keys (K_RRCenc/K_RRCint/K_UPenc/K_UPint) in use; and on a MAC-I≠XMAC-I mismatch, is it tamper/replay or simply a COUNT/key de-sync. Integrity is mandatory on SRBs and per-DRB in NR, and the monotonic COUNT bound into the tag gives replay protection for free.

Quick Q&A