深度解析 3GPP TS 33.501:5.3 Requirements on the gNB (gNB安全需求)
本文技术原理深度参考了3GPP TS 33.501 V18.9.0 (2025-03) Release 18规范中,关于“5.3 Requirements on the gNB”的核心章节,旨在为读者深度剖析作为连接用户与核心网桥梁的5G基站(gNB),所必须承担的各项关键安全职责。
在上一篇中,我们详细解读了对5G终端(UE)的安全要求,了解了我们手中的手机是如何成为一个主动的安全哨兵。今天,我们将视线从用户侧转移到网络侧的第一站——矗立在我们城市各个角落的5G基站,即gNB(Next Generation NodeB)。
规范的5.3节,正是gNB的“安全岗位职责说明书”。gNB作为无线接入网(RAN)的核心设备,其地理位置分散, spesso暴露于物理接触的风险之下,因此它自身的安全以及它在保护空中接口通信方面的角色都至关重要。
为了更好地理解这些看似冰冷的条文,我们引入一位新角色——“老王”。他是一位经验丰富的网络工程师,今天他的任务是在市中心的一座大楼楼顶上,安装并调测一台全新的5G gNB。我们将跟随老王的操作,看看一台gNB从一个普通的硬件盒子,成长为一个可靠的5G安全堡垒,需要满足哪些严苛的要求。而我们的老朋友“安安”,此时正从这栋大楼下走过,她的手机即将与老王部署的这台gNB进行第一次“安全对话”。
1. 5.3.1 通用要求 (General) - 普适的安全准则
本节开宗明义,强调了后续章节的普适性。
The security requirements given in this clause apply to all types of gNBs. More stringent requirements for specific types of gNBs may be defined in other 3GPP specifications.
这意味着,无论老王安装的是覆盖数公里的大型宏基站,还是覆盖一个商场的微基站,甚至是未来部署在路灯上的皮基站,都必须无一例外地遵循本章提出的所有安全要求。这为5G网络提供了一个统一且坚实的安全基线。
2. 5.3.2/5.3.3 机密性与完整性 - 空中接口的“守护神”
当安安的手机搜索到老王新开通的gNB信号并尝试连接时,gNB的首要职责之一就是建立一个安全的空中信道。这部分的要求与5.2节中对UE的要求形成了完美的“对偶”。
5.3.2 User data and signalling data confidentiality The gNB shall support ciphering of user data between the UE and the gNB. The gNB shall activate ciphering of user data based on the security policy sent by the SMF. The gNB shall support ciphering of RRC-signalling.
5.3.3 User data and signalling data integrity The gNB shall support integrity protection and replay protection of user data between the UE and the gNB. The gNB shall activate integrity protection of user data based on the security policy sent by the SMF. The gNB shall support integrity protection and replay protection of RRC-signalling.
这几段话的核心思想是:gNB作为通信的另一端,必须具备与UE完全对称的加解密和完整性保护能力。
-
对称的能力:gNB必须支持与UE相同的算法集,即强制支持
NEA0/1/2和NIA0/1/2,可选支持NEA3/NIA3。这保证了无论UE使用哪种受支持的算法,gNB都能正确地进行加解密和完整性校验。 -
执行者的角色:值得注意的是,gNB并非安全策略的决策者,而是执行者。决定是否对安安的用户数据(比如她正在看的视频)进行加密或完整性保护的策略,是由核心网的SMF(会话管理功能)制定的。该策略通过AMF下发给gNB,gNB负责忠实地执行这一策略。
-
强制的信令保护:与UE侧一样,gNB必须对RRC信令进行完整性保护。这是因为RRC信令(如切换命令、资源分配等)是无线网络的“交通指挥信号”,一旦被篡改,后果不堪设𝐠。
NOTE from 5.3.3: Integrity protection of user plane adds the overhead of the packet size and increases the processing load both in the UE and the gNB. NIA0 will add an unnecessary overhead of 32-bits MAC with no security benefits.
规范中的这个注脚(NOTE)非常重要,它解释了为什么用户平面完整性保护是可选的。对每个数据包都计算MAC值会增加32位的额外开销,并消耗大量的计算资源。对于追求极致速率和时延的eMBB业务,这个开销可能是不可接受的。因此,规范允许网络根据业务需求来权衡。同时,它也明确指出,使用NIA0(空完整性算法)去“保护”用户数据是没有意义的,因为它只增加了开销,却不提供任何安全增益。
场景代入:老王完成了gNB的初始配置。这时,安安的手机发起了连接请求。
- gNB从核心网AMF那里接收到了为安安生成的密钥
KgNB以及她的安全能力。 - 同时,负责安安视频业务的SMF下发了安全策略:“加密:需要;完整性:不需要”。
- gNB根据这些信息,选择了双方都支持的最高优先级的加密算法(如AES),并启动了RRC信令的完整性保护和加密,同时按照策略,只对用户数据进行加密,而不进行完整性保护。
3. 5.3.4 gNB的自身安全:安装与配置 (Requirements for the gNB setup and configuration) - “打铁还需自身硬”
gNB不仅要保护别人,更要保护自己。由于gNB物理上分散部署,它本身就是潜在的攻击目标。5.3.4节详细规定了如何确保gNB从“出生”到“上岗”全过程的自身安全。
Setting up and configuring gNBs by O&M systems shall be authenticated and authorized by gNB so that attackers shall not be able to modify the gNB settings and software configurations via local or remote access.
- The certificate enrolment mechanism specified in TS 33.310 for base station should be supported for gNBs.
- Communication between the O&M systems and the gNB shall be confidentiality, integrity and replay protected…
- The gNB shall be able to ensure that software/data change attempts are authorized.
- The gNB software update shall be verified before its installation…
场景代入:老王正在对楼顶的gNB进行最后的配置。他的每一步操作,都受到了规范的严格约束。
-
安全的远程管理:老王通过笔记本电脑连接到公司的运维管理中心(O&M),再由O&M远程配置gNB。他和O&M之间,以及O&M和gNB之间的所有通信链路,都必须是经过认证和加密的(例如使用IPsec VPN)。这防止了攻击者冒充老王向gNB下发恶意指令。
-
gNB的“数字身份证”:在gNB首次上电并连接到核心网时,它需要一个可信的身份。规范推荐使用证书注册机制。gNB会生成一对公私钥,并将包含其公钥和身份信息的证书签名请求(CSR)发送给运营商的证书颁发机构(CA)。CA审核通过后,会为其签发一个唯一的数字证书。这张证书就是gNB在网络世界中不可伪造的“身份证”,用于后续与其他网络实体(如AMF)建立安全的TLS/IPsec连接。
-
安全的软件更新:厂商发布了一个新的gNB软件版本。老王不能随便下载一个文件就进行更新。这个软件更新包必须经过厂商的数字签名。当gNB收到更新包后,它会用预置在设备内的厂商公钥来验证签名。只有验证通过,确认软件是来自合法厂商且未被篡改,gNB才会执行安装。
-
安全的启动过程:gNB内部采用了“安全启动”(Secure Boot)机制。从开机的第一行代码(Bootloader)开始,每一级程序在加载下一级程序前,都会对其进行签名验证。这形成了一个信任链,确保了从硬件上电到操作系统完全运行,整个软件栈都是可信的,没有被植入恶意代码。
这些措施确保了gNB自身是一个可信的计算平台,这是它能承担后续所有安全职责的基础。
4. 5.3.5 - 5.3.8 gNB内部的安全环境 (Secure Environment) - 基站的“保险箱”
即使gNB的物理外壳和软件系统是安全的,其内部处理的密钥和敏感数据仍然需要最高级别的保护。
5.3.5 Requirements for key management inside the gNB Any part of a gNB deployment that stores or processes keys in cleartext shall be protected from physical attacks. If not, the whole entity is placed in a physically secure location, then keys in cleartext shall be stored and processed in a secure environment. Keys stored inside a secure environment … shall never leave the secure environment…
5.3.8 Requirements for secure environment of the gNB The secure environment is logically defined within the gNB. It ensures protection and secrecy of all sensitive information and operations from any unauthorized access or exposure.
这些章节共同定义了gNB内部的一个逻辑概念——安全环境(Secure Environment)。 这可以类比于我们之前在UE章节中提到的“防篡改硬件”。在gNB中,这也通常是一个硬件安全模块(HSM)或者一个基于可信执行环境(TEE)技术构建的隔离区域。
这个“安全环境”的职责是:
- 安全存储:保护gNB的长期身份密钥、数字证书私钥,以及从AMF下发给每个UE的会话密钥
KgNB。 - 安全运算:所有敏感的密码学运算,如RRC和UP数据的加解密,都必须在这个安全环境中执行。
- 隔离性:存储在安全环境中的密钥,永远不能以明文形式出现在gNB的通用处理器或内存中。
场景代入:老王安装的这台gNB,其核心主板上焊接了一块专用的安全芯片。当AMF将用于保护安安通信的密钥KgNB下发给gNB时,这个密钥被直接送入安全芯片,并被加密存储。当安安手机发来一个加密的数据包时,gNB的通用处理器会将这个数据包传递给安全芯片,由安全芯片完成解密,然后再将解密后的数据(如果需要转发给核心网)送出。整个过程中,KgNB从未暴露在安全芯片之外。
5. 5.3.9 & 5.3.10 分布式基站的接口安全 (F1/E1 Interfaces)
现代5G基站普遍采用CU-DU分离架构。DU(Distributed Unit)负责处理基带和射频,靠近天线部署;CU(Centralized Unit)负责处理高层协议,可以集中部署在区域机房。CU和DU之间通过F1接口连接。
5.3.9 Requirements for the gNB F1 interfaces F1-C interface shall support confidentiality, integrity and replay protection. The gNB shall support confidentiality, integrity and replay protection on the gNB DU-CU F1-U interface for user plane.
5.3.10 Requirements for the gNB E1 interfaces The E1 interface between CU-CP and CU-UP shall be confidentiality, integrity and replay protected.
规范强制要求保护CU和DU之间的F1-C(控制面)和F1-U(用户面)接口,以及CU内部分离的CU-CP和CU-UP之间的E1接口。
为什么这很重要? 因为CU和DU之间的传输网络(称为前传网络,Fronthaul)可能并非运营商自建的专用光纤,而可能是租用的商业网络链路。这意味着这条链路本身是不可信的。如果不加以保护,攻击者就可以在这条链路上窃听或篡改一个基站的所有用户数据和信令。因此,必须使用IPsec等技术对F1/E1接口进行端到端的安全保护。
场景代入:老王安装的只是一个DU设备,而与之配套的CU设备位于数公里外的中心机房。它们之间的连接是通过租用的一条商业光纤。gNB的软件会自动在这条光纤上建立一个IPsec隧道,所有CU和DU之间的F1信令和数据,都在这个加密隧道中传输,确保了即使有人在光纤上进行窃听,也无法获取任何有用信息。
6. 总结
通过对5.3节的深入解读,我们清晰地看到,5G gNB远不止是一个简单的信号收发器,它是一个被多层安全机制层层包裹的、高度强化的网络节点。
- 对外,它是空中卫士:与UE对称地执行强大的加密和完整性保护算法,守护着无线信道的安全。
- 对内,它是坚固堡垒:通过安全启动、软件签名验证、证书身份管理等机制,确保自身平台的安全可信。
- 其核心,是数字金库:拥有一个硬件级的“安全环境”,以“密钥不出库”的原则,死守着最敏感的密钥材料。
- 其架构,考虑周全:即使在CU-DU分离的分布式部署模式下,也通过强制的接口保护,将安全风险降至最低。
老王完成了一天的工作,楼顶的gNB已经正式上岗。当安安从楼下走过,她的手机与这台gNB完成了一次快速而安全的连接,她对此毫无察觉,只是感觉手机网络一如既往的流畅。这背后,正是5.3节所定义的这些严苛的安全需求在默默守护。
FAQ
Q1:gNB的安全性和4G eNB相比,主要增强在哪些方面?
A1:主要增强在三个方面:1) 自身平台安全:33.501对gNB的安全启动、软件完整性验证、O&M安全接入等方面提出了比4G时代更明确和严格的要求。2) 密钥管理:引入了更灵活的密钥更新机制(如Key-change-on-the-fly),并且对KgNB在gNB内部的安全存储和处理要求更高。3) 架构安全:针对5G的CU-DU分离架构,明确要求对F1/E1等新的内部分裂接口进行强制性的安全保护,这是4G eNB所没有的。
Q2:gNB物理上暴露在外,如果整个设备被盗,安全会受到威胁吗?
A2:会有威胁,但规范的设计最大限度地降低了这种威胁。即使gNB被盗,攻击者也无法从中提取出用户的长期密钥K(因为它根本不在gNB中)或核心网的根密钥。由于规范要求KgNB等会话密钥必须存储在“安全环境”中,攻击者想通过物理手段(如拆解芯片)来提取这些密钥的难度极大。最大的风险是,攻击者可能获取gNB自身的身份私钥/证书,从而可能尝试冒充该gNB。但运营商可以通过吊销其证书来快速响应,使其无法再接入核心网。
Q3:为什么gNB需要支持多种加密/完整性算法,而不是只用一种最强的? A3:这主要是出于互联互通性、向后兼容性和策略灵活性的考虑。1) 互联互通:全球有成千上万的终端制造商和运营商,标准化一个算法“集合”而不是单一算法,可以给各方留有一定的选择空间,同时保证只要在集合内就能互通。2) 向后兼容:一些老的终端可能不支持最新的算法。3) 策略灵活性:不同的业务(如物联网、高清视频、普通网页浏览)对安全和性能的要求不同,支持多种算法可以让网络根据业务需求、终端能力和安全策略,灵活地选择最合适的算法,实现安全与性能的最佳平衡。
Q4:CU-DU分离架构下,安全处理是在CU还是DU完成? A4:这取决于协议层。通常,较高层次的安全协议(如NAS信令的端到端保护)的终结点在核心网的AMF,与CU/DU无关。对于无线侧(AS)的安全,RRC信令的处理终结在CU,而用户数据(UP)的PDCP层处理(包括加密和完整性保护)也通常位于CU(CU-UP)。DU更专注于物理层和MAC层的处理。因此,大部分AS层的密码学运算是在CU的“安全环境”中完成的。这也是为什么保护CU和DU之间的F1接口如此重要的原因,因为未加密的用户数据和部分控制信息需要在它们之间传递。
Q5:谁来为gNB签发数字证书?这个过程是自动的吗? A5:为gNB签发数字证书的是运营商自己的证书颁发机构(CA)。这个CA是运营商私有PKI(公钥基础设施)体系的一部分。这个过程通常是高度自动化的。当一个新gNB首次上电时,它会使用预置的初始凭证或配置,安全地连接到网络的注册服务器或O&M系统,然后自动发起证书签名请求(CSR)。CA在验证了gNB的合法性(例如,通过其出厂时烧录的设备序列号)后,会自动为其签发证书。这个过程被称为“证书注册”(Certificate Enrolment)。