51学通信

深度解析 3GPP TS 33.401：7.2.9-7.5 特殊场景下的密钥管理与安全增强

21分钟阅读

好的，我们继续对3GPP TS 33.401第七章的探索。在上一篇中，我们深入剖析了切换（Handover）这一复杂移动场景下的密钥处理机制。现在，我们将目光转向一些更为特殊但同样重要的安全流程，包括动态的密钥更换、RRC连接的“暂停-恢复”以及一种周期性的本地认证机制。

本文将聚焦于7.2.9至7.5节，涵盖Key-change-on-the fly（动态密钥更换）、Suspend and resume of RRC connection（RRC连接的暂停与恢复）和Signalling procedure for periodic local authentication（周期性本地认证），揭示4G网络在处理这些精细化状态转换和安全增强功能时的智慧。

深度解析 3GPP TS 33.401：7.2.9-7.5 特殊场景下的密钥管理与安全增强

本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“7.2.9 Key-change-on-the fly”至“7.5 Signalling procedure for periodic local authentication”的核心章节，旨在为读者阐明在非切换场景下如何安全地更新密钥，以及在RRC连接暂停/恢复等低功耗特性中的安全处理，并介绍一种用于检测潜在攻击的本地认证机制。

我们的主角“小明”现在正在公司里，连接着稳定的4G网络。虽然他没有在高速移动，但网络的安全机制并未因此而“懈怠”。网络可能会因为各种原因，需要为他更换一套全新的空口密钥，或者在他长时间不使用手机时，让他的连接进入一种比IDLE更深度的“休眠”状态。这些操作，都必须在严密的安全保障下进行。

1. “平地起惊雷”：动态密钥更换 (7.2.9 Key-change-on-the-fly)

“Key-change-on-the-fly”或称“Intra-cell handover based key change”，是一种在不发生真实小区切换的情况下，强制更新UE空口密钥的机制。它像一场“演习式”的切换，目的是更换密钥，而非改变服务小区。

为什么要动态更换密钥？(7.2.9.1 General)

规范指出了两种主要的动态密钥更换类型：

  1. 密钥刷新 (Key-refresh)

    Key refresh shall be possible for KeNB, KRRC-enc, KRRC-int, KUP-int, and KUP-enc and shall be initiated by the eNB when a PDCP COUNTs is about to be re-used…

    深度解读：PDCP层的加密/完整性算法，其输入除了密钥，还有一个关键参数就是32位的PDCP COUNT。这个COUNT在每个数据包发送时都会递增。如果COUNT达到最大值后回绕（wrap around）到0，而此时的密钥（如KUPenc）没有改变，就会发生灾难性的“密钥流重用”——使用相同的密钥和相同的COUNT值加密了不同的数据包。为了避免这种情况，eNB必须在PDCP COUNT即将回绕之前，主动发起一次“密钥刷新”，生成一个全新的KeNB，从而派生出全新的AS密钥。

  2. 密钥重置 (Re-keying)

    Re-keying shall be possible for the KeNB…This re-keying shall be initiated by the MME when an EPS AS security context different from the currently active one shall be activated.

    Re-keying shall be possible for KNAS-enc and KNAS-int…initiated by the MME when a EPS NAS security context different from the currently active one shall be activated.

    深度解读：当MME需要激活一个全新的安全上下文时（例如，在后台完成了一次新的AKA，生成了新的KASME，或者在从2G/3G切换回来后，需要激活原生的4G上下文），就需要进行“密钥重置”。这个过程是“全家桶”式的：

    • 首先，MME通过NAS SMC流程，激活新的KASME，并重置KNASenc/KNASint。

    • 然后，MME会发起KeNB的重置流程，用新的KASME派生出一个全新的KeNB，并通知eNB和UE更换。

如何实现动态更换？——“伪装”成切换 (7.2.9.2 KeNB re-keying & 7.2.9.3 KeNB refresh)

无论是刷新还是重置，AS层的密钥更换都巧妙地复用了我们已经熟悉的**Intra-cell handover（同小区内切换）**流程。

KeNB re-keying (由MME发起) 流程：

  1. MME的准备：MME需要一个新的KeNB。它使用当前的KASME和一个新鲜的上行NAS COUNT（通常来自一次成功的NAS SMC流程）作为输入，派生出一个全新的KeNB。

  2. MME的指令：MME向eNB发送一条S1-AP UE CONTEXT MODIFICATION REQUEST消息，其中包含了这个新的KeNB。这条消息本身在S1接口上是受IPsec保护的。

  3. eNB的执行：eNB收到新KeNB后，向UE发起一次“同小区切换”流程。它在切换命令中指示UE“我们要进行一次密钥更换”。

  4. UE的计算：UE收到指示后，并不会去联系其他小区，而是在本地执行与MME在第一步完全相同的派生逻辑（使用同一个KASME和NAS COUNT），计算出那个全新的KeNB。

  5. 同步与激活：后续流程与真实的切换完全一样，UE和eNB基于新KeNB派生并激活新的AS密钥。

KeNB refresh (由eNB发起) 流程：

This procedure is based on an intra-cell handover. The KeNB chaining that is performed during a handover ensures that the KeNB is re-freshed w.r.t. the RRC and UP COUNT after the procedure.

深度解读：当eNB检测到PDCP COUNT即将溢出时，它会自己对自己发起一次“切换”。它会执行一次水平密钥派生（新KeNB ← (旧KeNB, 本小区PCI, 本小区频率)），然后通过同小区切换流程，通知UE也执行同样的计算，从而双方同步到一个新的KeNB。由于派生过程中没有引入新的随机源，所以这被称为“刷新”而非“重置”，但它同样达到了更换密钥、避免COUNT回绕风险的目的。

2. 深度“休眠”：RRC连接的暂停与恢复 (7.2.11 Suspend and resume of RRC connection)

为了进一步降低UE的功耗，Release 13引入了一项重要的特性——RRC连接暂停。这是一种比ECM-IDLE更“轻量级”的休眠方式。

  • Suspend (暂停)：eNB可以将UE的RRC连接“冻结”，并保存其完整的AS安全上下文。UE也同样保存。此时，UE无需监听寻呼，功耗极低。

  • Resume (恢复)：UE可以快速恢复之前被“冻结”的连接，无需重新执行RRC建立、安全激活等完整流程，时延极低。

这个过程的安全核心在于：如何在恢复时，既快速又安全地验证UE的身份，并重新激活安全上下文。

暂停 (7.2.11.2 RRC connection suspend)

The eNB shall include a Resume ID…in the RRC Connection Suspend message…The eNB shall store the Resume ID together with the UE context including the AS security context.

深度解读：eNB在命令UE进入暂停状态时，会分配一个Resume ID。这个ID就像一个“衣帽间的存衣牌”，eNB将UE的所有上下文（包括KeNB, AS密钥, RRC配置等）打包，贴上这个“存衣牌”后存入自己的“衣帽间”（内存）。UE也保存这个“存衣牌”。

恢复到新eNB (7.2.11.3 RRC connection resume to a new eNB)

小明在公司A座暂停了RRC连接，然后走到了B座，决定在B座楼下的eNB-B恢复连接。

the UE sends the RRC Connection Resume Request message on SRB0 and hence it is not integrity protected. The UE shall include…the Resume ID and a ShortResumeMAC-I.

深度解读：

  • 无保护的请求：恢复请求是在SRB0（公共信道）上发送的，此时UE和eNB-B之间没有任何安全上下文，所以是无保护的。

  • 双重凭证：为了在这种无保护的情况下验证身份，UE必须同时出示两个凭证：

    1. Resume ID: “存衣牌”，告诉eNB-B“我的衣服存在哪个衣帽间（eNB-A）的哪个柜子里”。

    2. ShortResumeMAC-I: 一个简短的消息认证码。这是安全的关键。

The ShortResumeMAC-I is a message authentication token, which shall be calculated with…using the stored KRRCint used with the source eNB…

深度解读：UE在发送恢复请求时，会使用之前在eNB-A保存的KRRCint密钥，以及一些动态参数（如源小区ID、目标小区ID等），计算出一个16比特的ShortResumeMAC-I。

完整恢复流程：

  1. UE向eNB-B发送包含Resume ID和ShortResumeMAC-I的恢复请求。

  2. eNB-B根据Resume ID中的信息，找到并联系源eNB-A，请求UE的上下文。它会把UE发来的ShortResumeMAC-I一并转发给eNB-A。

  3. eNB-A收到请求后，从自己的“衣帽间”里找到UE的上下文，然后用其中保存的KRRCint，和eNB-B提供的动态参数，独立地、重新计算一遍ShortResumeMAC-I。

  4. eNB-A将自己计算的结果与eNB-B转发来的ShortResumeMAC-I进行比对。如果一致，就证明发起恢复请求的确实是那个合法的UE，因为只有它才拥有正确的KRRCint密钥。

  5. 验证通过后，eNB-A会执行一次密钥派生（通常是垂直派生，如果MME之前给过NH的话），生成一个全新的KeNB*，然后将这个新密钥连同UE的全部上下文，通过X2接口安全地发送给eNB-B。

  6. eNB-B收到后，向UE发送RRC Connection Resume消息，激活新的安全上下文，连接成功恢复。

这套机制，巧妙地利用了旧密钥对新请求进行认证，并通过X2接口的安全传递和密钥更新，实现了RRC连接在不同基站间的快速、安全恢复。

3. 定期的“健康检查”：周期性本地认证 (7.5 Signalling procedure for periodic local authentication)

这是一个可选的安全增强功能，旨在检测一种特定类型的攻击——“数据流重定向”或“竞合攻击”。

The eNB is monitoring the PDCP COUNT values associated to each radio bearer. The procedure is triggered whenever any of these values reaches a critical checking value…a Counter Check message is sent by the eNB.

流程如 Figure 7.5-1 所示：

  1. eNB发起检查：eNB会周期性地或在PDCP COUNT达到某个阈值时，向UE发送一条Counter Check消息。这条消息是完整性保护的，其中包含了eNB侧记录的、该UE各个数据承载（DRB）的上行和下行PDCP COUNT值的最高位（MSB）。

  2. UE进行比对：UE收到后，将消息中的COUNT值与自己本地记录的PDCP COUNT进行比对。

  3. UE响应：UE在Counter Check Response消息中，报告自己本地的PDCP COUNT值的MSB。

  4. eNB决策：eNB比对UE上报的值和自己的记录。如果存在显著差异，就可能意味着存在异常。例如，一个中间人攻击者可能在窃取UE的数据后，没有将其正确转发给eNB，导致eNB侧记录的COUNT值远小于UE侧。

If the eNB receives a counter check response that contains one or several PDCP COUNT values [that differ], the eNB may release the connection or report the difference … to the serving MME or O&M server for further traffic analysis for e.g. detecting the attacker.

深度解读：这提供了一种带外的、低开销的同步性校验机制。它虽然不能直接阻止攻击，但能有效地检测出异常，并触发后续的告警或防御措施（如强制释放连接）。它就像是eNB和UE之间定期的一次“对账”，确保双方的数据收发计数没有出现大的偏差。

4. 总结

7.2.9至7.5节向我们展示了4G安全在处理特殊状态和增强功能时的灵活性与严谨性。

  • 动态密钥更换：通过巧妙地复用切换流程，实现了在不中断业务的情况下，对空口密钥进行按需刷新（应对COUNT回绕）或重置（响应核心网安全上下文更新），体现了设计的高效复用。

  • RRC连接暂停/恢复：为低功耗物联网场景设计了安全的深度休眠方案。通过“存衣牌（Resume ID）+旧密钥签名（ShortResumeMAC-I）”的组合，解决了在无保护信道上进行快速、安全身份认证的难题，体现了设计的精巧创新。

  • 周期性本地认证：提供了一种轻量级的“心跳”检测机制，通过周期性地同步PDCP COUNT，能够及时发现潜在的数据流异常，为网络的主动防御和威胁感知提供了可能。

这些看似“边缘”的安全流程，实际上是成熟的通信系统不可或缺的组成部分。它们与核心的AKA、切换安全等机制共同协作，构成了一张覆盖各种场景、动静结合、攻防兼备的、立体的安全防护网络。

至此，我们完成了对第七章的全部解读。从下一篇文章开始，我们将进入第八章，将视角再次拉回到NAS层，专门探讨NAS信令保护的更多细节。

FAQ 环节

Q1：Key-refresh（密钥刷新）和Re-keying（密钥重置）的根本区别是什么？

A1：根本区别在于新密钥的“血统”。

  • Key-refresh 是由eNB发起的，新KeNB是从**旧KeNB**派生出来的（水平派生）。它没有引入来自核心网的新鲜随机源，其主要目的是为了解决PDCP COUNT回绕问题，可以看作是当前安全会话的“延续”。

  • Re-keying 是由MME发起的，新KeNB是从**KASME和一个新鲜的NAS COUNT**派生出来的（全新的初始派生）。它引入了来自核心网的新鲜度，通常与一次全新的NAS安全上下文激活相关联。这可以看作是开启了一个全新的AS安全会话。

Q2：RRC连接恢复时，为什么使用ShortResumeMAC-I（16比特）而不是一个完整的MAC（32比特）？

A2：这主要是为了节省SRB0（公共信道）上的无线资源。RRC Connection Resume Request消息必须尽可能地小，以便在各种信号条件下都能被成功发送。16比特的ShortResumeMAC-I虽然比32比特的完整MAC更容易发生碰撞（即两个不同的输入碰巧算出同一个MAC），但考虑到其计算输入中包含了源PCI、目标Cell-ID等动态参数，并且KRRCint密钥本身是保密的，攻击者在短时间内伪造一个能通过验证的ShortResumeMAC-I的概率已经足够低，足以满足该场景下的安全需求。这是一种在安全性和信令开销之间的 pragmatic trade-off（务实权衡）。

Q3：RRC连接恢复到同一个eNB，还需要像恢复到新eNB那样进行复杂的密钥派生吗？

A3：需要。规范在7.2.11.4节中明确指出，即使恢复到同一个eNB，也应被视为源eNB和目标eNB是同一个实体的特例。这意味着，eNB在收到自己的恢复请求后，也需要验证ShortResumeMAC-I，并**派生出一个全新的KeNB***来激活新的AS安全上下文。这样做的目的是为了保证安全流程的统一性，并为每次恢复连接都引入新的AS密钥，增强安全性。

Q4：周期性本地认证（Counter Check）能防御所有类型的中间人攻击吗？

A4：不能。它主要用于检测那些会导致UE和eNB之间PDCP COUNT计数显著不一致的攻击。最典型的就是“数据丢弃”或“延迟转发”攻击。但对于某些更高级的攻击，比如攻击者能够实时地、一对一地篡改数据包内容（在不改变包数量的情况下），Counter Check机制是无法发现的。这种攻击需要依赖PDCP层的完整性保护（如果开启的话）来防御。因此，Counter Check是一种辅助性的、用于异常检测的安全机制，而非根本性的防御措施。

Q5：7.2.10 Rules on Concurrent Running of Security Procedures 这一节的主要目的是什么？

A5：这一节的目的是为了防止“死锁”和“状态不一致”。网络中可能同时发生多个安全流程，例如，MME刚发起了一次NAS SMC想更新KASME，同时eNB又因为信号原因决定发起一次切换。如果这两个流程并发执行，UE可能会收到相互冲突的指令，导致其安全上下文错乱。7.2.10节制定了一系列“互斥”规则，例如“当NAS SMC正在进行时，MME不能发起包含新KeNB的S1流程”以及“当UE正在进行切换时，源eNB应拒绝MME发起的UE Context Modification请求”。这些规则确保了在任何时刻，只有一个“主导”的安全流程在改变UE的安全状态，保证了流程的原子性和一致性。

关系图谱