应用中的合理推诿:是什么及为何重要
合理推诿意味着隐藏数据的存在无法被证明。
加密中的合理否认性是一种存储属性,它允许用户公开一个数据集,而不会留下证明另一个数据集存在的结构工件。该声明必须命名其威胁模型:正确填充的加密存储的静态图像不同于实时的、受损的设备、云服务元数据或其他地方保存的副本。这不仅仅是一个隐藏功能。这取决于加密、布局、填充和操作设计的协同工作。
本指南解释合理推诿在应用中的工作原理、真正的加密推诿与表面诱饵模式的区别、它重要的现实世界场景,以及如何评估推诿声明。
加密中的合理推诿意味着什么
在日常用语中,合理的否认意味着你可以可信地否认某件事。在存储密码学中,有用的目标更窄:加密存储的检查者不应该能够将隐藏内容与所声明的威胁模型中未使用的填充空间区分开来。没有任何应用程序可以将这一承诺扩展到已经打开的保管库、记录的输入、外部副本或各种形式的设备妥协。
这个概念起源于磁盘加密。TrueCrypt(及其继任者 VeraCrypt)开创了隐藏卷:另一个加密卷中的加密卷。一个密码揭示带有无害文件的外部卷。另一个密码揭示带有敏感文件的内部隐藏卷。取证检查员无法确定隐藏卷是否存在,因为外部卷的未使用空间填充了与加密数据无法区分的随机数据。
对于应用,合理推诿意味着不同的凭据(密码、PIN、图案)打开不同的数据集,并且不存在揭示额外数据集存在的元数据、注册表、配置标志或结构性工件。
真正的推诿与表面诱饵模式
这是大多数应用出错的关键区别。
表面诱饵模式(不是真正的推诿)
许多保险库应用提供「诱饵」或「假 PIN」功能。您设置一个打开带有不同照片的独立空间的辅助 PIN。问题是:这些应用通常存储一个布尔值标志、数据库条目或配置文件,表明诱饵模式存在且已配置。
了解该应用的取证检查员可以找到这个标志。找到已配置的诱饵模式证明了隐藏数据的存在。推诿是表面性的——它对随意的窥探者有效,但在取证检查下会失败。
表面推诿的迹象:
- 应用设置中有「诱饵模式」开关
- 配置文件存储诱饵模式是否已启用
- 数据库表列出带有类型指示符(主要/诱饵)的保险库 ID
- 诱饵模式打开时应用的存储结构发生变化
- 在配置了诱饵模式后卸载并重新安装应用会显示不同的行为
真正的加密推诿
真正的推诿是架构属性,而非功能开关。加密存储必须设计为:
备用凭证仅公开他们自己的数据集。 系统不会保留将一个凭证标识为伪装的单独诱饵标志。无效的凭据可能会失败,但该失败不得揭示是否存在未公开的数据集。
不存在保险库注册表。应用无法枚举存在多少个保险库。没有计数、没有索引、没有保险库 ID 列表。对应用存储拥有无限访问权限的取证检查员会发现没有结构标记指示保险库边界的未分化加密数据池。
没有配置标志揭示隐藏保险库。没有布尔值、没有数据库条目、没有偏好文件指示是否存在额外保险库。
存储经过填充。消耗的总存储不会根据保险库数量或文件数量而变化。没有填充,检查员可以从总加密数据大小与可见内容的比较中估计保险库数量。
加密数据与随机噪声无法区分。没有文件边界、没有标头、没有揭示一个保险库数据在哪里结束另一个保险库在哪里开始的结构标记。
| 属性 | 表面诱饵 | 真正推诿 |
|---|---|---|
| 每个凭据的独立数据 | 是 | 是 |
| 无保险库注册表 | 否(数据库跟踪保险库) | 是 |
| 无配置标志 | 否(诱饵开关被存储) | 是 |
| 存储填充 | 罕见 | 是 |
| 在静态图像中隐藏备用存储 | 否 | 是的,在规定的存储威胁模型内 |
| 架构与功能 | 功能开关 | 架构属性 |
现实世界中重要的场景
合理推诿不是理论上的担忧。它解决了有据可查的、反复出现的现实世界情况。
过境检查
在过境点,检查员可能会检查设备并要求提供凭证。如果设计实际上提供了存储级可否认性,则一个凭证可以泄露无害的数据集,而静态图像则缺乏区分隐藏内容和填充内容的结构标记。 Vaultaire 当前的每个 Vault 一个索引文件的布局无法为具有应用程序容器访问权限的审查员提供这一保证。
家庭暴力和胁迫关系
处于虐待关系中的人可能需要在施虐者监控的设备上存储证据(伤害照片、威胁短信、法律文件)。如果施虐者要求查看保险库,用户可以打开包含非敏感内容的保险库。没有真正的推诿,应用配置中的「诱饵模式」标志会揭示隐藏内容的存在。
设备盗窃
具有技术技能的小偷可能会尝试从被盗手机中提取数据。适当填充的可拒绝存储旨在隐藏占用池的数据集数量,尽管总分配、设备状态、备份和操作跟踪仍然属于威胁模型。 Vaultaire 目前对内容进行加密,但为每个配置的保管库公开一个可计数的本地索引。
法律和新闻保护
保护消息来源的记者、保护客户文件的律师以及威权体制下的活动人士面临设备内容可能被强制的场景。真正的推诿提供了对抗数据没收的可信辩护。
Vaultaire 今天实施了什么
沃尔泰尔 实现模式分隔的访问和没有可见保管库列表的正常界面。这些属性在普通应用程序使用期间有所帮助,但它们并不能满足上面的真实否认清单中的所有要求。
配置的模式打开单独的加密保管库。 PBKDF2 从模式和设备范围的盐中派生出保管库密钥。配置的密钥验证其加密索引并解包随机主密钥。未配置的模式显示空状态而不是“不正确的模式”消息。
本地格式是可枚举的。 Vaultaire 存储了一个 vault_index_<fingerprint>.bin 每个保管库的文件。指纹不会显示模式或保管库名称,但具有应用程序容器访问权限的人员可以对索引文件进行计数。 AES-GCM 身份验证和确定性文件名还为候选保管库密钥提供离线测试。
本地存储的大小不是恒定的。 文件内容和元数据被加密,云备份块使用大小填充和诱饵记录。本地应用程序容器不保留真实和虚拟保管库插槽的固定池,因此总存储和索引计数可以公开结构。
存在恢复和胁迫状态。 Vaultaire 将恢复信息保存在 AES-GCM 加密的 Keychain 数据库。 胁迫模式 删除非胁迫保管库的本地索引和恢复映射,并将该设备与同步隔离。它不会删除云备份、对等设备上的副本或每个共享的加密 blob,并且完成时间取决于执行的本地工作。
因此,Vaultaire 提供了接口划分和加密存储,而不是证明不存在额外保管库的信息理论证明。未来的固定容量目录需要具有无法区分的真实插槽和虚拟插槽,以隐藏脱机应用程序容器快照中的本地保管库计数。
如何评估推诿声明
当应用声称具有合理推诿时,询问:
- 是否有「诱饵模式」开关?如果有,它是表面性的。取证检查员可以找到该开关。
- 应用是否有保险库列表或数据库?如果有,保险库的存在是可证明的。
- 猜测可以离线验证吗? 经过身份验证的密文可以验证候选密钥,而无需单独的密码哈希。询问是什么限制了猜测成本以及存储布局是否提供了更便宜的密钥指纹。
- 存储消耗是否随保险库计数变化?如果是,磁盘分析可以估计保险库计数。
- 应用能否枚举保险库?如果应用可以向您显示保险库列表,该列表存在于设备上且可被发现。
常见问题
合理推诿合法吗?
在大多数民主国家,使用具有合理推诿的加密是合法的。没有法律禁止在设备上保存无法证明其存在的加密数据。在某些司法管辖区(英国的 RIPA、澳大利亚的《援助和访问法》),当局可以强制披露加密密钥。法律问题是强制披露无法证明其存在的数据密钥是否可执行。这仍是一个正在发展的法律领域。
取证工具能检测到合理推诿吗?
获得 Vaultaire 应用程序容器的审查员可以检测加密存储并计数 vault_index_*.bin 文件。这些文件不会泄露保管库名称或纯文本内容,但它们的计数显示了本地加密索引的数量。因此,当前的设计将金库隐藏起来,使其无法正常导航,而不是每次法医存储检查。
合理推诿对一个有决心的国家级行为者有效吗?
AES-256-GCM 当密钥、随机数和实现合理时,可提供强大的内容加密边界。这并不意味着 Vaultaire 当前的存储布局对于国家检查员来说是可否认的:本地索引计数仍然可见,并且实时妥协可以在保管库打开时针对模式、密钥、预览或导出。当前功能区分了界面中打开的不同模式;它并不保证坚定的审查员无法证明其他本地索引的存在。
合理推诿和隐藏保险库有什么区别?
隐藏保管库是在应用程序的正常界面中不可见的保管库。强加密可否认性是隐藏数据无法与未使用的填充存储区分开的单独属性。 Vaultaire 目前提供第一个房产。它的“每个库一个索引文件”格式不提供针对具有应用程序容器访问权限的审查员的第二个格式。
我可以在云备份中使用合理推诿吗?
Vaultaire 将加密的备份清单和填充的加密文件块写入用户的私有空间 CloudKit 数据库。随机记录名称、统一记录类型、10 MB 块填充和诱饵记录可减少直接内容泄露。记录计数、总量、时间和更新模式仍然可见的服务元数据,因此云备份不会创建大小恒定、信息理论上可否认的存储。
总结
强存储否认性旨在防止检查者将隐藏数据与静态加密存储中的填充可用空间区分开来。大多数声称具有此功能的应用程序都提供带有可发现的配置标志的装饰诱饵模式。满足更强的定义需要精确的威胁模型,没有可数的保管库注册表,没有泄露的配置标志,稳定的填充以及不暴露哪些插槽是真实的加密记录。
沃尔泰尔 使用配置的模式来分离加密的保管库,并使保管库名称和内容远离锁定界面。其当前的存储布局仍然向应用程序容器检查公开加密的索引计数。将其视为由经过身份验证的加密支持的接口级隐藏,而不是作为不存在其他保险库的证据。