取证结果取决于设备和密钥的实际状态，而不只是数据库或算法的名称。
端到端加密与本地数据保护是相互关联但不同的两个问题。消息在网络传输中受到保护，但要在设备上显示，就必须变得可读。取证检查的结果取决于设备状态、访问类型、系统与应用版本以及密钥位置；任何算法名称本身都不能决定结果。
因此，对“只要物理接触设备就能立即读取一切”和“永远不可能提取”这两种说法，都需要谨慎。
分别检查四个保护层
| 层次 | 主要作用 | 重要局限 |
|---|---|---|
| 消息 E2EE | 保护参与者设备之间的内容 | 不保证设备健康或本地副本安全 |
| 应用隔离 | 限制普通应用访问彼此的数据 | 高权限访问或漏洞可能改变这一模型 |
| 文件或磁盘加密 | 在特定条件下保护已存储的数据 | 锁定状态和密钥是否可用很重要 |
| 应用内数据库加密 | 为数据库文件增加一道边界 | 密钥的保存和使用方式起决定性作用 |
Android FBE 文档区分了依赖用户凭据的存储空间和 Direct Boot 时可用的空间。仅凭“手机已锁定”这句话，无法了解所有密钥的状态；设备启动后是否已经首次解锁，也可能很重要。
SQLite 文件能证明什么？
SQLite 是存储格式和引擎，并不是能独自表明所有保护是否存在的标签。文件可能位于操作系统加密的存储空间中，也可能由独立方案保护。
此外，删除一行并不一定会清除它在所有文件中的全部痕迹。SQLite 文档解释了安全删除设置及虚拟表的局限。检查数据生命周期时，还应考虑附属文件和备份。这并不意味着保证能在每部手机上恢复每条已删除的消息。
不了解应用时，不要对真实数据执行数据库维护命令；直接修改应用文件可能损坏数据或改变证据。
SQLCipher 和 Keystore 是方案，不是免疫证明
SQLCipher 用于透明数据库加密，但必须结合版本阅读其规格。SQLCipher 设计页面描述了带认证的 AES-CBC 结构；2026 年 9 月的第 5 版 Beta 介绍则说明改用 AES-GCM。因此，把同一种加密模式归于所有版本是不准确的。
Android Keystore 也能提供密钥保护和使用控制，但需要明确应用实际使用了哪些功能、何种硬件安全级别。文章里出现 StrongBox 这个名称，不是产品使用它的证据。参见 Keystore 指南。
即使密钥不可提取，在某些条件下也可能通过获准的操作使用。“无法复制密钥”与“攻击者无法解开任何数据”不是同一种主张。
RAM 和棘轮机制起什么作用？
限制密钥和敏感明文的存活时间，可以减少暴露机会。但清除一个缓冲区，并不能证明库、预览或显示过程中没有留下其他副本。
棘轮机制的作用范围也取决于泄露的是哪类密钥，以及攻击者是否仍能持续访问。不能从“每条消息使用独立密钥”推断一次内存抓取最多只会暴露一条消息。在设备上保存可读历史记录，与传输密钥是不同的问题。
关于 Livara，哪些事情尚未得到确认？
Livara 威胁模型不保证保护已感染或已解锁的设备。本文没有独立确认某个具体版本的 Livara 使用 SQLCipher、StrongBox、彻底清除 RAM，或不在本地保存通话数据。没有测试报告和实现证据，就不应将这些特性归于产品。
另外，安全文档中的身份恢复包并不等于历史记录备份。在 Proof Lab 检查 APK 哈希，可以显示文件与可信哈希是否匹配；其结果不是存储审计，也不是反取证测试。
可信的取证主张应包含哪些信息？
应要求提供设备型号、系统和应用版本、锁定状态、访问方法和权限级别、获得的数据类型以及测试局限。某个工具在一次试验中失败，并不能证明所有方法都不可能成功；有限的成功也不能推广到所有用户。
对普通用户而言，更新、强锁屏、减少多余媒体副本以及保护恢复途径更为优先。发生严重事件时，在采取会改变数据或证据的行动之前，请寻求有授权的专业人员帮助。
