深度解析 3GPP TS 33.512：4.2.2.1.1 Synchronization failure handling (同步失败处理)

本文技术原理深度参考了3GPP TS 33.512 V18.2.0 (2024-06) Release 18规范中，关于“4.2.2.1.1 Synchronization failure handling”的核心章节，旨在为读者提供一个关于5G认证过程中关键异常处理机制的全景视图。

引言：当认证流程遭遇“时空错乱”

在我们的系列解读中，工程师李工已经铺开了针对“先锋通信”AMF的“作战地图”。现在，他将打响第一场关键战役：认证与密钥协商流程（Authentication and key agreement procedure）。这是UE进入5G网络的第一道“安检门”，其安全性至关重要。

今天，李工要模拟一个非常特殊但又极其重要的场景——“同步失败”（Synchronization Failure）。让我们引入今天场景的另一位主角，一位名叫小敏的普通5G用户。小敏刚刚从一次长途飞行中落地，打开了她的手机。手机尝试注册到本地网络，此时，一场看不见的“时空对话”在她的手机和网络核心之间展开了。

在5G AKA（认证与密钥协商）流程中，为了防止重放攻击，网络和UE的USIM卡内部都维护着一个同步的序列号（Sequence Number, SQN）。网络下发的认证质询（AUTN）中包含了网络侧认为的SQN。UE收到后会进行校验，如果发现网络下发的SQN不是“更新”的（即小于或等于自己存储的SQN），或者AUTN的MAC校验失败，UE就会判断发生了“同步失败”。这可能意味着网络侧的数据出现了回滚，或者更糟，UE正在遭受一次重放攻击。

此时，UE不会继续认证，而是会向网络发送一个“同步失败”信号，并附带一个名为AUTS（Authentication Synchronization Token）的参数。AUTS中包含了UE侧正确的SQN信息。AMF在收到这个特殊的“求救信号”后，将如何正确、安全地处理，正是李工今天要测试的核心。

1. 规范解读：AMF作为“信息中继官”的职责

面对同步失败，AMF（更准确地说是其内部的SEAF逻辑功能）的角色不是“法官”，而是“信使”。它自身不具备解决同步问题的能力（因为处理SQN和生成认证向量所需的长期密钥存储在UDM/ARPF中），它的核心职责是忠实、安全地将问题转发给有权处理的上级——AUSF。

规范原文 4.2.2.1.1 Requirement Description:

“As specified in TS 33.501 clause 6.1.3.3.2, upon receiving an authentication failure message with synchronisation failure (AUTS) from the UE, the SEAF sends an Nausf_UEAuthentication_Authenticate Request message with a synchronisation failure indication to the AUSF and the AUSF sends an Nudm_UEAuthentication_Get Request message to the UDM/ARPF, together with the following parameters:

• RAND sent to the UE in the preceding Authentication Request, and

• AUTS received by the SEAF in the response from the UE to that request, as described in clause 6.1.3.2.0 and 6.1.3.3.1 of TS 33.501.”

深度解析：

这段描述清晰地定义了一条三步走的“上报处理链”：

1. 触发点 (UE → AMF/SEAF)：当AMF/SEAF从UE收到了一个包含AUTS的Authentication Failure消息时，整个流程被触发。这就是小敏手机发出的“时空错乱”信号。

2. 第一级转发 (AMF/SEAF → AUSF)：AMF/SEAF并不会尝试去解析AUTS。它的唯一标准动作是，立即打包一个Nausf_UEAuthentication_Authenticate Request消息给AUSF。这个消息里必须明确包含一个“同步失败指示”，并附上从UE收到的AUTS和之前下发给UE的RAND。AMF就像一个基层联络员，发现问题后立刻填写标准报告单，上报给部门主管AUSF。

3. 第二级转发与处理 (AUSF → UDM/ARPF)：AUSF作为安全部门主管，收到报告后识别出是同步问题，它会将问题继续上报给最终的“档案管理员”——UDM/ARPF。UDM/ARPF利用长期密钥，解开AUTS，验证其有效性，并用其中的SQN来重新同步自己的记录，然后生成一个新的、同步的认证向量返回。

除了这个“上报”的主流程，规范还定义了两个关键的“防御性”要求，李工对此格外关注，因为这正是考验AMF健壮性的地方。

规范原文 4.2.2.1.1 Requirement Description (cont.):

“An SEAF will not react to unsolicited “synchronisation failure indication” messages from the UE.

The SEAF does not send new authentication requests to the UE before having received the response to its Nausf_UEAuthentication_Authenticate Request message with a “synchronisation failure indication” from the AUSF (or before it is timed out)..”

深度解析：

1. “不理睬未经请求的失败消息”：这个要求是为了防止一种潜在的DoS（拒绝服务）攻击。如果一个已注册的合法UE（比如小敏的手机正在正常上网），一个攻击者冒用其身份向AMF发送一个伪造的、不请自来的Authentication Failure(AUTS)消息。如果AMF处理了这个消息，可能会错误地启动重同步流程，甚至干扰到合法的通信。因此，规范要求AMF必须忽略这种“没头没脑”的失败消息。只有在AMF主动发起了一次认证，并且正在等待响应的“事务窗口”内收到的失败消息，才是合法的。

2. “必须等待上级批复”：这个要求确保了流程的原子性和状态的正确性。AMF在上报了同步失败问题给AUSF后，必须“耐心等待”，直到收到AUSF的响应（无论是成功还是失败），或者等待超时。在此期间，AMF不能自作主张地向UE发起新的认证请求。这避免了网络中出现多个悬而未决、相互冲突的认证流程，保证了状态机的一致性。

2. 测试场景：李工的三重考验

理论学习完毕，李工卷起袖子，开始在测试平台上对“先锋通信”的AMF进行实战检验。他设计了三个测试用例，分别对应规范中的“正确处理流程”、“超时处理”和“非法消息丢弃”。

2.1 Test Case A：验证标准重同步流程

这是对AMF作为“忠实信使”的基本考验。

• 场景设置：李工配置他的UE模拟器（模拟小敏的手机）和AUSF/UDM模拟器。他首先在UDM模拟器中设置一个“过时”的SQN，确保AMF从它那里获取的第一个认证向量必然会导致同步失败。

• 执行步骤：

  1. 李工触发UE模拟器向AMF发起Registration Request。

  2. AMF按流程向AUSF/UDM请求认证向量，并向UE发送了包含“过时”SQN的Authentication Request。

  3. UE模拟器检测到SQN错误，计算出AUTS，并将其包含在Authentication Failure消息中返回给AMF。

  4. 【关键观测点】：李工立刻聚焦于AMF与AUSF之间的N12接口。他使用抓包工具（如Wireshark）捕获流量，必须看到AMF发出了一条Nausf_UEAuthentication_Authenticate Request消息，该消息中不仅包含了从UE收到的AUTS，还有一个明确的synchronisation failure indication标志。

  5. 李工的AUSF/UDM模拟器被配置为“合作模式”，它收到重同步请求后，立刻生成一个新的、正确的认证向量并返回给AMF。

• 预期结果：测试通过的标志是，AMF在收到来自AUSF的新认证向量后，应立即向UE发起第二次 Authentication Request。李工的UE模拟器收到这个新的请求，验证通过，认证成功。这证明AMF完整、正确地执行了重同步的上报和触发流程。

2.2 Test Case B：验证超时等待机制

这个测试考验AMF在“上级领导”无响应时的耐心和状态管理能力。

• 场景设置：基本设置同Test Case A，但这次，李工将他的AUSF/UDM模拟器设置为“不合作模式”。

• 执行步骤：

  1. 重复Test Case A的前4步。AMF成功地将同步失败问题上报给了AUSF。

  2. 【关键观测点】：李工的AUSF模拟器收到请求后，选择“沉默”，不作任何回应。此时，李工开始掐表，同时密切监视AMF与UE之间的N1接口。他知道，AMF内部的NAS定时器T3520已经启动。

• 预期结果：在定时器T3520超时之前，被测AMF绝对不能向UE发送任何新的Authentication Request。它必须静静等待。直到超时后，AMF可能会选择放弃本次注册（发送Registration Reject）或进行重试，但关键在于等待期间的“沉默”。这证明了AMF遵循了“必须等待上级批复”的原则，没有造成流程混乱。

2.3 Test Case C：验证对非法消息的防御力

这是对AMF安全性的压力测试，考验它面对恶意骚扰时的“定力”。

• 场景设置：李工首先让UE模拟器完成一次正常的注册，使其处于已连接的REGISTERED状态。

• 执行步骤：

  1. 在没有任何认证流程正在进行的情况下，李工突然从UE模拟器向AMF发送一个“不请自来”的Authentication Failure(AUTS)消息。这模拟了攻击者试图干扰合法用户的场景。

  2. 【关键观测点】：李工同时监视AMF的内部日志和其与AUSF的N12接口。

• 预期结果：一个健壮的AMF应该对这个消息“视而不见”。其日志中可能会记录一条“收到意外消息”的调试信息，但它绝不能将这个同步失败请求转发给AUSF。N12接口上必须一片沉寂。UE的正常通信状态也不应受到任何影响。这证明AMF成功地抵御了这种“垃圾信息”攻击。

通过这三重考验，李工对“先锋通信”AMF的同步失败处理机制有了全面而深刻的评估。它不仅要“会办事”，还要“能扛事”，在复杂的网络环境下保持清醒和稳健。

---

FAQ 环节

Q1：为什么AMF（SEAF）自己不直接处理同步失败，而要转发给AUSF？

A1：这是5G核心网安全架构中“职责分离”原则的体现。AMF/SEAF是安全流程的“执行者”和“锚点”，但它不持有用于生成认证向量的长期密钥（K）。这个最敏感的密钥安全地存储在UDM/ARPF中。AUSF是专门处理认证服务的“专家”，UDM是用户数据的“最终权威”。因此，只有AUSF和UDM才有能力和权限去验证AUTS并重新同步SQN。AMF的职责就是安全、可靠地进行消息转发。

Q2：AUTS参数里到底包含了什么？

A2：AUTS (Authentication Synchronization Token) 主要由两部分构成：一部分是 SQN_MS ⊕ AK，即UE的USIM卡认为正确的序列号（SQN_MS）用匿名密钥（AK）进行加密后的结果；另一部分是基于RAND、SQN_MS等计算出的MAC值（MAC-S），用于保证AUTS本身的完整性和真实性，证明它确实是由持有正确密钥的USIM卡生成的。

Q3：在现实网络中，什么情况下最容易发生同步失败？

A3：除了网络攻击，常见的场景包括：1）网络侧数据库恢复到了一个旧的备份，导致SQN回滚。2）UE长时间处于关机或无信号状态，期间网络侧（如因维护操作）多次尝试寻呼或隐式注销该UE，可能导致网络侧SQN大幅跳跃，而UE侧SQN保持不变，当UE重新开机时，网络下发的第一个认证向量就可能被UE认为是“过时”的。3.）UE在不同运营商网络漫游，各网络对SQN的管理机制差异也可能导致同步问题。

Q4：Test B中提到的NAS定时器T3520是什么？它的超时值一般是多久？

A4：T3520是在AMF发送Authentication Request后启动的一个守护定时器。它的作用是等待UE回应Authentication Response/Failure。规范中虽然没有强制规定其具体值，但通常建议在几秒到十几秒的量级（例如12秒）。在同步失败的场景中，这个定时器被巧妙地复用为等待AUSF响应的超时定时器。如果在这个时间内整个重同步流程没有完成，AMF就会认为本次认证事务失败。

Q5：如果攻击者伪造AUTS并成功让网络重同步，会发生什么？

A5：这几乎不可能发生。因为AUTS中包含了用USIM卡和UDM共享的长期密钥派生出的密钥（AK和MAC密钥）进行加密和完整性保护的部分。攻击者没有这个长期密钥，就无法计算出合法的AUTS。UDM/ARPF在收到AUTS后会进行严格的校验，一个伪造的AUTS会立即被识别并丢弃。因此，这个重同步机制本身是安全的。