CKSRVCC

Cipher Key for Single Radio Voice Continuity

Security
Introduced in Rel-16
A security key used to protect voice calls during a Single Radio Voice Call Continuity (SRVCC) handover from LTE/5G to legacy 2G/3G networks. It ensures call confidentiality and integrity is maintained during the inter-system mobility procedure, preventing security downgrades.

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.

Key Features

  • Enables secure ciphering context transfer from PS to CS domain during SRVCC
  • Derived from the long-term subscriber key (K) via the AKA framework, ensuring cryptographic strength
  • Prevents security downgrade and maintains call confidentiality across LTE/5G to 2G/3G handover
  • Standardized key derivation function for generating legacy CS cipher key (Kc) from CKSRVCC
  • Managed and distributed by the HSS/UDM and MME/AMF core network elements
  • Eliminates need for re-authentication during handover, ensuring seamless voice continuity

Evolution Across Releases

Rel-16 Initial

Introduced CKSRVCC as part of the enhanced security mechanisms for 5G systems. It was defined within the 5G security architecture specification (TS 33.501) to support SRVCC from 5G NR (VoNR) and LTE (VoLTE) to legacy CS networks. The initial architecture established the key derivation path from the 5G anchor key (KAUSF) and its provisioning from the UDM to the AMF/MME for secure transfer to the MSC server.

Defining Specifications

SpecificationTitle
TS 33.501 3GPP TR 33.501