51学通信

深度解析 3GPP TS 31.102：4.2.42 EFHiddenkey (隐藏电话本密钥)

17分钟阅读

好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。由于规范中 4.2.41 和 4.2.43 是 Void（空白章节），我们将直接跳过，进入下一个技术章节。

深度解析 3GPP TS 31.102：4.2.42 EFHiddenkey (隐藏电话本密钥)

本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.42 EFHiddenkey (Key for hidden phone book entries)”的核心章节，旨在为读者深入剖析在USIM卡提供的标准化电话本功能中，是如何通过EFHiddenkey这一特殊的“密室钥匙”，为用户的敏感联系人信息提供一层额外的隐私保护。

在之前的探索中，我们已经了解了USIM如何通过DF_PHONEBOOK下的EFADN等文件，来构建一个功能完备的电话本。然而，在日常生活中，我们总有一些联系人信息不希望被轻易看到。这可能是一位重要的商业伙伴、一位私人律师，或者仅仅是用户希望保密的个人联系方式。

如果手机丢失但尚未锁屏，或者被他人临时借用，存储在普通电话本中的所有联系人都将一览无余。为了满足用户对敏感联系人信息的隐私保护需求，3GPP规范在USIM电话本体系中，设计了一套巧妙的“隐藏条目 (Hidden entries)”机制。

这个机制允许用户将电话本中的某些特定联系人标记为“隐藏”。这些被隐藏的联系人，在正常情况下不会显示在手机的联系人列表中。只有当用户输入一个额外的、独立的密码后，这些“密室”中的联系人才能被“解锁”并显示出来。

这个用于解锁隐藏电话本的专属密码，就存储在EFHiddenkey文件中。

EFHiddenkey，全称 Hidden key，即“隐藏密钥”。它的使命非常专一：存储那个用于访问和显示隐藏电话本条目的密码。

1. 电话本的“密室”：隐藏条目机制的核心价值

EFHiddenkey及其所支持的隐藏条目机制，核心价值在于为用户的电话本数据提供了分级的隐私保护。

This EF contains the hidden key that has to be verified by the ME in order to display the phone book entries that are marked as hidden. The hidden key can consist of 4 to 8 digits.

NOTE 2: The phone book entries marked as hidden are not scrambled by means of the hidden key. They are stored in plain text in the phone book.

这段原文和注释揭示了该机制的几个关键点：

  1. 功能: 存储一个4到8位的“隐藏密钥”，手机必须验证 (verified) 这个密钥，才能显示被标记为“隐藏”的电话本条目。

  2. 标记机制: 联系人是否隐藏，不是由EFHiddenkey决定的，而是由我们之前在DF_PHONEBOOK章节简单提过的EFPBC (Phone Book Control) 文件中的一个标志位来标记的。EFHiddenkey只负责存储“解锁密码”。

  3. 非加密存储: 一个非常重要的技术说明是，被隐藏的联系人数据本身并不是被EFHiddenkey加密的 (not scrambled)，它们依然以明文 (plain text) 形式存储在EFADN等文件中。EFHiddenkey只扮演一个“访问控制密码”的角色，而非“数据加密密钥”。

工作流程：

  1. 设置密码: 我们的主角“李想”在他的手机电话本高级设置中，找到了“隐藏联系人”功能。他首次使用时，系统会提示他设置一个4到8位的“隐藏密码”，例如1234。手机会将这个密码加密或处理后，写入EFHiddenkey文件。

  2. 标记联系人: 李想将“张律师”这个联系人标记为“隐藏”。手机会在EFPBC文件中，找到与“张律师”这条EFADN记录相对应的那条EFPBC记录，并将其中的一个“隐藏标志位”置为1。

  3. 日常隐藏: 设置完成后，李想正常打开手机的联系人应用，他会发现“张律师”这个条目已经从列表中消失了。

  4. 访问与解锁:

    • 李想需要联系张律师。他在联系人应用的菜单中点击了“显示隐藏联系人”选项。

    • 手机弹出一个密码输入框，要求输入“隐藏密码”。

    • 李想输入1234。

    • 手机将用户输入的1234与存储在EFHiddenkey中的值进行比对。

    • 比对成功: 手机暂时获得了一个“解锁”状态。它再次遍历电话本，当遇到EFPBC中被标记为“隐藏”的条目时，这次它会将其正常显示出来。“张律师”重新出现在了联系人列表中。

    • 比对失败: 手机提示密码错误，隐藏的联系人依然保持不可见。

  5. 自动锁定: 当李想退出联系人应用或手机锁屏后，这个“解锁”状态通常会自动失效。下次再想查看，需要重新输入密码。

2. 简单的守护者：EFHiddenkey文件结构与编码

EFHiddenkey的设计极为简洁，专注于其单一的使命。

2.1 文件结构

表 4.2.42-1: EFHiddenkey 文件结构

| 属性 | 值 |

| :--- | :--- |

| Identifier | ‘6FC3’ |

| Structure | Transparent |

| File size | 4 bytes |

| Update activity| Low |

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

字节内容

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

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

| 1 to 4 | Hidden Key (隐藏密钥) | M | 4 bytes |

逐项解读：

  • File size: 固定4字节。

  • Access Conditions: READ和UPDATE权限均为PIN。这意味着：

    • 手机在验证用户输入的隐藏密码时，必须先确保USIM已解锁（通过开机PIN），才能读取EFHiddenkey中的正确密码进行比对。

    • 用户在修改隐藏密码时，也需要先通过PIN码验证身份。这防止了在手机临时未锁屏的状态下，他人可以随意修改隐藏密码。

2.2 编码方式

Coding: - the hidden key is coded on 4 bytes using BCD coding. The minimum number of digits is 4. Unused digits are padded with ‘F’.

NOTE 1: Digits are not swapped, i.e. for instance the key “1234” is coded as ‘12 34 FF FF’.

  • 编码: 使用BCD (Binary-Coded Decimal) 编码。

  • 长度: 4个字节可以存储8个BCD码数字，正好对应了密码的最大长度8位。

  • 填充: 如果密码长度不足8位（例如4位），剩余的半字节（nibbles）用'F'填充。

  • 字节序: 注释1特别强调了这里的BCD编码是直接映射的，没有像IMSI编码那样进行奇偶位对调。1234就直接编码为'12 34'。这简化了手机端的处理逻辑。

场景化举例（编码）：

李想设置的隐藏密码是1234。

  • 根据直接BCD编码规则：

    • 数字1和2组成第1个字节 → '12'

    • 数字3和4组成第2个字节 → '34'

    • 密码只有4位，剩余的4个数字位用'F'填充，组成第3和第4字节 → 'FF FF'

  • 最终，EFHiddenkey文件中存储的内容就是：12 34 FF FF (十六进制)。

3. 安全性考量：为何不是加密？

规范的注释2明确指出，隐藏的联系人数据是明文存储的。这是一个非常重要的安全认知。

NOTE 2: The phone book entries marked as hidden are not scrambled by means of the hidden key. They are stored in plain text in the phone book.

这意味着，EFHiddenkey机制提供的是一层**“防君子不防小人”的UI层隐私保护**。它能有效地防止在手机已解锁状态下，被他人通过普通浏览发现敏感联系人。

然而，如果攻击者拥有专业的技术手段，能够绕过手机的操作系统，直接向USIM卡发送APDU命令来读取EFADN文件，那么即使他不知道EFHiddenkey，他依然可以读取到所有联系人的明文信息，包括那些被标记为“隐藏”的。

为什么不加密？

  • 复杂性与性能: 如果对每一条隐藏联系人都用EFHiddenkey进行加密，会大大增加手机和USIM的计算负担，尤其是在显示和搜索时需要实时解密。

  • 密钥管理: 会引入复杂的密钥管理问题。如果EFHiddenkey被修改，所有已加密的联系人数据都需要用旧密钥解密，再用新密钥重新加密，过程非常繁琐且容易出错。

  • 功能定位: USIM电话本隐藏功能的设计初衷，就是提供一种轻量级的、方便快捷的隐私区隔，而不是一个高强度的加密存储方案。它的目标用户场景是防止“临时窥探”，而非对抗“专业攻击”。

总结：简单而实用的隐私“隔断”

EFHiddenkey及其配套的隐藏条目机制，是USIM电话本功能中一个非常人性化和实用的补充。它在不增加过多系统复杂度的前提下，为用户的电话本数据提供了一层有效的隐私隔离。

  • 分级隐私保护: 将电话本划分为“公开区”和“隐藏区”，满足了用户对不同敏感度联系人的差异化管理需求。

  • 独立的认证体系: 使用独立的“隐藏密码”，与开机PIN码分离，提供了第二层访问控制，增强了安全性。

  • 实现简洁高效: 通过简单的标志位（在EFPBC中）和明文存储，避免了复杂的加密解密流程，保证了功能的响应速度和易用性。

对于李想而言，EFHiddenkey就像是他电话本公寓里一间“密室”的钥匙。他可以将最重要的联系人放入这间密室，并锁上门。虽然这扇门不是银行金库级别的，但对于日常生活中的隐私保护已经绰绰有余。它为李想的数字社交生活，提供了一份简单、可靠的安心。

FAQ环节

Q1：EFHiddenkey和PIN/PIN2码有什么区别？

A1：它们是三把功能完全不同的“锁”。

  • PIN码: 是USIM的“大门钥匙”，用于解锁整张卡片的基础通信和安全功能。

  • PIN2码: 是“保险箱钥匙”，用于授权修改FDN、计费信息等高级配置。

  • Hidden Key: 是“电话本密室钥匙”，专门用于解锁和显示被隐藏的联系人，其作用域仅限于电话本功能。这三者密码独立，互不影响。

Q2：如果我忘记了隐藏密码 (EFHiddenkey) 怎么办？

A2：这取决于手机制造商的实现。规范没有定义EFHiddenkey的解锁机制（如PUK）。因此，如果忘记了，通常没有简单的办法可以找回。一些手机可能会提供“重置电话本设置”的选项，但这可能会导致所有隐藏联系人的标记被清除。在最坏的情况下，可能需要联系运营商寻求帮助，或者通过特殊工具对USIM文件进行操作，但这对于普通用户来说非常困难。因此，这个密码需要妥善记忆。

Q3：EFHiddenkey机制可以用来隐藏短信或通话记录吗？

A3：不可以。根据TS 31.102规范，EFHiddenkey和隐藏标记机制是专为电话本功能 (DF_PHONEBOOK) 设计的。EFSMS（短信）和EFICI/EFOCI（通话记录）的文件结构中，并没有定义类似的“隐藏标志位”或与之关联的密钥。隐藏短信或通话记录的功能，如果存在，通常是由手机操作系统（Android/iOS）在上层应用中自己实现的，与USIM卡无关。

Q4：为什么EFHiddenkey的READ权限是PIN？我只是想比对一下密码，为什么需要先解锁整张卡？

A4：这是一种“纵深防御”的安全设计。如果READ权限是ALWAYS，那么恶意软件就可以在手机未锁屏但开机的状态下，无限次地尝试猜测隐藏密码（暴力破解），并通过USIM返回的成功/失败状态码来判断是否猜对。而将READ权限设为PIN，意味着任何尝试验证隐藏密码的操作，都必须先通过第一道大门——整卡解锁。这大大增加了攻击的难度，并确保了只有机主本人才能进行密码验证。

Q5：这个功能在现代智能手机上还常见吗？

A5：这个标准化的、基于USIM的隐藏电话本功能，在现代智能手机上的原生支持已经不太常见。取而代之的是，手机操作系统（如Android的“私密空间”、iOS的“屏幕使用时间”中的限制）提供了更强大、更全面的应用级和系统级的隐私保护功能，它们不仅可以隐藏联系人，还可以隐藏应用、照片、文件等，并且通常与手机的锁屏密码或生物识别（指纹/面容）深度集成。但EFHiddenkey所代表的设计思想——为特定数据提供独立的、第二层的访问密码——在各种现代隐私功能中都得到了继承和发扬。

关系图谱