51学通信

深度解析 3GPP TS 33.401：5.3 Security requirements on eNodeB (对eNodeB的安全要求)

30分钟阅读

好的，我们继续深入TS 33.401的殿堂。上一章我们详细探讨了用户与网络交互最前沿的5.1节，现在，我们将把目光从用户终端转向网络的“前哨”——基站（eNodeB），并审视规范对其提出的严苛安全要求。

深度解析 3GPP TS 33.401：5.3 Security requirements on eNodeB (对eNodeB的安全要求)

本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“5.2 Security visibility and configurability”与“5.3 Security requirements on eNodeB”的核心章节，旨在为读者揭示4G基站作为网络安全第一道物理防线的关键作用及其必须满足的硬性安全指标。

在前文中，我们跟随主角“小明”的视角，体验了从身份隐藏到空口加解密的完整用户-网络安全流程。这些流程大多发生在小明的手机和远端的核心网之间。然而，在这条漫长的通信链路上，有一个实体是无法绕过的，它既是空口安全的终结点，也是接入网安全的起始点，它就是——eNodeB（基站）。

基站通常部署在城市街道的灯杆上、建筑物的楼顶，甚至是偏远郊外的铁塔上。这种物理上的“暴露”特性，使得它成为整个通信网络中最容易受到物理攻击和近场攻击的薄弱环节。如果一个基站被“黑化”，其后果不堪设想：它可能成为一个超级“伪基站”，窃听其覆盖下所有用户的通信；也可能成为攻击者滲透运营商核心网的“跳板”。

因此，3GPP对eNodeB提出了极其严格的安全要求。在深入探讨5.3节之前，我们先快速过一下内容非常简短的5.2节。

1. 透明的安全：可视性与可配置性 (5.2 Security visibility and configurability)

本章节篇幅极短，旨在阐述用户对于网络安全的知情权和控制权，是安全架构五大支柱中“V”部分的具体体现。

Although in general the security features should be transparent to the user, for certain events and according to the user’s concern, greater user visibility of the operation of following security feature shall be provided:

  • indication of access network encryption: the property that the user is informed whether the confidentiality of user data is protected on the radio access link, in particular when non-ciphered calls are set-up;

可视性（Visibility）：规范指出，通常安全特性对用户应该是透明的，但在特定情况下，用户应该被告知安全功能的运行状态。最典型的例子就是“接入网加密指示”。比如，当建立一个未加密的通话时，手机应该有能力（例如通过屏幕上的一个特殊图标）告知用户“您当前的通话未受保护”。在早期的2G网络或一些特殊通话（如某些VoIP应用）中，这种指示比较有意义。但在今天的4G/5G网络中，空口加密已成为默认配置，因此我们很少在手机上看到明确的“已加密”提示，因为它已经是“理所当然”的了。

Configurability is the property that the user can configure whether the use or the provision of a service should depend on whether a security feature is in operation… The following configurability features are suggested:

  • enabling/disabling user-USIM authentication…

可配置性（Configurability）：规范建议，用户应该能够配置是否将服务的使用与安全功能的开启相绑定。例如，一个对安全极度敏感的用户可以设置：“如果网络不支持双向认证，则我的手机不允许接入”。然而，与可视性类似，这种高级配置选项在面向公众的商用网络中几乎不提供，因为错误的配置可能导致用户无法正常使用网络服务。

简而言之，5.2节定义了一种理想化的用户与安全的交互模式。虽然在日常使用中我们很少直接接触，但它体现了标准制定者对用户权利的尊重。现在，让我们将焦点转向更为硬核的技术要求——对eNodeB的安全规定。

2. 网络的“城门”：为何必须加固eNodeB？(5.3.1 General)

5.3节开宗明义，指出本章的安全要求适用于所有类型的eNodeB。

The security requirements given in this clause apply to all types of eNodeBs. More stringent requirements for specific types of eNodeBs may be defined in other 3GPP specifications.

eNodeB是整个EPS网络的“城门”。所有用户的数据流和控制流都必须经过这道门才能进入核心网这座“内城”。加固“城门”的意义不言而喻。本章接下来的内容，就是为这座“城门”的设计和运作，制定了一系列金科玉律。

3. “准入”的门槛：eNB的安装与配置安全 (5.3.2 Requirements for eNB setup and configuration)

一个全新的eNodeB设备，从仓库里拿出来，安装到站址，再到开通服务，这个过程本身就充满了安全风险。如果任何人都可以在路边装一个“eNodeB”并接入运营商的核心网，那整个网络就形同虚设。5.3.2节正是为了规避这些风险，提出了7点关键要求。

要求1：与核心网及邻居基站建立安全连接

  1. The support of security associations is required between the Evolved Packet Core (EPC) and the eNB and between adjacent eNBs, connected via X2. These security association establishments shall be mutually authenticated and used for user and control plane communication between the entities.

深度解读：一个新eNB在上电后，它要做的第一件事不是为用户服务，而是向核心网（EPC）“报到”并证明自己的合法身份。同样，它也需要和它的邻居eNBs建立信任关系，以便进行快速切换。这个“报到”和“建立邻里关系”的过程，不是简单的发个“Hello”消息，而是要建立一个经过相互认证的安全联盟（Security Association, SA）。

  • 技术实现：这个过程通常采用IPsec/IKEv2技术。每个合法的eNodeB在出厂或部署前，都会被运营商写入一个唯一的数字证书（就像是它的身份证）。当eNB首次连接核心网时，它会与核心网的安全网关（SEG）通过IKEv2协议交换证书，验证彼此的身份。验证通过后，它们会协商出一套密钥，用于建立一条IPsec加密隧道。

  • 场景串联：运营商“M-Operator”的工程师在小明家小区楼顶新安装了一个eNodeB。工程师接通电源和传输光纤后，这个eNodeB并不会立刻开始广播信号。它会先通过光纤，找到核心网的安全网关，并发起IKEv2握手。它出示自己的证书说：“我是总部派来的编号为BJ-HD-075的基站，这是我的身份证明。”安全网关验证证书后，确认无误，也出示自己的证书，并与之协商出一套“秘密接头暗号”（IPsec密钥）。从此，这个eNodeB和核心网之间的所有通信（S1接口），都将在这条加密隧道中进行。它与邻居基站建立X2接口的过程也与此类似。

要求2：与运维管理系统（O&M）的安全通信

  1. Communication between the O&M systems and the eNB shall be confidentiality, integrity and replay protected from unauthorized parties…These security association establishments shall be mutually authenticated.

深度解读：O&M系统是运营商用于远程配置、监控和维护基站的“大脑”。工程师可以通过O&M系统修改基站的发射功率、配置小区参数、升级软件版本等。如果这条管理通道不安全，攻击者就可以冒充O&M系统，向基站下发恶意指令，比如让它停止服务，或者把它变成一个钓鱼基站。因此，规范强制要求eNB与O&M系统之间的通信也必须是经过相互认证、加密、完整性保护和抗重放的。实现方式同样可以是IPsec/IKEv2或TLS。

要求3 & 4：软件/数据的授权与来源验证

  1. The eNB shall be able to ensure that software/data change attempts are authorized
  1. The eNB shall use authorized data/software.

深度解读：这两条要求关注的是软件供应链安全。eNodeB的操作系统和配置文件如果被恶意篡改，其行为将完全失控。

  • 授权更改：意味着eNodeB必须有机制验证收到的配置或软件更新指令是否来自合法的O&M系统（关联要求2）。

  • 使用授权软件：意味着eNodeB在加载或升级软件时，必须验证软件本身的合法性。这通常通过安全启动（Secure Boot）和软件签名来实现。运营商发布的每一个软件版本，都会用自己的私钥进行数字签名。eNodeB在启动或升级时，会用预置的运营商公钥来验证这个签名。签名验证失败的软件将被拒绝加载。

  • 场景串联：“M-Operator”需要为小明所在小区的eNodeB升级一个补丁以优化性能。运维中心将签好名的软件包推送到eNodeB。eNodeB收到后，首先通过安全的O&M通道确认了指令的合法性。然后，在安装前，它使用内置的运营商公钥，对软件包的数字签名进行校验。校验通过，确认软件包在传输过程中未被篡改，且确实是官方发布的，eNodeB才会执行升级操作。

要求5, 6, 7：启动与软件加载过程的安全

  1. Sensitive parts of the boot-up process shall be executed with the help of the secure environment.
  1. Confidentiality of software transfer towards the eNB shall be ensured.
  1. Integrity protection of software transfer towards the eNB shall be ensured.

深度解读：这三条是对软件安全要求的进一步细化和强调。

  • 安全启动环境：要求eNodeB的启动过程本身是分阶段、可信的。从最底层的Boot ROM（通常是固化且不可更改的）开始，每一级的加载器都会验证下一级代码的签名，形成一条“信任链”，直到整个操作系统安全加载。

  • 软件传输的机密性和完整性：重申了在向eNodeB传输软件升级包的过程中，必须保证其不被窃听（机密性）和篡改（完整性）。这通常由安全的O&M通道（如IPsec或TLS）来保障。

4. “保险柜”的设计：eNB内部的密钥管理 (5.3.3 Requirements for key management inside eNB)

eNodeB在运行过程中，会存储和处理大量的密钥。除了与核心网、O&M系统建立隧道所需的长期密钥（证书私钥），更重要的是它会为每一个连接到它的用户（比如小明）临时保存会话密钥KeNB以及由KeNB派生的KRRC和KUP密钥。如果这些密钥泄露，后果不堪设想。

  1. Keys stored inside eNBs shall never leave a secure environment within the eNB except when done in accordance with this or other 3GPP specifications.

深度解读：这是对eNodeB内部密钥管理提出的核心原则——密钥不离安全区。

  • 安全环境 (Secure Environment)：这不是一个泛泛的概念，而是指eNodeB硬件内部一个经过特殊安全设计的隔离区域。这可以是一个专用的硬件安全模块（HSM），也可以是基于ARM TrustZone等技术构建的可信执行环境（TEE）。这个环境与eNodeB的普通操作系统（如Linux）是隔离的，即使普通系统被攻破，攻击者也无法直接访问到安全环境中的数据。

  • 密钥的生命周期：所有密钥的产生（或接收）、存储、使用和销毁，都必须在这个“安全环境”内部完成。例如，当MME通过S1接口将小明的KeNB发送给eNodeB时，这个密钥会被直接送入安全环境，并存储在其中。当需要加密发送给小明的数据时，是普通系统将明文数据“喂”给安全环境，由安全环境使用KUPenc密钥完成加密，再将密文返回给普通系统去发送。密钥本身从未暴露在不安全的环境中。

  • 例外情况：规范也指出了例外，即“按照3GPP规范的要求”。一个典型的例子是在X2切换时，源eNB需要将用户的安全上下文（包含KeNB派生的KeNB*）通过安全的X2隧道发送给目标eNB。这个过程是在规范的严格定义和保护下进行的。

场景串联：为小明的视频通话会话派生的KeNB，被安全地存储在小区楼顶eNodeB主板上的一个专用安全芯片中。这个芯片就是“安全环境”。当eNodeB的无线协议栈需要加密一个发往小明手机的数据包时，它会调用一个特殊的驱动程序接口，将数据包和加密指令发送给这个安全芯片。芯片内部完成加密操作后，将加密后的数据包返回。整个过程中，KeNB密钥就像一位从不出“保险柜”的神秘工匠，默默地完成着它的工作。

5. 数据的“安全中转站”：用户面与控制面数据处理 (5.3.4 & 5.3.4a)

这两节分别对用户面（UP）和控制面（CP）数据在eNodeB内部的处理流程提出了安全要求。它们的核心思想是一致的，并且是5.3.3节密钥管理原则的自然延伸。

5.3.4 - 1. User plane data ciphering/deciphering and integrity handling shall take place inside the secure environment where the related keys are stored.

5.3.4a - 1. Control plane data ciphering/deciphering and integrity handling shall take place inside the secure environment where the related keys are stored.

深度解读：这两条规定了**“谁持有密钥，谁执行运算”**的原则。既然密钥被安全地存储在“安全环境”中，那么所有使用这些密钥的密码学运算（加密、解密、完整性计算与校验）也必须在这个安全环境中执行。这彻底杜绝了将密钥从安全区读出到普通内存中再进行计算的危险操作。

5.3.4 - 2. The transport of user data over S1-U and X2-U shall be integrity, confidentially and replay-protected…

5.3.4a - 2. The transport of control plane data over S1-MME … and X2-C shall be integrity-, confidentiality- and replay-protected…

深度解读：这两条再次强调了对回传链路（S1和X2接口）的安全要求，与5.3.2中的第一条要求相呼应，构成了完整的端到端（UE-EPC）安全链条中的关键一环：接入网回传安全。

场景串联（完整流程）：

  1. 小明发给朋友的一张图片（用户数据），在手机内部被KUPenc加密，通过空口发送。

  2. eNodeB接收到加密数据包，将其送入安全环境。

  3. 安全环境使用存储的KUPenc密钥将数据包解密。

  4. 解密后的IP包需要通过S1-U接口送往核心网。此时，eNodeB的IPsec模块（它本身也可以被视为或集成在安全环境中）使用与核心网SEG协商好的IPsec密钥，将这个IP包再次加密，封装进IPsec隧道。

  5. 加密后的数据包通过运营商的地面传输网，安全抵达核心网。

这个“解密-再加密”的过程，确保了数据在eNodeB这个“中转站”的内部流转也是受控和安全的，并且在不同安全域（空口域 vs. 网络域）之间进行了清晰的转换。

6. “黑匣子”的属性：对安全环境的最终定义 (5.3.5 Requirements for secure environment of the eNB)

本节是对前面多次提到的“安全环境”这个概念的一个总结和正式定义。它列出了一个合格的eNodeB安全环境必须具备的六大核心属性，如同定义一个“黑匣子”的制造标准。

  1. The secure environment shall support secure storage of sensitive data…
  1. The secure environment shall support the execution of sensitive functions…
  1. Sensitive data used within the secure environment shall not be exposed to external entities.
  1. The secure environment shall support the execution of sensitive parts of the boot process.
  1. The secure environment’s integrity shall be assured.
  1. Only authorised access shall be granted to the secure environment…

深度解读：

  1. 安全存储：必须能抵抗物理和软件攻击，保护存储在其中的密钥和配置数据。

  2. 安全执行：必须能安全地运行加密、解密等敏感的算法代码。

  3. 信息隐藏：内部的敏感数据（如密钥）绝不能泄露到环境外部。

  4. 可信启动根：必须是安全启动链条的一部分，保证其自身代码的完整性。

  5. 自身完整性：必须有机制保证环境本身的软硬件没有被篡改。

  6. 访问控制：必须有严格的接口和权限控制，只允许授权的模块以预定义的方式与其交互。

这六点共同定义了一个理想的、可信的计算环境，它是eNodeB能够成为一个可信网络节点的基础。

规范的5.4节为空节 (Void)，代表无内容。

7. 总结

第五章的5.2和5.3节，将我们的视角从终端用户拉到了网络基础设施的第一线——eNodeB。规范通过一系列严苛、细致且环环相扣的要求，为这个暴露在外的“城门”构建了坚不可摧的防御体系。

  • 从部署阶段开始，通过基于证书的相互认证，确保了只有“根正苗红”的设备才能入网。

  • 在运行阶段，通过构建一个隔离的“安全环境”，实现了密钥和敏感运算的“保险柜”式管理，做到了“密钥不出安全区，运算不离可信地”。

  • 对于软件生命周期，通过安全启动和软件签名，确保了从启动到升级的每一步都在信任链的监控之下。

  • 对于数据处理，通过“解密-再加密”的安全中转流程，无缝衔接了空口安全域和网络域安全，保证了数据流的全程保护。

这些要求共同将eNodeB从一个潜在的安全风险点，转变成了一个坚实可靠、值得信赖的网络安全基石。正是有了这些看不见的安全设计，小明才能在城市的每个角落，安心地享受4G网络带来的便利与快捷。

下一章，我们将进入更为具体和流程化的第六章 Security Procedures between UE and EPC Network Elements，深入探索AKA认证和EPS密钥体系的每一个细节，敬请期待。

FAQ 环节

Q1：eNodeB的安全要求（5.3节）和网络域安全（第11-13章）是什么关系？

A1：它们是相辅相成的关系。5.3节定义了eNodeB作为一个实体必须具备的内在安全能力和行为准则，比如它必须有安全环境、必须能进行安全启动、必须在安全环境中处理密钥等。而第11-13章则具体定义了eNodeB与其它网络实体通信时所遵循的安全协议，即网络域安全，其核心就是IPsec。可以说，5.3节是eNodeB能够执行网络域安全协议的能力基础。一个连自身软件安全都无法保证的eNodeB，即使配置了IPsec，其安全性也是不可信的。

Q2：eNodeB中的“安全环境”（Secure Environment）在实际硬件中通常是什么？

A2：在实际的电信设备中，“安全环境”通常以两种主要形式存在：一种是硬件安全模块（Hardware Security Module, HSM），这是一个专用的、具有高度物理和逻辑防护能力的安全芯片或板卡，所有密码学操作和密钥存储都在其中进行。另一种是利用通用处理器中的**可信执行环境（Trusted Execution Environment, TEE）**技术，如ARM TrustZone。它在硬件层面上将处理器划分为安全世界（Secure World）和普通世界（Normal World），安全环境运行在安全世界中，与普通操作系统（如Linux）完全隔离，从而实现同等水平的安全保障。

Q3：为什么保护O&M（运维管理）通道如此重要？

A3：O&M通道是运营商对网络设备进行控制的“生命线”，拥有极高的权限。如果O&M通道被攻击者劫持，攻击者就可以冒充运营商对eNodeB进行任意操作，危害巨大。例如，攻击者可以：1) 下发恶意配置，将用户重定向到钓鱼网站；2) 关闭基站服务，造成大范围网络瘫痪；3) 推送恶意软件，将基站变成僵尸网络的一部分或持续性窃密据点；4) 窃取基站的长期密钥，从而可能冒充该基站。因此，保护O&M通道的安全，对于保障整个网络的稳定和安全至关重要。

Q4：如果一个eNodeB被物理盗窃，主要的风险是什么？规范中的要求如何缓解这些风险？

A4：主要风险有二：1) 密钥泄露：攻击者可能试图通过物理手段（如芯片解剖）提取存储在其中的长期密钥（如设备证书私钥）和短期会话密钥。2) 逆向工程：攻击者可能试图分析设备的软件，寻找漏洞。

规范的要求可以极大地缓解这些风险：

  • 安全环境：要求密钥必须存储在HSM或TEE等具有抗物理攻击设计的安全环境中，使得提取密钥的成本和难度极高。

  • 会话密钥的短暂性：用户会话密钥KeNB是临时的，一个用户离开该小区后，其KeNB很快就会失效，降低了密钥泄露的长期影响。

  • 安全启动与软件签名：确保了被盗设备即使被修改了软件也无法正常启动或接入网络，防止了逆向工程后被用于制造恶意固件。

  • 网络侧吊销：运营商发现设备失窃后，可以在核心网侧吊销该设备的数字证书，使其永远无法再通过认证接入网络。

Q5：规范中提到对S1-U和X2-U（用户面）的加密保护是“运营商的可选决定”（operator’s decision），这是为什么？

A5：这同样是出于性能和成本的权衡。在S1-U和X2-U接口上（即基站与核心网之间，或基站与基站之间）应用IPsec加密，会带来额外的处理开销（CPU消耗）和带宽开销（IPsec头部）。在一些部署场景下，运营商可能认为其回传网络（如自建的专用光纤网络）在物理上是足够安全的，为了追求极致的性能和降低设备成本，可能会选择不开启用户面的IPsec加密。然而，随着网络安全威胁的日益严峻和处理器性能的大幅提升，为主干链路开启IPsec已成为主流趋势。规范将其设为可选，是给予运营商根据自身网络环境和安全策略进行决策的灵活性。

关系图谱