Description
Cipher Block Chaining (CBC) is a block cipher mode of operation standardized within 3GPP for securing user plane data and control plane signaling. It operates by dividing the plaintext message into fixed-size blocks (typically 128 bits for AES). Before encryption, each plaintext block is XORed with the ciphertext of the previous block. The first block is XORed with an Initialization Vector (IV). This chaining mechanism introduces data dependency between blocks, ensuring that identical plaintext sequences result in completely different ciphertext outputs, thereby defeating pattern analysis attacks.
The CBC encryption process follows this sequence: For the first block (i=1), C₁ = Eₖ(P₁ ⊕ IV), where Eₖ is the encryption function with key K, P₁ is the first plaintext block, IV is the Initialization Vector, and C₁ is the resulting ciphertext block. For subsequent blocks (i>1), Cᵢ = Eₖ(Pᵢ ⊕ Cᵢ₋₁). Decryption reverses this process: P₁ = Dₖ(C₁) ⊕ IV and Pᵢ = Dₖ(Cᵢ) ⊕ Cᵢ₋₁ for i>1, where Dₖ is the decryption function. This structure means that a single-bit error in ciphertext block Cᵢ corrupts the decryption of both block Pᵢ (completely garbled) and block Pᵢ₊₁ (single-bit error in the same position), but subsequent blocks decrypt correctly once the error propagates through.
Within 3GPP architectures, CBC mode is implemented in the cryptographic algorithms of the confidentiality protection mechanisms. For example, in LTE and 5G, the 128-EEA1 and 128-NEA1 algorithms use SNOW 3G in a specific stream cipher mode, but the underlying principles of chaining for integrity are conceptually related. Historically, in UMTS, the f8 confidentiality algorithm for UTRAN employed KASUMI in a specific output-feedback mode. While not pure CBC, these 3GPP-specific modes share the cryptographic design philosophy of using feedback to prevent patterns in the plaintext from appearing in the ciphertext. The actual implementation in 3GPP often uses a modified approach optimized for the air interface, such as generating a keystream block that is XORed with the plaintext, where the keystream itself is generated using a chaining mechanism dependent on a COUNT (freshness parameter), a BEARER identity, a DIRECTION bit, and a length parameter.
The role of CBC-like chaining in the network is critical for the AS (Access Stratum) and NAS (Non-Access Stratum) security. In the PDCP (Packet Data Convergence Protocol) layer, the ciphering function takes these inputs (KEY, COUNT, BEARER, DIRECTION, LENGTH) to initialize a ciphering algorithm (like AES in CTR mode for 128-EEA2, or ZUC for 128-EEA3). While these are technically stream cipher modes or counter modes, the requirement for cryptographic synchronization and the use of a state (COUNT) that changes per packet serves a similar anti-replay and pattern-obscuring purpose as the IV in CBC. The core security property provided is confidentiality, ensuring that eavesdroppers on the radio interface cannot decipher the user's data or signaling messages.
Purpose & Motivation
CBC mode was introduced to address the critical vulnerability of the Electronic Codebook (ECB) mode, where identical plaintext blocks yield identical ciphertext blocks. This flaw allows attackers to recognize patterns, deduce information, and potentially execute replay attacks. In telecommunications, where signaling messages and user data packets often contain repetitive structures (headers, protocol padding, common commands), ECB mode would leak significant information about the traffic, compromising user privacy and network security.
The adoption of chaining modes like CBC was motivated by the need for robust confidentiality in digital cellular systems starting with 3G (UMTS). As mobile networks evolved from primarily voice (2G GSM, which used the A5 stream ciphers) to packet-switched data services, the threat model expanded. The deterministic nature of ECB was completely unsuitable for protecting IP packets, SMS data, or sensitive signaling like authentication exchanges. CBC provides semantic security under chosen-plaintext attacks (IND-CPA) when used with a secure block cipher and a random, unpredictable IV for each encryption session.
In the 3GPP context, while the specific algorithms (KASUMI, AES, SNOW 3G, ZUC) may not operate in textbook CBC mode for performance reasons (CBC is not parallelizable and requires sequential processing), the cryptographic design principles are incorporated. The 3GPP specifications define confidentiality algorithms (the f8 family for UMTS, the 128-EEA family for LTE/5G) that use core ciphers in modes ensuring ciphertext is a non-deterministic function of the plaintext, the key, and a time-varying input (COUNT, IV). This directly addresses the limitations of previous, weaker ciphering schemes and is fundamental to meeting the stringent confidentiality requirements of modern mobile broadband standards.
Classification
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (1 CRs across 1 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-4, normative work from Rel-17.
In Release 17, no new technical details or changes were introduced for the "CBC" (Cipher Block Chaining) function itself. The provided Change Request titles and grounding context exclusively describe other features, such as introducing support for UP IP in EPC-connected architectures using NR PDCP. Therefore, Release 17 contained no specific updates or modifications to the CBC cryptographic mode.
- Introducing support of UP IP for EPC connected architectures using NR PDCP TS 36.300CR1353
Explore further
Broader topics and technologies where CBC plays a role.
Defining Specifications
3GPP specifications that define or reference CBC, with the latest known release. Sourced from the 3GPP document catalog — see methodology.
| Specification | Title | Release |
|---|---|---|
| TR 21.905 vj00 | 3GPP Technical Terms and Definitions | Rel-19 |
| TS 22.268 vk00 | Public Warning System (PWS) Requirements | Rel-20 |
| TS 23.048 v1400 | Secured Packets for UICC Remote Management | Rel-5 |
| TS 23.401 vj50 | Evolved Packet System (EPS) Stage 2 Description | Rel-19 |
| TS 25.324 vj00 | Broadcast/Multicast Control Protocol | Rel-19 |
| TS 25.401 vj00 | UTRAN Overall Architecture | Rel-19 |
| TS 25.419 vj00 | Service Area Broadcast Protocol (SABP) | Rel-19 |
| TS 25.703 vc00 | HNB Emergency Warning Area Study for UTRA | Rel-12 |
| TR 26.944 vj00 | QoE, ESQoS and SQoS metrics for 3G multimedia services | Rel-19 |
| TS 28.702 vj00 | Core Network NRM IRP Information Service | Rel-19 |
| TS 29.168 vj00 | SBc-AP Protocol Specification | Rel-19 |
| TS 29.199 v1900 | Multimedia Messaging Web Services | Rel-9 |
| TS 31.113 v1800 | USAT Interpreter Byte Code Specification | Rel-8 |
| TS 31.114 v1800 | USAT Interpreter Transmission Protocol | Rel-8 |
| TS 31.115 vj00 | Secured Packet Structure for UICC Applications | Rel-19 |
| TS 32.102 vj00 | Telecom Management Physical Architecture Framework | Rel-19 |
| TS 32.632 vb00 | Core Network Resources IRP: Network Resource Model | Rel-11 |
| TS 32.732 vb00 | IMS Network Resource Model IRP: Information Service | Rel-11 |
| TR 33.969 vj00 | Security for Public Warning System (PWS) | Rel-19 |
| TR 35.909 vj00 | 3GPP MILENAGE Algorithm Design Report | Rel-19 |
| TS 36.300 vj00 | E-UTRAN Radio Interface Protocol Architecture Overview | Rel-19 |
| TS 36.896 ve00 | Study on Flexible eNB-ID and Cell-ID in E-UTRAN | Rel-14 |
| TS 48.049 vj00 | Cell Broadcast Service Protocol Specification | Rel-19 |