51学通信

深度解析 3GPP TS 33.514：4.2.2 认证程序的健壮性 (同步失败处理与状态存储)

19分钟阅读

深度解析 3GPP TS 33.514：4.2.2 认证程序的健壮性 (同步失败处理与状态存储)

本文技术原理深度参考了3GPP TS 33.514 V18.3.0 (2024-06) Release 18规范中，关于“4.2.2 Authentication and key agreement procedure”及其子章节“4.2.2.1 Synchronization failure handling”与“4.2.2.2 Storing of authentication status of UE by UDM”的核心内容。本文将带您深入探讨，在成功解密用户身份之后，UDM如何处理认证过程中的“意外”与“后续”，以确保5G认证机制既能从异常中恢复，又具备完整的可追溯性。

“保险库”的核心业务：密码验证的鲁棒性与可审计性

在上一篇的实战中，新人工程师小王在导师陈姐的指导下，成功为“IdentiCore-UDM”产品安装了第一道精密门锁——SUCI解密模块。这道门锁不仅能为合法用户打开大门，更能抵御各种“有毒”和“非标”的恶意SUCI攻击。小王觉得，既然已经能准确识别用户的真实身份，UDM的核心安全工作就完成了一大半。

陈姐看出了小王的想法，她笑了笑，提出了两个新的、更贴近现实运营的挑战：“小王，我们的‘保险库’现在有了一流的门禁系统。但现实世界充满了意外。设想一下：一位持有顶级VIP卡的客户‘刘总’来访，他的VIP卡（USIM）因为某种原因，内部的计数器与我们银行（网络）的记录发生了偏差。我们的门禁系统‘对不上暗号’，直接把他拒之门外，这将是一场灾难。这是第一个挑战：健壮性，即如何从这种‘同步失败’中优雅地恢复。”

“第二个挑战，”陈姐继续说道，“刘总成功进入保险库后，我们的安保系统必须在一本‘绝密日志’上精确记录：‘刘总，于X年X月X日X时X分，通过了身份验证，成功进入。’如果这本日志记录不下来，或者记错了，一旦未来发生任何安全事件，我们将无法追溯和取证。这就是可审计性。今天，我们的任务就是为‘IdentiCore-UDM’加上这两项至关重要的能力：处理同步失败和存储认证状态。”

1. 同步失败处理 (4.2.2.1)：“对不上暗号”时的智能恢复

这是对UDM认证程序健壮性的核心考验，确保网络不会因为可恢复的异常而错误地拒绝合法用户。

1.1 威胁：当“一次性密码”发生漂移

5G AKA认证过程，类似于使用一个动态口令牌。USIM卡和网络中的UDM/ARPF都维护着一个同步的、单向递增的序列号（SQN）。网络每次发起认证，都会使用一个新的SQN。USIM卡会校验收到的SQN是否在预期的窗口内，以此来防范重放攻击。

**同步失败（Synchronization Failure）就发生在这个SQN上。比如，UE因为异常掉电，没能成功完成一次认证，但网络侧的SQN已经增加了。当UE下次再用旧的SQN来验证网络时，就会失败。此时，UE不会简单放弃，而是会向网络发送一个包含AUTS（Authentication Resynchronization Token）**的特殊响应。

AUTS是用USIM密钥计算出的，它向网络证明：“我是合法的，不是攻击者。但我们之间的SQN确实‘漂移’了，请根据我提供的信息来重新校准你的SQN。”

1.2 规范原文

4.2.2.1 Synchronization failure handling Requirement Name: Synchronization failure handling Requirement Reference: TS 33.501, clause 6.1.3.3.2. Requirement Description: When the UDM/ARPF receives an Nudm_UEAuthentication_Get Request message with a “synchronisation failure indication” it acts as described in TS 33.102, clause 6.3.5 where ARPF is mapped to HE/AuC. The UDM/ARPF sends an Nudm_UEAuthentication_Get Response message with a new authentication vector… Threat References: TR 33.926, clause E.2.2.2, Synchronization failure.

Test Case: Test Name: TC_SYNC_FAILURE_HANDLING_UDM Purpose: Verify that synchronization failure is recovered correctly in the home network.

1.3 深度解读与测试实践

需求解读 (The “What” and “Why”)

  • 核心要求：当UDM收到一个带有“同步失败指示”的认证请求（其中包含了UE计算的AUTS）时，它绝不能简单地拒绝。它必须触发重同步程序。
  • 重同步程序：
    1. UDM首先要用存储的根密钥来验证AUTS的合法性。这一步是为了确保这个请求确实是来自合法的USIM卡，而不是攻击者伪造的。
    2. 如果AUTS验证通过，UDM会从中提取出UE侧正确的SQN，用它来更新自己数据库中的SQN，从而完成“重新校准”。
    3. 最后，UDM必须基于这个新的、同步后的SQN，生成一个全新的认证向量（AV），并将其发送给AUSF，以便网络能立即用这个新AV与UE重试认证。
  • 为何重要？ 陈姐解释道：“如果UDM没有这个能力，刘总的手机一旦发生同步失败，他就会被永久锁定在网络之外，除非他去营业厅换卡。这对用户体验是毁灭性的。一个健壮的认证系统，必须具备从这种常见异常中自我恢复的能力。”

测试用例解读 (The “How to Verify”)

  • 目标 (Purpose)：验证UDM能够正确地从同步失败中恢复。
  • 执行步骤 (Execution Steps)：
    1. 测试工具模拟AUSF，向UDM的Nudm_UEAuthentication_Get服务接口发送一个精心构造的请求。这个请求的关键在于：它包含synchronisation failure indication，以及一个由测试工具预先计算好的、合法的RAND和AUTS参数。
    2. UDM接收到这个请求后，应执行上述的重同步程序。
  • 预期结果 (Expected Results)：
    • UDM服务必须保持稳定，不能因为这个特殊请求而出现异常或崩溃。
    • UDM返回的Nudm_UEAuthentication_Get Response消息必须是成功的，并且其中包含一个全新的认证向量。
    • 测试人员可以进一步解析这个新的认证向量，验证其内部的SQN是否已经基于AUTS进行了正确的更新。

2. 存储认证状态 (4.2.2.2)：为每一次“开锁”行为留下铁证

认证成功，用户进入网络。但故事并未结束。一个负责任的“保险库”，必须记录下每一次成功的访问。

2.1 威胁：无法追溯的安全“悬案”

陈姐向小王描绘了一个场景：“安全审计团队发现，刘总的账户在凌晨3点有异常的漫游数据流量。他们来找我们，要求核实刘总当时是否真的通过了我们网络的认证。如果我们UDM的日志系统一片空白，或者记录不全，会怎么样？”

小王回答：“那这将成为一桩‘悬案’。我们无法判断这是刘总的真实行为，还是他的身份被盗用。我们无法为调查提供任何证据，也无法改进我们的安全策略。这在安全合规上是绝对不允许的。”

2.2 规范原文

4.2.2.2 Storing of authentication status of UE by UDM Requirement Name: Storing of authentication status of UE by UDM. Requirement Reference: TS 33.501, clause 6.1.4.1a Requirement Description: The UDM stores the authentication status of the UE (SUPI, authentication result, timestamp, and the serving network name) after authentication as specified in TS 33.501, clause 6.1.4.1a. Threat References: TR 33.926, clause E.2.2.3, Failure to store of authentication status.

Test Case: Test Name: TC_AUTH_STATUS_STORE_UDM Purpose: Verify that the UDM under test stores the authentication status of UE…

2.3 深度解读与测试实践

需求解读 (The “What” and “Why”)

  • 核心要求：在每一次认证流程结束后，UDM必须存储该UE的认证状态。
  • 存储四要素：规范明确规定了必须记录的四个关键信息，构成了一个完整的证据链：
    1. SUPI：谁被认证了。
    2. Authentication result：认证结果如何（成功/失败）。
    3. Timestamp：认证发生的时间。
    4. Serving network name：认证发生时，用户在哪个网络（例如，归属网络，或漫游到的某个国外运营商网络）。
  • 为何重要？ 这份日志是网络安全运营的基石，它服务于：
    • 安全审计与合规：满足法律法规和行业标准对可追溯性的要求。
    • 威胁检测：通过分析认证日志，可以发现异常模式，如不可能的快速移动（短时间内在两个相距遥远的地点认证成功）、暴力破解尝试（大量失败的认证记录）等。
    • 故障排查与争议解决：当用户申诉无法接入网络或质疑账单时，这份日志是定位问题和解决争议的权威依据。

测试用例解读 (The “How to Verify”)

这是一个典型的“端到端状态验证”测试，比之前的API调用测试更复杂。

  • 执行步骤 (Execution Steps)：
    1. 执行并捕获：首先，完整地执行一次成功的5G AKA认证流程。同时，使用抓包工具捕获N12 (AMF-AUSF) 和 N13 (AUSF-UDM) 接口上的所有交互报文。
    2. 提取“地面实况” (Ground Truth)：从捕获的报文中，人工或通过脚本精确地提取出本次认证的“四要素”：
      • SUPI：通常在Nudm_UEAuthentication_Get Response中。
      • Authentication result：通常在AMF与UE交互后的Nausf_UEAuthentication_Authenticate Response中体现为EAP-success或类似结果。
      • Serving network name：在Nudm_UEAuthentication_Get Request中由AUSF上报。
      • Timestamp：以认证流程结束的时间为准。
    3. 访问“黑盒”：通过某种后台机制（如数据库查询、专用维护接口、日志文件导出），访问并获取UDM为该SUPI存储的最新一条认证状态记录。
    4. 最终比对：将从UDM内部获取的记录，与我们从网络报文中提取的“地面实况”进行逐一比对。
  • 预期结果 (Expected Results)：UDM中存储的SUPI、认证结果、时间戳和网络名称，必须与网络上实际发生的情况完全一致。任何一项的缺失或错误，都意味着测试失败。

总结：健壮与尽责，认证程序的“一体两面”

通过今天对4.2.2节的深入学习，小王对UDM的安全职责有了更深刻的理解。他认识到，一个顶级的“数字保险库”，不仅要在“开门”这一个瞬间做到极致安全，更要具备两种宝贵的品质：

  1. 健壮（Robust）：面对“VIP客户忘带钥匙”这类意外情况，它不能粗暴地拒绝，而是要有一套智能、安全的恢复流程，确保服务的连续性。这就是同步失败处理的精髓。
  2. 尽责（Accountable）：它必须对自己的每一次操作负责，为每一次“开门”行为都留下不可磨灭的、精确的记录。这就是存储认证状态的核心。

健壮性保证了认证服务的可用性，而可审计性则保证了认证过程的可追溯性。这两者共同构成了5G认证程序除基础安全性之外，最重要的两大支柱，确保了整个体系在真实、复杂的网络环境中，既可靠，又可信。

FAQ 环节

Q1：什么是AUTS？它为什么能安全地用于重同步？ A1：AUTS (Authentication Resynchronization Token) 是由UE的USIM卡在检测到SQN同步失败后计算出来的一个值。其计算输入包括了网络下发的随机数RAND和USIM卡自己的密钥K以及它期望的SQN。当UDM收到AUTS后，它会用自己存储的同一个K和RAND进行反向计算和校验。只有合法的USIM卡才能计算出正确的AUTS。因此，AUTS本身既传递了UE期望的SQN信息，又自带了“防伪标识”，确保了这个重同步请求是可信的。

Q2：存储用户的认证状态，会不会因为数据量太大而给UDM/UDR带来存储压力？ A2：确实会产生大量数据，但这在设计时就已经被充分考虑。首先，UDR作为专用的数据存储层，其设计目标就是支持海量数据的存储和高并发读写。其次，运营商会制定精细的数据管理策略，例如，认证日志可能会被分级存储，近期的热数据存在高性能存储中，数月前的冷数据则会被归档到成本更低的存储介质上，并设置一个保留期限（如1年），过期后自动清理。

Q3：测试用例TC_AUTH_STATUS_STORE_UDM看起来非常依赖对UDM内部数据的访问。如果厂商不提供这种访问接口怎么办？ A3：这是一个现实问题。在SCAS认证或运营商的入网测试中，设备商通常有义务提供必要的“可测性”接口或工具，以便测试方能够验证其内部状态是否符合规范要求。这可能是一个受严格权限控制的CLI命令、一个专用的测试API、或者一套日志分析工具。如果一个产品无法以任何方式证明其内部正确地存储了认证状态，那么它就无法通过这项测试。

Q4：同步失败是一个常见的现象吗？ A4：在正常运营的网络中，它不应该频繁发生，但也不是极其罕见。它可能由多种原因触发，如UE的非正常关机、短暂的无线链路中断导致信令丢失、或者USIM卡的轻微缺陷等。虽然不频繁，但考虑到5G网络巨大的用户基数，即使发生概率很低，每天实际发生的案例也可能有成千上万。因此，一个能自动处理该问题的健壮机制，对于保障网络稳定和减少运维成本至关重要。

Q5：认证状态中存储的“serving network name”有什么具体的安全价值？ A5：它的安全价值巨大。这个字段记录了用户认证时所在的网络（是本地网，还是漫游到了哪个国家、哪个运营商）。在安全分析中，它可以用来：1) 检测漫游欺诈。2) 发现不可能的漫游行为，例如，一个用户的SUPI在5分钟内，先后在美国和日本的网络中都认证成功，这显然是一个身份被盗用的强烈信号。3) 进行地理位置相关的风险评估。

关系图谱