应用中的合理推诿：是什么及为何重要

合理推诿意味着隐藏数据的存在无法被证明。

加密领域的合理否认性是一种存储特性：用户可以公开一组数据，而不留下能证明另一组数据存在的结构痕迹。这一说法必须写明其威胁模型：对正确填充的加密存储做静态镜像，与正在运行、已被入侵的设备、云服务元数据或保存在别处的副本是两回事。它不只是一个隐藏功能，而是依赖加密、布局、填充和操作设计的共同作用。

本指南解释合理推诿在应用中的工作原理、真正的加密推诿与表面诱饵模式的区别、它重要的现实世界场景，以及如何评估推诿声明。

加密中的合理推诿意味着什么

在日常用语中，合理否认意味着你可以令人信服地否认某件事。在存储密码学中，实用的目标要窄得多：在所声明的威胁模型下，审查加密存储的人应无法把隐藏内容与未使用的填充空间区分开来。任何 App 都无法把这一承诺延伸到已经打开的保险库、被记录的输入、外部副本或各种形式的设备入侵。

这个概念起源于磁盘加密。TrueCrypt（及其继任者 VeraCrypt）开创了隐藏卷：另一个加密卷中的加密卷。一个密码揭示带有无害文件的外部卷。另一个密码揭示带有敏感文件的内部隐藏卷。取证检查员无法确定隐藏卷是否存在，因为外部卷的未使用空间填充了与加密数据无法区分的随机数据。

对于应用，合理推诿意味着不同的凭据（密码、PIN、图案）打开不同的数据集，并且不存在揭示额外数据集存在的元数据、注册表、配置标志或结构性工件。

真正的推诿与表面诱饵模式

这是大多数应用出错的关键区别。

表面诱饵模式（不是真正的推诿）

许多保险库应用提供「诱饵」或「假 PIN」功能。您设置一个打开带有不同照片的独立空间的辅助 PIN。问题是：这些应用通常存储一个布尔值标志、数据库条目或配置文件，表明诱饵模式存在且已配置。

了解该应用的取证检查员可以找到这个标志。找到已配置的诱饵模式证明了隐藏数据的存在。推诿是表面性的——它对随意的窥探者有效，但在取证检查下会失败。

表面推诿的迹象：

• 应用设置中有「诱饵模式」开关
• 配置文件存储诱饵模式是否已启用
• 数据库表列出带有类型指示符（主要/诱饵）的保险库 ID
• 诱饵模式打开时应用的存储结构发生变化
• 在配置了诱饵模式后卸载并重新安装应用会显示不同的行为

真正的加密推诿

真正的推诿是架构属性，而非功能开关。加密存储必须设计为：

1. 备用凭证只公开各自的数据集。 系统不保留任何把某个凭证标记为伪装的单独诱饵标志。无效凭证可以失败，但失败本身不得透露是否存在未公开的数据集。

2. 不存在保险库注册表。应用无法枚举存在多少个保险库。没有计数、没有索引、没有保险库 ID 列表。对应用存储拥有无限访问权限的取证检查员会发现没有结构标记指示保险库边界的未分化加密数据池。

3. 没有配置标志揭示隐藏保险库。没有布尔值、没有数据库条目、没有偏好文件指示是否存在额外保险库。

4. 存储经过填充。消耗的总存储不会根据保险库数量或文件数量而变化。没有填充，检查员可以从总加密数据大小与可见内容的比较中估计保险库数量。

5. 加密数据与随机噪声无法区分。没有文件边界、没有标头、没有揭示一个保险库数据在哪里结束另一个保险库在哪里开始的结构标记。

现实世界中重要的场景

合理推诿不是理论上的担忧。它解决了有据可查的、反复出现的现实世界情况。

过境检查

在过境口岸，检查人员可能会检查设备并要求提供凭证。如果设计真正做到了存储层面的可否认性，一个凭证可以只公开无害的数据集，而静态镜像中不存在能区分隐藏内容和填充内容的结构标记。Vaultaire 目前“每个保险库一个索引文件”的布局，无法对能访问 App 容器的审查人员提供这一保证。

家庭暴力和胁迫关系

处于虐待关系中的人可能需要在施虐者监控的设备上存储证据（伤害照片、威胁短信、法律文件）。如果施虐者要求查看保险库，用户可以打开包含非敏感内容的保险库。没有真正的推诿，应用配置中的「诱饵模式」标志会揭示隐藏内容的存在。

设备盗窃

懂技术的窃贼可能会尝试从被盗手机中提取数据。填充得当的可否认存储，目的是隐藏存储池中有多少个数据集，但总占用空间、设备状态、备份和操作痕迹仍在威胁模型之内。Vaultaire 目前会加密内容，但每个已配置的保险库都会暴露一个可计数的本地索引。

法律和新闻保护

保护消息来源的记者、保护客户文件的律师以及威权体制下的活动人士面临设备内容可能被强制的场景。真正的推诿提供了对抗数据没收的可信辩护。

Vaultaire 目前实现了什么

Vaultaire 实现了按图案分隔的访问，正常界面中也没有可见的保险库列表。这些特性在日常使用 App 时有帮助，但并不能满足上面真正可否认性清单中的全部要求。

已配置的图案打开各自独立的加密保险库。 PBKDF2 从图案和全设备共用的盐值派生出保险库密钥。已配置的密钥会认证对应的加密索引，并解开随机主密钥。未配置的图案显示空状态，而不是“图案错误”提示。

本地格式可以被枚举。 Vaultaire 为每个保险库存储一个 vault_index_<fingerprint>.bin 文件。指纹不会透露图案或保险库名称，但能访问 App 容器的人可以统计索引文件的数量。AES-GCM 认证和确定性的文件名也让候选保险库密钥可以被离线测试。

本地存储大小并不固定。 文件内容和元数据都经过加密，云备份数据块使用大小填充和诱饵记录。本地 App 容器不会保留由真实和虚拟保险库槽位组成的固定池，因此总存储量和索引数量可能暴露结构。

存在恢复状态和胁迫状态。 Vaultaire 将恢复信息保存在经过 AES-GCM 加密的 Keychain 数据库中。胁迫模式会删除非诱饵保险库的本地索引和恢复映射，并让该设备暂停同步。它不会删除云备份、对等设备上的副本或每个共享的加密 blob，完成时间取决于所需的本地工作量。

因此，Vaultaire 提供的是界面上的分隔和加密存储，而不是在信息论意义上证明不存在其他保险库。将来若采用固定容量的目录，需要让真实槽位和虚拟槽位无法区分，才能在离线的 App 容器快照中隐藏本地保险库的数量。

如何评估推诿声明

当应用声称具有合理推诿时，询问：

1. 是否有「诱饵模式」开关？如果有，它是表面性的。取证检查员可以找到该开关。
2. 应用是否有保险库列表或数据库？如果有，保险库的存在是可证明的。
3. 猜测能否离线验证？ 经过认证的密文无需单独的密码哈希就能验证候选密钥。请询问是什么限制了猜测成本，以及存储布局是否提供了更容易利用的密钥指纹。
4. 存储消耗是否随保险库计数变化？如果是，磁盘分析可以估计保险库计数。
5. 应用能否枚举保险库？如果应用可以向您显示保险库列表，该列表存在于设备上且可被发现。

常见问题

合理推诿合法吗？

在大多数民主国家，使用具有合理推诿的加密是合法的。没有法律禁止在设备上保存无法证明其存在的加密数据。在某些司法管辖区（英国的 RIPA、澳大利亚的《援助和访问法》），当局可以强制披露加密密钥。法律问题是强制披露无法证明其存在的数据密钥是否可执行。这仍是一个正在发展的法律领域。

取证工具能检测到合理推诿吗？

拿到 Vaultaire App 容器的审查人员可以发现加密存储，并统计每个保险库的存储目录数量。vault_index_*.bin 根文件位于一个含有掩护文件的 64 槽位池中，但存储目录会暴露哪些是真实的。这些文件不会泄露保险库名称或明文内容，但其数量反映了本地加密索引的数量。因此，当前设计能在正常导航中隐藏保险库，却挡不住每一次取证存储检查。

合理推诿对一个有决心的国家级行为者有效吗？

在密钥、随机数和实现都可靠的情况下，AES-256-GCM 能提供强有力的内容加密边界。但这并不意味着 Vaultaire 当前的存储布局能对国家级审查人员做到可否认：本地索引数量仍然可见，而在保险库打开时，实时入侵可以针对图案、密钥、预览或导出下手。当前功能能在界面中区分不同图案打开的内容，但不能保证坚决的审查人员无法证明其他本地索引的存在。

合理推诿和隐藏保险库有什么区别？

隐藏保险库是指在 App 正常界面中看不到的保险库。强加密可否认性则是另一种特性：隐藏数据无法与未使用的填充存储区分开来。Vaultaire 目前提供的是第一种特性。它“每个保险库一个索引文件”的格式，无法对能访问 App 容器的审查人员提供第二种特性。

我可以在云备份中使用合理推诿吗？

Vaultaire 会把加密的备份清单和填充后的加密文件块写入用户的私有 CloudKit 数据库。随机记录名称、统一的记录类型、10 MB 数据块填充和诱饵记录减少了直接的内容泄露。但记录数量、总量、时间和更新规律仍是可见的服务元数据，因此云备份并不能构成大小恒定、在信息论意义上可否认的存储。

总结

强存储可否认性的目标，是让审查人员无法在静态加密存储中把隐藏数据与填充的空闲空间区分开来。多数声称具备此功能的 App 提供的只是装饰性的诱饵模式，并带有可被发现的配置标志。要满足更严格的定义，需要明确的威胁模型、没有可计数的保险库登记表、没有会泄露的配置标志、稳定的填充，以及不会暴露哪些槽位是真实的加密记录。

Vaultaire 用已配置的图案分隔各个加密保险库，并让保险库名称和内容不出现在锁定界面上。但它当前的存储布局仍会向 App 容器检查暴露加密索引的数量。应把它看作由认证加密支撑的界面级隐藏，而不是不存在其他保险库的证据。