好的，我们继续沿着3GPP TS 33.401的脉络，深入探索第六章的核心内容。在上一篇详细解读了作为“信任之舞”的AKA流程之后，我们已经知道，这场舞蹈的最终“果实”是在UE和MME之间协商出的一个强大而隐秘的会話根密钥——KASME。

现在，我们将聚焦于6.2节 EPS密钥体系，看看这个“祖先密钥”是如何开枝散叶，衍生出一个庞大而有序的密钥家族，为4G网络的每一个角落提供恰如其分的、“量身定制”的安全保护。

深度解析 3GPP TS 33.401：6.2 EPS key hierarchy (EPS密钥体系)

本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“6.2 EPS key hierarchy”的核心章节，旨在为读者清晰地呈现4G网络中从根密钥到各层应用密钥的完整派生链条，并阐明其分层隔离的设计哲学。

在我们的主角“小明”的手机与网络成功完成AKA认证之后，他的手机（ME）和网络核心（MME）都共同拥有了一把“万能钥匙”——KASME。然而，这把钥匙太过珍贵和强大，绝不会被轻易示人，更不会被直接用于日常的“开门锁门”。相反，它被安全地存放在最核心的保险柜中，作为所有其他“日常使用钥匙”的制造母版。

这种由一个根密钥衍生出一系列子密钥的机制，就是密钥体系（Key Hierarchy）。TS 33.401设计的这套体系，堪称现代通信安全设计的典范。

1. 密钥家族的全貌：一棵枝繁叶茂的“安全树”

规范在6.2节的开头，首先提出了对密钥长度的基本要求，并用一张图为我们勾勒了整个密钥家族的全貌。

a) The EPC and E-UTRAN shall allow for use of encryption and integrity protection algorithms for AS and NAS protection having keys of length 128 bits and for future use the network interfaces shall be prepared to support 256 bit keys.

b) The keys used for UP, NAS and AS protection shall be dependent on the algorithm with which they are used.

深度解读：

• 密钥长度：规范要求当前必须支持128比特的密钥，这在当今被认为是足够安全的。同时，它也高瞻远瞩地要求网络接口为未来支持256比特的密钥做好准备。

• 算法依赖：最终用于加密和完整性保护的密钥，其派生过程会与所选的具体算法（如AES或SNOW 3G）的标识符相绑定。这意味着，即使根密钥相同，为AES算法派生的密钥和为SNOW 3G派生的密钥也是完全不同的。这可以防止跨算法的潜在攻击。

规范中的 Figure 6.2-1: Key hierarchy in E-UTRAN 为我们直观地展示了这棵“密钥树”。让我们从树根到树叶，逐层解析这个家族的成员和它们之间的血缘关系：

• 树根 (The Root): 位于USIM/AuC层级的永久密钥 K。这是整个信任体系的源头，永不离开最安全的环境。

• 一级派生: 由K在AKA过程中派生出的会话密钥 CK (Ciphering Key) 和 IK (Integrity Key)。它们是KASME的“父母”。

• 二级派生 (会话根密钥): 由CK和IK在 UE/HSS 中计算，并在 UE/MME 之间共享的 KASME。这是本次附着会话期间所有安全密钥的“祖先”。

• 三级派生 (NAS层 vs. AS层): KASME 开枝散叶，派生出两大分支：

  • NAS密钥分支：在 UE/MME 之间使用，用于保护UE和MME之间的NAS信令。包括 KNASenc (用于加密) 和 KNASint (用于完整性保护)。

  • AS密钥分支：KASME 首先派生出一个中间密钥 KeNB，这个密钥将在UE和基站eNB之间共享。

• 四级派生 (AS层应用密钥): 由KeNB在 UE/eNB 之间派生出最终用于空口保护的密钥：

  • KRRCenc / KRRCint: 用于保护RRC信令的加密和完整性。

  • KUPenc / KUPint: 用于保护用户面数据（UP）的加密和完整性。

这棵结构清晰的“安全树”完美体现了分层安全和风险隔离的设计思想。核心网的秘密（KASME）永远不会暴露给接入网（eNB），即使eNB的安全被攻破，也只会影响到其与UE之间的空口通信，而无法危及更高级别的NAS信令安全。

2. 密钥家族成员详解：各司其职的“守护者”

现在，让我们详细认识一下这棵树上的每一位关键成员。规范对每个密钥的用途都给出了精确的定义。

2.1 NAS信令的“贴身保镖”：KNASint 和 KNASenc

• KNASint is a key, which shall only be used for the protection of NAS traffic with a particular integrity algorithm This key is derived by ME and MME from KASME…

• KNASenc is a key, which shall only be used for the protection of NAS traffic with a particular encryption algorithm. This key is derived by ME and MME from KASME…

深度解读：

• KNASint (NAS Integrity Key)：NAS信令的完整性密钥。

• KNASenc (NAS Encryption Key)：NAS信令的加密密钥。

这对“兄弟密钥”由KASME直接派生，并且只存在于UE和MME中。它们的使命只有一个：保护UE和MME之间的非接入层（NAS）信令。

场景串联：当小明乘坐的地铁进入一个新的跟踪区（Tracking Area），他的手机需要发起一次“位置更新”（TAU Request）流程。这个请求信令就属于NAS信令。在发送前，手机会：

1. 使用KNASint为这条信令计算一个“完整性签名”（NAS-MAC）。

2. （如果运营商配置了NAS加密）使用KNASenc对信令内容进行加密。

MME收到后，会执行相反的解密和验证过程。由于KeNB对此一无所知，所以沿途的基站eNB对于这条信令的内容和真实性是无法感知的，它仅仅扮演了一个“信使”的角色。

2.2 用户数据的“空中盾牌”：KUPenc 和 KUPint

• KUPenc is a key, which shall only be used for the protection of UP traffic with a particular encryption algorithm. This key is derived by ME and eNB from KeNB…

• KUPint is a key, which shall only be used for the protection of UP traffic with a particular integrity algorithm… from KeNB…

深度解读：

• KUPenc (User Plane Encryption Key)：用户面数据的加密密钥。

• KUPint (User Plane Integrity Key)：用户面数据的完整性密钥。

这对密钥由基站级密钥KeNB派生，在UE和eNB之间共享。它们负责保护小明最关心的内容——他实际使用的App产生的数据。

场景串联：小明正在观看高清视频，视频数据流（UP traffic）源源不断地从基站发送到他的手机。在离开基站的天线之前，每一个数据包都会被基站的PDCP层使用KUPenc进行加密。小明的手机收到这些加密包后，同样在PDCP层使用自己派生出的KUPenc进行解密，然后送给视频播放器。如前文所述，对用户数据的完整性保护（即使用KUPint）是可选的，大多数商用网络为了性能考虑并未开启。

2.3 RRC信令的“专用通道”：KRRCint 和 KRRCenc

• KRRCint is a key, which shall only be used for the protection of RRC traffic with a particular integrity algorithm. KRRCint is derived by ME and eNB from KeNB…

• KRRCenc is a key, which shall only be used for the protection of RRC traffic with a particular encryption algorithm. KRRCenc is derived by ME and eNB from KeNB…

深度解读：

• KRRCint (RRC Integrity Key)：RRC信令的完整性密钥。

• KRRCenc (RRC Encryption Key)：RRC信令的加密密钥。

这对密钥同样由KeNB派生，在UE和eNB之间共享。它们专门用于保护无线资源控制（RRC）信令。RRC信令是UE和eNB之间用来管理无线连接的“工作语言”，例如切换命令、测量控制等。

场景串串联：系统检测到小明所在位置的信号开始变弱，而邻近小区的信号更好。eNB决定发起切换。它会通过RRC信令（RRC Connection Reconfiguration）告诉小明的手机：“准备切换到xxx小区，这是它的频率和ID”。这条至关重要的指令，在发送前会同时经过KRRCint的完整性保护和KRRCenc的加密。这确保了切换指令不会被篡改，也不会被窃听者用来追踪小明的精确移动轨迹。

2.4 承上启下的“中间人”：NH 和 KeNB*

• NH is a key derived by ME and MME to provide forward security as described in clause 7.2.8.

• KeNB* is a key derived by ME and eNB when performing an horizontal or vertical key derivation as specified in clause 7.2.8…

深度解读：NH和KeNB*并非直接用于保护数据，而是作为切换过程中的中间密钥，它们是实现安全、快速切换的关键。

• NH (Next Hop)：由KASME派生，仅在UE和MME中计算和存储。它像一个“预备密钥”，是MME为了下一次可能发生的S1切换（需要MME介入的切换）而提前准备的“种子”。NH的设计提供了前向安全性（Forward Security），即旧基站无法通过已知信息推算出新基站的密钥。

• KeNB*：在切换过程中，由旧的安全上下文（可能是旧KeNB，也可能是NH）结合目标小区的物理信息（如PCI）临时计算出的一个中间值。这个KeNB*经过进一步处理后，将成为UE与新基站之间的新KeNB。

我们将在后续解读7.2.8节切换流程时，再详细剖析NH和KeNB*的精妙用法。在此，我们只需理解它们是密钥体系中为了支持移动性而设计的特殊成员。

3. 密钥的诞生：派生流程的可视化

仅仅知道有哪些密钥还不够，理解它们是如何一步步从KASME诞生出来的，对于深入理解整个体系至关重要。规范通过Figure 6.2-2（网络侧视图）和Figure 6.2-3（UE侧视图）两张流程图，详细展示了密钥的派生过程。这两张图本质上是镜像对称的，展示了通信双方如何通过相同的输入和相同的函数，得到完全一致的密钥。

以网络侧的 Figure 6.2-2 为例，我们来追踪密钥的诞生之旅：

1. KASME的诞生：在图的顶端HSS部分，AKA的产物CK和IK，连同SN id（服务网络ID）和SQN ⊕ AK等参数，一同被送入一个KDF（Key Derivation Function，密钥派生函数）。这个KDF的输出，就是256比特的KASME。HSS将KASME连同认证向量一起发送给MME。

2. KeNB的诞生：在MME部分，当需要为UE建立空口连接时，MME拿出KASME，再结合一个新鲜度参数——Uplink NAS COUNT（上行NAS计数器），将它们再次送入KDF。这次的输出，就是256比特的KeNB。MME随后会将这个KeNB通过安全的S1接口下发给eNB。

3. NAS/AS应用密钥的诞生：

   • 在MME侧，KASME与选定的NAS算法ID一起进入KDF，生成256比特的KNASint和KNASenc的“原材料”。

   • 在eNB侧，KeNB与选定的AS算法ID一起进入KDF，生成256比特的KRRCint, KRRCenc, KUPint, KUPenc的“原材料”。

4. 最后的“精加工”：Trunc函数

   In case the encryption or integrity algorithm … requires a 128-bit key as input, the key is truncated and the 128 least significant bits are used.

   深度解读：KDF的输出统一为256比特，但我们前面看到的EEA和EIA算法都只需要128比特的密钥。这里的Trunc（Truncate，截断）函数就起作用了。它简单地取KDF输出的256比特结果中最低的128比特作为最终的算法输入密钥。这是一个非常重要的细节，保证了密钥长度的适配。

通过这一系列级联的KDF运算，一个KASME就成功地、安全地衍生出了所有在本次连接中需要的子密钥，并且保证了UE和网络侧（MME/eNB）的计算结果完全一致。

4. 总结

6.2节“EPS密钥体系”为我们展示了4G安全设计的核心智慧。它不仅仅是一个密钥列表，更是一套体现了深刻安全思想的系统工程：

• 集中派生，分级下发：所有密钥的根源KASME都与核心网MME绑定。需要空口保护时，才由MME派生出KeNB并“授权”给基站eNB。这种中心化的控制模式，保证了密钥生命周期的可管理性。

• 功能隔离，专钥专用：NAS信令、RRC信令、用户数据，都使用由不同密钥派生出的、相互独立的专用密钥进行保护。这极大地降低了攻击的横向扩散风险。

• 新鲜度注入，抵抗重放：在KeNB的派生中引入了NAS COUNT这个动态参数，确保了每次重建空口连接时（即使KASME不变），生成的KeNB都是全新的，从而杜绝了密钥重用带来的风险。

• 前向安全设计：通过NH等中间密钥的设计，为高安全性的移动切换场景预留了强大的安全保障能力。

这套密钥体系，如同一支纪律严明、各司其职的“皇家卫队”，在“国王”KASME的统一授权下，默默守护着通信王国的每一个角落，确保了小明的每一次数据交互，都在恰当且充分的安全保护之下。

在下一篇文章中，我们将继续深入第六章，探讨6.3节EPS key identification和6.4节Handling of EPS security contexts，看看网络是如何管理和识别这些复杂的密钥和安全状态的。

---

FAQ 环节

Q1：为什么需要一个中间密钥KeNB？MME为什么不直接为RRC和UP派生密钥然后发给eNB？

A1：引入KeNB是为了进一步增强安全隔离和提高效率。1) 安全隔离：MME是核心网的可信实体，它不应该过多地关心接入层的具体算法细节。通过只派生和下发一个通用的KeNB，MME将空口具体密钥（KRRC/KUP）的派生任务“下放”给了eNB，实现了核心网与接入网在密钥管理职责上的解耦。2) 效率：在某些场景下（如切换），eNB可能需要基于旧KeNB快速派生新KeNB，而无需MME介入。如果所有密钥都由MME派生，会增加信令开销和切换时延。KeNB作为一个eNB级别的根密钥，为接入网内部的安全管理提供了更大的灵活性。

Q2：KASME和KeNB的生命周期有什么不同？

A2：它们的生命周期有显著不同。KASME的生命周期与UE在核心网的一次附着会话绑定。只要小明的手机不关机、不进入飞行模式、不发生导致需要重新AKA的异常，这个KASME就可以一直有效，即使他跨越了成百上千个基站。而KeNB的生命周期则与UE在某个eNB下的RRC连接相关。当小明从A基站切换到B基站，旧的KeNB就会被废弃，UE和B基站会建立一个新的KeNB。当小明的手机进入空闲态（ECM-IDLE）时，KeNB也会被删除。因此，KASME是“长效”的，KeNB是“短效”的。

Q3：密钥派生函数（KDF）是什么？可以简单理解为一个哈希函数吗？

A3：可以近似地这么理解，但它更准确地说是一个“密钥派生函数”。KDF的功能与密码学中的哈希函数（如SHA-256）类似，都是将一个任意长度的输入（密钥+参数）映射成一个固定长度的、看起来随机的输出。但KDF的设计目标更专注于从一个“主密钥”中安全地衍生出多个“子密钥”。它必须满足一些关键特性，如伪随机性（输出看起来是随机的）、不可逆性（无法从子密钥反推出主密钥）等。在3GPP规范中，KDF的具体实现通常是基于HMAC-SHA256等标准算法。

Q4：在上行NAS COUNT被用作派生KeNB的“新鲜度”参数，这是什么意思？有什么作用？

A4：“新鲜度”参数（freshness parameter）的作用是确保每次密钥派生的输出都是独一无二的，即使主密钥（KASME）没有改变。NAS COUNT是一个随着每条上行NAS消息递增的计数器。当小明的手机从空闲态恢复连接并发起一条NAS业务请求时，这条消息会有一个新的NAS COUNT值。MME就用这个独一无二的COUNT值和KASME来派生KeNB。这样做的好处是，即使小明反复进入空闲再恢复连接，每次生成的KeNB都是全新的，从而防止了使用相同的密钥加密不同的数据流，避免了严重的“密钥流重用”攻击。

Q5：KUPint（用户数据完整性密钥）在图中存在，但实际网络中为什么很少使用？

A5：这主要是性能和开销的权衡。为每一个用户数据包（通常很小，如几十到1500字节）计算并附加一个消息认证码（MAC，通常16-32字节），会带来几个问题：1) CPU开销：UE和eNB的基带处理器需要消耗大量计算资源。2) 带宽开销：附加的MAC会占用宝贵的无线频谱资源，降低了有效数据的传输效率，即“好钢没用在刀刃上”。对于信令而言，完整性是第一位的，这点开销是值得的。但对于用户数据，业界普遍认为机密性（防窃听）是主要矛盾，而篡改的风险和危害相对较低，因此为了保证更高的传输速率和更长的手机续航，大多数网络选择不开启用户面的完整性保护。