51学通信

深度解析 3GPP TS 33.501：6.13-6.14 “安全审计”与“漫游引导”

19分钟阅读

好的，我们继续深入解读3GPP TS 33.501规范。

深度解析 3GPP TS 33.501：6.13-6.14 “安全审计”与“漫游引导”

本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“6.13 Signalling procedure for PDCP COUNT check”和“6.14 Steering of roaming security mechanism”的核心章节，旨在为读者揭示5G安全体系中的两种高级“治理”机制：一种是RAN侧的“内部审计”，另一种是HPLMN对漫游用户的“宏观调控”。

在之前的系列文章中，我们已经详细地剖析了5G安全的核心流程，从认证、密钥派生到各种状态下的移动性管理。我们已经构建起了一座坚固的“安全堡垒”。然而，任何一座堡垒都需要定期的“巡检”和来自“中央”的宏观指令，以应对内部的潜在风险和外部环境的变化。

今天，我们将深入解读规范的6.13节和6.14节。这两章分别代表了5G安全体系中的两种“治理”手段：

  • 6.13 PDCP COUNT检查：这是一种由基站（gNB）发起的、针对UE的“本地化安全审计”，旨在检测无线链路上是否存在潜在的数据注入攻击。它像是一场定期的“账目核对”。
  • 6.14 漫游引导安全机制：这是一种由归属网络（HPLMN）主导的、对漫游UE的“远程宏观调控”。它允许HPLMN安全地向其海外用户下发“优选网络列表”，引导用户接入更友好或更经济的网络。

为了让这些概念更易于理解，我们将引入两个新的场景。主角“安安”在一家高科技公司的园区内使用5G专网进行工作，该网络对安全性和可靠性要求极高。突然，网络工程师“李工”在后台发起了一次针对安安手机的“PDCP COUNT检查”。之后，安安出国度假，她的手机收到了一条来自国内运营商的“神秘指令”，自动切换到了一个信号更好、网速更快的当地网络。这两个场景，将帮助我们揭开6.13节和6.14节的神秘面纱。

1. 6.13 PDCP COUNT检查 - 无线链路的“定期对账”

在建立了安全的用户平面（UP）连接后，UE和gNB会使用K_UPint密钥和PDCP COUNT序列号，对用户数据进行完整性保护。这可以防止数据被篡改。但是，它能否防止恶意的“数据注入”攻击呢？例如，一个攻击者能否伪造一个带有合法序列号的虚假数据包插入到数据流中？

The following procedure is used optionally by the gNB to periodically perform a local authentication. At the same time, the amount of data sent during the AS connection is periodically checked by the gNB and the UE for both up and down streams. NOTE: The PDCP COUNT check is used to detect maliciously inserted packets. Packet insertion is detected automatically in integrity protected DRBs; therefore, the PDCP COUNT check procedure is superfluous for integrity protected bearers.

核心思想与矛盾点：

  • 目的：PDCP COUNT检查的初衷，是通过定期“核对账目”（即双方收发数据包的序列号），来检测是否存在数据包被恶意注入的异常情况。
  • 矛盾点：规范中的NOTE明确指出，对于已经开启了完整性保护的数据承载（DRB），这个检查是多余的（superfluous）。因为每一次完整性校验（检查MAC值）本身就已经能确保数据包是来自合法的发送方且未被篡改，自然也能防范数据注入。

那么，这个流程的实际意义何在？它更像是一种可选的、额外的安全审计层，或者是在某些未开启UP完整性保护但又需要某种程度审计的特殊场景下的补充手段。

PDCP COUNT检查流程 (Figure 6.13-1)

场景代入： 安安正在公司园区内，通过一个对安全性要求极高的DRB传输数据。园区gNB的安全策略配置为每传输1GB数据，就进行一次COUNT检查。

  1. gNB发起检查 (Step 1)：当gNB检测到安安的上行或下行数据流量达到了阈值，它会向安安的手机发送一条受RRC完整性保护的**Counter Check消息。这条消息里包含了gNB当前记录的、每个活跃DRB的PDCP COUNT值的最高位部分**。例如，如果一个COUNT值是0x12345678，gNB可能会发送0x1234。

  2. UE核对并响应 (Step 2)：安安的手机收到消息后，会取出自己本地为每个DRB维护的COUNT值，并与gNB发来的值进行比较。然后，它会将自己本地的完整COUNT值，打包在Counter Check Response消息中，发回给gNB。

  3. gNB最终比对 (Step 3)：gNB收到UE的响应后，将UE上报的完整COUNT值与自己本地记录的进行最终比对。

    • 一致：一切正常，流程结束。
    • 不一致：gNB检测到异常！这意味着在UE和gNB之间，对于收发了多少数据包的“账目”出现了差异。gNB可能会采取进一步的行动，如释放连接，或者将这个异常事件上报给AMF或运维中心（O&M），由李工这样的工程师进行深入分析，以判断是否存在潜在的攻击。

这个流程就像gNB和UE之间的一次“电话对账”，虽然在开启了完整性保护后显得有些多余，但它提供了一种独立于逐包校验的、周期性的、更高维度的安全审计机制。

2. 6.14 漫游引导安全机制 - HPLMN的“远程遥控器”

当用户漫游时，连接到哪个当地网络，不仅影响用户体验，也直接关系到运营商之间的结算成本。因此，归属网络（HPLMN）迫切需要一种机制，能“引导”其漫游用户优先选择那些与自己有更优惠协议或网络质量更好的合作伙伴网络。这就是漫游引导（Steering of Roaming, SoR）。

然而，这份“优选网络列表”如果以明文下发，可能会被中间网络（如漫游中转商IPX）或攻击者篡改，引导用户连接到恶意或昂贵的网络。6.14节就是为了解决如何安全地下发这份列表。

If the control plane solution for Steering of Roaming is supported by the HPLMN, the AUSF shall store the latest KAUSF after the completion of the latest primary authentication. The content of the Steering List… includes either a list of preferred PLMN/access technology combinations, a secured packet or the HPLMN indication that ‘no change…’ is needed…

核心思想：基于K_AUSF的端到端保护

  • 信任的根：SoR安全机制的信任根，是归属网络AUSF中存储的K_AUSF密钥。这个密钥是UE和HPLMN之间共享的、服务网络（VPLMN）无法触及的更高层级密钥。
  • 端到端保护：HPLMN使用K_AUSF对SoR列表进行完整性保护（生成一个MAC值），然后将列表和MAC值一起下发给UE。由于只有HPLMN和UE拥有K_AUSF，VPLMN和任何中间人都无法伪造或篡改这个MAC值。
  • 新鲜性保证：为了防止重放攻击（例如，攻击者重放一年前的旧SoR列表），该机制引入了一个在UE和AUSF之间同步的、专门用于SoR的计数器——SoR Counter。

SoR安全流程 (Figure 6.14.2.1-1)

场景代入： 安安抵达日本后开机，手机注册到了当地运营商A的网络。但安安的归属运营商（HPLMN）其实与运营商B有更优惠的漫游协议。于是，HPLMN决定向安安的手机下发一条SoR指令，引导她切换到运营商B。

  1. UE发起注册 (Step 1-3)：安安的手机在日本运营商A的网络成功完成主认证。
  2. HPLMN决策 (Step 7)：安安的HPLMN中的UDM在处理安安的注册信息时，发现她当前所在的网络（运营商A）并非最优选择。于是，UDM决定下发SoR信息。它准备好了新的“优选列表”（包含运营商B）。
  3. AUSF“加密打包” (Step 8-9)：UDM将这份列表和用户的SUPI，发送给AUSF，请求进行安全保护。AUSF执行以下关键操作：
    • 取出之前为安安存储的K_AUSF密钥。
    • 取出或更新SoR Counter的值。
    • 使用K_AUSF和SoR Counter，对包含“优选列表”的SoR内容计算出一个MAC值，我们称之为**SoR-MAC-IAUSF**。
  4. 下发“安全包裹” (Step 10-11)：AUSF将“优选列表”、SoR Counter和计算出的SoR-MAC-IAUSF，作为一个“SoR透明容器”，通过UDM→AMF→UE的路径，最终在Registration Accept消息中下发给安安的手机。这里的“透明容器”意味着中间的AMF无法也无需解析其内容。
  5. UE“开箱验货” (Step 12)：安安的手机收到这个“安全包裹”后：
    • 它也取出自己本地存储的K_AUSF。
    • 它检查收到的SoR Counter是否比自己本地存储的要新。如果是旧的，则认为是重放攻击，直接丢弃。
    • 如果计数器是新鲜的，它就用自己的K_AUSF和收到的SoR Counter，对“优选列表”执行完全相同的MAC计算。
    • 最后，比对自己计算出的MAC值与收到的SoR-MAC-IAUSF是否一致。
  6. 执行或确认 (Step 13-15)：如果MAC值一致，UE就确认这份列表是来自其归属网络的、未经篡改的合法指令。它会更新本地的优选网络列表，并在后续可能发起一次新的注册流程，尝试连接到运营商B。如果HPLMN要求“回执”（ACK），UE还会计算一个上行的MAC（SoR-MAC-IUE）在Registration Complete消息中返回，告知HPLMN指令已成功接收。

这个端到端的、基于K_AUSF和SoR Counter的保护机制，确保了HPLMN能够跨越不受信任的服务网络，对其漫游用户进行安全的“远程遥控”。

3. 总结

本章我们深入解读的6.13和6.14节，为我们展示了5G安全体系中两种不同层级、不同目的的“治理”手段。

  • PDCP COUNT检查 (6.13)：是一种RAN内部的、可选的、本地化的安全审计机制。它通过gNB与UE之间的周期性“对账”，为防止数据注入等攻击提供了额外的保障，更像是一种“微观治理”。
  • 漫游引导安全 (6.14)：是一种HPLMN主导的、跨网络的、端到端的策略控制机制。它利用比K_AMF更高一级的密钥K_AUSF，构建了一条穿越VPLMN的“保密通道”，确保了HPLMN对漫游用户的“宏观调控”指令能够安全、可靠地下达。

这两大机制，一个聚焦于无线链路的数据流细节，一个着眼于跨运营商的漫游策略，共同丰富了5G安全体系的内涵，使其不仅具备了坚固的防御能力，更拥有了灵活、智能的“治理”和“调控”手腕。

FAQ

Q1：既然UP完整性保护已经能防注入攻击，为什么还要设计PDCP COUNT检查这个“多余”的流程？ A1：这可能有几个原因：1) 历史遗留与补充：这个流程在早期的规范版本中就已经存在，可能当时对UP完整性保护的普及性和性能影响评估与现在不同。2) 审计与监控：它提供了一种独立于逐包校验的、周期性的审计方法。网络运维人员可以利用这个流程来监控特定UE或DRB的数据流量是否异常，作为一种网络性能监控和故障排查的辅助手段。3) 应对未来未知威胁：作为一种可选的额外安全层，它为应对未来可能出现的、能绕过单包完整性校验的新型攻击（尽管目前尚不存在）提供了一种潜在的防御机制。

Q2：漫游引导（SoR）安全机制为什么选择使用K_AUSF而不是K_SEAF或K_AMF？ A2：这是由SoR业务的性质决定的。SoR是归属网络（HPLMN）对其用户的直接策略控制，其内容和服务网络（VPLMN）无关，甚至VPLMN可能是被“引导”的对象。因此，这个过程必须是端到端的，即从HPLMN到UE，中间的VPLMN（包括其AMF/SEAF）都不能参与和知晓。K_SEAF和K_AMF都是由VPLMN的实体（SEAF/AMF）所持有的密钥，如果用它们来保护SoR，就无法实现对VPLMN的保密。而K_AUSF是UE与HPLMN的AUSF共享的、VPLMN无法触及的更高层级密钥，用它来保护SoR，可以完美地构建一条跨越VPLMN的、端到端的“保密通信管道”。

Q3：SoR Counter和NAS COUNT有什么区别？ A3：它们都是用于防重放的计数器，但服务于完全不同的安全协议和密钥。

  • NAS COUNT：与K_AMF绑定，用于保护UE和AMF之间的NAS信令。它的生命周期与K_AMF一致。
  • SoR Counter：与K_AUSF绑定，专门用于保护HPLMN的AUSF向UE下发的SoR数据。它的生命周期与K_AUSF一致，可能比K_AMF更长。 使用独立的计数器，确保了不同协议层、不同通信实体之间的安全状态不会相互干扰，遵循了严格的密钥和状态分离原则。

Q4：如果一个恶意VPLMN故意丢弃或阻止HPLMN下发的SoR消息，UE会知道吗？ A4：UE无法直接知道。SoR机制可以保证UE收到的SoR消息是真实、完整的，但无法保证它一定能收到。阻止消息是VPLMN可以做到的。但是，这种行为对VPLMN来说风险很高。首先，HPLMN可以通过分析其用户的后续选网行为，发现其SoR指令没有被执行，从而检测到VPLMN的不合作行为。其次，这种行为违反了运营商之间的漫游协议（SLA），可能会导致商业上的惩罚。因此，虽然技术上可能，但在商业上是不可行的。

Q5：除了漫游引导，还有其他功能使用K_AUSF进行端到端保护吗？ A5：是的。规范6.15节定义的**UE参数更新（UPU, UE Parameters Update）**机制，也使用了与SoR完全相同的安全模型。UPU允许HPLMN向UE安全地更新一些非接入层的配置参数，例如，更新UE的路由选择策略。与SoR一样，这个过程也需要HPLMN与UE之间的端到端安全，因此也使用了基于K_AUSF和独立的UPU Counter的保护机制。这体现了K_AUSF作为HPLMN与UE之间“最高级别信任通道”的通用性。

关系图谱