51学通信

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

27分钟阅读

好的，我们马上开始。这是本系列解读的第二篇文章，我们将正式进入规范的细节，从第一章开始，重点剖析5G空中接口信令安全的核心基石。

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

本文技术原理深度参考了3GPP TS 33.511 V18.3.0 (2024-03) Release 18规范，我们将首先快速浏览规范的前三章，然后将显微镜聚焦于第4章的核心内容：4.2.2.1 gNodeB从TS 33.501派生的安全功能需求，特别是与RRC信令安全相关的条款。本文旨在为读者构建一个关于5G空口控制面（信令）如何被保护的完整技术视图。

引言：新晋工程师李明的第一项挑战

在上一篇文章中，我们认识了设备制造商“星辰通信”和运营商“赛博网络”。今天，我们的故事将聚焦于“星辰通信”安全团队的一位新晋工程师——李明。李明刚刚加入负责“Orion-gNB 9000”基站产品的安全合规团队，他的导师，正是我们之前提到的首席安全架构师艾米。

艾米交给李明的第一个任务，就是对照3GPP TS 33.511规范，深入理解并参与验证gNodeB最核心的安全功能之一：RRC信令保护。RRC（Radio Resource Control，无线资源控制）信令，是手机（UE）和gNodeB之间沟通的“神经系统”，所有关键的连接建立、切换、资源分配指令都通过它来传递。如果这个“神经系统”被窃听或篡改，后果不堪设想。

“李明，” 艾米语重心长地说，“我们的Orion-gNB 9000能否获得‘赛博网络’的认可，首先就要看我们能否完美实现TS 33.511中关于RRC信令保护的每一条要求。你的任务，就是成为这方面的专家。从规范的第一个字开始读起，直到你能亲手在实验室里复现每一个相关的测试用例。”

就这样，李明翻开了3GPP TS 33.511规范，开启了他的深度解读之旅。

1. 规范的基石：快速浏览第1、2、3章

在进入技术深水区之前，李明首先快速浏览了规范的前三个引导性章节。根据艾米的指导，这些章节虽然简短，但为理解整个规范奠定了基础。

  • 第1章：范围 (Scope) 本章只有一段话，明确了这份文档的使命——它不是一本理论书籍，而是一本为gNodeB量身定制的、包含具体“安全要求”和“测试用例”的工程手册。它告诉李明，他在这里读到的每一句话，最终都要落实到Orion-gNB 9000的代码实现和测试结果上。

  • 第2章：参考文献 (References) 这一章是规范的“引用书目”。李明注意到，这里列出了大量其他3GPP规范的编号，如TS 33.501（5G系统安全架构）、TS 38.331（NR RRC协议规范）等。这让他立刻明白，TS 33.511并非孤立存在，而是庞大3GPP标准体系中的一环，他需要将这些规范关联起来阅读，才能形成完整的知识图谱。

  • 第3章：定义与缩略语 (Definitions and abbreviations) 通信行业充满了缩略语。本章就像一本“随行字典”，定义了文中使用的专业术语和缩写，如gNB、AMF、SMF等。对于刚入行不久的李明来说，这是他未来几周需要反复查阅的重要章节。

完成这三章的预读后，李明对规范的结构和定位有了清晰的认识。现在，他准备好迎接真正的挑战——第4章。

2. RRC信令的“三层护盾”：完整性、机密性与抗重放

李明深吸一口气，翻到了第4章，并直接定位到 4.2.2.1 节。这一节详细列出了gNodeB必须满足的、源自于5G安全总纲 TS 33.501 的各项功能。他首先将目光锁定在与RRC信令直接相关的几个条款上，发现3GPP为RRC信令设计了堪称“三层护盾”的严密保护体系。

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

李明看到的第一个要求，是关于完整性保护的。

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发送一条RRC消息，指令手机切换到一个新的小区。如果一个黑客在空中截获这条消息，并将其中的目标小区ID篡改成一个由他控制的伪基站ID，那么手机就会乖乖地连接到伪基站上，后续所有的通信都将被监听。

为了防止这种情况，5G系统要求对大部分RRC信令进行完整性保护。其原理是在RRC消息的末尾附加一个“消息认证码”（Message Authentication Code for Integrity, MAC-I）。这个MAC-I是使用只有UE和gNodeB共享的完整性密钥（KRRCint）以及特定的完整性算法（如NIA1, NIA2）对RRC消息本身计算得出的“指纹”。

  • 发送方 (gNodeB): 计算RRC消息的MAC-I并附加在消息尾部，然后发送。
  • 接收方 (UE): 收到消息后，使用相同的密钥和算法，对消息内容进行同样的计算。如果计算出的MAC-I与收到的MAC-I完全一致，则证明消息在传输过程中“完好无损”；如果不一致，则说明消息已被篡改，UE会立刻丢弃这条消息。

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

理论学习完毕，李明进入实验室，准备亲手验证Orion-gNB 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-gNB 9000，连接到一个可以模拟5G核心网和UE的测试仪上。

  1. 执行步骤1 (禁用NIA0): NIA0是“空完整性算法”，即不进行任何保护。测试的第一步就是确保gNodeB和UE都禁用了这个“放水”选项，强制它们使用真正的保护算法（如NIA2）。
  2. 执行步骤2 (执行AS安全模式命令流程): 接着，测试仪模拟核心网，触发gNodeB向模拟UE发起“接入层安全模式命令”（AS Security Mode Command, AS SMC）流程。这个流程至关重要，它协商了将要使用的完整性和加密算法，并激活了之前从核心网下发的安全密钥。只有这个流程成功后，保护才会真正启动。
  3. 执行步骤3 (捕获并验证): 在AS SMC流程完成后，李明让测试仪模拟UE执行一些需要与gNodeB交互的动作，例如发起一次RRC重配置。同时，他使用空口抓包工具（信令分析仪）捕获gNodeB发送的RRCReconfiguration消息。

在抓包软件的界面上，他清晰地看到RRCReconfiguration消息的PDCP层PDU的末尾，附加了4个字节的MAC-I。然后，他将抓到的消息内容，以及预先从测试仪中导出的完整性密钥KRRCint，输入到一个独立的验证工具中。工具计算出的MAC-I与抓包结果完全一致！

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

李明兴奋地在测试报告上写下：“Orion-gNB 9000成功通过TC_CP_DATA_INT_RRC-SIGN_gNB测试，RRC信令完整性保护功能验证通过。” 他为RRC信令加上了第一层坚固的护盾。

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

有了完整性保护，黑客无法篡改指令，但他们仍然可以窃听。某些RRC消息可能包含敏感信息，例如UE上报的测量报告（Measurement Report），其中包含了邻近小区的信号强度信息，分析这些信息可以大致推断出用户的位置。因此，第二层护盾——机密性保护（即加密）——是必不可少的。

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.

【李明的深度解读】

机密性保护的原理，是使用只有UE和gNodeB共享的加密密钥（KRRCenc）和加密算法（如NEA1, NEA2）对RRC消息的“载荷”部分进行加密，将其变为一串无意义的乱码。只有拥有正确密钥的接收方才能将其解密，恢复成原始信息。

这个过程与完整性保护几乎是同时激活的，同样是在AS SMC流程中协商好算法并激活密钥。此后，大部分需要保护的RRC信令在发送前都会经过加密处理。

【实验室实战：复现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. 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发送的RRC消息，例如SecurityModeCommand消息本身（该消息的一部分内容需要被加密）。

在信令分析仪中，他定位到消息的载荷部分。这一次，他看到的不再是清晰可读的字段和数值，而是一长串十六进制的乱码。这正是加密生效的直观表现！为了进一步确认，他使用测试仪中保存的加密密钥KRRCenc和协商好的加密算法，对这串乱码进行解密。瞬间，乱码恢复成了原始的、有意义的RRC信令内容。

“太棒了！” 李明心想，“现在黑客既改不了我们的指令，也看不懂我们的指令了。” RRC信令的第二层护盾成功加装。

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

黑客虽然无法篡改和窃听，但他们还剩下最后一招：重放攻击（Replay Attack）。

【李明的深度解读】

什么是重放攻击？假设一个黑客录制了一条合法的RRC消息，比如一条“RRC连接释放”（RRCRelease）消息。虽然他看不懂也改不了这条消息，但他可以在未来的某个时间点，把这条“录音”原封不动地重新播放给UE。UE收到这条消息后，由于其MAC-I校验是正确的（因为是原始消息），UE会误以为是gNodeB发来的新指令，从而执行连接释放动作，导致业务中断。

为了防御这种攻击，5G引入了抗重放机制。其核心是利用PDCP（Packet Data Convergence Protocol）层的序列号（COUNT）。

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

这里的replay protection和integrity protection在同一条需求中提出，是因为它们的实现机制紧密相关。之前提到的MAC-I，其计算输入不仅仅是RRC消息本身，还包括了这个单向递增的PDCP COUNT值。

  • 发送方 (gNodeB): 每发送一个RRC消息，其PDCP COUNT值就加1。计算MAC-I时，会把这个最新的COUNT值也包含进去。
  • 接收方 (UE): 维护一个“接收窗口”，只接受COUNT值落在窗口内的消息。对于已经成功接收过的COUNT值，会记录下来并拒绝重复接收。

这样一来，当黑客重放旧消息时，UE会发现这个消息的COUNT值是已经处理过的、过时的值，因此会直接丢弃它，从而免疫了重放攻击。

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

这是李明面临的最复杂的测试，因为它需要主动发起攻击。

Test Case: Test Name: TC-UP-DATA-RRC-REPLAY_gNB (Note: logical name should be TC-CP-DATA… for Control Plane) 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 check for the PDCP COUNT of the filtered RRC signalling packets and … 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 or not…
  5. Tester shall confirm that gNB provides replay protection by dropping/ignoring the replayed packet…

李明这次扮演了“黑客”的角色。

  1. 捕获与分析: 他首先正常地让模拟UE向Orion-gNB 9000发送了一条RRC消息，例如“RRCSetupComplete”，并用抓包工具捕获了这条消息。他记录下这条消息的完整内容，包括其PDCP COUNT值，假设为N。
  2. 发起重放攻击: 稍等片刻，在UE和gNodeB继续通信，PDCP COUNT值已经增长到N+k之后，李明使用一个报文生成和注入工具，将刚才保存的、COUNT值为N的“RRCSetupComplete”消息，原封不动地再次注入到空口，发送给gNodeB。
  3. 验证gNodeB的行为: 攻击发出后，李明紧盯着Orion-gNB 9000的后台日志和行为。他发现，gNodeB的RRC协议栈日志中没有任何处理这条重放消息的记录，也没有向上层应用递交任何事件。gNodeB就像什么都没发生一样，默默地丢弃了这条过时的消息。

实验成功！Orion-gNB 9000的抗重放机制有效。RRC信令的第三层护盾也已坚不可摧。

3. 防线的响应机制：如何处理完整性校验失败 (Integrity Check Failure)

构建了坚固的防线，还需要定义好当防线遭到攻击时的应对策略。如果gNodeB收到了一个完整性校验失败的RRC消息（意味着它可能被篡改了），应该怎么做？是大声报警，还是默默丢弃？规范给出了明确的答案。

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错误”和“解密错误”的响应不同，攻击者就可能据此发起旁路攻击。最安全的做法就是对所有无效的、恶意的消息一视同仁——石沉大海，不给攻击者任何反馈。

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

李明再次扮演“黑客”，这次他要制造两条“坏”消息来测试Orion-gNB 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. 2b) The gNB verifies the integrity of the RRC message from the UE. 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-gNB 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使用的是真正有效的安全算法，从而真实地检验产品的安全保护能力。

关系图谱