51学通信

深度解析 3GPP TS 33.401：第十五章 “生命热线”的守护——IMS紧急呼叫安全机制

22分钟阅读

好的，我们继续对3GPP TS 33.401的深度探索。在完成了对常规通话（VoLTE）在4G与2G/3G网络间切换（SRVCC）的安全机制解读之后，我们将目光转向一个更为特殊、也更为重要的通信场景——紧急呼叫。

本文将聚焦于第十五章 Security Aspects of IMS Emergency Session Handling (IMS紧急会话处理的安全方面)。我们将看到，当“生命安全”这一最高优先级出现时，常规的安全流程是如何做出适应性调整，以确保求救信号能够以最快、最可靠的方式被建立的。

深度解析 3GPP TS 33.401：第十五章 “生命热线”的守护——IMS紧急呼叫安全机制

本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“15 Security Aspects of IMS Emergency Session Handling”的核心章节，旨在为读者阐明在认证和非认证两种截然不同的场景下，IMS紧急呼叫是如何建立，以及安全策略是如何为了保障呼叫的可靠性而进行灵活调整的。

我们的主角“小明”遭遇了紧急情况，他按下了手机的紧急呼叫按钮。此时，他的手机可能处于各种复杂的状态：可能是一部没有插入SIM卡的手机，可能处于一个没有漫游协议的国外运营商网络覆盖下，也可能是一部正常使用的手机。

无论处于何种状态，通信网络都必须尽最大努力为他接通紧急服务中心。第十五章的核心任务，就是定义在这种“最高优先级”场景下的安全处理原则，其核心思想是：在可能的情况下提供最高级别的安全；在必要的情况下，安全可以为可靠性让路。

1. 紧急呼叫的基本原则 (15.1 General)

Support for IMS Emergency Sessions is defined in the TS 23.401. Limited service state of a UE is defined in TS 23.122. IMS Emergency Sessions can be made by normally attached UEs or UEs attached for EPS emergency bearer services.

深度解读：

  • IMS紧急会话：在4G/5G时代，紧急呼叫（如拨打112, 911, 120）是通过IMS（IP Multimedia Subsystem）承载的，其本质是一次特殊的VoIP通话。

  • 两种发起者：

    1. 正常附着的用户（Normally attached UEs）：小明正常使用手机时拨打的紧急电话。

    2. 为紧急承载服务而附着的用户（UEs attached for EPS emergency bearer services）：这是特殊情况，比如小明的手机没有SIM卡，或者SIM卡无效。此时，手机会发起一种特殊的“紧急附着（Emergency Attach）”流程，目的仅仅是为了建立一个能够通向紧急中心的IP通路。这种状态下，手机处于“受限服务模式（Limited Service Mode）”。

It depends on the serving network policy if unauthenticated IMS Emergency Sessions are allowed. Any behaviour not explicitly specified as being special to IMS Emergency Sessions is handled in accordance with normal procedures.

深度解读：

  • 策略决定一切：是否允许“未经认证的”紧急呼叫，最终取决于运营商和当地法规的策略。

  • 默认常规流程：除非本章有特殊规定，否则紧急呼叫的安全处理应遵循与普通呼叫相同的流程。这确立了“尽可能安全”的基线。

2. 场景一：已认证的IMS紧急会话 (15.2.1 Authenticated IMS Emergency Sessions)

这是最理想、最安全的情况。小明的手机处于正常服务状态，拥有一个有效的安全上下文。

15.2.1.1 General

UEs that are not in limited service state, shall initiate normal initial attach when not already attached to receive EPS emergency bearer services. The security mode control procedure shall be applied…Thus, integrity protection (and optionally ciphering) shall be applied as for normal EPS bearers.

深度解读：

  • 等同于普通呼叫：对于一个正常在网的用户，发起紧急呼叫的安全流程与发起一个普通的VoLTE通话完全相同。

  • 完整安全流程：需要经过AKA认证（如果尚无有效上下文）、密钥派生、NAS/AS SMC激活等全套流程。空口的信令和语音数据都会受到完整的完整性和机密性保护。

认证失败时的特殊处理

如果在一个已认证的会话中，网络突然发起了重认证，而这次认证失败了，会发生什么？

15.2.1.2 UE and MME share a current security context

If the authentication failure is detected in the UE or in the MME during an attach procedure for EPS emergency bearer services…and the related signalling messages were correctly integrity-protected by the current EPS security context, the set up of the EPS emergency bearers shall then proceed in one of two ways:

a) The set-up proceeds according to clause 15.2.2. …the MME requests the use of the NULL ciphering and integrity algorithms…

b) Or else, if the serving network policy allows unauthenticated IMS Emergency Sessions and MME continues using the current security context, the use of the EPS emergency bearers may proceed…

深度解读：这是一个非常关键的决策点，体现了安全与可靠性的权衡。

  • 前提：UE和MME之间本来有一个有效的、受完整性保护的信道。在此基础上，一次新的AKA认证失败了。

  • 两种选择：

    1. 降级到“不设防”模式 (a)：MME认为认证失败是一个严重的安全信号，但为了保障紧急呼叫，它决定放弃安全。MME会发起一次新的SMC流程，强制要求UE使用空算法（EEA0/EIA0），即不加密、不保护完整性。UE根据规范必须接受这个指令，然后呼叫在无保护状态下继续。

    2. 维持现状模式 (b)：MME认为，尽管新的AKA失败了，但我们之间原有的那个安全信道（旧的KASME）本身还是可信的。为了既保障呼叫，又维持一定的安全水平，MME决定继续使用旧的安全上下文来保护这次紧急呼叫，不再尝试新的认证。

网络策略会决定在这两种模式中如何选择。无论哪种方式，最终目的都是确保紧急呼叫不因认证失败而中断。

3. 场景二：未经认证的IMS紧急会话 (15.2.2 Unauthenticated IMS Emergency Sessions)

这是更具挑战性的场景。通常发生在UE无法通过网络认证的情况下。

15.2.2.1 General

…IMS Emergency Sessions may be established in limited service state without the network having to authenticate the UE or apply ciphering or integrity protection for either AS or NAS.

The following are the only identified cases where the “security procedure not applied” option may be used:

a) Authentication is impossible because the USIM is absent;

b) …serving network cannot obtain authentication vectors due to a network failure;

c) …USIM is in limited service mode in the serving network…

d) Authentication is possible but the serving network cannot successfully authenticate the USIM.

深度解读：规范明确列出了四种可以（如果策略允许）建立“不设防”紧急呼叫的场景：

a) 无USIM/SIM卡。

b) 网络故障：MME无法从HSS获取认证向量。

c) USIM受限：例如，在没有签订漫游协议的国外网络。

d) 认证失败：AKA流程因为各种原因（如RES不匹配、SQN同步失败等）最终失败。

在这些情况下，如果网络策略允许，MME将主导建立一个使用**空算法（EEA0/EIA0）**的承载。

“不设防”的建立流程 (15.2.2.2 UE and MME share no security context)

小明有一部旧手机，没有插SIM卡，但遇到了紧急情况。他拨打了紧急号码。

  1. UE发起紧急附着：手机会发起Emergency Attach请求。由于没有IMSI，它会携带自己的IMEI作为身份标识。

  2. MME的决策：MME收到请求后，发现无法对这个UE进行认证。根据本地紧急呼叫策略，它决定允许该呼叫。

  3. 强制空算法SMC：MME会向UE发起一次NAS SMC流程。

    After receiving EC Indication from the UE, the MME knows of that UE’s intent to establish an IMS Emergency Session.

    If the MME cannot identify the subscriber, or cannot obtain authentication vectors, the MME shall send NAS SMC with NULL algorithms to the UE regardless of the supported algorithms announced previously by the UE.

    深度解读：MME会无视UE上报的任何安全能力（即使UE声称自己支持AES），强制在SMC命令中选择EEA0（不加密）和EIA0（不保护完整性）。

  4. UE的配合：

    The UE will proceed as specified for the non-emergency case…except that the UE shall accept a NAS SMC selecting EEA0 and EIA0 algorithms from the MME.

    深度解读：UE在紧急呼叫场景下，被要求必须接受网络下发的空算法指令。这是规范中的一个特殊条款，保证了在这种“生命攸关”的时刻，UE不会因为安全策略与网络不符而拒绝连接。

  5. “虚拟”的KASME：

    An unauthenticated UE does not share a complete EPS NAS security context with the network. Since there has been no successful EPS AKA run, the UE and the MME does not share a KASME…the UE and the MME independently generate a KASME in an implementation defined way…all key derivations proceed as if they were based on a KASME generated from an EPS AKA run. (15.2.4.1)

    深度解读：这是一个非常有趣的设计。即使全程使用空算法，UE和MME的协议栈依然需要一个“形式上”的KASME来填充安全上下文的结构。此时，UE和MME会各自独立地、本地地生成一个“伪KASME”（例如，一个全零的串）。这个密钥不会被用于任何实际的加解密，但它使得后续的协议流程（如切换时派生KeNB*）可以“形式上”走通，尽管最终派生出的所有密钥也都是无效的。这极大地简化了协议栈的实现，无需为紧急呼叫设计一套全新的、没有密钥概念的状态机。

4. 紧急呼叫中的切换 (15.2.4.2 Handover)

When UE attempts to make X2/S1 handover, UE and eNB derive and transfer the keys as normal to re-use the normal handover mechanism. Since the derived keys have no ability to affect the output of the NULL algorithms it is irrelevant that the network and the UE derive different keys.

深度解读：

  • 流程照常，结果无效：当一个正在进行的、未经认证的紧急呼叫需要切换时，切换的信令流程和密钥派生照常进行。源eNB和目标eNB会像处理普通切换一样传递安全上下文，UE和eNB也会各自计算新的KeNB*。

  • “殊途同归”：然而，因为大家都在使用空算法（EIA0/EEA0），这些算法的输出永远是固定的（加密输出等于输入，MAC输出为全零），与输入的密钥完全无关。因此，即使UE和网络因为使用不同的“伪KASME”而派生出了完全不同的KeNB*，也完全不影响通信。最终，切换后的信道依然是一个“不设防”的信道。

这种设计，再次体现了协议栈实现的优雅——用一套统一的流程来处理所有场景，只是在不同的安全等级下，这个流程的“实际效果”不同。

5. 总结

第十五章向我们展示了4G安全体系在面对“生命安全”这一最高原则时的灵活性与适应性。它并非一套僵硬的、非黑即白的规则，而是一个懂得权衡、有优先级的智能系统。

  • 安全是基线：对于正常在网用户，紧急呼叫默认享受与普通VoLTE通话同等级别的最高安全保护。

  • 可靠性优先于安全性：在认证失败或无法认证的极端情况下，为了确保紧急呼叫的建立，规范允许甚至强制网络和UE“降级”到不加密、不保护完整性的“裸奔”模式。

  • 流程统一，实现简化：通过引入“空算法”和“虚拟KASME”的概念，使得未经认证的紧急呼叫也能复用绝大多数常规的安全信令流程（如SMC、切换），极大地降低了终端和网络设备实现的复杂度。

  • 策略驱动，灵活可配：最终是否允许未经认证的紧急呼叫，决定权交给了运营商和当地法规，为不同国家和地区的策略差异预留了空间。

通过对第十五章的学习，我们不仅理解了紧急呼叫的特殊安全处理，更深刻地体会到，任何一个成功的、大规模部署的工程系统，其设计都必然是理想主义（追求极致安全）与现实主义（保障核心功能）的完美结合。

至此，TS 33.401正文部分的核心章节（4至15章）我们已经基本解读完毕。从下一篇文章开始，我们将进入**附录（Annexes）**部分，那里同样隐藏着大量关键的技术细节，例如各种密钥派生函数（KDF）的精确定义。同时，我们将对整部规范进行一次全面的回顾与总结。

FAQ 环节

Q1：为什么在已认证的紧急通话中，如果重认证失败，网络可以选择“继续使用旧的安全上下文”？这不会有安全风险吗？

A1：这确实是一种权衡。选择“继续使用旧上下文”的逻辑是：虽然新的认证失败了（这可能是一个攻击信号，也可能只是暂时的网络问题），但旧的上下文本身是通过一次成功的AKA建立的，其安全性在当时是得到过验证的。在“中断紧急通话”和“承担一定风险继续使用旧密钥”之间，后者显然是更优的选择。这种风险被认为是可控的，因为攻击者即使能干扰新的AKA，也未必能破解旧的KASME。

Q2：一部没有SIM卡的手机，是如何发起“紧急附着”并与网络通信的？

A2：没有SIM卡的手机，其射频模块依然可以工作。它会扫描周围的无线信号，找到一个可用的网络（即使没有签约），然后发起一个特殊的Attach Request，并在消息类型中明确指出Attach Type = "Emergency"。在身份标识方面，由于没有IMSI，它会使用手机硬件的唯一标识IMEI来向网络表明身份。MME收到这种请求后，会识别出这是一个紧急附着，即使在HSS中查不到这个IMSI/IMEI的签约信息，也会根据本地策略，为其分配一个临时的、仅用于紧急呼叫的IP连接。

Q3：既然未经认证的紧急呼叫不加密，那通话内容不是可以被任何人窃听吗？

A3：是的。在未经认证、使用空算法的紧急呼叫中，空口的语音数据是明文传输的，理论上可以被拥有相应设备的人窃听。这正是为了保证呼叫的“可建立性”而做出的安全妥协。规范的隐含逻辑是，在紧急关头，能够成功把求救信息（“我在哪里，我遇到了什么事”）传递出去，其重要性远远超过通话内容被窃听的风险。

Q4：为什么在未经认证的紧急呼叫切换时，UE和网络派生出不同的KeNB*也无所谓？

A4：因为最终使用的加密和完整性算法是EEA0和EIA0（空算法）。这些算法的特点是，它们的输出与输入的密钥无关。

  • EEA0的“加密”操作是：密文 = 明文 ⊕ 0，所以密文 = 明文。

  • EIA0的“完整性”计算是：无论输入的消息是什么，输出的MAC永远是0。

因此，无论UE和eNB各自用什么五花八门的（伪）密钥作为输入，最终作用在数据包上的安全效果都是“零”，即不加密、不校验。所以双方密钥是否一致，已经变得毫无意义。

Q5：如果攻击者利用紧急呼叫的“不设防”特性，发起大量虚假的紧急呼叫来消耗网络资源（DoS攻击），怎么办？

A5：这是一个真实存在的风险，也是网络运营商需要重点防范的问题。虽然33.401主要关注信道安全，但其他3GPP规范和运营商的实际部署会采取多种措施来缓解这种风险：

  • 网络侧限流：核心网可以对来自未经认证用户的紧急呼叫请求进行速率限制。

  • IMEI追踪：虽然IMEI可以被伪造，但对于大量使用真实IMEI的攻击，网络可以记录这些IMEI并将其列入黑名单。

  • 位置信息分析：通过分析大量虚假呼叫的来源位置，可以帮助定位攻击源。

  • 与紧急服务中心的协同：网络可以将呼叫信息传递给紧急中心，由其接线员来最终判断呼叫的真实性。

最终，这是一个需要网络安全、无线资源管理和上层应用协同解决的复杂问题。

关系图谱