51学通信

深度解析 3GPP TS 31.102：4.2.3 & 4.2.4 安全的基石 (EF_Keys & EF_KeysPS)

22分钟阅读

好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。

深度解析 3GPP TS 31.102：4.2.3 & 4.2.4 安全的基石 (EF_Keys & EF_KeysPS)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.3 EFKeys (Ciphering and Integrity Keys)”和“4.2.4 EFKeysPS (Ciphering and Integrity Keys for Packet Switched domain)”的核心章节，旨在为读者深入剖析USIM中存储和管理核心安全会话密钥的机制。

在上一篇文章中，我们认识了USIM中的身份核心EF_IMSI。当我们的主角“李想”的手机利用IMSI（或由其生成的SUCI）向网络表明身份后，一场至关重要的“信任建立”过程——AKA（Authentication and Key Agreement）认证和密钥协商便拉开了序幕。这场过程的最终成果，除了网络对用户身份的确认外，更关键的是生成了一对用于本次通信会话的“动态密码”：加密密钥（CK）和完整性密钥（IK）。

那么，这对至关重要的密钥被存放在哪里？USIM又是如何管理它们的呢？答案就藏在EF_Keys和EF_KeysPS这两个文件中。它们如同USIM内部的“安全保险箱”，妥善保管着保护李想每一次通话和数据传输的钥匙。这两个文件在结构和功能上高度相似，分别对应电路交换（CS）域和分组交换（PS）域的安全上下文。

今天，我们将聚焦于这两个安全基石文件，深入理解它们的结构、内容以及在保障通信安全中扮演的关键角色。

1. 电路域的守护者：4.2.3 EF_Keys (加密与完整性密钥)

当李想需要进行传统的语音通话或收发短信时（在不使用VoLTE/VoNR的情况下，即通过CS域），EF_Keys文件中的密钥便会出鞘，为他的通信保驾护航。

This EF contains the ciphering key CK, the integrity key IK and the key set identifier KSI.

规范开宗明义，指出了这个文件存储的三大核心要素：CK、IK 和 KSI。这三者共同构成了一个完整的CS域安全上下文。

1.1 文件结构与编码剖析

让我们像工程师一样，仔细审视EF_Keys的“设计图纸”，探究其内部的精密构造。

表 4.2.3-1: EF_Keys 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F08’ |

| SFI | ‘08’ |

| Structure | Transparent |

| File size | 33 bytes |

| Update activity | High |

| Access Conditions | |

| READ | PIN |

| UPDATE | PIN |

| DEACTIVATE | ADM |

| ACTIVATE | ADM |

字节内容

| 字节 | 描述 | M/O | 长度 |

| :--- | :--- | :--- | :--- |

| 1 | Key set identifier KSI (密钥集标识符) | M | 1 byte |

| 2 to 17 | Ciphering key CK (加密密钥) | M | 16 bytes |

| 18 to 33 | Integrity key IK (完整性密钥) | M | 16 bytes |

逐项解读：

  • Identifier & SFI: ‘6F08’是它的固定地址，‘08’是它的快捷访问码。

  • Structure: 透明文件。文件内容是一个连续的33字节数据块，需要ME一次性读写和解析。

  • File size: 固定为33字节。这个大小精确地容纳了1字节的KSI、16字节（128位）的CK和16字节（128位）的IK。

  • Update activity: High (高)。这一点非常重要，它表明这个文件会被频繁更新。每当一次成功的AKA认证发生，新的CK和IK就会生成并覆盖旧值，确保了“一次一密”的安全性。

  • Access Conditions:

    • READ和UPDATE权限都是PIN。这意味着无论是读取还是更新这些会话密钥，都需要用户身份的验证（PIN码解锁）。这构成了USIM安全模型的重要一环：即使手机的操作系统被攻破，攻击者也难以在USIM未解锁的状态下窃取或篡改这些关键密钥。

    • DEACTIVATE/ACTIVATE权限是ADM，文件的启停权在运营商手中。

1.2 三大核心要素详解

1.2.1 KSI (Key Set Identifier - 密钥集标识符)

KSI是一个非常小（仅3位有效比特）但极其重要的标识符。它的作用是作为当前这套CK/IK密钥的“版本号”或“标签”。

编码细节：

Coding: bits b4 to b8 are coded 0

KSI只使用一个字节中的低3位（b1-b3），高5位固定为0。因此，KSI的取值范围是0到7。

KSI 的工作机制：

  1. USIM 侧: 每当一次成功的AKA认证后，USIM会生成新的CK和IK，同时，它会为这套新密钥分配一个新的KSI值。这个KSI通常是上一个值的循环递增（例如，从2变成3，从6变成7，从7变回0）。USIM将新的CK、IK和这个新的KSI一同存储在EF_Keys中。

  2. 网络侧: 网络（核心网的VLR/MSC）在同一次AKA认证后，也生成了同样的CK、IK，并且也知道与之关联的KSI值。网络会将这个KSI与用户的临时身份标识TMSI一起保存。

  3. 后续流程: 当李想的手机发起下一次业务请求时（如拨打电话），它会带上这个KSI。网络收到后，首先检查这个KSI是否与自己为该用户存储的KSI匹配。

    • 如果匹配: 网络确认双方使用的是同一套“密码”，直接使用本地存储的CK/IK进行加密和完整性保护，无需再次进行完整的AKA认证。这大大提高了效率，减少了信令开销。

    • 如果不匹配: 说明双方的安全上下文可能已经“失步”（例如，网络侧因为某些原因重启，丢失了旧的密钥）。此时，网络会发起一次全新的AKA认证流程，重新协商密钥和KSI。

场景化举例：

李想成功开机并完成了一次AKA认证，USIM和网络都生成了一套密钥，并标记为KSI=2。现在，李想拨打了一个电话，通话结束后，手机处于待机状态。几分钟后，他又拨打了第二个电话。

此时，手机向网络发起呼叫请求，并在请求信令中携带了KSI=2。网络侧的MSC查询后发现，自己为李想存储的KSI也是2。于是，MSC确信双方“对上了暗号”，立即启用对应的CK和IK来保护这次呼叫的信令，整个过程快速而高效，李想几乎感觉不到延迟。

1.2.2 CK (Ciphering Key - 加密密钥)

CK是一个128位的密钥，它的唯一使命就是对无线信道上传输的数据进行加密，保护其机密性 (Confidentiality)。

Coding: - the least significant bit of CK is the least significant bit of the 17th byte. The most significant bit of CK is the most significant bit of the 2nd byte.

这段编码描述定义了16字节CK的存储顺序，确保了ME和USIM对密钥的解析方式完全一致。

作用：

在CS域，CK主要用于对语音通话数据和部分信令进行加密。当李想打电话时，他的声音被数字化后，会由手机的基带芯片使用CK进行加密，变成一串无意义的乱码在空中传输。接收方的手机在收到后，再用同样的CK进行解密，还原成声音。任何没有CK的第三方，即使截获了无线信号，也无法听懂通话内容。

1.2.3 IK (Integrity Key - 完整性密钥)

IK同样是一个128位的密钥，但它的职责不是加密，而是保护信令的完整性 (Integrity) 和进行消息认证 (Message Authentication)。

作用：

完整性保护的目标是防止信令在传输过程中被恶意篡改。例如，防止攻击者将一个“呼叫转移到A号码”的信令，在空中篡改为“呼叫转移到B号码”。

工作机制：

手机在发送每一条关键信令（如呼叫建立、位置更新等）时，会使用IK和一个特定算法（如UIA1/EIA1）对信令内容计算出一个简短的“摘要”或“签名”，我们称之为MAC-I (Message Authentication Code for Integrity)。这个MAC-I会附在信令的末尾一同发送出去。

网络侧收到信令后，用同样的IK和算法，对信令内容也计算一个X-MAC-I。然后比对收到的MAC-I和自己计算的X-MAC-I。

  • 如果一致: 说明信令在传输途中没有被改动过，是“原装正品”。

  • 如果不一致: 网络会立即丢弃这条信令，因为它很可能已经被篡改，从而防止了潜在的攻击。

场景化举例：

李想正在通话，此时他发起了一个“保持通话”的请求。

  1. 手机生成一条包含“保持通话”指令的信令。

  2. 手机使用存储在USIM旁的IK，对这条信令计算出一个MAC-I。

  3. 手机将“信令原文 + MAC-I”一同发送给基站。

  4. 网络侧收到后，分离出信令原文和MAC-I。

  5. 网络用自己保存的IK，对信令原文也计算一个X-MAC-I。

  6. 比对MAC-I和X-MAC-I，发现完全一致。网络确信这条指令确实是李想本人发出的，且内容未经修改，于是执行通话保持操作。

通过CK的加密和IK的完整性保护，USIM为李想的电路域通信构建了一道坚不可摧的安全防线。

2. 分组域的壁垒：4.2.4 EF_KeysPS (用于分组交换域的加密与完整性密钥)

随着移动通信进入数据时代，李想更多的时间是在上网、刷视频、玩游戏。这些都属于分组交换（PS）域的业务。为了保护这些数据业务的安全，USIM提供了EF_KeysPS文件，它在功能上是EF_Keys在PS域的“孪生兄弟”。

This EF contains the ciphering key CKPS, the integrity key IKPS and the key set identifier KSIPS for the packet switched (PS) domain.

可以看到，除了名称上加上了“PS”后缀，其内容三要素（密钥、密钥标识符）与EF_Keys完全一致。

2.1 文件结构与异同点

表 4.2.4-1: EF_KeysPS 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F09’ |

| SFI | ‘09’ |

| Structure | Transparent |

| File size | 33 bytes |

| Update activity | High |

| Access Conditions | … (与EF_Keys相同) |

字节内容

| 字节 | 描述 | M/O | 长度 |

| :--- | :--- | :--- | :--- |

| 1 | Key set identifier KSIPS | M | 1 byte |

| 2 to 17 | Ciphering key CKPS | M | 16 bytes |

| 18 to 33 | Integrity key IKPS | M | 16 bytes |

与 EF_Keys 的对比：

  • 相同点: 文件结构、大小、访问条件、更新频率以及内部三要素（KSI/CK/IK）的功能原理和编码方式，两者完全相同。

  • 不同点:

    1. 文件ID/SFI不同: EF_KeysPS的ID是6F09，SFI是09。

    2. 应用域不同: EF_Keys用于CS域（如GSM/UMTS的语音通话），而EF_KeysPS用于PS域（如GPRS/LTE/5G的数据上网）。

2.2 为什么需要两套独立的密钥？

将CS域和PS域的安全上下文分开管理，是3GPP安全架构的一个重要设计。李想可能同时在进行一个CS域的语音通话，和一个PS域的数据下载。这种“并行会话”要求两个域的安全是相互独立的。

  • 独立的安全生命周期: CS域的会话密钥可能因为一次通话的结束而更新，但这不应该影响到正在进行的PS域数据会话的安全性。反之亦然。

  • 不同的安全算法: 在某些网络演进阶段，CS域和PS域可能使用不同的加密或完整性算法。拥有独立的密钥使得这种异构性成为可能。

  • 防止跨域攻击: 将安全上下文隔离，可以防止在一个域中可能出现的安全漏洞（理论上）影响到另一个域。

场景化举例：

李想正在使用VoLTE（Voice over LTE，基于PS域的通话）与朋友聊天，同时后台正在下载一个大文件。

  • VoLTE通话: 所有与这次通话相关的信令（SIP信令）和语音数据（RTP包），都会使用存储在EF_KeysPS中的IKPS和CKPS进行完整性保护和加密。

  • 后台下载: 下载文件的数据流，同样会受到CKPS的加密保护。

突然，李想的手机收到了一个传统的2G短信（通过CS域）。网络侧的MSC会利用EF_Keys中的IK来验证这条短信相关信令的完整性。这两套密钥体系并行工作，互不干扰，共同为李想的混合业务场景提供了全面的安全保障。

总结：动态密钥，守护每一次连接

EF_Keys和EF_KeysPS是USIM安全体系中承上启下的关键环节。它们存储的不是静态的、永久的密钥，而是通过AKA流程动态生成的、具有生命周期的会话密钥。

  • KSI 机制通过“版本号”管理，实现了高效的快速重认证，在保证安全的前提下，极大地优化了用户体验和网络信令开销。

  • CK 和 IK 的分工合作，分别从机密性和完整性两个维度，为无线信道上的通信构建了双重保险。

  • CS/PS分离的设计，体现了3GPP架构对复杂并发业务场景的前瞻性考虑，确保了不同业务域的安全独立性。

正是这两个看似简单的33字节文件，将AKA认证的理论成果，转化为了守护李想每一次通话、每一比特数据的坚实盾牌。它们是USIM从一个静态的身份凭证，转变为一个动态的安全交互核心的体现。

FAQ环节

Q1：EF_Keys和EF_KeysPS中的密钥（CK/IK）会过期吗？它们什么时候会被更新？

A1：这些密钥本身没有“过期时间”的概念，但它们与一个称为“安全上下文”的状态绑定。它们在以下几种主要情况下会被更新：1) 新的AKA认证: 每当网络发起一次全新的AKA认证并成功完成，就会生成一套新的CK/IK和KSI，并覆盖掉EF_Keys或EF_KeysPS中的旧值。2) 移动性管理: 当用户移动到新的跟踪区（TA）或路由区（RA），并进行相应的更新流程时，可能会触发密钥的更新或推衍。3) 网络策略: 网络侧可以基于安全策略，主动发起重认证来刷新密钥。高频次的更新确保了即使一套密钥被破解（虽然极其困难），其危害也仅限于极短的时间窗口。

Q2：KSI只有3个比特（0-7），会不会很快就用完了？

A2：KSI的值是循环使用的。当值达到7后，下一个值会回到0。因为KSI总是与一个特定的UE以及一个临时的身份标识（如TMSI/GUTI）相关联，所以在一个小范围内（例如一个MSC/AMF覆盖区），同一个UE在短时间内重复使用同一个KSI的概率很低。网络侧通过将KSI与TMSI/GUTI绑定，可以准确地识别出对应的密钥。这种循环使用机制在保证安全性的同时，也极大地节省了信令资源。

Q3：既然有了完整性密钥IK，为什么还需要加密密钥CK？只用IK保护信令不被篡改不行吗？

A3：CK和IK解决了两个不同维度的安全问题。IK只保证“不被篡改”（完整性），不保证“不被看见”。也就是说，即使有IK保护，攻击者虽然无法修改信令内容，但仍然可以窃听并看到信令的明文内容。而CK则负责将数据“加密”成乱码，保证“不被看见”（机密性）。对于包含敏感信息（如用户位置、通话内容）的数据，机密性是必须的。两者互为补充，缺一不可。

Q4：为什么VoLTE/VoNR（基于PS域的语音）使用的是EF_KeysPS而不是EF_Keys？

A4：因为VoLTE/VoNR的本质是把语音数据打包成IP数据包，通过PS（分组交换）数据通道来传输，它是一种数据业务。因此，它自然受到PS域安全机制的保护，使用EF_KeysPS中的CKPS和IKPS。而传统的2G/3G语音通话走的是专门的CS（电路交换）通道，所以使用EF_Keys。这也是为什么EF_KeysPS中的“PS”代表Packet Switched（分组交换），而不是代表“Phone Service”。

Q5：如果手机突然断电，EF_Keys和EF_KeysPS中的密钥会丢失吗？

A5：不会丢失。USIM卡内部使用的是非易失性存储器（如EEPROM或Flash），类似于一个微型SSD。写入EF_Keys和EF_KeysPS的数据是持久化的，即使断电也会被保存。当手机重新开机后，它会重新读取这些文件，恢复之前的安全上下文，并携带存储的KSI尝试重新连接网络。如果网络侧也保存了对应的上下文，就可以实现快速重连。

关系图谱