深度解析 3GPP TS 33.501：6.5 RRC安全机制 (无线空中的“带甲护卫”)
本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中，关于“6.5 RRC security mechanisms”的核心章节，旨在为读者深入剖析在UE与基站之间，保护无线控制信令安全的最后一道、也是最直接的一道防线。
在上一篇文章中，我们详细解读了NAS安全机制，了解了UE与核心网AMF之间的“中枢神经”是如何被严密保护的。然而，从AMF发出的指令，要想到达UE，必须经过一个关键的“中转站”——基站（gNB）。同样，UE的请求也必须先通过gNB，才能抵达核心网。UE与gNB之间的这段无线链路，是整个通信链条中暴露面最大、最容易受到攻击的部分。
今天，我们将聚焦于守护这段“最后也是最前一公里”安全的卫士——6.5 RRC安全机制。RRC（Radio Resource Control，无线资源控制）是UE与gNB之间用于管理无线连接的“行话”。本章将详细揭示，这些“行话”是如何被一套与NAS安全平行但又独立的机制所保护的。我们将了解到：
- RRC安全与NAS安全的核心区别在哪里？
- 保护RRC信令的“防伪封条”和“加密信封”是如何制作的？
- 一个看似普通的UE能力上报流程，背后隐藏着怎样重要的安全考量？
我们的主角，AGV“智行一号”，已经成功与核心网AMF建立了安全的NAS连接。现在，它需要根据AMF的指令，与为它提供直接覆盖的基站建立一个用于传输实际生产数据的无线承载。这个建立过程，就是一场由RRC信令主导的“现场施工”。而核心网工程师“李工”，将为我们解释，为了确保这场“施工”不被外界干扰和破坏，UE和gNB这两位“现场工程师”是如何使用他们的“带甲护卫”——RRC安全机制——来保护彼此的通信的。
1. 战场剖析：RRC安全 vs. NAS安全，有何不同？
在深入细节之前，我们必须清晰地辨别RRC安全与NAS安全这两位“护卫”的不同职责。虽然它们都采用“机密性+完整性”的双重保护，但其保护的“对象”和“主导者”完全不同。
| 特性 | NAS 安全 (6.4节) | RRC 安全 (6.5节) |
|---|---|---|
| 通信双方 | UE ←> AMF (核心网) | UE ←> gNB (无线接入网) |
| 保护对象 | NAS信令 (如注册、认证、移动性管理) | RRC信令 (如连接建立、切换、承载配置) |
| 终结点 | 逻辑上是端到端的，跨越接入网 | 仅限于UE和当前服务的gNB之间 |
| 主导者 | AMF | gNB |
| 父密钥 | K_AMF | K_gNB |
场景代入： 李工用一个生动的比喻解释了这个区别：“NAS安全，就像‘智行一号’和我的‘中央调度中心’（AMF）之间的对讲机。这个对讲机是加密的，无论‘智行一号’在工厂的哪个角落，它都能安全地向中心汇报位置、接受核心指令。而RRC安全，是‘智行一号’和它面前那个路口的‘交通警察’（gNB）之间的手势信号。这些手势信号（RRC信令）也需要加密和防伪，以确保‘智行一号’收到的‘左转’、‘停止’指令是真实的，而不是路边捣乱的人发出的假指令。调度中心的指令管全局，交通警察的指令管局部。”
2. 6.5.1 RRC完整性机制 - 不可伪造的“数字将令”
RRC信令是管理无线资源的“军令”，其真实性至关重要。
RRC integrity protection shall be provided by the PDCP layer between UE and gNB and no layers below PDCP shall be integrity protected. Replay protection shall be activated when integrity protection is activated…
解读：
- 执行层：RRC的完整性保护任务，由其下一层的PDCP（Packet Data Convergence Protocol）层来执行。PDCP层会为每一个RRC消息计算一个MAC（Message Authentication Code）值，并附加在消息尾部。
- 强制防重放：与完整性保护一同被激活的，是重放保护。PDCP层会为每一条RRC消息赋予一个独一无二的32位序列号（PDCP COUNT），接收方会检查这个序列号是否是“新鲜”的，从而防止攻击者将之前截获的合法指令重新播放给UE或gNB。
The input parameters to the 128-bit NIA algorithms as described in Annex D are the RRC message as MESSAGE, an 128-bit integrity key KRRCint as KEY, a 5-bit bearer identity BEARER…, the 1-bit direction of transmission DIRECTION and a bearer specific direction dependent 32-bit input COUNT which corresponds to the 32-bit PDCP COUNT.
解读： 与NAS完整性算法的输入参数极其相似，RRC完整性算法（NIA）的输入“配方”包括：
KEY: 128位的RRC完整性密钥K_RRCint。这把“钥匙”是从K_gNB派生而来的。COUNT: 32位的PDCP COUNT。这是防重放的核心。它的长度（32位）远大于NAS COUNT（24位），因为RRC信令的交互可能比NAS信令更频繁。BEARER: 5位的承载标识。对于RRC信令，通常有特定的SRB（Signalling Radio Bearer）ID，如SRB1, SRB2。这个参数确保了不同信令承载上的密钥流不会混淆。DIRECTION: 1位的方向，0代表上行（UE→gNB），1代表下行（gNB→UE）。MESSAGE: 需要保护的RRC消息本身。
场景代入： 基站（gNB）需要向“智行一号”发送一条RRC连接重配置消息。
- gNB的PDCP层取出了专用的RRC完整性密钥
K_RRCint。 - 它查看了该信令承载（SRB1）的下行PDCP COUNT计数器，当前值为
1025。 - 它将
K_RRCint、COUNT=1025、BEARER=SRB1、DIRECTION=1以及RRC消息本身，一起输入到NIA算法中，计算出一个32位的MAC值。 - 它将这个MAC值附加在RRC消息的末尾，然后通过物理层发送出去。 “智行一号”收到后，会以完全相同的参数（除了方向为1）进行相同的计算，并比对计算出的MAC值与收到的MAC值是否一致。如果不一致，它会立即丢弃这条指令，因为它知道这封“将令”是伪造的或在途中被篡改了。
3. 6.5.2 RRC机密性机制 - 无线信令的“隐身斗篷”
除了防篡改，防止RRC信令被窃听也同样重要。
RRC confidentiality protection is provided by the PDCP layer between UE and gNB. The input parameters to the 128-bit NEA algorithms as described in Annex D are a 128-bit cipher Key KRRCenc as KEY, a 5-bit bearer identity BEARER…, the 1-bit direction of transmission DIRECTION, the length of the keystream required LENGTH and a bearer specific direction dependent 32-bit input COUNT…
解读： RRC的机密性保护，同样由PDCP层执行。其加密算法（NEA）的输入“配方”与完整性算法几乎完全一样，唯一的关键区别在于使用的密钥：
KEY: 128位的RRC机密性密钥K_RRCenc。这把“钥匙”同样是从K_gNB派生而来，但与K_RRCint不同，遵循了密钥分离原则。
PDCP层会使用上述参数生成一段与RRC消息等长的密钥流（keystream），然后将密钥流与RRC消息进行逐比特的异或（XOR）运算，从而得到加密后的密文。接收方再以相同参数生成相同的密钥流，与密文进行一次异或运算，即可恢复出明文。
4. 6.5.3 RRC UE能力传输流程 - 一场“先认证，后汇报”的安全演练
在建立了安全的RRC连接后，gNB通常会做一件事：询问UE“你都会些什么？”。这就是UE能力传输流程。UE会向gNB上报自己支持的各种无线能力，如支持的频段、调制方式、多天线技术等等。这个看似普通的流程，却隐藏着一个重要的安全“陷阱”。
The network should activate AS security (i.e., perform a successful AS SMC procedure) before running the RRC UE capability transfer procedure. With the exception of unauthenticated emergency calls…, if the network had acquired UE capabilities using RRC UE capability transfer procedure before AS security activation, then the network shall not store them locally for later use and shall not send them to other network entities. In that case, the network shall re-run the RRC UE capability transfer procedure after a successful AS SMC procedure.
解读： 规范在这里提出了一个强烈建议（should）和一个强制规定（shall），共同构成了一个关键的安全程序：
- 先建安全，再问能力 (SHOULD)：网络应该先与UE完成AS安全模式命令（SMC）流程，即激活了RRC的加密和完整性保护之后，再去请求UE上报其能力。
- 不安全，不信任 (SHALL)：如果网络在AS安全激活之前就收到了UE的能力信息（例如，在一些早期的消息中），那么网络绝不能（shall not）存储或使用这份能力信息。它必须在AS安全成功激活之后，重新发起一次UE能力查询流程，获取一份在安全信道中传输的能力报告。
为什么这个顺序如此重要？ 这是为了防范一种更高级的“能力降级攻击”。
场景代入： 一个攻击者“小黑”建立了一个伪基站。
- “智行一号”在初始接入时，可能会先与这个伪基站进行一些未受保护的交互。
- 伪基站立即向“智行一号”发起“能力查询”。“智行一号”诚实地回答：“我支持从算法A到Z的所有高级功能。”
- 伪基站记录下这份完整的能力清单，然后通过某种方式（例如，作为中间人）将“智行一号”的连接请求转发给合法的gNB。在转发时，它篡改了能力信息，只告诉合法gNB：“这个UE只支持最老的A算法。”
- 如果合法的gNB相信了这份被篡改的能力报告，它在后续与“智行一号”建立安全连接时，就只会选择A算法，从而成功实施了降级攻击。
而规范的这个要求，完美地堵住了这个漏洞。合法的gNB会遵循“先建安全，再问能力”的原则。它会先和“智行一号”完成AS SMC流程，建立起加密和完整性保护的RRC信道。然后，gNB再通过这条安全信道发起能力查询。“智行一号”此时上报的能力信息，是经过加密和完整性保护的，伪基站既无法窃听，也无法篡改。这样，gNB获取到的就是一份绝对可信的能力清单。
5. 总结
本章深入剖析的6.5节，为我们揭示了5G无线空中接口上那对不可或缺的“带甲护卫”——RRC安全机制。
- 职责明确：它专注于保护UE与gNB之间的无线控制信令，与保护核心网信令的NAS安全形成了功能互补、责任分离的完整体系。
- 双锁并行：通过在PDCP层实现的完整性保护（
K_RRCint）和机密性保护（K_RRCenc），为RRC信令提供了“防伪”和“防窃听”的双重保障。 - 防线坚固：以32位的PDCP COUNT作为序列号，构建了强大的抗重放攻击能力。
- 流程严谨：通过“先激活安全，后传输能力”的强制性程序要求，从流程上杜绝了复杂的“能力降级攻击”，体现了5G安全设计的深思熟虑。
RRC安全机制，是确保5G网络无线资源得以高效、可靠、安全调度的基石。它保证了从连接建立、业务承载配置到小区切换的每一个“空中指令”，都是可信和保密的。
FAQ
Q1：RRC安全和NAS安全，哪个先建立？
A1：NAS安全先于RRC安全建立。这是一个严格的先后顺序。逻辑是：UE必须先和核心网的“大脑”（AMF）建立起信任关系（NAS安全上下文，核心是K_AMF），AMF才能放心地将用于接入网的密钥K_gNB下发给gNB。gNB拿到K_gNB后，才能与UE建立起RRC安全。这个顺序体现了信任从核心向边缘逐级传递的过程。
Q2：为什么RRC和用户数据（UP）的保护都在PDCP层完成？ A2：将安全功能置于PDCP层，是综合考虑了效率、灵活性和协议栈结构的结果。1) 位于高层：PDCP位于RLC和MAC层之上，更接近IP层。在PDCP层进行加解密，可以使得下方的RLC层（负责分段和重传）和MAC层（负责调度）无需关心上层数据是明文还是密文，可以更高效地执行其物理传输功能。2) 基于承载：PDCP是按“承载”（Bearer）来处理数据的。将安全与承载绑定，可以非常灵活地为不同业务（如RRC信令承载、语音数据承载、视频数据承载）配置不同的安全策略（如是否加密、是否完整性保护）。3) 序列号：PDCP层本身就维护着用于重排序和保证有序递交的序列号（SN），这个序列号被扩展后直接用作安全上下文的COUNT值，实现了功能复用。
Q3：K_RRCint和K_RRCenc都是从K_gNB派生而来，为什么一定要用两把不同的钥匙？
A3：这是密码学安全中的“密钥用途分离（Key Separation）”基本原则。虽然现代算法（如AES-GCM）可以在一次操作中同时提供加密和认证，但3GPP的传统架构中，加密和完整性是两个独立的算法。如果对这两个独立的算法使用相同的密钥，可能会引入潜在的密码学漏洞，即攻击者可能通过分析一个算法（如完整性算法）的某些特性，来获取关于另一个算法（加密）所用密钥的信息。通过从同一个父密钥K_gNB，使用不同的输入参数派生出两把完全不同、互不关联的子密钥，可以彻底杜绝这种风险。
Q4：如果一个RRC消息的完整性校验失败，UE或gNB会怎么做？ A4：根据规范，如果PDCP层在对收到的RRC消息进行完整性校验时发现MAC值不匹配，它会向上层（RRC层）递交一个失败指示，并且**丢弃（discard）**这个消息。RRC层收到这个失败指示后，会认为无线链路出现了严重问题。根据TS 38.331的规定，这可能会触发“无线链路失败（Radio Link Failure, RLF）”程序。UE会尝试进行RRC连接重建（RRC Re-establishment）等恢复操作。这是一种快速的故障检测和恢复机制。
Q5：UE能力信息到底有多敏感，以至于需要如此严格的保护程序？ A5：UE能力信息本身可能不是机密，但它在安全协商的上下文中变得极其敏感。它直接决定了UE与网络之间能够使用的“安全工具箱”的范围。如果攻击者能够在安全建立之前，欺骗网络，让网络相信UE只支持一些老旧、甚至有已知漏洞的“安全工具”，那么网络在后续的安全协商中，就只能从这个被“阉割”后的工具箱里做选择，从而被迫降低了整个通信的安全等级。因此，保护UE能力信息的真实性和完整性，就是保护整个安全协商过程的基础不被动摇。