深度解析 3GPP TS 33.512：4.2.2.1.2 RES* verification failure handling (RES*校验失败处理)

本文技术原理深度参考了3GPP TS 33.512 V18.2.0 (2024-06) Release 18规范中，关于“4.2.2.1.2 RES* verification failure handling”的核心章节，旨在为读者深度剖析5G认证流程中另一关键异常——RES*校验失败的处理机制。

引言：一份错误的“答卷”

在上一篇文章中，我们的主角工程师李工成功地测试了“先锋通信”AMF在处理认证“同步失败”时的表现。用户小敏的手机与网络之间的“时空错乱”问题，通过AMF作为“忠实信使”的精准操作得到了解决。现在，认证流程进入了实质性的第二步：对答案。

网络向小敏的手机（UE）发送了一道“谜题”（RAND），手机的USIM卡利用其内部的神秘密钥（K）解开谜题，得出了一个“答案”，这个答案被称为RES*。手机将这份“答卷”——RES*——提交给网络。网络侧（主要是AUSF）会用同样的“谜题”和存储在UDM中的“标准答案生成器”（即用户的密钥K）计算出一个“标准答案”XRES*。

RES*校验，就是将UE提交的答案RES*与网络自己算出的标准答案XRES*进行比对。如果两者一致，证明“答卷人”确实是合法的USIM卡持有者，认证成功。但如果……这份答卷是错的呢？

这正是李工今天要模拟的场景。一份错误的RES*可能意味着多种情况：一个潜在的攻击者正在尝试猜测答案；UE的计算单元出现故障；甚至是信道中发生了数据篡改。无论原因为何，AMF作为安全流程的守门人，必须对此做出果断、正确且智能的反应。

1. 规范解读：AMF的“双轨制”应对策略

当RES*校验失败时，AMF不能简单地一拒了之。它的应对策略取决于一个关键的前提：发起这次注册的UE，用的是什么身份标识？是临时的5G-GUTI，还是永久的SUCI？规范对此制定了清晰的“双轨制”处理方案。

规范原文 4.2.2.1.2 Requirement Description:

“As specified in TS 33.501, clause 6.1.3.2.2…

• If the AUSF has indicated in the Nausf_UEAuthentication_Authenticate Response message to the SEAF that the verification of the RES* was not successful in the AUSF, or

• if the verification of the RES* was not successful in the SEAF,

then the SEAF either rejects the authentication by sending an Authentication Reject to the UE if the SUCI was used by the UE in the initial NAS message or the SEAF/AMF initiates an Identification procedure with the UE if the 5G-GUTI was used by the UE in the initial NAS message to retrieve the SUCI and an additional authentication attempt may be initiated.”

深度解析：

这段描述的核心思想是，RES*校验失败的信号可能来自两个地方：一是“上级领导”AUSF在比对答案后，明确告知AMF“答案错误”；二是AMF/SEAF自身也可能参与校验并发现错误。无论来源如何，AMF/SEAF的后续动作都遵循以下逻辑：

• 轨道一：SUCI注册 → 直接拒绝 (Authentication Reject)

  如果UE在最初的Registration Request中使用的是其永久身份的加密版——SUCI，那么一旦RES*校验失败，AMF的动作非常干脆：直接向UE发送Authentication Reject消息。整个认证过程宣告失败，UE被拒之门外。这背后的逻辑是：网络已经知道了这个UE的真实身份（SUCI），而这个身份无法证明自己，那么就没有必要再进行纠缠，直接拒绝是最安全、最高效的选择。

• 轨道二：5G-GUTI注册 → 发起身份识别 (Identification Procedure)

  如果UE使用的是临时的身份标识5G-GUTI，情况就变得微妙了。5G-GUTI是为了保护用户隐私而分配的临时ID，它本身并不暴露用户的永久身份。当一个使用5G-GUTI的设备提交了错误的RES*，网络会产生一个疑问：“这个持有临时门卡的人，到底是谁？”。此时，AMF不能只简单地拒绝，因为它需要剥开这层“临时马甲”，查明其背后的真实身份。因此，规范要求AMF发起一个身份识别流程（Identification Procedure），强制UE上报其SUCI。拿到SUCI后，AMF可以选择发起一次全新的、基于SUCI的认证流程，或者根据策略直接拒绝。

这个双轨制策略体现了5G安全设计的精妙之处：在身份明确时果断处置，在身份模糊时升级盘查。

规范还考虑了另一种异常情况：

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

“Also, if the SEAF does not receive any Nausf_UEAuthentication_Authenticate Response message from the AUSF as expected, then the SEAF either rejects the authentication to the UE or initiate an Identification procedure with the UE.”

深度解析：

这里描述了AUSF超时的场景。如果AMF将UE的RES*转发给AUSF进行校验，但AUSF由于故障或网络问题迟迟没有响应，AMF不能无限期地等待。在内部定时器超时后，AMF会将此视为一次认证失败。后续的处理逻辑与RES*明确校验失败时完全相同，依然遵循基于SUCI/5G-GUTI的“双轨制”策略。这保证了AMF在依赖的上游服务不可用时，依然能够独立地做出安全决策。

2. 测试场景：李工的“真假美猴王”大戏

李工将设计一系列精巧的测试用例，来验证“先锋通信”的AMF是否能在这场“真假美猴王”大戏中扮演好“火眼金睛”的角色。

2.1 Test Scenario A & C: SUCI注册失败的“铁面无私”

这个场景模拟一个身份明确的“冒牌货”。

• 场景设置：李工为他的UE模拟器设定了一个场景：小敏刚买了一部有些问题的“水货”手机，这部手机的USIM卡是真的，但手机的软件在计算RES*时存在一个Bug，总会算出一个错误的结果。手机第一次开机，没有5G-GUTI，因此它会使用SUCI发起注册。

• 执行步骤：

  1. UE模拟器向AMF发送Registration Request(SUCI)。

  2. AMF正常下发Authentication Request。

  3. UE模拟器因为Bug，计算并返回了一个**错误的RES***在Authentication Response中。

  4. AMF将此RES*转发给AUSF模拟器。李工配置AUSF模拟器进行校验，并返回Nausf_UEAuthentication_Authenticate Response，其中明确指示“RES*校验失败”。

  5. 【关键观测点】：李工紧盯着UE与AMF之间的N1接口。

• 预期结果：AMF在收到AUSF的失败指示后，必须立即向UE发送一条Authentication Reject消息。N1接口上不应该出现Identity Request消息。李工在UE模拟器的界面上看到“注册被拒绝”的提示，这证明AMF在处理SUCI注册失败时做到了“铁面无私”，测试通过。

2.2 Test Scenario B & D: 5G-GUTI注册失败的“刨根问底”

这个场景模拟一个身份模糊的“可疑人员”。

• 场景设置：这次，李工模拟一个攻击者。攻击者通过某种方式嗅探到了小敏的5G-GUTI（注意：他无法获取USIM卡密钥）。现在，攻击者想利用这个临时的5G-GUTI冒充小敏接入网络。

• 执行步骤：

  1. 攻击者的UE模拟器向AMF发送Registration Request(5G-GUTI)。

  2. AMF认为这是一个合法的移动性更新，向其下发Authentication Request。

  3. 攻击者没有合法的USIM卡，无法计算出正确的RES*，只能胡乱编造一个并返回。

  4. AUSF校验后，发现RES*错误，并通知AMF。

  5. 【关键观测点】：李工再次聚焦N1接口。

• 预期结果：这次，AMF的行为必须不同。它不能只发送Authentication Reject。正确的行为是，AMF应该向UE发送一条Identity Request消息，要求对方提供其永久身份SUCI。攻击者因为没有合法的USIM，无法响应或只能响应一个伪造的SUCI，最终依然会被拒绝。但AMF这个“刨根问底”的动作，完美地执行了规范要求的安全升级策略，测试通过。

2.3 Test Scenario E & F: AUSF超时的“独立决断”

这个场景考验AMF在“后援失联”时的应变能力。

• 场景设置：李工恢复使用小敏的正常手机进行注册，无论是用SUCI还是5G-GUTI，手机都能计算出正确的RES*。但是，李工这次将他的AUSF模拟器配置为“静默模式”，即收到AMF的校验请求后不作任何回应。

• 执行步骤：

  1. UE发起注册，AMF下发挑战，UE返回正确的RES*。

  2. AMF将RES*发给AUSF请求校验。

  3. AUSF模拟器“掉线”，不返回任何消息。AMF内部的超时定时器开始倒计时。

  4. 【关键观测点】：李工观察在定时器超时后，AMF的行为。

• 预期结果：定时器超时后，AMF必须将此视为认证失败。

  • 如果UE的初始注册是基于SUCI，AMF应发送Authentication Reject。

  • 如果UE的初始注册是基于5G-GUTI，AMF应发送Identity Request。

  这个结果证明，AMF的容错机制是完善的，它不会因为依赖的上游网元故障而陷入瘫痪或不安全的状态，而是能够独立地、安全地结束当前的认证事务。

通过这三场精心编排的大戏，李工成功地验证了“先锋通信”AMF在处理RES*校验失败时的所有逻辑分支，其表现精准、智能，完全符合3GPP的安全设计哲学。

---

FAQ 环节

Q1：RES*校验到底是在AMF/SEAF中完成，还是在AUSF中完成？

A1：两者都可能。3GPP TS 33.501定义了两种模式。在标准模式下，AMF/SEAF将UE的RES*转发给AUSF，由AUSF进行计算XRES*并完成比对。但规范也允许一种优化模式，即AUSF可以将XRES*连同认证向量一起提前下发给AMF/SEAF，由SEAF在本地直接进行比对。无论在哪一侧完成校验，当失败发生时，AMF/SEAF作为最终的决策执行点，其后续行为都必须遵循TS 33.512中定义的双轨制策略。

Q2：为什么对5G-GUTI注册失败要多一步“身份识别”，这有什么安全上的好处？

A2：这样做有多重好处。首先，它能有效地区分是合法用户偶然失败（比如瞬时信道干扰导致RES*传输出错）还是恶意攻击。对于前者，获取SUCI后可以重新发起认证，提升用户体验。其次，对于后者，它能将一个匿名的攻击尝试（使用临时GUTI）转化为一个暴露身份的事件（获取了其SUCI）。这为网络后续的追踪、告警和黑名单机制提供了关键线索，极大地提升了网络的安全审计和防御能力。

Q3：RES*和RES有什么区别？为什么5G要用带星号的RES*？

A3：RES是3G/4G时代的产物，它仅仅是USIM卡对RAND进行密码学计算的结果。而5G中使用的RES*是RES的增强版。RES*的计算不仅涉及到RES，还引入了更多的参数，如网络名称（Serving Network Name），以确保计算出的结果与特定的服务网络绑定。这增强了安全性，可以抵御一些跨网络的攻击，确保UE的响应是针对当前服务的网络，而不是被欺骗为另一个网络生成。

Q4：在现实世界中，一个合法的UE有没有可能算出错误的RES*？

A4：理论上，如果USIM卡和手机的硬件是完好的，这是极不可能发生的，因为密码学算法是确定性的。但现实中仍有几种罕见可能：1）手机的基带芯片或固件存在Bug，导致算法实现错误。2）USIM卡物理损坏，导致计算单元出错。3.）极强的电磁干扰导致传输过程中RES*数据位翻转。尽管罕见，但网络侧必须具备处理这种异常的能力。

Q5：测试工程师如何在一个黑盒的AMF产品上验证这些行为？

A5：测试工程师通常会使用专业的测试仪表或模拟器来扮演UE、gNB和核心网的其他网元（如AUSF, UDM）。通过控制这些模拟器，可以精确地构造出各种场景。例如，UE模拟器可以被编程为发送任意指定内容的RES*（包括正确的和错误的）。AUSF模拟器可以被配置为返回特定的失败原因，或者干脆不响应。通过在N1（UE-AMF）和N12（AMF-AUSF）接口上进行抓包分析，就可以精确地观测到被测AMF的行为是否与规范的预期结果一致。