51学通信

深度解析 3GPP TS 31.102：4.2.51 EFSTART-HFN & 4.2.52 EFTHRESHOLD (密钥寿命的守护神)

18分钟阅读

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

深度解析 3GPP TS 31.102：4.2.51 EFSTART-HFN & 4.2.52 EFTHRESHOLD (密钥寿命的守护神)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.51 EFSTART-HFN (Initialisation values for Hyperframe number)”和“4.2.52 EFTHRESHOLD (Maximum value of START)”的核心章节，旨在为读者深入揭示在3G/UMTS安全体系中，USIM卡是如何通过EFSTART-HFN和EFTHRESHOLD这两个文件，像一个严谨的“里程表”和“报警器”，来守护会话密钥的生命周期，防止因密钥重用而引发的安全风险。

在我们之前的探索中，已经深入了解了AKA认证过程如何生成用于通信加密和完整性保护的会话密钥CK和IK。这些密钥虽然是动态生成的，但如果被无限期地、无限制地使用，仍然会增加被密码分析攻击破解的风险。一个健壮的安全体系，必须确保密钥能够被定期、安全地更新。

为了解决这个问题，3GPP的UMTS（3G）安全架构引入了一个核心概念——密钥生命周期管理。其基本思想是：为每一对CK和IK设定一个“有效期”，这个有效期不是按时间计算，而是按使用次数计算。当使用次数即将达到上限时，就必须强制触发一次新的AKA认证，生成全新的密钥。

这个“使用次数”的计数器，在3GPP规范中被称为COUNT，它由两部分组成：一个由手机维护的、不断增长的序列号SQN，和一个高阶计数器HFN (Hyperframe Number)。EFSTART-HFN和EFTHRESHOLD这两个文件，正是USIM卡参与并监督这个密钥生命周期管理机制的核心工具。

  • EFSTART-HFN: 像一个“里程表”，记录了上次通信会话结束时，HFN计数器的终点读数。

  • EFTHRESHOLD: 像一个“报警器”，设定了HFN计数器的最大允许值 (阈值)。

今天，我们将一起探索这对“密钥寿命守护神”，理解它们是如何协同工作，确保每一次通信会话都在安全的密钥生命周期内进行的。

1. “里程表”与“报警器”：密钥生命周期管理机制

在深入文件细节之前，我们必须先理解HFN和密钥生命周期的工作原理。

每一次手机与网络之间的加密通信（无论是语音还是数据），都需要一个同步的计数器COUNT来防止重放攻击。COUNT是一个32位的数值，由HFN（高位）和SQN（低位）拼接而成。SQN在每次通信中都会递增，而当SQN即将溢出时，HFN就会加1。

密钥与HFN的绑定关系：

在一次AKA认证后生成的CK和IK，与认证时使用的SQN是相关联的。为了防止“密钥流重用”（即用同一密钥和同一COUNT值加密不同的数据，这是密码学上的大忌），3GPP规定，一对CK/IK只能与一组连续的COUNT值一起使用。

EFSTART-HFN和EFTHRESHOLD的工作流程：

  1. 初始状态: 我们的主角“李想”的手机完成了一次AKA认证，生成了新的CK/IK，并启动了CS（电路域）和PS（分组域）的通信会话。此时，CS域的HFN_CS和PS域的HFN_PS都从0开始计数。

  2. 通信过程: 李想开始打电话（CS域）和上网（PS域）。随着通信的进行，HFN_CS和HFN_PS会各自独立地不断增长。

  3. 会话结束: 李想挂断电话并关闭了数据连接。在RRC（无线资源控制）连接释放的最后一刻：

    • 手机必须读取此刻的HFN_CS和HFN_PS的终值。

    • 手机立即将这两个终值写入USIM卡的EFSTART-HFN文件中。这个动作，就像停车前记录下里程表的读数。

  4. 下一次会话开始: 李想重新发起一次呼叫或数据连接。

    • 手机在建立连接前，首先从EFSTART-HFN中读取上次保存的HFN_CS和HFN_PS的终值。

    • 手机将这两个值作为本次新会话中HFN计数器的起始值 (START)。

    • 同时，手机会读取EFTHRESHOLD文件，获取HFN的最大允许值。

    • 手机进行一次关键的安全检查：IF (START >= THRESHOLD)?

      • 如果START已经大于或等于THRESHOLD: 这意味着上次会话已经将密钥的“寿命”几乎用尽。继续使用这对旧密钥将有重用密钥流的风险。手机必须立即强制发起一次全新的AKA认证，生成新的CK/IK和START值，才能继续。

      • 如果START小于THRESHOLD: 说明旧密钥的寿命尚有余量，可以安全地继续使用。连接正常建立。

通过这个闭环流程，EFSTART-HFN确保了HFN计数的连续性，而EFTHRESHOLD则在计数器即将“爆表”前及时拉响警报，强制进行密钥更新，从而有效地保障了密钥的生命周期安全。

2. “里程记录本”：4.2.51 EFSTART-HFN 文件剖析

EFSTART-HFN是存储HFN“里程”的记录本。

2.1 文件结构

表 4.2.51-1: EFSTART-HFN 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F5B’ |

| SFI | ‘0F’ |

| Structure | Transparent |

| File size | 6 bytes |

| Update activity| High |

| Access Conditions| READ: PIN, UPDATE: PIN |

字节内容

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

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

| 1 to 3 | STARTCS | M | 3 bytes |

| 4 to 6 | STARTPS | M | 3 bytes |

逐项解读：

  • Update activity: High。每次RRC连接释放时都可能需要更新，是一个高频写入的文件。

  • Access Conditions: 读写都需要PIN保护。HFN的值是安全上下文的关键部分，必须在USIM解锁状态下才能访问和修改。

  • STARTCS (3 bytes): 存储电路交换域的HFN值。

  • STARTPS (3 bytes): 存储分组交换域的HFN值。

2.2 编码方式

Contents: Initialisation value for Hyperframe number – CS domain / PS domain.

Coding: The LSB of STARTCS is stored in bit 1 of byte 3. Unused nibbles are set to ‘F’.

  • 每个HFN值是一个20位的整数，存储在3个字节中。

  • STARTCS和STARTPS的编码方式是相同的。以STARTCS为例：

    • 字节1、字节2和字节3的低4位（共8+8+4=20位）用于存储HFN值。

    • 字节3的高4位是未使用的，用'F'填充。

    • 存储顺序是大端模式（Most Significant Byte first）。

场景化举例：

李想结束通话时，CS域的HFN_CS计数器值为0x12345。

手机需要将这个值写入EFSTART-HFN的前3个字节。

  • 0x12345的20位二进制是 0001 0010 0011 0100 0101。

  • 编码为3个字节将是：'12 34 F5' (十六进制)。

    • 字节1: '12'

    • 字节2: '34'

    • 字节3: 低4位是'5'，高4位填充'F'，所以是'F5'。

手机将'12 34 F5'写入USIM，下次启动CS业务时再将其读出，并从0x12345这个值开始继续计数。

3. “安全红线”：4.2.52 EFTHRESHOLD 文件剖析

EFTHRESHOLD为HFN的增长设定了不可逾越的“红线”。

3.1 文件结构

表 4.2.52-1: EFTHRESHOLD 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6F5C’ |

| SFI | ‘10’ |

| Structure | Transparent |

| File size | 3 bytes |

| Update activity| Low |

| Access Conditions| READ: PIN, UPDATE: ADM |

字节内容

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

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

| 1 to 3 | Maximum value of STARTCS or STARTPS | M | 3 bytes |

逐项解读：

  • File size: 3字节，与一个HFN值的长度相同。

  • Access Conditions: UPDATE权限为ADM。这个阈值是运营商的核心安全策略之一，必须由运营商在个人化时设定，用户不可更改。

  • 内容: 存储一个20位的阈值。这个阈值对CS域和PS域同时有效。编码方式与EFSTART-HFN中的START值完全相同。

运营商通过设定这个阈值，来平衡安全性和性能：

  • 阈值设得较低: 密钥更新会更频繁，安全性更高，但会增加AKA认证的信令开销，可能影响业务建立时延。

  • 阈值设得较高: 密钥更新频率低，信令开销小，但单次密钥的使用周期变长，理论上的安全风险略有增加。

4. 机制的演进与局限性

EFSTART-HFN和EFTHRESHOLD是UMTS（3G）安全架构的标志性设计。它们与AKA流程紧密耦合，构建了3G时代强大的安全体系。

  • 在4G/LTE时代: 虽然底层的计数器机制依然存在（如NAS COUNT），但其管理和更新方式发生了变化，更多地由手机和核心网（MME）直接管理，USIM卡中这两个文件的作用被弱化，主要用于在3G-4G网络切换（Inter-RAT handover）时保持安全上下文的连续性。

  • 在5G时代: 5G引入了全新的、更强大的安全上下文管理机制。NAS COUNT的管理被明确定义在EF5GS3GPPNSC等文件中。EFSTART-HFN和EFTHRESHOLD则主要保留其在回落到3G网络时的兼容性作用。

因此，理解这对文件，更多的是理解3GPP安全机制演进的“昨天”，但其核心思想——通过计数器来管理密钥生命周期，并通过阈值来强制更新——至今仍然是通信安全设计中的黄金法则。

总结：为密钥安全设定的“倒计时”

EFSTART-HFN和EFTHRESHOLD共同构成了一套精巧的密钥生命周期管理机制，它们是3G时代USIM安全体系中深思熟虑的体现。

  • EFSTART-HFN (里程表): 忠实地记录了每次会话结束时的HFN计数，确保了跨会话计数的连续性，是防止密钥流重用的第一道防线。

  • EFTHRESHOLD (报警器): 设定了不可逾越的安全红线，在密钥寿命即将耗尽前，强制触发新的认证和密钥生成，是保障长期安全性的第二道、也是最坚固的防线。

  • CS/PS分离: EFSTART-HFN为CS和PS域分别记录HFN，体现了对并发、异构业务场景的精细化安全管理。

对于李想而言，他完全感觉不到EFSTART-HFN的频繁更新，也意识不到EFTHRESHOLD的存在。他所能体验到的，只是他的通信服务始终是安全的。这份安全感的背后，正是这对“守护神”在USIM卡中，为每一对会话密钥，默默地设定和执行着“生命倒计时”，并在倒计时归零前，悄然完成新旧密钥的“无感交接”。

FAQ环节

Q1：EFSTART-HFN和EFTHRESHOLD这两个文件是做什么用的？

A1：它们是3G/UMTS安全机制中用于管理密钥生命周期的。EFSTART-HFN像“里程表”，记录了上次通信结束时的高阶计数器HFN的值。EFTHRESHOLD像“报警器”，设定了HFN允许达到的最大值。手机每次建立新连接时，会从EFSTART-HFN的值开始计数，并检查是否已接近EFTHRESHOLD。如果接近，就必须强制进行一次新的认证以更换密钥，从而防止密钥被过度使用而带来安全风险。

Q2：为什么HFN计数器需要存储在USIM卡里，而不是手机内存里？

A2：存储在USIM中是为了安全性和可移植性。HFN是安全上下文的核心组成部分，与密钥紧密相关。将其存储在USIM这个硬件安全模块中，可以防止被手机上的恶意软件篡改。同时，HFN值是跟SIM卡走的。当用户更换手机时，新手机可以从USIM中读出上次的HFN值，无缝地接续安全上下文，这对于跨设备保持通信服务的连续性非常重要。

Q3：如果手机在写入EFSTART-HFN之前突然断电了会怎么样？

A3：这是一个可能导致安全上下文“回滚”的风险点。如果手机未能成功将最新的HFN值写入USIM，那么下次开机时，USIM中保存的将是一个过时的HFN值。手机会从这个旧值开始计数。网络侧的核心网（如SGSN/MSC）保存了最新的HFN，当它收到手机使用一个“较小”的COUNT值发来的信令时，会认为这是一次重放攻击并拒绝该请求。此时，网络会强制发起一次全新的AKA认证流程，重新同步双方的安全上下文。所以，即使发生这种小概率事件，安全机制也能通过重认证来纠正。

Q4：EFTHRESHOLD的值由谁设定？可以修改吗？

A4：EFTHRESHOLD的值由运营商在USIM卡个人化时设定，其UPDATE权限是ADM，用户和手机都无法修改。这个值是运营商核心安全策略的一部分，反映了运营商对安全性和网络性能之间平衡的取舍。

Q5：这两个文件在5G网络下还有用吗？

A5：在纯5G网络（5G SA）的通信中，它们的作用已经被新的机制所取代。5G有自己更完善的密钥体系和安全上下文管理，相关的计数器（NAS COUNT）直接存储在EF5GS3GPPNSC等5G专属文件中。但是，EFSTART-HFN和EFTHRESHOLD的存在对于网络兼容性至关重要。如果5G手机需要回落（Fallback）到3G网络进行语音通话，或者在3G和5G网络之间进行切换（Handover），那么这套基于HFN的机制就会被重新激活，以确保在3G网络下的通信安全。因此，它们是作为保障向后兼容性的重要“遗产”而被保留的。

关系图谱