好的,这是本系列解读的第四篇文章。在前面的章节中,我们已经为5G的空中接口构建了坚不可摧的信令和数据“保险箱”。但是,再坚固的保险箱,也依赖于两样东西:一把好锁(加密算法)和一把安全的钥匙(密钥)。如果锁的型号选错了,或者钥匙用得太久变钝了,保险箱的安全性就会大打折扣。

今天,我们将深入探讨5G安全体系中更具动态性和策略性的部分:gNodeB如何智能地选择“锁”的型号,以及在何时必须更换“钥匙”。

深度解析 3GPP TS 33.511:4.2.2.1 算法选择与密钥管理

本文技术原理深度参考了3GPP TS 33.511 V18.3.0 (2024-03) Release 18规范,我们将聚焦于第4章中关于接入层(AS)安全算法选择和密钥管理的核心条款:4.2.2.1.12 AS algorithms selection, 4.2.2.1.13 Key refresh at the gNB, 4.2.2.1.14 Bidding down prevention in Xn-handovers, 以及 4.2.2.1.15 AS protection algorithm selection in gNB change。本文将揭示gNodeB在动态安全策略执行中的“智慧”与“责任”。

引言:李明的进阶挑战——从“执行者”到“决策者”

“星辰通信”的工程师李明已经成功验证了Orion-gNB 9000的信令和用户面数据保护功能。他为此感到自豪,但他的导师艾米很快就给他提出了更深层次的问题。

“李明,我们知道gNodeB要加密,但用什么加密?”艾米问道,“我们的Orion-gNB 9000支持最先进的128-NEA3算法,但如果一部老款5G手机只支持NEA1怎么办?反之,如果一部旗舰手机进入到一个只被配置了基础算法的gNodeB覆盖区,又会发生什么?更重要的是,如果一个用户连续不断地传输高清视频长达数小时,我们能永远用同一把密钥吗?”

这些问题让李明意识到,gNodeB在安全方面扮演的角色,远不止是一个被动的“指令执行者”。在某些场景下,它必须根据环境变化,动态地做出关键的安全决策。艾米交给他今天的任务:彻底厘清gNodeB在算法选择密钥刷新这两个动态过程中的行为逻辑和规范要求。

为了让这个过程更具象化,李明设想了两个典型的5G用户:

  • 极客小张:他拥有一部最新款的旗舰5G手机,支持3GPP定义的所有最高等级的安全算法。
  • 王阿姨:她使用一部经济型5G手机,出于成本考虑,手机芯片只支持基础的几套安全算法。

现在,让我们跟随李明,看看Orion-gNB 9000将如何为这两位截然不同的用户提供既安全又兼容的通信服务。


1. 锁的选择艺术:接入层安全算法协商 (AS Algorithm Selection)

当UE(无论是小张的手机还是王阿姨的手机)初次接入gNodeB时,双方需要做的第一件事,就是在安全保护正式启动前,商定好要使用哪一套“锁具”,即哪种加密算法和完整性保护算法。这个过程并非简单的“我用什么你就得用什么”,而是一场有规则的“双向奔赴”。

4.2.2.1.12 AS algorithms selection Requirement Name: AS algorithms selection Requirement Reference: TS 33.501, clause 6.7.3.0 and clause 5.11.2. Requirement Description: The gNB selects the algorithms to use dependent on: the UE security capabilities of the UE, the configured allowed list of security capabilities of the currently gNB as specified in TS 33.501, clause 5.11.2. Each gNB is configured via network management with lists of algorithms which are allowed for usage. There is one list for integrity algorithms, and one for ciphering algorithms. These lists are ordered according to a priority decided by the operator as specified in TS 33.501, clause 6.7.3.0.

【李明的深度解读】

这段描述揭示了算法选择的核心逻辑,李明将其总结为“gNB主导下的交集内最优原则”。

  1. UE亮出底牌:首先,UE在接入过程中,会向网络(通过gNodeB)上报自己的“安全能力”(UE Security Capabilities)。这份清单详细说明了它支持哪些加密算法(如NEA1, NEA2, NEA3…)和完整性保护算法(如NIA1, NIA2, NIA3…)。

    • 极客小张的手机会上报一个长长的列表,包含所有新旧算法。
    • 王阿姨的手机则可能只上报一个较短的列表,比如仅支持NEA1和NIA1。
  2. gNodeB的“优选菜单”:每个gNodeB的“内心”都有一份由运营商通过网管系统配置好的“允许使用算法列表”。这份列表不仅规定了哪些算法可以用,更重要的是,它是一个按优先级排序的列表。运营商会把他们认为最安全、最高效的算法排在最前面。例如,“赛博网络”可能会将Orion-gNB 9000的列表配置为:

    • 加密算法优先级: [NEA3, NEA2, NEA1]
    • 完整性算法优先级: [NIA3, NIA2, NIA1]
  3. gNodeB做出最终决定:gNodeB收到UE的能力后,会执行以下操作:

    • 取交集:找出UE支持的算法与gNodeB自身允许的算法之间的共同部分。
    • 按gNodeB优先级选择最优:在这个交集中,选择一个在gNodeB优先级列表中位置最靠前的算法。

【场景推演】

  • 当极客小张接入时

    • UE能力: [NEA1, NEA2, NEA3], gNB列表: [NEA3, NEA2, NEA1]
    • 交集: [NEA1, NEA2, NEA3]
    • gNodeB的选择: NEA3 (因为NEA3在gNodeB的列表中优先级最高)。
  • 当王阿姨接入时

    • UE能力: [NEA1], gNB列表: [NEA3, NEA2, NEA1]
    • 交集: [NEA1]
    • gNodeB的选择: NEA1 (这是唯一的共同选项)。

通过这种机制,gNodeB确保了在满足兼容性的前提下,总是尽可能地使用当前可用的最安全的算法。

【实验室实战:复现TC-AS-alg-select_gNB测试用例】

李明进入实验室,着手验证这一逻辑。

  1. 配置gNodeB: 他通过网管接口,将Orion-gNB 9000的加密算法优先级列表配置为 [NEA2, NEA1],并禁用NEA3。
  2. 模拟UE: 他使用UE模拟器,模拟一个仅支持 [NEA1] 的老旧UE(王阿姨的手机)发起注册请求。
  3. 捕获与验证: 他捕获了gNodeB后续下发的 AS SECURITY MODE COMMAND 消息。通过解析该消息,他确认其中指定的加密算法正是 NEA1
  4. 重复测试: 随后,他又模拟了一个支持 [NEA1, NEA2, NEA3] 的高端UE(小张的手机)。再次捕获 AS SECURITY MODE COMMAND 消息,发现这次gNodeB选择的算法是 NEA2,因为它是在交集 [NEA1, NEA2] 中,gNodeB侧优先级最高的算法。

Expected Results: The gNB initiates the SECURITY MODE COMMAND message that includes the chosen algorithm with the highest priority according to the ordered lists and is contained in the UE NR security capabilities.

实验结果与预期完全一致,证明Orion-gNB 9000的算法选择逻辑完美符合规范。


2. 移动中的安全握手:切换时的算法选择与防护

用户在网络中是移动的。当小张或王阿姨从一个gNodeB覆盖区移动到另一个gNodeB时,安全上下文也需要随之迁移。这个过程引入了新的安全挑战和要求。

2.1 切换中的“防骗术”:防止降级攻击 (Bidding Down Prevention)

4.2.2.1.14 Bidding down prevention in Xn-handovers Requirement Name: Bidding Down Prevention Requirement Reference: TS 33.501, clause 6.7.3.1 Requirement Description: In the Path-Switch message, the target gNB/ng-eNB sends the UE’s 5G security capabilities received from the source gNB/ng-eNB to the AMF. as specified in TS 33.501, clause 6.7.3.1.

【李明的深度解读】

李明立刻嗅到了这里的风险点:切换是多个网元协同的过程,如果源gNodeB是恶意的(比如一个被攻破的基站),它在向目标gNodeB传递用户信息时,会不会“撒谎”?

这就是所谓的“降级攻击”(Bidding Down Attack)。一个恶意的源gNodeB在发起切换时,可以故意告诉目标gNodeB,这个UE(比如小张的手机)只支持低级别的加密算法NEA1,尽管它实际上支持NEA3。如果目标gNodeB轻信了这个谎言,它就只会选择使用NEA1与UE通信,从而大大削弱了通信的安全性。

为了防止这种情况,规范设计了一个闭环校验机制。在切换流程中,目标gNodeB在从源gNodeB处获得UE的安全能力后,并不会完全相信它。它需要将这份能力清单包含在发往核心网AMF的 Path-Switch 消息中。AMF保存着UE在注册时上报的原始、可信的安全能力。AMF可以对比这两份清单,如果发现不一致,就可以判定这是一次潜在的攻击,并中止切换流程。

2.2 切换时的算法重新选择 (Algorithm Selection in gNB Change)

4.2.2.1.15 AS protection algorithm selection in gNB change Requirement Name: AS protection algorithm selection in gNB change. Requirement Description: The target gNB/ng-eNB selects the algorithm with highest priority from the received 5G security capabilities of the UE according to the prioritized locally configured list of algorithms… The chosen algorithms are indicated to the UE in the Handover Command message if the target gNB/ng-eNB selects different algorithms compared to the source gNB/ng-eNB…

【李明的深度解读】

在确保信息真实性的前提下,目标gNodeB会进行一次新的算法选择。这个过程与初始接入时完全相同:用UE的真实能力,去匹配目标gNodeB自己的、按优先级排序的算法列表,然后选出交集中的最优者。

关键点在于,不同的gNodeB可能由不同厂商提供,或者被运营商配置了不同的策略。

  • 场景一(无变化): 小张的手机(使用NEA3)从一个gNodeB切换到另一个同样将NEA3作为最高优先级的gNodeB。目标gNodeB计算后发现,最优选择依然是NEA3,与当前正在使用的算法相同。那么在发给UE的 Handover Command 消息中,就无需特别指明安全算法。
  • 场景二(有变化): 小张的手机(使用NEA3)切换到了一个老旧的、只支持NEA2和NEA1的gNodeB。目标gNodeB根据自己的能力,重新选择的最优算法是NEA2。因为这个算法与源端使用的NEA3不同,所以目标gNodeB必须在 Handover Command 中明确地告诉UE:“从现在开始,我们要用NEA2了!”

【实验室实战:复现Alg_select_change_gNB测试用例】

李明搭建了一个包含两个gNodeB的切换环境。

  • Source gNB: 算法优先级 [NEA3, NEA2, NEA1]
  • Target gNB: 算法优先级 [NEA2, NEA1] (不支持NEA3)

他模拟小张的手机先连接到Source gNB,此时协商使用的算法是NEA3。然后,他触发了一次向Target gNB的切换。通过捕获和分析 Handover Command 消息,他清晰地看到其中包含了算法变更的指示,新的加密算法被指定为 NEA2。切换完成后,他抓取用户面数据包,验证其确实是使用NEA2算法加密的。实验成功。


3. 永葆青春的秘诀:密钥刷新 (Key Refresh)

算法选对了,但如果“钥匙”用得太久,也会有风险。3GPP设计了主动的密钥刷新机制,来确保安全性不会因为时间的推移而降低。

4.2.2.1.13 Key refresh at the gNB Requirement Name: Key refresh at the gNB Requirement Reference: TS 33.501, clause 6.9.4.1; TS 38.331, clause 5.3.1.2 Requirement Description: Key refresh is possible for KgNB, KRRC-enc, KRRC-int, KUP-enc, and KUP-int (if available), and is to be initiated by the gNB/ng-eNB when a PDCP COUNTs are about to be re-used with the same Radio Bearer identity and with the same KgNB. as specified in TS 33.501, clause 6.9.4.1.

【李明的深度解读】

这个需求的核心是为了解决一个重大的密码学禁忌:密钥流重用(Keystream Reuse)

在5G中,加密算法(特别是流密码)产生的用于加密数据的伪随机比特流,被称为“密钥流”。这个密钥流的生成,依赖于两个主要输入:密钥(如KUPenc) 和一个 变化的种子(Nonce)。在5G中,这个“种子”很大程度上就依赖于我们之前提到过的PDCP COUNT

这意味着,(密钥, COUNT) 这个组合,唯一确定了一段密钥流。如果 (密钥, COUNT) 的组合发生了重复,那么产生的密钥流就会完全相同。攻击者如果能获取到两段用相同密钥流加密的密文,就可以通过简单的异或操作消除密钥流,从而得到两段明文的异或结果,这极大地降低了破解明文的难度。

因此,绝对不允许 (密钥, COUNT) 的组合出现重复!

什么时候会发生重复呢?

  1. PDCP COUNT回绕: PDCP COUNT是一个32位的计数器,虽然它很大,但对于超高速率、超长时间的连接(比如一个工业物联网设备持续数月上传海量数据),它最终会用完并从0开始。如果此时密钥(KgNB及其派生密钥)没有改变,(密钥, COUNT) 的组合就会开始重复。
  2. 无线承载(RB)重用: 在某些场景下,一个RB被释放后,它的ID可能会在短时间内被一个新的RB复用。新的RB建立时,PDCP COUNT会从0开始。如果在此期间gNodeB没有更换密钥,同样会导致 (密钥, COUNT) 组合的重复。

规范明确规定,gNodeB作为PDCP层的终结点,有责任监控COUNT的使用情况。当它预见到COUNT即将回绕,或者一个RB ID即将被重用时,gNodeB必须主动发起密钥刷新

如何刷新?规范建议的方式非常巧妙:gNodeB可以触发一次 “intra-cell handover”(小区内切换)。这相当于让UE“左手换右手”,名义上做了一次切换,但目标小区还是当前服务的小区。这个流程会触发gNodeB从AMF获取一个新的根密钥(新的NCC值),然后重新派生出一整套全新的AS密钥(KgNB, KRRC/KUP密钥等)。这样,即使COUNT从0开始,但因为密钥已经换了,(新密钥, COUNT) 组合就不会与之前重复,安全得以保证。

【实验室实战:复现TC_GNB_KEY_REFRESH_DRB_ID测试用例】

这是李明遇到的最复杂的测试之一。

  1. 模拟场景: 他设计了一个脚本,让UE模拟器在一次RRC连接中,反复地建立和释放IMS通话。这会导致用于承载通话语音的DRB(Data Radio Bearer)被频繁地建立和拆除,很容易触发DRB ID的重用。
  2. 监控与触发: 他在后台严密监控Orion-gNB 9000的内部状态,特别是DRB ID的分配池和每个RB的PDCP COUNT。
  3. 验证行为: 在脚本运行到即将发生DRB ID重用的临界点时,他通过信令分析仪观察到,Orion-gNB 9000主动发起了一次小区内切换流程。切换完成后,他通过gNodeB的内部日志和与核心网的接口消息确认,gNodeB确实使用了新的AS密钥。

实验成功!Orion-gNB 9000像一个负责任的“安全管家”,在风险发生前就主动更换了门锁,确保了通信长期的安全。


FAQ 环节

Q1:gNodeB上配置的算法优先级列表由谁决定? A1:这个列表完全由运营商决定,并通过网络管理系统(OAM)进行配置。运营商会根据自己的网络策略、设备能力和安全考虑来设定。例如,一个追求极致安全的运营商可能会将最新的、经过更严格安全审计的算法放在最高优先级;而一个需要兼容大量老旧物联网终端的运营商,可能会将兼容性更好的算法也保留在列表中。

Q2:如果UE和gNodeB支持的算法没有任何交集,会发生什么? A2:如果双方的算法能力列表没有任何共同支持的算法,那么安全模式将无法建立。gNodeB在发送 AS SECURITY MODE COMMAND 之后,会收不到UE正确的 AS SECURITY MODE COMPLETE 响应,最终会导致接入失败和RRC连接释放。

Q3:密钥刷新是一个很频繁的操作吗?对用户体验有影响吗? A3:对于普通的用户上网、打电话等业务,PDCP COUNT要达到回绕需要非常长的时间,因此密钥刷新并不频繁。它主要针对那些有极大流量或极长连接时长的特殊业务,如高清视频直播、工业数据采集等。刷新过程(如小区内切换)通常非常快,对用户来说是无感的,不会造成业务中断。

Q4:除了小区内切换,还有其他方式可以刷新密钥吗? A4:是的。另一种有效的方式是让UE进入RRC_IDLE或RRC_INACTIVE状态,然后再返回RRC_CONNECTED状态。这个“状态转换”过程同样会触发一次新的AS密钥派生,从而达到刷新密钥的目的。gNodeB可以根据网络负载和具体情况选择最合适的方式。

Q5:切换时的“降级攻击”听起来很危险,仅靠AMF的校验足够吗? A5:AMF的校验是防御降级攻击的核心机制,因为它拥有对UE能力的最高信任记录。此外,整个5G安全架构是分层防御的。即使降级攻击得逞(例如,AMF的校验功能因某种原因被绕过),也只是将算法强度降低,并不会导致加密或完整性保护完全失效。而且,所有接口(如Xn接口)本身都受到IPsec的保护,使得在传输过程中篡改信令变得非常困难。因此,这是一个多重保障下的纵深防御体系。