好的,我们继续对3GPP TS 33.401第七章的深度拆解。在上一篇中,我们详细剖析了SMC流程,也就是激活所有安全保护的“总开关”。现在,安全机制已经启动,UE和网络都已“穿上盔甲”。然而,在一部手机漫长的使用周期中,它的大部分时间并非处于高速数据传输的“战斗”状态,而是在口袋里静静待命的“休眠”状态。

本文将聚焦于7.2.5至7.2.7节,深入探讨UE在各种核心状态转换——从休眠到唤醒、从连接到分离、在城市中穿梭——的过程中,其背后的密钥是如何被精妙地创造、使用、销毁和保存的。这几节是理解4G网络移动性管理和功耗管理中安全机制的关键。

深度解析 3GPP TS 33.401:7.2.5-7.2.7 UE状态转换中的密钥乾坤

本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中,关于“7.2.5 Key handling at state transitions to and away from EMM-DEREGISTERED”、“7.2.6 Key handling in ECM-IDLE to ECM-CONNECTED…”和“7.2.7 Key handling for the TAU procedure…”的核心章节,旨在为读者揭示UE在不同生命周期状态下的密钥管理策略。

我们的主角“小明”正坐在咖啡馆里,他刚刚用手机回复完一封邮件。现在,他按下了手机的锁屏键,屏幕随之暗淡。对小明来说,这只是一个简单的动作,但对他的手机和网络而言,这意味着一次重要的状态转换。手机将从高速运转的连接态(ECM-CONNECTED)进入节能的空闲态(ECM-IDLE)

这一“动”一“静”之间,以及后续的再次唤醒、跨区移动、乃至最终关机,其背后都有一套严谨的密钥处理规则在默默运行,确保安全与效率的完美平衡。

1. 动静之间:连接态与空闲态的密钥之舞 (7.2.6 Key handling in ECM-IDLE to ECM-CONNECTED and ECM- CONNECTED to ECM-IDLE transitions)

这是UE最常见的两种状态,也是本节的重点。ECM代表EPS Connection Management,即连接管理。

  • ECM-CONNECTED:连接态。此时UE与eNB之间有活跃的RRC连接,可以随时高速收发数据。这就像小明正在与朋友热聊的电话线路。

  • ECM-IDLE:空闲态。UE没有活跃的RRC连接,但已在核心网MME注册。网络知道UE在哪一片区域(一组小区的集合,即Tracking Area),但不知道它具体在哪一个小区。这就像电话挂断了,但双方都知道对方的电话号码,随时可以再打过去。UE进入此状态是为了省电。

1.1 从静到动:IDLE CONNECTED 的密钥唤醒 (7.2.6.1 ECM-IDLE to ECM-CONNECTED transition)

小明想起了要给朋友发一张照片。他点亮屏幕,打开微信,点击发送。这个动作触发了手机从ECM-IDLEECM-CONNECTED的转换。

The UE sends an initial NAS message to initiate transition from ECM-IDLE to ECM-CONNECTED state.

这个“初始NAS消息”通常是Service Request。UE此时需要建立RRC连接和数据承载,才能把照片发出去。空口安全(AS安全)必须在此刻被重新激活。这意味着,需要生成一个全新的KeNB

Upon receipt of the NAS message, if the MME does not require a NAS SMC procedure…, the MME shall derive key KeNB as specified in clause A.3 using the NAS COUNT corresponding to the NAS message and the KASME of the current EPS NAS security context.

深度解读

  1. 触发:UE发送的Service Request信令(该信令本身由NAS密钥保护)是激活AS安全的“扳机”。

  2. KeNB的诞生:MME收到该请求后,立刻执行KeNB的派生。正如我们在6.2节学到的,KeNB的诞生需要两个关键输入:

    • KASME:当前会话的根密钥,它在IDLE状态下一直被UE和MME安全地保存着。

    • 新鲜度参数:就是这条Service Request消息自己的上行NAS COUNT

这个设计再次体现了NAS COUNT作为“新鲜度源泉”的关键作用。它确保了小明每次从空闲态唤醒手机,都会生成一个与以往完全不同的KeNB,从根本上杜绝了密钥重用。

The MME shall communicate the KeNB to the serving eNB in the S1-AP procedure INITIAL CONTEXT SETUP. The UE shall derive the KeNB from the KASME of the current EPS NAS security context.

深度解读

  • MME侧:计算出KeNB后,通过INITIAL CONTEXT SETUP消息将其安全地发送给eNB。

  • UE侧:UE也使用完全相同的KASMENAS COUNT,在本地独立计算出同一个KeNB

至此,UE和eNB再次共享了一个全新的KeNB。随后,eNB会发起AS SMC流程(如7.2.4节所述),双方协商好AS算法,并各自用KeNB派生出KRRC/KUP密钥,空口安全保护被全面激活,小明的照片得以安全地发送出去。

前向安全的“伏笔”:NH的派生

The MME shall further derive a next hop parameter NH as specified in clause A.4 using the newly derived KeNB and the KASME as basis for the derivation.

深度解读:在MME派生出KeNB的同时,它还会“多做一步”,立刻用KASME和这个新鲜的KeNB派生出一个NH(Next Hop)密钥。这个NH是为未来可能发生的、需要MME介入的S1切换准备的“备用种子”,它为切换提供了“前向安全”保障。这个新NH会被MME存储起来,以备不时之需。

1.2 从动到静:CONNECTED IDLE 的密钥休眠 (7.2.6.3 ECM-CONNECTED to ECM-IDLE transition)

小明发送完照片,再次锁屏。一段时间没有数据传输后,eNB决定释放他的RRC连接,让他回到ECM-IDLE状态以节省电量。

On ECM-CONNECTED to ECM-IDLE transitions the eNB does no longer need to store state information about the corresponding UE.

In particular, on ECM-CONNECTED to ECM-IDLE transitions:

  • The eNB and the UE shall release all radio bearers and delete the AS security context.
  • MME and the UE shall keep the EPS NAS security context stored…

深度解读:这是理解AS与NAS安全分离的关键所在。

  • AS安全上下文被删除:一旦进入IDLE状态,UE和eNB之间的RRC连接断开。eNB会删除所有与该UE相关的AS安全上下文,包括KeNB及其派生的所有KRRCKUP密钥。UE也会执行同样的操作。KeNB的生命周期,随着RRC连接的释放而结束。 这就像电话挂断后,电话局的交换机就释放了为这次通话建立的临时电路。

  • NAS安全上下文被保留:与此同时,UE和MME会继续保留NAS安全上下文,包括KASMENAS COUNTGUTI等。KASME的生命周期并未结束。 这就像电话虽然挂断了,但双方的电话号码(身份)和信任关系依然存在。

这种“动静分离”的设计,既保证了eNB侧的轻量化(无需为海量的空闲用户保留状态),又保证了UE再次唤醒时,能够基于保留的NAS上下文快速恢复安全连接,实现了效率与安全的完美统一。

2. 跨区穿行:TAU过程中的密钥处理 (7.2.7 Key handling for the TAU procedure when registered in E-UTRAN)

TAU (Tracking Area Update) 本质上也是一种从IDLECONNECTED的转换,但其触发原因并非用户发起业务,而是UE在IDLE状态下移动到了一个新的跟踪区(Tracking Area)。

Before the UE can initiate the TAU procedure, the UE needs to transition to ECM-CONNECTED state. The UE shall use the current EPS security context to protect the TAU Request…

深度解读:当UE发现当前小区的TA(Tracking Area)与自己存储的TA不同时,它会发起TAU流程。它发送的TAU Request消息,本身就是一条NAS消息,因此必须使用当前有效的KNASint进行完整性保护。

If the “active flag” is set in the TAU request message or the MME chooses to establish radio bearers… a KeNB derivation is necessary… the uplink NAS COUNT of the TAU request message … is used as freshness parameter in the KeNB derivation…

深度解读:这段话揭示了TAU流程中KeNB的派生逻辑,它与Service Request触发的流程完全一致

  • KeNB的派生:同样,KeNB也是由**KASME + TAU Request消息的上行NAS COUNT** 派生而来。

  • “active flag”:这是一个在TAU请求中的标志位。如果UE在发起TAU的同时,正好有数据要发送(例如,小明在地铁上边移动边聊微信),它就会置起这个“active flag”。MME看到这个标志,就知道在完成TAU之后,需要立即为UE建立数据承载,因此会触发KeNB的派生。如果该标志未置位,但MME发现有下行数据在等待UE,MME同样会触发KeNB的派生。

3. 终极的告别与重逢:注册与注销状态的密钥处理 (7.2.5 Key handling at state transitions to and away from EMM-DEREGISTERED)

EMM代表EPS Mobility Management,移动性管理。EMM-DEREGISTERED(去注册)是比ECM-IDLE更“彻底”的离线状态。

  • EMM-DEREGISTERED:去注册态。UE在网络中没有任何有效的上下文,网络不知道它的任何信息。这通常发生在关机、拔卡、或网络附着被拒绝时。

  • EMM-REGISTERED:注册态。UE已在网络注册,包含ECM-IDLEECM-CONNECTED两种子状态。

3.1 走向沉寂:转入EMM-DEREGISTERED (7.2.5.1 Transition to EMM-DEREGISTERED)

小明结束了一天的工作,准备睡觉。他长按手机电源键,选择了“关机”。这个动作触发了手机向网络发送Detach Request消息,从EMM-REGISTERED转变为EMM-DEREGISTERED

此时,安全上下文将如何处理?

On transitioning to EMM-DEREGISTERED, the UE and MME shall do the following:

  1. If they have a full non-current native EPS NAS security context and a current mapped EPS NAS security context, then they shall make the non-current native EPS NAS security context the current one.
  1. They shall delete any mapped or partial EPS NAS security contexts they hold.

深度解读

  • 清理门户:所有“非原生”的(mapped)或“不完整”的(partial)上下文都将被无条件删除。网络不希望在UE的“长期休眠”期间,还保留这些临时的、过渡性的状态。

  • 原生上下文优先:如果此时UE碰巧同时有一个映射上下文(当前)和一个原生上下文(非当前),规范要求优先保留原生的

原生上下文的“冬眠”:持久化存储

对于那个唯一的、完整的原生上下文(full native EPS NAS security context),规范设计了一套精密的“冬眠”机制,以便下次开机时能够快速恢复。

Storage of the full native EPS NAS security context, excluding… KNASint and KNASenc, in the UE when the UE transitions to EMM-DEREGISTERED state is done as follows:

a) If the USIM supports EMM parameters storage, then the ME shall store the full native EPS NAS security context parameters on the USIM…

c) If the USIM does not support EMM parameters storage, then the ME shall store the full native EPS NAS security context … in a non-volatile part of its memory…

深度解读

  • 存储内容:除了临时的NAS密钥(KNASintKNASenc,它们可以在下次使用前由KASME重新派生),核心的安全上下文参数,如KASMEeKSINAS COUNT等,将被持久化存储。

  • 存储位置(优先级)

    1. 首选USIM卡:如果USIM卡支持(现代USIM卡通常都支持),上下文将被安全地写入USIM的文件系统中。这是最安全的方式,因为它将安全上下文与信任根物理地绑定在一起。

    2. 次选手机的非易失性内存:如果USIM不支持,则上下文将被写入手机的闪存(Flash Memory)中一个受保护的区域。

  • 标记为有效:存储后,该上下文会被标记为“valid”(有效),以便下次开机时识别和加载。

3.2 再次唤醒:离开EMM-DEREGISTERED (7.2.5.2 Transition away from EMM-DEREGISTERED)

第二天清晨,小明再次按下开机键。

When starting the transition away from EMM- DEREGISTERED state…, if no current EPS NAS security context is available in the ME, the ME shall retrieve native EPS NAS security context stored on the USIM…or…from its non-volatile memory… The retrieved native EPS NAS security context…shall then become the current EPS NAS security context.

深度解读

  1. 唤醒“冬眠”的上下文:手机开机后,会检查USIM卡或自己的非易失性内存中,是否存在一个被标记为“valid”的EPS NAS安全上下文。

  2. 加载为当前:如果找到了,它会将其加载到内存中,并将其状态设置为“当前上下文”。

  3. 重新派生NAS密钥:由于存储时没有保存KNASintKNASenc,手机会使用加载的KASME和算法信息,重新计算出这对NAS密钥。

When the ME is transitioning away from EMM- DEREGISTERED state…, the ME shall mark the stored EPS NAS security context on the USIM as invalid.

深度解读:一旦上下文被成功加载到内存中,存储在USIM或闪存中的副本就会被标记为“invalid”(无效)。这是一个关键的安全措施,确保了这份持久化的上下文副本只是一次性的“启动盘”,一旦使用,就不能再用,防止了可能的状态回滚攻击。

场景串联(完整生命周期)

  1. 小明关机(Detach),手机将包含KASME和最新NAS COUNT的上下文安全地写入USIM,并标记为valid。MME侧也同样保存了这份上下文。

  2. 小明开机,手机从USIM中读出该上下文,加载到内存,并将其标记为current。同时,USIM中的副本被标记为invalid

  3. 手机发起Attach Request,用加载的上下文进行完整性保护,并携带对应的eKSI和GUTI。

  4. MME收到后,使用eKSI和GUTI找到自己保存的上下文,成功验证了请求。

  5. 无需AKA:由于双方拥有一个有效的、同步的安全上下文,本次附着无需重新进行AKA认证,极大地加快了开机入网速度。

4. 总结

7.2.5至7.2.7节,为我们揭示了UE在不同生命周期状态下的密钥管理大智慧。这套机制在安全性和功耗/效率之间取得了绝佳的平衡。

  • 动静分离,分层管理:在IDLECONNECTED之间切换时,AS上下文(如KeNB)被“用后即焚”,保证了eNB的轻量化;而NAS上下文(KASME)则被长期保留,保证了快速恢复连接的能力。

  • 新鲜度是生命线:无论是Service Request还是TAU Request,其NAS COUNT都被用作派生新KeNB的新鲜度来源,这是杜绝密钥重用的核心机制。

  • 持久化实现快速启动:通过在关机时将安全上下文安全地“冬眠”在USIM或手机闪存中,实现了开机时的快速认证和入网,极大地改善了用户体验。

  • 状态标记,杜绝回滚:对持久化上下文“一次性使用”的标记规则,体现了对状态一致性的严格要求,是防止高级攻击的精妙设计。

通过对这些细节的理解,我们不仅知道了安全机制“是什么”,更理解了它们“为什么”要这么设计。在下一篇文章中,我们将继续深入第七章,探讨更为复杂的移动性场景——切换(Handover)中的密钥处理(7.2.8节)。


FAQ 环节

Q1:ECM-IDLE(空闲态)和 EMM-DEREGISTERED(去注册态)最主要的区别是什么?

A1:最主要的区别在于网络侧是否保留了用户的上下文

  • 在**ECM-IDLE**下,UE虽然没有RRC连接,但MME中依然保留着它完整的上下文(包括KASMEGUTI、承载信息等),并且知道UE所在的大致区域(TA)。网络可以随时通过寻呼(Paging)找到UE。

  • 在**EMM-DEREGISTERED下,MME理论上**已经删除了UE的所有活动上下文。网络不知道UE的任何信息,也无法寻呼到它。UE对于网络来说是完全离线的。虽然为了快速开机,上下文可能被持久化存储,但在网络的“活动用户列表”里已经没有它了。

Q2:为什么进入空闲态时要删除KeNB,但保留KASME

A2:这是AS和NAS安全上下文生命周期管理分离的体现。KeNBAS层的密钥,与UE和特定eNB之间的RRC连接绑定。当RRC连接释放,UE进入空LE,它不再与任何特定的eNB保持连接,因此KeNB也就失去了存在的意义,删除它可以释放eNB的资源。而KASMENAS层的密钥,与UE和核心网MME之间的注册会话绑定。只要UE还注册在网络上(即使是IDLE状态),这个会话就依然有效,因此KASME必须被保留,以便UE下次发起业务时能够快速恢复AS安全。

Q3:将安全上下文保存在USIM和保存在手机的非易失性内存中,安全性有什么差别?

A3:将上下文保存在USIM中被认为是更安全的方式。USIM是一个专为安全设计的硬件,具有防物理攻击和防软件篡改的能力,对文件系统的访问有严格的权限控制。而手机的非易失性内存(闪存)虽然也可以划分出安全区域(如使用TEE),但其整体的攻击面比USIM更广。如果手机的操作系统或固件存在严重漏洞,存储在闪存中的数据理论上存在被非法读取的风险。因此,规范将USIM作为首选的持久化存储位置。

Q4:如果我的手机在关机时意外断电(比如电池耗尽),没来得及发送Detach消息,下次开机时会怎么样?

A4:下次开机时,手机会发现自己有一个在USIM/闪存中标记为“valid”的上下文。它会加载这个上下文,并尝试发起AttachTAU。然而,在MME侧,由于没有收到上次的Detach消息,它可能仍然认为UE处于连接状态(虽然有定时器会最终清理掉这个“僵尸”上下文)。这可能会导致一些短暂的状态不一致。但最终结果通常是,MME无法验证UE使用旧上下文发来的请求(例如,MME侧可能已经清理了旧上下文),MME会拒绝该请求,并强制UE使用IMSI发起一次全新的Attach流程,通过AKA来重建所有上下文。整个过程对用户来说可能只是开机入网比正常情况稍慢一些。

Q5:TAU Request消息为什么要进行完整性保护?

A5:TAU Request是一条非常关键的NAS信令,它告诉网络用户的最新位置。对其进行完整性保护至少有两个重要原因:1) 防止身份欺骗:确保这条位置更新请求确实是由合法的UE(拥有KNASint密钥)发出的,而不是攻击者伪造的。2) 防止拒绝服务攻击:防止攻击者篡改TAU请求的内容,例如修改其中的GUTI,导致MME无法识别用户,从而拒绝服务,使用户掉线。保护TAU Request的完整性,对于保障用户在移动过程中的连接连续性至关重要。