51学通信

深度解析 3GPP TS 33.401：第十四章 VoLTE通话的“安全着陆”——SRVCC安全机制

19分钟阅读

好的，我们继续对3GPP TS 33.401的深度探索。在完成了对网络基础设施内部“固定”链路的安全防护（网络域安全）的解读之后，我们将再次回到“移动”的用户视角，探讨一个极为重要的业务场景——语音通话，特别是在4G LTE与传统2G/3G电路域网络之间无缝切换时的安全保障。

本文将聚焦于第十四章 SRVCC between E-UTRAN and Circuit Switched UTRAN/GERAN (E-UTRAN与电路域UTRAN/GERAN之间的SRVCC)，我们将看到，当一次高清流畅的VoLTE通话遭遇4G信号盲区时，网络是如何通过SRVCC技术，在保证通话不中断的同时，完成安全上下文的“跨域接力”。

深度解析 3GPP TS 33.401：第十四章 VoLTE通话的“安全着陆”——SRVCC安全机制

本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“14 SRVCC between E-UTRAN and Circuit Switched UTRAN/GERAN”的核心章节，旨在为读者深入剖析在VoLTE到CS语音的切换过程中，安全上下文是如何从PS域（分组域）平滑映射到CS域（电路域）的。

我们的主角“小明”正驾车行驶在郊区公路上，通过车载蓝牙，与一位重要客户进行着一场VoLTE高清语音通话。VoLTE（Voice over LTE）是承载在4G分组域（PS）数据网络上的语音解决方案。突然，汽车驶入一个长长的隧道，4G信号骤然消失，但幸运的是，隧道内还有传统的3G信号覆盖。

如果没有SRVCC技术，小明的这通重要电话将会瞬间中断。但有了SRVCC，他几乎感觉不到任何变化，通话仍在继续，只是手机屏幕顶端的“HD”或“VoLTE”标识可能悄然消失了。

SRVCC (Single Radio Voice Call Continuity，单射频语音呼叫连续性)，就是这样一个“魔术”，它能在手机只有一个射频单元的情况下，将正在进行的PS域VoLTE语音，无缝切换到传统的CS域（2G/3G的电路交换）语音通道上。这个“魔术”的背后，同样隐藏着一套精妙的安全接力机制。

1. 从4G PS域到2G/3G CS域的切换 (14.1 From E-UTRAN to Circuit Switched UTRAN/GERAN)

这是SRVCC最核心的场景。一次VoLTE通话本质上是一个IP数据流，受EPS PS域的安全机制保护（即KASME → KeNB → KUPenc）。而一次CS通话，则受CS域独立的安全机制保护，其密钥（CKcs, IKcs）与PS域完全分离。SRVCC安全的核心，就是要从现有的PS域安全上下文中，派生出一套全新的、可用于CS域的密钥。

这个过程，与我们之前在第九章学习的从4G PS域到3G PS域的切换非常相似，都是一次密钥映射。

The MME and the UE shall derive a confidentiality key CKSRVCC, and an integrity key IKSRVCC from KASME of the current EPS security context and the selected NAS downlink COUNT…

The KDF returns a 256-bit output, where the 128 most significant bits are identified with CKSRVCC and the 128 least significant bits are identified with IKSRVCC.

深度解读：SRVCC密钥的派生

  1. 触发：当eNB检测到UE信号变弱且判断需要进行SRVCC时，会向MME发起切换请求。

  2. MME主导派生：MME收到请求后，立刻执行密钥派生。它使用的“原料”与从4G PS切换到3G PS时如出一辙：

    • 密钥：当前UE的KASME。

    • 新鲜度参数：一个新鲜的**NAS downlink COUNT (下行NAS计数器)**。MME会选择一个COUNT值，然后将自己本地存储的COUNT加一，以防重用。

  3. KDF运算：MME将KASME和NAS downlink COUNT送入一个专为SRVCC定义的密钥派生函数（KDF，定义在附录A.12）。这个KDF的256比特输出，被一分为二：

    • 高128位，成为CS域的加密密钥 CKSRVCC。

    • 低128位，成为CS域的完整性密钥 IKSRVCC。

这对新生成的CKSRVCC和IKSRVCC，就是VoLTE通话安全“着陆”到CS域的“降落伞”。

密钥的传递与UE侧的同步

UE and MME shall assign the value of eKSI to KSI. MME shall transfer CKSRVCC, IKSRVCC with KSI and the UE security capability to the MSC server enhanced for SRVCC.

The MME shall also provide the 4 LSB of the selected NAS downlink COUNT value to the source eNB, which then includes the bits to the HO Command to the UE. The UE shall use the received 4 LSB and its stored NAS downlink COUNT to estimate the NAS downlink COUNT selected by the MME.

深度解读：

  1. MME → MSC Server：MME将派生出的CKSRVCC, IKSRVCC，连同当前4G上下文的eKSI（在CS域中被称为KSI），一起通过核心网接口发送给负责处理CS通话的MSC Server（移动交换中心）。

  2. MME → eNB → UE：为了让UE能够计算出完全相同的密钥，MME必须把那个用作新鲜度参数的NAS downlink COUNT值告诉UE。与PS切换一样，为了节省空口资源，MME不会发送完整的32位COUNT，而是只将其**最低的4个比特（LSB）**发送给源eNB。

  3. eNB → UE：源eNB在构建发往UE的切换命令（Handover Command）时，会将这4个比特包含进去。

  4. UE的计算：UE收到切换命令后，提取出这4个比特，并结合自己本地维护的、与MME大致同步的NAS downlink COUNT，推算出MME使用的那个完整的32位COUNT值。然后，UE使用完全相同的KASME和推算出的COUNT，执行相同的KDF运算，得到与MME完全一致的CKSRVCC和IKSRVCC。

CS域安全的激活

The UE shall replace all the stored UTRAN CS key parameters CK, IK, KSI, if any, with CKSRVCC, IKSRVCC, KSI in both ME and USIM. STARTCS shall comply with the rules in TS 25.331.

深度解读：

  • 密钥替换：一旦UE成功计算出新的CS密钥，它会用这对新密钥覆盖掉USIM卡和手机内存中任何已有的CS域密钥。这确保了SRVCC生成的密钥成为当前唯一合法的CS密钥。

  • STARTcs：这是一个在3G CS域中用于同步加密启动时机的参数。UE会根据3G的规范（TS 25.331）来处理它。

  • 无缝激活：切换到3G/2G网络后，UE和MSC Server就立即使用这对CKSRVCC/IKSRVCC来保护CS域的信令和语音数据，实现了通话的持续加密。

场景串联：小明的VoLTE通话正在进行。当他的车进入隧道，eNB向MME发出SRVCC请求。MME立刻从“保险柜”里拿出小明的KASME，结合一个最新的NAS downlink COUNT，通过KDF“铸造”出一对CS域的密钥CKSRVCC/IKSRVCC。MME将这对密钥通过内部通道送往MSC Server，同时将COUNT的“尾号”（低4位）告诉eNB。eNB在给小明手机的“紧急撤离”指令中附上了这个“尾号”。小明的手机收到指令后，根据“尾号”推算出完整的COUNT，同样“铸造”出了完全一样的CS密钥。瞬间之后，手机切换到3G网络，并立刻启用这对新密钥，与MSC Server建立起加密的CS语音通道。整个过程一气呵成，小明甚至没有感觉到通话有任何卡顿。

2. 紧急呼叫的特殊处理 (14.2 Emergency call in SRVCC from E-UTRAN…)

SRVCC同样适用于紧急呼叫。规范对此做了简单的区分。

If the SRVCC is for an emergency call and the session in EUTRAN complies with clause 15.2.1, the security procedure in clause 14.1 shall be applied.

If the SRVCC is for an emergency call and the session in EUTRAN complies with clause 15.2.2, the security procedure in clause 14.1 shall not be applied, i.e., no key derivation is needed.

深度解读：

  • 场景1：已认证的紧急呼叫：如果小明是在4G网络下、通过了正常认证后拨打的紧急VoLTE电话（符合15.2.1节的场景），那么在发生SRVCC时，安全流程与普通通话完全一样，即需要从KASME派生CKSRVCC/IKSRVCC来保证切换后的通话安全。

  • 场景2：未认证的紧急呼叫：如果小明是在没有SIM卡、或无法通过认证的特殊情况下建立的紧急VoLTE电话（符合15.2.2节的场景），此时4G链路上可能使用的是“空算法”（不加密）。那么在发生SRVCC时，将不进行任何密钥派生，切换到CS域后，也大概率会是一个未加密的紧急通话。

这个区分，再次体现了“生命安全优先”和“安全级别平移”的原则。

3. 从CS域返回PS域 (14.3 SRVCC from circuit switched UTRAN/GERAN to E-UTRAN)

当小明驾车驶出隧道，4G信号恢复时，网络可能会将他的通话从3G CS域再切换回4G VoLTE，以提供更好的通话质量。这个反向过程被称为rSRVCC (reverse SRVCC)。

The procedure for SRVCC handover from UTRAN/GERAN CS to E-UTRAN…is as described below.

The activation of NAS and AS security in E-UTRAN, and selection of the key set from the source system for the handover shall be according to following principles…

深度解读：rSRVCC的安全机制，与我们在第九章学习的从3G PS域切换到4G PS域（9.2.2节）的流程高度相似。

  1. 密钥源：源端MSC Server会选择UE当前使用的CS密钥（CKcs/IKcs，即之前SRVCC生成的CKSRVCC/IKSRVCC）作为派生的基础。

  2. 映射K'ASME：MSC Server和MME协同，UE则独立计算。与PS域切换一样，通过交换**NONCE随机数**，双方从128比特的CKcs/IKcs中，安全地派生出一个256比特的映射密钥K'ASME。

  3. 安全激活：UE使用这个K'ASME立即建立起与目标eNB的空口安全，并将IMS信令（VoLTE的核心信令）承载切换到4G PS域上，完成rSRVCC。

  4. 后续（可选）：切换完成后，UE同样可以发起TAU流程，尝试恢复其原生的KASME上下文。

4. 总结

第十四章为我们揭示了SRVCC这个保障VoLTE业务连续性的“黑科技”背后的安全逻辑。它通过一套与PS域互通一脉相承的密钥映射机制，实现了安全上下文在PS域和CS域之间的平滑“翻译”和“接力”。

  • 对称的映射机制：无论是PS域之间的切换，还是PS到CS的切换（SRVCC），其核心都是从一个已有的强安全上下文中，结合一个新鲜度参数（COUNT或NONCE），通过KDF派生出适用于目标域的新密钥。这体现了3GPP安全设计的高度一致性和模块化。

  • 下行COUNT作为新鲜度：在网络主导的SRVCC流程中，使用NAS downlink COUNT作为新鲜度来源，简化了信令流程，保证了切换的低时延。

  • 安全级别平移：SRVCC确保了在切换前后，通话的加密状态得以保持（已认证的通话保持加密，未认证的紧急通话保持不加密），为用户提供了连续的安全体验。

  • 与核心移动性安全流程复用：反向的rSRVCC流程，巧妙地复用了PS域切换的安全机制，避免了为每个场景都设计一套全新流程的复杂性。

正是有了这套严谨而高效的安全机制，小明才能在4G信号时有时无的山路上，保持与客户通话的畅通无阻，不错过任何一笔重要的生意。

FAQ 环节

Q1：SRVCC中的密钥CKSRVCC/IKSRVCC和第九章中从4G PS到3G PS切换时派生的CK'/IK'是同一个东西吗？

A1：它们在功能和派生原理上是相同的（都是从KASME和NAS downlink COUNT派生），但它们服务于不同的域，并且使用的KDF函数是不同的。

  • CK'/IK'（第九章）：用于PS域（分组交换），保护的是数据业务，如上网。它们被送往SGSN。

  • CKSRVCC/IKSRVCC（第十四章）：用于CS域（电路交换），保护的是语音通话。它们被送往MSC Server。

规范为这两种不同的映射场景定义了不同的KDF函数（附录A.8 vs A.12），这意味着即使输入完全相同，生成的密钥值也是不同的。这确保了PS域和CS域的密钥空间完全分离，互不影响。

Q2：为什么SRVCC需要一个“增强型MSC Server”（MSC server enhanced for SRVCC）？

A2：因为传统的MSC Server只懂得处理CS域的信令和安全。而SRVCC要求MSC Server能够与4G核心网的MME进行交互，理解并能处理从MME传递过来的、基于4G安全上下文派生出的密钥（CKSRVCC/IKSRVCC）。“增强型”就体现在它新增了与MME之间的接口（如Sv接口）以及处理这种跨域安全上下文的能力。

Q3：如果VoLTE通话在SRVCC到3G CS后，又从3G CS切换到2G CS，安全密钥会怎样变化？

A3：这是一个很好的问题，体现了密钥链的传递。当UE已经位于3G CS域，使用CKSRVCC/IKSRVCC保护通话时，如果再发生到2G CS的切换，此时将遵循3G到2G的CS切换安全规则（定义在TS 33.102中）。通常，MSC Server会使用当前的CKSRVCC/IKSRVCC作为输入，通过c3转换函数，派生出64位的GSM密钥Kc，然后在2G网络下使用Kc来保护通话。

Q4：在rSRVCC（从CS返回PS）过程中，为什么还需要交换NONCE？直接用CKcs/IKcs和COUNT派生不行吗？

A4：这与从3G PS返回4G PS的原因相同。CS域的密钥CKcs/IKcs是128比特的，且CS域没有像4G NAS那样定义良好且同步的、可用于跨域派生的COUNT。为了从128比特的密钥安全地派生出256比特的强密钥K'ASME，必须注入额外的随机性。通过UE和网络侧交换NONCE，共同为KDF提供了足够的新鲜度和熵，保证了派生出的K'ASME的安全性。

Q5：SRVCC流程对手机的射频单元有什么要求？为什么叫“单射频”？

A5：“单射频”（Single Radio）是SRVCC技术的一个关键特征和挑战。这意味着手机在任意时刻，其射频硬件只能工作在一种无线接入技术上（比如LTE或UMTS），不能同时在两个网络上收发信号。因此，SRVCC的切换是一个“先断后通”（Break-before-make）的过程，手机必须先中断在LTE上的连接，再在UMTS/GERAN上建立连接。整个切换流程必须被设计得极快，以至于这个短暂的中断（通常在200-300毫秒）不会被人耳察觉，从而实现“连续性”的体验。所有支持VoLTE的手机都必须支持SRVCC功能。

关系图谱