51学通信

深度解析 3GPP TS 33.401：6.3 & 6.4 安全上下文的管理与识别

22分钟阅读

好的，我们继续对3GPP TS 33.401第六章的深度探索。在前两篇文章中，我们已经见证了“信任之舞”AKA流程的精妙，并梳理了由KASME这棵“祖先”繁衍出的庞大密钥家族。现在，我们面临一个实际问题：网络中同时存在着这么多密钥和安全状态，UE和MME是如何精确地管理、识别和切换它们的呢？

本文将聚焦于6.3节 EPS key identification (EPS密钥识别) 和 6.4节 Handling of EPS security contexts (EPS安全上下文的处理)，揭示EPS安全体系中的“状态管理”智慧。

深度解析 3GPP TS 33.401：6.3 & 6.4 安全上下文的管理与识别

本文技术原理深度参考了3GPP TS 33.401 V18.3.0 (2025-03) Release 18规范中，关于“6.3 EPS key identification”和“6.4 Handling of EPS security contexts”的核心章节，旨在为读者阐明4G网络是如何通过eKSI来唯一标识密钥集，以及如何处理不同类型（native/mapped）和不同状态（current/non-current）的安全上下文，从而实现高效而安全的移动性管理。

在我们的主角“小明”享受无缝移动网络服务的背后，他的手机和MME的内存中，可能同时存在不止一套安全密钥。比如，一套是当前正在使用的，另一套可能是上次从3G网络切换过来时“映射”生成的，还有一套可能是刚刚完成一次新的AKA后准备启用的“后备”密钥。

如何在这些复杂的状态中保持清醒和同步，不出任何差错？这就是6.3和6.4节要为我们解答的核心问题。

1. 密钥的“身份证”：eKSI (EPS Key Set Identifier) - 6.3节详解

我们已经知道，会话根密钥KASME是所有子密钥的源头。因此，只要能唯一地识别出KASME，就等于识别了由它派生的整个密钥家族。为KASME分配一个简短而唯一的“身份证号”，就是**eKSI (evolved Packet System Key Set Identifier)** 的使命。

The key KASME shall be identified by the key set identifier eKSI. eKSI may be either of type KSIASME or of type KSISGSN. An eKSI shall be stored in the UE and the MME together with KASME and the temporary identifier GUTI, if available.

深度解读：

  • 核心功能：eKSI是KASME的唯一标识符，它与KASME密钥本身以及临时身份标识GUTI一同存储在UE和MME的安全上下文中。

  • 两种类型：eKSI有两种“出身”：

    • KSIASME: 这种类型的eKSI是在EPS网络内部通过一次原生的AKA认证产生的。它代表着一个“根正苗红”的本地安全上下文。MME在AKA过程中分配这个值，并通过认证请求消息下发给UE。

    • KSISGSN: 这种类型的eKSI是在跨系统移动（如从2G/3G移动到4G）时，通过映射（mapping）过程产生的。它代表一个从旧系统安全上下文转换而来的“外来”安全上下文。SGSN的出现表明了它的3G血统。

eKSI的格式与用途

The format of eKSI shall allow a recipient of such a parameter to distinguish whether the parameter is of type ‘KSIASME’ or of type ‘KSISGSN’. The format shall further contain a value field. KSIASME and KSISGSN have the same format. The value fields of KSIASME and KSISGSN are three bits each. Seven values are used to identify the key set. A value of ‘111’ is used by the UE to indicate that a valid KASME is not available for use.

深度解读：

  • 格式：eKSI的总长度是7比特，但其核心价值在于最高的1比特（用于区分KSIASME和KSISGSN）和最低的3比特（用于表示0-6共7个值的Value字段）。

  • Value字段 (3比特)：这个3比特的字段可以表示0到6，共7个不同的值。MME每次生成一个新的KASME时，会为其分配一个新的、与当前已存储的KSIASME值不同的value。这使得UE和MME最多可以同时管理7个不同的原生安全上下文。

  • 特殊值 ‘111’：这是一个非常有用的“信号旗”。当UE因为某些原因（如刚开机、USIM卡更换）没有任何有效的KASME时，它就会在发送给网络的第一条消息中将eKSI设置为’111’。MME看到这个值，就明白了“这位朋友是‘裸奔’来的，我需要立刻对他发起一次AKA认证”。

场景串联：

  1. 小明第一次在4G网络开机，手机没有任何有效的密钥，于是它向网络发送Attach Request时，将eKSI设置为’111’。

  2. MME收到后，立刻启动AKA流程。成功后，MME生成了一个新的KASME，并为它分配了一个KSIASME，比如值为001。MME将这个KASME和KSIASME=001一同保存在小明的上下文中，并通过Authentication Request消息将KSIASME=001告知了小明的手机。手机也将收到的KASME与KSIASME=001关联存储。

  3. 之后，小明手机发起的所有受保护的信令（如TAU Request），都会附上eKSI=001。MME收到后，看到这个ID，就立刻从数据库中检索出KASME-001这把密钥，用于解密和验证该信令的完整性。

eKSI就像是挂在不同保险柜钥匙上的标签，让UE和MME能够迅速、准确地找到并使用正确的那一把。

2. 状态的艺术：处理EPS安全上下文 (Handling of EPS security contexts) - 6.4节详解

一个**EPS安全上下文（EPS security context）**可以理解为一个包含KASME、eKSI、UE安全能力、NAS COUNT计数器等所有安全相关参数的“状态集合”。UE和MME必须严格同步地创建、激活、存储和删除这些上下文，才能保证通信的持续安全。

上下文的分类

规范从两个维度对安全上下文进行了分类：

  • 来源维度：

    • 原生上下文 (Native context)：通过在EPS网络内部执行一次完整的AKA流程而创建。

    • 映射上下文 (Mapped context)：从2G/3G网络切换到4G时，由旧的2G/3G密钥映射而来。

  • 状态维度：

    • 当前上下文 (Current context)：当前正在用于保护通信的安全上下文。在任何时刻，UE和MME都只能有一个“当前”上下文。

    • 非当前上下文 (Non-current context)：已成功建立但暂未启用的“备用”上下文。

上下文的存储与管理

Both the ME and MME shall be capable of storing one non-current EPS security context and one current EPS security context in volatile memory.

深度解读：这是一条非常重要的能力要求。它规定了UE和MME必须能够至少同时存储两个安全上下文：一个current和一个non-current。这个“一主一备”的设计，是实现安全、无缝的密钥更新和上下文切换的基础。

场景串联（上下文切换）：

  1. 小明的手机当前正在使用一个KASME-A（对应的eKSI-A），这是“当前上下文”。

  2. 此时，网络出于安全策略（例如KASME-A已使用较长时间），决定发起一次重认证。一次新的AKA流程成功执行，生成了新的KASME-B（对应的eKSI-B）。

  3. 这个新的上下文（包含KASME-B）此时就是“非当前上下文”。它被静静地存储在UE和MME的内存中，等待被激活。

  4. 随后，MME通过一次**NAS安全模式命令（SMC）**流程，明确指示UE：“从现在开始，请启用eKSI-B对应的安全上下文”。

  5. 一旦SMC流程成功完成，KASME-B上下文就从“非当前”状态跃迁为“当前”状态，而原来的KASME-A上下文则被废弃或降级为“非当前”（如果网络策略允许保留）。

这种“先建后切”的机制，保证了在新的安全上下文启用之前，通信始终由旧的、有效的上下文保护着，避免了切换过程中出现安全“空窗期”。

上下文的创建与覆盖规则

Any successful run of an EPS AKA creates, by the definition in clause 3, a partial native EPS security context. This context shall overwrite any existing non-current EPS security context.

深度解读：这是一条关键的覆盖规则。每当一次新的AKA成功运行，它会立刻创建一个“部分的（Partial）”原生上下文（所谓“部分”，是因为此时NAS层的加密和完整性保护还未通过SMC激活）。这个新创建的上下文会立即覆盖掉内存中任何已经存在的“非当前”上下文。

安全考量：这个规则确保了最新的认证结果拥有最高的优先级。它防止了内存中堆积过时的“备用”密钥，简化了状态管理，并保证了网络始终倾向于使用最新、最安全的密钥材料。

上下文的删除规则

安全上下文的生命周期管理同样至关重要，过期的上下文必须被及时、彻底地清除，以防被滥用。

Any EPS security context shall be deleted from the ME if:

a) the UICC is removed from the ME when the ME is in power on state;

b) the ME is powered up and the ME discovers that a UICC different from the one which was used to create the EPS security context has been inserted to the ME;

c) the ME is powered up and the ME discovers that no UICC has been inserted to the ME.

深度解读：规范定义了三种ME（手机）必须删除所有EPS安全上下文的场景，它们都与USIM卡的物理状态变化有关。

  1. 热拔卡：当手机开机状态下，小明拔出了USIM卡。

  2. 换卡开机：小明关机，换了一张新SIM卡，然后开机。

  3. 无卡开机：小明关机，取出了SIM卡，然后无卡开机。

安全考量：EPS安全上下文中的所有密钥，其根源都来自特定的USIM卡中的根密钥K。当这张USIM卡物理上不存在于手机中时，这些派生出来的上下文就成了“无根之木”，必须被立即清除。这可以防止一种潜在的攻击：攻击者先用合法卡A在手机中建立一个安全上下文，然后拔掉卡A，再通过某种手段（如软件漏洞）试图利用这个残留的上下文进行非法通信。规范的这条规定，从物理层面将安全上下文与USIM卡进行了强绑定，杜绝了这类风险。

3. 总结

6.3和6.4节共同构成了EPS安全体系的“状态机”和“指挥中心”。它们虽然不像AKA或密钥体系那样充满了复杂的密码学运算，但其对于整个系统稳定、高效、安全地运行起着至关重要的作用。

  • eKSI：高效识别的“标签”。通过为每个KASME密钥集打上唯一的、简短的标签，eKSI实现了对安全上下文的快速索引和无歧义识别。其特殊的’111’值和类型区分比特，为网络与UE之间的状态协商提供了高效的信令语言。

  • 上下文管理：灵活而稳健的“状态机”。通过定义“原生/映射”、“当前/非当前”等不同类型的上下文，并规定了“一主一备”的存储能力，EPS安全体系能够灵活应对移动性、重认证等复杂场景。

  • 严格的生命周期规则：从创建时的“立即覆盖”，到切换时的“先建后切”，再到与USIM卡物理状态绑定的“立即删除”，规范为安全上下文的整个生命周期制定了严谨的操作规程，确保了在任何状态转换中都不会出现安全漏洞。

正是有了这套精密的状态管理机制，小明的手机才能在各种复杂的网络环境中穿梭自如，而其背后的安全保护总能保持同步、准确和有效。

在下一篇文章中，我们将继续深入第六章，解读6.5节Handling of NAS COUNTs，看看这个在密钥派生和抗重放保护中都扮演了关键角色的计数器，是如何被精细管理的。

FAQ 环节

Q1：UE和MME为什么要支持存储一个“non-current”的上下文？只保留一个“current”的不是更简单吗？

A1：支持存储“non-current”上下文是为了实现无缝的安全更新（make-before-break）。如果只存储一个“current”上下文，当需要更换密钥时（如重认证），必须先删除旧上下文，再创建新上下文。在这个短暂的空窗期，通信将不受保护。而有了“一主一备”的机制，网络可以在不中断当前安全通信（由“current”上下文保护）的情况下，在后台悄悄完成新上下文（“non-current”）的建立。一旦新上下文万事俱备，再通过一条信令瞬间切换过去。这个过程对用户业务是完全透明的，不会造成中断或安全降级。

Q2：如果MME因为故障重启，丢失了小明的所有安全上下文，会发生什么？

A2：当MME重启后，小明手机如果发起一次TAU（位置更新），它会携带之前MME分配的GUTI和对应的eKSI。MME收到这个GUTI后，发现自己的数据库里已经没有这个用户的任何信息了。此时，MME无法验证这条TAU请求的完整性，也无法识别用户。它会向UE回复一条拒绝消息，并可能要求UE重新发起Attach（附着）流程。UE收到指示后，会发起Attach Request，并在其中携带自己的IMSI。MME收到IMSI后，会将其视为一个新用户，向HSS请求认证向量，发起一次全新的AKA流程。成功之后，UE和MME会建立一个全新的安全上下文，并分配新的GUTI和eKSI。整个过程对小明来说，可能只是手机信号短暂地断开再重连。

Q3：什么是“Partial native EPS security context”？它和完整的上下文有什么区别？

A3：“Partial”（部分的）原生上下文是指一次AKA成功运行后，但在NAS安全模式命令（SMC）完成前的那一小段时间内的状态。此时，UE和MME已经共享了KASME，并且可以派生出KNASint和KNASenc。但是，双方还没有就具体使用哪种NAS加密和完整性算法达成一致，也还没有正式“开启”NAS层的保护。这个上下文被称为“部分的”，因为它已经具备了安全保护的“潜力”（即密钥已经就位），但保护功能尚未被激活。一旦SMC流程成功完成，双方激活了NAS保护，这个上下文就变成了“Full”（完整的）安全上下文。

Q4：为什么规范对UE和MME在不同PLMN（运营商网络）之间传递“未使用”的认证向量有那么严格的限制？

A4：这主要是出于责任边界和安全域控制的考虑。认证向量（AVs）是由用户的归属网络（HSS）生成的，包含了用于认证的敏感信息。允许一个服务网络（VPLMN）使用从HSS获取的AV来认证用户，是基于运营商之间的漫游协议和信任关系。但是，如果允许服务网络A将它从HSS获取的、尚未使用的AVs再转发给服务网络B，这就打破了“HSS → 服务网络”这条清晰的信任链。服务网络B并没有直接从HSS获得授权，而是间接地从A那里获得了认证用户的“权力”。这会使得认证行为的追溯和审计变得困难，也可能导致AVs在不受归属网络控制的情况下被滥用或泄露。因此，规范严格禁止这种“二手”AV的传递。

Q5：手机换了SIM卡后，为什么必须删除旧的安全上下文？留在手机里以后换回旧卡还能用，不是更方便吗？

A5：这是出于一个核心的安全原则：安全上下文必须与它的信任根（USIM卡）强绑定。手机内存（即使是安全区）的安全性通常低于USIM卡。如果旧的上下文（派生自旧SIM卡的密钥K）在手机中残留，而此时手机插入了一张新卡，可能会存在一些理论上的攻击场景。例如，一个恶意App可能通过某种方式（如利用系统漏洞）访问到这个残留的上下文，并结合新卡的信息进行某些非法操作。虽然这种攻击难度极高，但从“纵深防御”的角度，最安全的设计就是“卡在，上下文在；卡走，上下文亡”。这确保了任何时刻手机中存在的安全上下文，都与其当前物理插入的USIM卡严格对应，消除了任何状态不一致带来的潜在风险。

关系图谱