51学通信

深度解析 3GPP TS 33.511：4.2.2.1 空口控制面安全 (Part 1 - RRC信令保护)

27分钟阅读

好的，我们继续对3GPP TS 33.511规范的逐章拆解。这是本系列解读的第四篇文章。在上一篇中，我们已经清晰地描绘出了gNodeB安全需求的宏观蓝图。现在，我们将拿起“手术刀”，正式进入这份规范最核心、最庞大的区域——4.2.2节，开始对gNodeB源自5G系统安全总纲（TS 33.501）的具体功能进行精密解剖。

今天，我们将聚焦于5G安全的第一道，也是最关键的一道防线：空中接口控制面安全。

深度解析 3GPP TS 33.511：4.2.2.1 空口控制面安全 (Part 1 - RRC信令保护)

本文技术原理深度参考了3GPP TS 33.511 V18.3.0 (2024-03) Release 18规范中，关于4.2.2.1节下属的 4.2.2.1.1, 4.2.2.1.4, 4.2.2.1.6, 4.2.2.1.9 等核心条款。本文旨在为读者构建一个关于5G空口控制面（RRC信令）如何被“三层护盾”严密保护的完整技术视图。

引言：李明的第一项“筑墙”任务

在“星辰通信”的实验室里，工程师李明已经完全理解了gNodeB安全设计的整体蓝图。他的导师艾米对他扎实的理论准备感到满意，决定让他开始参与Orion-gNodeB 9000产品的实际安全验证工作。

“李明，理论学习结束了，现在是实践时间，”艾米指着一台正在运行的信令分析仪说，“任何一座城堡，最先要建的，就是那道最外围、最坚固的城墙。在5G世界里，这道墙就是对RRC信令的保护。”

艾米解释道：“RRC（无线资源控制）信令是gNodeB和UE之间的‘指挥语言’，是整个无线网络的神经系统。如果这个神经系统被窃听，攻击者就能通过分析测量报告推断出你的位置；如果它被篡改，攻击者就能把你重定向到他的伪基站；如果它被重放，攻击者就能在你不知不觉中切断你的网络连接。你的第一个任务，就是亲手验证，我们的Orion-gNodeB 9000为这套‘神经系统’构建的防护，是否如规范要求的那般坚不可摧。”

李明感到一股责任感涌上心头。他知道，他接下来的每一个操作，都是在为亿万用户未来的通信安全，砌上第一块坚实的砖。

1. 第一层护盾：完整性保护 (Integrity Protection) - 确保指令未被篡改

李明翻开规范，首先定位到关于RRC信令完整性保护的条款。这是防御主动攻击的第一道屏障。

4.2.2.1.1 Integrity protection of RRC-signalling Requirement Name: Integrity protection of RRC-signalling Requirement Reference: TS 33.501, clause 5.3.3 Requirement Description: The gNB supports integrity protection and replay protection of RRC-signalling as specified in TS 33.501, clause 5.3.3. Threat References: TR 33.926, clause D.2.2.2 – Control plane data integrity protection.

【李明的深度解读】

“完整性保护”，用最直白的话说就是“防篡改”。李明立刻设想了一个经典的攻击场景： 一个用户正在使用手机，其手机收到了gNodeB发来的一条RRCReconfiguration消息，指示手机切换到邻近的另一个小区。如果一个中间人攻击者能截获这条消息，并将其中的目标小区ID修改为一个由他自己控制的、信号更强的伪基站ID，那么手机就会在不知不觉中连接到这个“贼窝”，后续所有的通信都将被监听和控制。

为了杜绝这种风险，5G系统强制要求对绝大部分RRC信令进行完整性保护。其技术核心是在RRC消息的PDCP层 PDU（协议数据单元）的末尾，附加一个消息认证码（Message Authentication Code for Integrity, MAC-I）。这个MAC-I，可以被理解为RRC消息的“数字指纹”。

这个“指纹”是使用以下几样“原料”通过特定的完整性算法（如NIA1, NIA2, NIA3）计算得出的：

  1. RRC消息本身：要保护的对象。
  2. 完整性密钥 (KRRCint)：一把只有UE和gNodeB才知道的、32字节的共享密钥。
  3. 变化的种子 (COUNT)：一个单向递增的、32位的PDCP序列号。
  4. 其他参数：如承载ID、传输方向等。

发送方（如gNodeB）在发送前计算出这个32位的MAC-I并附在消息尾部。接收方（UE）在收到后，用完全相同的“原料”和算法，独立计算一次。如果算出的结果与收到的MAC-I完全吻合，就证明消息在空中“完璧归赵”；若不吻合，则说明消息已被篡改，UE会立刻丢弃这条“假圣旨”。

【实验室实战：复现TC_CP_DATA_INT_RRC-SIGN_gNB测试用例】

理论学习完毕，李明走进实验室，开始亲手验证Orion-gNodeB 9000的RRC完整性保护功能。他严格按照规范中的测试用例进行操作。

Test Case: Test Name: TC_CP_DATA_INT_RRC-SIGN_gNB Purpose: To verify that the RRC-signalling data sent between UE and gNB over the NG RAN air interface are integrity protected. Pre-Condition:

  • The gNB network product shall be connected in emulated/real network environments. UE may be simulated.
  • Tester shall have access to the integrity algorithm and the integrity protection keys.
  • The tester can capture the message via the NG RAN air interface, or can capture the message at the UE. Execution Steps:
  1. The NIA0 is disabled at UE and gNB.
  2. gNB sends AS SMC message to the UE, and UE responses AS SMP.
  3. Check any RRC message sent by gNB after sending AS SMC and before UE enters CM-Idle state is integrity protected.

李明和同事一起搭建了测试环境：一台真实的Orion-gNodeB 9000，连接到一个可以模拟5G核心网和UE的强大测试仪上。

  1. 执行步骤1 (禁用NIA0): NIA0是“空完整性算法”，即不进行任何保护，MAC-I永远是0。这是测试时必须首先排除的“后门”。李明在gNodeB和UE模拟器的配置中，都明确禁用了NIA0，强制双方必须使用真刀真枪的加密算法（如NIA2）。
  2. 执行步骤2 (执行AS安全模式命令流程): AS SMC（接入层安全模式命令）是激活空口安全保护的“点火开关”。李明通过测试仪，模拟核心网向gNodeB下发安全上下文，然后触发gNodeB向UE发起AS SMC流程。这个流程会协商好接下来要使用的算法，并正式启用密钥。
  3. 执行步骤3 (捕获并验证): 在AS SMC流程成功完成后，李明操作测试仪，触发一次RRC重配置流程。同时，他使用空口信令分析仪（一个专业的抓包工具），捕获gNodeB发送的RRCReconfiguration消息。

在分析仪的界面上，他将捕获到的消息展开到PDCP层，清晰地看到PDU的末尾，稳稳地附着了4个字节（32位）的MAC-I字段。他将这条消息的载荷、预先从测试仪中导出的KRRCint密钥、以及当时的PDCP COUNT值，全部输入到一个独立的验证程序中。程序“滴”的一声，计算出的MAC-I与抓包结果中的值完全一致！

Expected Results: Any RRC-signalling over the NG RAN air interface is integrity protected after gNB sending AS SMC.

李明激动地在测试报告上签下了自己的名字：“Orion-gNodeB 9000成功通过TC_CP_DATA_INT_RRC-SIGN_gNB测试。” RRC信令的第一层护盾，坚不可摧。

2. 第二层护盾：机密性保护 (Ciphering) - 确保指令不被窃听

完整性保护防止了篡改，但无法防止窃听。攻击者虽然改不了指令，但他依然能看懂指令的内容。

4.2.2.1.6 Ciphering of RRC-signalling Requirement Name: Ciphering of RRC-signalling Requirement Reference: TS 33.501, clause 5.3.2 Requirement Description: The gNB supports ciphering of RRC-signalling as specified in TS 33.501, clause 5.3.2. Threat References: TR 33.926, clause D.2.2.1 – Control plane data confidentiality protection.

【李明的深度解读】

机密性保护，即加密，就是要把RRC消息变成一串只有gNodeB和UE才能看懂的“天书”。

李明想到了一个隐私泄露的风险：UE会定期向gNodeB上报MeasurementReport（测量报告），其中包含了UE测量到的周边小区的信号强度信息。如果这些信息被攻击者持续监听，他就可以通过三角定位等方法，大致追踪到UE的物理位置，这构成了严重的隐私威胁。

为了应对这种威胁，5G要求对包含敏感信息的RRC信令进行加密。其技术核心，是使用另一把独立的共享密钥——加密密钥 (KRRCenc)，以及一套加密算法（如NEA1, NEA2, NEA3），对RRC消息的载荷（Payload）进行加密处理。

这个过程与完整性保护是同步启用的，都在AS SMC流程中激活。此后，需要保护的RRC信令在发送前，其内容会被加密算法“打乱”，变成一串无意义的乱码。只有拥有正确KRRCenc密钥的接收方，才能将其“复原”。

【实验室实战：复现TC-CP-DATA-CIP-RRC-SIGN_gNB测试用例】

李明继续他的测试，这次的目标是验证加密功能。

Test Case: Test Name: TC-CP-DATA-CIP-RRC-SIGN_gNB Purpose: To verify that the RRC-signalling data sent between UE and gNB over the NG RAN air interface are confidentiality protected. Pre-Condition: … Execution Steps:

  1. The UE sends a Registration Request to the AMF.
  2. The AMF sends a Kgnb and the UE security capability to the gNB.
  3. The gNB selects an algorithm and sends AS SMC to the UE.
  4. The gNB receive AS SMP from the UE.

（注：此处的执行步骤描述了激活安全的前置流程，实际验证步骤与完整性类似，重点是捕获AS SMC之后的消息并观察其载荷。）

李明重复了之前的测试设置。在AS SMC流程成功后，他再次捕获了一条由gNodeB发送的SecurityModeCommand消息（该消息自身的一部分内容也需要被加密）。

在信令分析仪的解码窗口，他定位到消息的载荷部分。这一次，他看到的不再是清晰可读的“information element”（信息元）和字段值，而是一长串被标记为“Encrypted Payload”的十六进制乱码。这正是加密生效的最直观证据！为了最终确认，他将这段密文和从测试仪中获取的KRRCenc密钥，输入到验证工具的解密模块。瞬间，乱码恢复成了原始的、结构清晰的RRC信令内容。

“完美！”李明心想，“现在攻击者既改不了我们的指令，也看不懂我们的指令了。” RRC信令的第二层护盾也已成功加装。

3. 第三层护盾：抗重放保护 (Replay Protection) - 确保指令是“新鲜”的

攻击者既不能改，也不能看，但他们还有最后一招阴险的攻击方式：重放攻击（Replay Attack）。

4.2.2.1.9 Replay protection of RRC-signalling Requirement Name: Replay protection of RRC-signalling. Requirement Reference: TS 33.501, clause 5.3.3 Requirement Description: The gNB supports integrity protection and replay protection of RRC-signalling as specified in TS 33.501, clause 5.3.3.

【李明的深度解读】

李明设想了这种攻击的具体手法： 一个攻击者在某个咖啡馆里，用专业的设备“录制”了一段合法的空口信令。恰好，他录到了一条gNodeB发给某个用户的RRCRelease（连接释放）消息。这条消息是经过完整性保护和加密的，攻击者无法篡改和解读。但是，他可以将这条完整的、合法的消息原封不动地保存下来。

几天后，当这个用户正在进行一次重要的视频会议时，攻击者在附近，将他之前“录制”的这条RRCRelease消息，大功率地重新播放（重放）出去。用户的手机接收到这条消息后，会进行完整性校验——校验通过，因为这是原始消息！然后手机就会执行指令，断开RRC连接，导致视频会议中断。

这就是重放攻击的可怕之处：利用合法的“旧”消息，在错误的时间点造成破坏。

5G的防御机制，其核心正在于我们之前提到的PDCP COUNT。这个单向递增的序列号，确保了每一条RRC消息都有一个独一无二的、不可重复的“时间戳”。由于这个COUNT值参与了MAC-I的计算，因此，(RRC消息, COUNT)这个组合产生的“指纹”是唯一的。

接收方（无论是gNodeB还是UE）的PDCP层，都会维护一个“接收窗口”。它只接受COUNT值比已成功接收的最新值更大的新消息。任何带有过时COUNT值的消息，都会被PDCP层直接判定为重放攻击而丢弃，根本不会递交给上层的RRC协议栈去处理。

【实验室实战：复现TC-CP-DATA-RRC-REPLAY_gNB测试用例】

这是李明面临的最具挑战性的测试，因为它需要他主动扮演“黑客”。

Test Case: Test Name: TC-UP-DATA-RRC-REPLAY_gNB (逻辑上应为TC-CP-…, 控制面) Purpose: To verify the replay protection of RRC-signalling between UE and gNB over the NG RAN air interface. Execution Steps:

  1. The tester shall capture the data sent between UE and the gNB…
  2. Tester shall filter RRC signalling packets.
  3. Tester shall…replay the captured RRC uplink packet to the gNB…
  4. Tester shall check whether the replayed RRC signalling packets were processed by the gNB…
  5. Tester shall confirm that gNB provides replay protection by dropping/ignoring the replayed packet…

李明这次使用了测试仪的高级功能——报文注入。

  1. 捕获与分析: 他首先让模拟UE向Orion-gNodeB 9000发送了一条RRCSetupComplete消息，并捕获了它。他记录下这条消息的完整PDCP PDU，包括其COUNT值，假设为100。
  2. 发起重放攻击: 他让UE继续与gNodeB通信，几秒后，上行的PDCP COUNT值已经增长到了120。此时，李明通过注入工具，将他刚才保存的、COUNT值为100的那条RRCSetupComplete消息，再次发送给gNodeB。
  3. 验证gNodeB的行为: 攻击发出后，李明紧盯着Orion-gNodeB 9000的底层协议栈日志。他发现，gNodeB的PDCP层日志清晰地记录了一条“Stale message dropped”或类似的事件，指明收到了一个过期的序列号。而上层的RRC日志则毫无动静，完全没有处理这条重放消息。

实验成功！Orion-gNodeB 9000的抗重放机制像一个尽职的门卫，准确地识别并拦下了这条“过期”的指令。RRC信令的第三层护盾也已固若金汤。

4. 防线的响应机制：如何处理完整性校验失败

最后，一个好的防御体系，不仅要能防住攻击，还要在遭遇攻击时，做出最安全、最正确的响应。

4.2.2.1.4 RRC integrity check failure Requirement Name: RRC integrity check failure Requirement Reference: TS 33.501, clause 6.5.1 Requirement Description: The RRC integrity checks are performed both in the ME and the gNB. In case failed integrity check (i.e. faulty or missing MAC-I) is detected after the start of integrity protection, the concerned message is discarded.

【李明的深度解读】

规范的要求只有一个词：丢弃 (discarded)。

李明向艾米请教了这背后的深刻用意。艾米解释说，这是一种至关重要的安全设计原则，叫做“最小化信息泄露”。如果gNodeB对收到的坏消息做出任何形式的响应——比如，向对方回复一条“你的MAC-I错了”或者“你的消息我解不出来”——攻击者就能通过分析这些不同的错误响应，来反向推断网络的状态，甚至可能利用这些响应进行更高级的“旁路攻击”（Side-channel Attack）。

最安全的做法，就是对所有无效的、恶意的、无法通过校验的消息，都采取同一种处理方式：石沉大海，静默丢弃。不给攻击者任何额外的信息。

【实验室实战：复现TC-CP-DATA-RRC-INT-CHECK_gNB测试用例】

李明再次扮演“黑客”，这次他要制造两条“坏”消息来测试Orion-gNodeB 9000的反应。

Test Case: Test Name: TC-CP-DATA-RRC-INT-CHECK_gNB Purpose: Verify that RRC integrity check failure is handled correctly by the gNB. Execution Steps 1a) The UE sends a RRC message to the gNB without MAC-I; or 1b) The UE sends a RRC message to the gNB with a wrong MAC-I. … Expected Results: The RRC message is discarded by the gNB after step 1a) or after step 2b).

  1. 制造场景1a (缺失MAC-I): 李明使用报文 crafting 工具，构造了一条本应有MAC-I但却故意删除了MAC-I字段的RRC消息，然后发送给gNodeB。
  2. 制造场景1b (错误的MAC-I): 接着，他又构造了另一条RRC消息，这次他保留了MAC-I字段，但将其中的值随意修改了一个比特，使其成为一个错误的MAC-I。
  3. 观察结果: 对于这两种攻击，李明观察到Orion-gNodeB 9000的行为与预期完全一致。底层PDCP日志记录了完整性校验失败的事件，并指明PDU已被丢弃。上层的RRC协议栈没有任何相关日志，证明它根本没有收到这条消息。整个过程干净利落，没有产生任何多余的告警或对外响应。

至此，李明不仅验证了gNodeB的防护能力，也验证了其在遭遇攻击时的正确应对策略。他对RRC信令安全的理解，从书本上的条文，真正内化成了实验室里可触摸、可验证的现实。

FAQ 环节

Q1：RRC的完整性保护和加密是在什么时候启动的？ A1：RRC信令的保护并不是从UE一开机就有的。它是在初始的RRC连接建立之后，由网络侧（AMF通过gNodeB）发起的“接入层安全模式命令”（AS Security Mode Command）流程来激活的。在这个流程中，gNodeB和UE会协商采用哪种具体的加解密和完整性保护算法，并从此刻开始，使用核心网下发的密钥对后续的RRC信令进行保护。

Q2：什么是PDCP COUNT，它如何实现抗重放攻击？ A2：PDCP COUNT是一个32位的序列号，对于每一个无线承载（Radio Bearer），发送方每发送一个PDCP PDU（数据包），COUNT值就会加1。这个COUNT值会作为输入参数之一参与MAC-I的计算。接收方会维护一个接收窗口，只接受COUNT值在预期范围内且未被接收过的数据包。由于黑客重放的是旧的数据包，其COUNT值必然是过时的、小于当前接收窗口的，因此会被接收方识别并丢弃，从而实现了抗重放攻击。

Q3：为什么gNodeB在检测到完整性校验失败时只是“丢弃”报文，而不是向UE发送一个错误指示？ A3：这是一种重要的安全设计策略，旨在防止信息泄露。如果gNodeB对完整性校验失败的报文做出任何形式的响应，攻击者就可以通过观察这些响应来获取网络内部状态的有用信息，甚至可能利用这些响应进行更复杂的攻击。最安全的做法就是“沉默是金”，对所有格式错误或校验失败的报文一律静默丢弃，不给攻击者任何反馈。

Q4：规范中提到的“AS SMC”消息（Security Mode Command）是什么？它在安全流程中扮演什么角色？ A4：“AS SMC”即“接入层安全模式命令”，是由gNodeB发往UE的一条关键RRC信令。它标志着空口安全保护的正式启动。这条消息的主要作用是：1）告知UE，网络侧决定启用空口安全保护；2) 指示UE应该使用哪一套具体的加密和完整性保护算法（例如，使用NEA2进行加密，NIA2进行完整性保护）；3) 该消息本身受到完整性保护，UE需要用预置的密钥进行校验，以确保该指令确实来自合法的网络，而不是伪基站。UE正确响应后，双方的空口通信就进入了被保护状态。

Q5：规范测试用例中提到的Null-integrity algorithm (NIA0) 存在的意义是什么？为什么测试时要明确禁用它？ A5：NIA0，即“空完整性算法”，是一种“伪算法”，它不执行任何实际的完整性保护计算，输出的MAC-I永远是0。它主要用于特定的测试、调试场景，或者用于某些特殊业务（如紧急呼叫的早期阶段）在安全上下文还未完全建立时临时使用。在商业网络的正常安全运行中，不应使用NIA0。因此，在进行安全功能合规性测试时，必须明确禁用NIA0，以确保gNodeB和UE使用的是真正有效的安全算法，从而真实地检验产品的安全保护能力。

关系图谱