Cipher Key for Single Radio Voice Continuity

Description

The Cipher Key for Single Radio Voice Continuity (CKSRVCC) is a critical security parameter defined within the 3GPP Authentication and Key Agreement (AKA) framework. Its primary function is to serve as a ciphering key for securing voice traffic when a User Equipment (UE) performing a Voice over LTE (VoLTE) or Voice over NR (VoNR) call is handed over to a legacy Circuit-Switched (CS) domain, such as 2G (GERAN) or 3G (UTRAN), via the SRVCC procedure. This handover is necessary in coverage scenarios where the packet-switched (PS) LTE/5G coverage ends but legacy CS voice coverage persists. Without CKSRVCC, the handover could result in a security break, where the call might continue without encryption or fall back to weaker, legacy cryptographic algorithms.

The generation of CKSRVCC is tightly integrated with the core network's security architecture, specifically the Home Subscriber Server (HSS) or Unified Data Management (UDM) and the Mobility Management Entity (MME) or Access and Mobility Management Function (AMF). When an SRVCC-capable UE attaches to the network, the HSS/UDM, as part of the authentication procedure, can derive and store the CKSRVCC alongside other keys like K_ASME. The CKSRVCC is derived from the long-term secret key (K) and other parameters, ensuring it is cryptographically separate from keys used for PS domain security. During an impending SRVCC handover, the source MME/AMF retrieves the CKSRVCC (and its associated integrity key, IKSRVCC) from the HSS/UDM if not already stored locally, and forwards it securely to the target Mobile Switching Center (MSC) server via the Sv interface.

Upon receipt, the target MSC server uses the CKSRVCC to derive the actual ciphering key (Kc) used by the legacy CS radio access network (e.g., using the GSM A5 or UMTS f8 algorithms). This derivation is standardized to ensure interoperability between the 5G Core (5GC)/EPC and the CS domain. The UE performs the same derivation locally. This process ensures that the voice call transitions from being protected by algorithms like AES in the PS domain to being protected in the CS domain without the need for a new authentication procedure, which would cause an unacceptable call interruption. Thus, CKSRVCC enables a seamless and secure continuity of service, maintaining the confidentiality of the user's voice data across the technological boundary.

The specification of CKSRVCC in 3GPP TS 33.501 provides a formalized key hierarchy and key derivation functions. It is part of a suite of SRVCC-specific keys that also includes IKSRVCC for integrity and keys for the associated signaling protection. Its introduction was crucial for enabling secure VoLTE/VoNR deployments, as it closed a critical security gap that existed in early SRVCC implementations, which sometimes relied on null ciphering or weaker, pre-shared keys during the CS fallback phase, leaving calls vulnerable to eavesdropping.

Purpose & Motivation

CKSRVCC was created to solve the specific security problem of maintaining call confidentiality during an inter-RAT handover from a secure, packet-switched 4G/5G network to a legacy circuit-switched 2G/3G network. Prior to its standardization, SRVCC handovers presented a significant vulnerability. The LTE/5G networks use strong, EPS-AKA or 5G-AKA based encryption (e.g., 128-EEA1, AES), while legacy GSM and UMTS networks often used older, weaker ciphering algorithms (like A5/1) or could even operate in unencrypted mode. Without a mechanism to transfer a strong, session-specific key, the handover could force a security downgrade, breaking encryption or forcing a re-authentication that would interrupt the active call.

The historical context is the phased deployment of VoLTE and later VoNR. Operators needed a way to provide seamless voice service across their mixed-network footprints, especially in areas where LTE/NR data coverage was spotty but GSM/UMTS voice coverage was ubiquitous. The SRVCC procedure itself was defined to handle the mobility, but its initial specifications lacked a robust, standardized security solution for the key transfer. CKSRVCC filled this gap by defining a dedicated key within the AKA key hierarchy that is derived from the strong root key and can be mapped to the legacy CS domain's keying material.

This addressed the limitations of ad-hoc or non-standard implementations, ensuring a consistent, high level of security assurance for voice calls regardless of the underlying access technology. It protects against eavesdropping attacks during the critical handover window and afterward in the CS domain, thereby upholding the overall security promise of IMS-based voice services and meeting regulatory and user expectations for private communications. Its creation was motivated by the need to make SRVCC a truly carrier-grade and secure feature, which was essential for operators to confidently deploy VoLTE/VoNR as the primary voice service.