51学通信

深度解析 3GPP TS 33.401：7.2.4 安全模式命令 (SMC) 与算法协商

22分钟阅读

好的，我们继续对3GPP TS 33.401第七章的深度拆解。在前一篇文章中，我们已经了解了密钥是如何在E-UTRAN中被设置、识别和进行生命周期管理的。现在，我们将进入一个至关重要的信令流程——安全模式命令（Security Mode Command, SMC）。这个流程是真正“开启”所有安全保护的“总开关”。

本文将聚焦于7.2.4节 Security mode command procedure and algorithm negotiation (安全模式命令过程与算法协商)，通过对NAS SMC和AS SMC两个核心流程的精细解读，我们将看到UE与网络是如何在一个安全的环境下，同步安全算法并激活保护的。

深度解析 3GPP TS 33.401：7.2.4 安全模式命令 (SMC) 与算法协商

本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“7.2.4 Security mode command procedure and algorithm negotiation”的核心章节，旨在为读者深入剖析NAS和AS两个层面的安全模式命令流程，揭示其在同步安全上下文、抵御降级攻击中的关键作用。

在之前的章节中，AKA流程和密钥派生已经为我们的主角“小明”的手机和网络准备好了全套的“安全装备”（即各种密钥）。但是，这些装备还静静地躺在各自的“军械库”（UE和MME/eNB的内存）中。如何才能让双方在同一时刻、以同一种方式穿上这些装备，并开始真刀真枪地进行保护呢？这就是SMC流程要完成的使命。

1. “穿上装备”前的准备：算法协商要求 (7.2.4.1 Requirements for algorithm selection)

在下达“开启安全”的命令之前，双方必须先就“使用哪款盔甲”（即哪种加密和完整性算法）达成一致。7.2.4.1节为此制定了一系列基本原则。

a) An active UE and a serving network shall agree upon algorithms for

  • RRC ciphering and RRC integrity protection (to be used between UE and eNB)
  • UP ciphering and integrity protection (to be used between UE and eNB)
  • NAS ciphering and NAS integrity protection (to be used between UE and MME)

深度解读：这条规定明确了算法协商的范围，涵盖了NAS和AS（RRC和UP）两个层面的所有加密和完整性保护。

b) The serving network shall select the algorithms to use dependent on

  • the UE security capabilities of the UE,
  • the configured allowed list of security capabilities of the currently serving network entity

深度解读：算法的选择权在网络侧（MME选择NAS算法，eNB选择AS算法）。但网络的选择不是随心所欲的，它必须基于两个条件的交集：

  1. UE的能力：UE在附着时，会向网络上报一个“能力清单”，告诉网络“我会AES、SNOW 3G和ZUC这三种武功”。

  2. 网络自身的策略：网络侧也配置了一个“优选武功秘籍”，比如“我们优先推荐使用AES，其次是ZUC，不推荐用SNOW 3G”。

网络最终会从UE会且网络也允许的算法中，选择一个网络策略里优先级最高的。

防止“降级攻击”的关键要求

算法协商过程是安全体系中最容易受到“降级攻击”的环节。所谓降级攻击，就是中间人攻击者篡改UE上报的能力，欺骗网络，让网络误以为UE只支持很弱的甚至“不加密”的算法，从而迫使双方以较低的安全级别通信。为了防范这种攻击，规范提出了两条极其重要的要求。

d) Each selected algorithm shall be acknowledged to the UE in an integrity protected way such that the UE is ensured that the algorithm selection was not manipulated…

e) The UE security capabilities the ME sent to the network shall be repeated in an integrity protected NAS level message to the ME such that “bidding down attacks” against the UE’s security capabilities can be detected by the ME.

深度解读：

  • 要求(d)：网络在SMC消息中告诉UE“我们决定用AES算法”，这条SMC消息本身必须是经过完整性保护的。这样，UE就能确认这个算法选择是网络真实的意图，而不是攻击者在半路篡改的结果。

  • 要求(e)：这是一个更巧妙的“回声”校验机制。网络在NAS SMC消息中，不仅要包含最终选择的算法，还必须把自己收到的那份“UE能力清单”原封不动地再发回给UE。UE收到后，会和自己本地存储的原始能力清单进行比对。如果发现不一致（比如自己明明上报了支持AES，但网络返回的清单里却没有），UE就知道自己的能力上报在半路被攻击者篡改了，它会立刻拒绝本次SMC，从而挫败降级攻击。

场景串联（降级攻击与防御）：

  1. 小明的手机上报能力：“我会AES (EEA2) 和 SNOW 3G (EEA1)”。

  2. 攻击者在空中截获并篡改了该消息，改为：“我只会SNOW 3G (EEA1)”。

  3. MME收到后，误以为小明的手机不支持AES，于是选择了SNOW 3G，并发起了NAS SMC。

  4. 防御启动：根据要求(e)，MME在SMC消息中会包含它所理解的“UE能力清单”，即“你上报说你只会SNOW 3G”。

  5. 小明的手机收到SMC后，拿出自己的原始清单一看：“不对啊，我明明告诉过你会AES的，你怎么说我不会？” 手机立刻意识到遭到了攻击，于是拒绝该SMC，并可能断开连接或触发异常流程。一次降级攻击就这样被成功阻止了。

AS与NAS的分离

f) Separate AS and NAS level security mode command procedures are required.

深度解读：规范明确要求NAS和AS的安全激活必须通过两个独立的SMC流程来完成。这体现了NAS与AS在功能和安全域上的分离。MME负责NAS安全，eNB负责AS安全，两者职责清晰，不能混为一谈。

2. 核心网的“金牌令箭”：NAS SMC流程 (7.2.4.3 & 7.2.4.4)

NAS SMC是UE和MME之间同步NAS安全上下文、激活NAS层保护的关键流程。

算法选择 (7.2.4.3)

To establish the NAS security context, the MME shall choose one NAS ciphering algorithm and one NAS integrity protection algorithm. The MME shall then initiate a NAS security mode command procedure, and include the chosen algorithms and UE security capabilities…in the message to the UE.

深度解读：在AKA成功后，当MME需要激活NAS安全时（例如，在响应UE的Attach Request时），它会根据UE上报的能力和本地策略，选择好NAS加密和完整性算法，然后准备发起NAS SMC流程。

信令交互 (7.2.4.4)

Figure 7.2.4.4-1: NAS Security Mode Command procedure 描绘了NAS SMC的信令交互，这是一个简单的“请求-响应”过程。

  1. MME发送 NAS Security Mode Command

    这条消息是NAS SMC流程的核心，它包含了丰富的信息，并且其自身的安全处理也极为讲究。

    • 内容：

      • eKSI: 指明本次SMC要激活的是哪个KASME密钥集。

      • Replayed UE security capabilities: “回声”校验用的UE能力清单。

      • Selected NAS algorithms: MME最终选定的NAS加密和完整性算法。

      • NONCEUE, NONCEMME (可选): 在从2G/3G进行idle模式切换到4G的场景下，需要用到这两个随机数来派生映射密钥。

      • NAS-MAC: 这条消息本身的完整性校验码。

    • 安全处理：

      This message shall be integrity protected (but not ciphered) with NAS integrity key based on KASME indicated by the eKSI in the message.

      深度解读：NAS Security Mode Command消息本身只进行完整性保护，不进行加密。这是为什么呢？因为此时UE侧的NAS解密功能还未被激活，如果加密了UE将无法解开。但完整性保护是必须的，它使用即将被激活的新KNASint密钥进行计算，确保了这条“开机指令”本身不会被篡改。

  2. UE的验证与响应

    UE收到NAS Security Mode Command后，会进行一系列严格的校验：

    • 完整性校验：使用eKSI找到对应的KASME，派生出KNASint，然后校验消息的NAS-MAC是否正确。

    • 能力“回声”校验：比对消息中包含的UE能力清单是否与自己原始上报的一致。

    • 其他校验（如NONCE校验等）。

    如果所有校验都通过：

    If the checks of the NAS Security Mode Command pass the UE shall respond with a NAS Security Mode Complete…The NAS Security Mode Complete message shall include IMEISV in case MME requested it…this message [is] to MME ciphered and integrity protected.

    深度解读：UE会回复一条NAS Security Mode Complete消息。从这一刻起，UE的NAS安全正式被激活。因此，这条响应消息本身就必须是经过加密和完整性保护的，它成为了双方之间第一条被双重保护的NAS信令。这条消息还可以顺便携带MME之前请求的IMEISV。

  3. MME的最终确认

    MME收到并成功解密、验证NAS Security Mode Complete消息后，整个NAS SMC流程宣告成功。从此以后，MME与该UE之间的所有NAS信令都将处于被加密和完整性保护的状态。

启动时机：NAS SMC流程成功后，UE侧立即启动上行NAS消息的加密和完整性保护；MME侧在发送完SMC命令后，就开始准备接收加密的上行消息，在收到SMC Complete后，则启动下行消息的加密。

3. 接入网的“最后通牒”：AS SMC流程 (7.2.4.5)

在NAS安全建立之后，UE与MME之间的“内部通道”已经安全。接下来，需要为UE与基站eNB之间的“空战”做好准备。这个过程由AS SMC完成。

前提：NAS安全激活后，MME会将用户的AS安全上下文（包括KeNB、UE的AS安全能力、NH等）通过S1接口下发给eNB（Initial Context Setup流程）。eNB收到这些“弹药”后，就可以发起AS SMC了。

Figure 7.2.4.5-1: AS security setup 描绘了AS SMC的交互过程。

  1. eNB发送 AS Security Mode Command

    The AS security mode command message from eNB to UE shall contain the selected AS algorithms. This message shall be integrity protected with RRC integrity key based on the current KASME.

    深度解读：

    • 内容：这条RRC消息中包含了eNB根据UE的AS能力和自身策略选择的RRC和UP层面的加密和完整性算法。

    • 安全处理：与NAS SMC类似，这条命令本身也只做完整性保护，不做加密。它使用的是即将被激活的KRRCint密钥。

    注意：这里的规范原文based on the current KASME在早期版本中存在，后续版本中更精确的描述应为based on the new KeNB and KRRCint derived from it。AS SMC的保护密钥是KRRCint，其根源是MME下发的KeNB。

  2. UE的验证与响应

    UE收到AS Security Mode Command后，会使用MME下发的KeNB派生出KRRCint，并校验该命令的完整性。如果通过：

    The AS security mode complete message from UE to eNB shall be integrity protected with the selected RRC algorithm indicated in the AS security mode command message and RRC integrity key based on the current KASME.

    深度解读：UE会回复一条AS Security Mode Complete消息。这条响应消息本身也是只做完整性保护，不做加密。因为此时RRC层的加密功能也才刚刚在UE侧激活，eNB侧还未激活。

  3. 双方激活AS安全

    • UE在发送完AS Security Mode Complete后，立刻激活所有上行流量（RRC和UP）的加密。

    • eNB在发送完AS Security Mode Command后，就激活了所有下行流量（RRC和UP）的加密。

    • UE在收到AS Security Mode Command后，激活所有下行流量的解密。

    • eNB在收到AS Security Mode Complete后，激活所有上行流量的解密。

通过这个精密的“握手”时序，保证了双方在启用加解密功能上的同步，避免了因时序错乱导致通信中断。

4. 总结

7.2.4节为我们详细描绘了4G网络中“开启安全”这一关键动作的两个核心流程：NAS SMC和AS SMC。这两个流程虽然简单，但其设计充满了安全智慧：

  • 分层激活：严格区分NAS和AS两个层面，由不同的网络实体（MME和eNB）各自负责，体现了清晰的安全域划分。

  • 信赖链条：AS SMC必须在NAS SMC成功之后才能进行，形成了一个从核心网到接入网的信任链和安全上下文的逐级传递。

  • 防降级设计：通过巧妙的“能力回声”机制和对SMC命令本身的完整性保护，有效地抵御了针对算法协商过程的降级攻击，确保了通信的安全等级不会被恶意降低。

  • 精确同步：通过严密的信令交互时序设计，确保了UE和网络在启用和切换密钥及算法的瞬间能够精确同步，保证了业务的连续性。

SMC流程，就像是将军在战前下达的最后一道命令，它让每一位士兵（UE、MME、eNB）都明确了接下来的战斗规则（算法）和秘密口令（密钥），并确保他们在同一时刻进入战斗状态。正是有了这个流程，之前所有关于认证和密钥派生的准备工作，才最终转化为对小明每一比特数据的坚实守护。

在下一篇文章中，我们将继续探索第七章的后续内容，包括在各种状态转换（如空闲-连接态转换）和移动性场景（切换）中，密钥是如何被巧妙地处理和更新的。

FAQ 环节

Q1：为什么NAS SMC和AS SMC消息本身都“只做完整性保护，不做加密”？

A1：这是因为SMC流程的使命就是去“开启”加密功能。在SMC命令发出之前，接收方（UE）的解密模块还没有被告知应该使用哪个算法、哪个密钥。如果此时发送方（MME或eNB）将SMC命令加密，接收方将无法解密，整个流程就会卡住，陷入“死锁”。而完整性保护则不同，接收方可以先利用已有的根密钥（KASME或KeNB）派生出完整性密钥，对SMC命令进行验真，确认指令未被篡改后，再根据指令内容去配置和激活加密模块。

Q2：UE的安全能力是什么时候上报给网络的？

A2：UE的安全能力，包括它支持的NAS和AS算法列表，是在初始附着（Attach Request）或位置更新（TAU Request）等初始NAS消息中上报给MME的。MME会将这些能力信息存储在UE的上下文中。当需要建立AS安全时，MME再将AS相关的安全能力通过S1接口下发给eNB。

Q3：如果UE和eNB在AS SMC流程中协商的算法不一致（例如，eNB选了AES，但UE因为某些错误理解成了SNOW 3G），会发生什么？

A3：AS SMC的响应消息AS Security Mode Complete是经过完整性保护的。UE会使用它理解的“新”完整性密钥（基于SNOW 3G派生）来计算MAC。而eNB则期望收到一个用它指定的AES算法派生的密钥计算出的MAC。由于双方密钥不同，eNB收到的AS Security Mode Complete消息将无法通过完整性校验。eNB会认为SMC失败，可能会释放RRC连接或触发异常处理。因此，算法协商的不一致会导致AS安全建立失败，从而无法进行后续通信。

Q4：在7.2.4a Algorithm negotiation for unauthenticated UEs in LSM中提到的EIA0和EEA0（空算法）协商，与正常的SMC流程有何不同？

A4：这是为无法认证的紧急呼叫或受限服务模式（LSM）设计的特殊流程。当MME决定允许一个未经认证的UE建立连接时（例如紧急呼叫），它会强制选择EIA0（不保护完整性）和EEA0（不加密）。它依然会发起一个NAS SMC流程，但流程中的“UE能力回声”会被MME强制设置为只包含EIA0和EEA0。UE在接收到这样的SMC时，根据规范，必须接受这个“空算法”的选择，以确保紧急呼叫的建立。这个流程本质上是利用SMC的形式，来完成一个“不设防”状态的同步。

Q5：为什么要有独立的NAS SMC和AS SMC，而不是在一个流程里把所有算法都协商好？

A5：这源于4G架构中MME和eNB的职责分离。MME是移动性和会话管理的中心，它关心的是UE在核心网层面的安全状态，因此它负责NAS安全。eNB是无线资源管理的实体，它只关心空口的传输安全，因此它负责AS安全。让它们各自负责自己领域的安全激活，可以：1) 简化设计：MME无需关心UE当前在哪一个eNB，eNB也无需关心NAS层的复杂状态。2) 提高效率：当UE在同一MME下的不同eNB间切换时，NAS安全上下文保持不变，无需重新协商，只需要新的eNB与UE之间快速执行一次AS SMC（或切换中的安全激活流程）即可，信令开销更小。

关系图谱