Senvra 如何保护 iPhone 中的私密数据：四层纵深防御

私密数据不应该先离开手机，才有资格被保护。这正是我们开发 Senvra 的原因：它是一个离线优先的私密空间，可以保存照片、视频、音频、PDF、文件和笔记，不需要账号，不依赖托管云端，也不会自动上传保管库内容。

Senvra 的保管库不需要网络权限。 如果在唤起输入法后看到“网络访问”“本地网络”“无线数据”或第三方键盘“允许完全访问”的请求，可以直接拒绝；Senvra 的本地保管库、解锁、录入和浏览仍可使用。该请求可能来自 iOS 或所选输入法，而不是 Senvra 保管库。处理高敏感内容时，建议使用 Apple 系统键盘，关闭听写与不需要的云端输入功能，或关闭第三方键盘的“允许完全访问”。拒绝这些权限能减少输入内容被键盘组件传出设备的风险，但不能替代对设备安全、输入法来源和主动导出行为的整体管理。

但“存在手机里”不等于“安全”。一个可信的保管库必须回答更难的问题：

• 如果有人反复猜密码会怎样？
• 备份文件被拿走后会暴露什么？
• App 崩溃、录制中断或磁盘写满时，已经产生的数据还能否保住？
• App 进入后台后，解密状态是否还留在内存里？
• 当设备已经越狱时，哪些安全前提会失效？

我们的答案是纵深防御（Defense in Depth）。NIST 将它描述为把人员、技术和运行流程组合起来，在多个层次设置不同屏障。映射到 Senvra，就是四个可以落地的层次：可信环境、加密隔离、安全流程和日常交互保护。

flowchart TB
    A[1. 可信环境<br/>最新 iOS、设备密码、不越狱]
    B[2. 加密隔离<br/>独立空间、独立密钥、认证文件]
    C[3. 安全流程<br/>找回、备份、校验、原子提交]
    D[4. 交互保护<br/>隐私遮罩、闲置锁定、快速关闭]
    A --> B --> C --> D
    D -. 减少暴露窗口 .-> A

这里没有任何一层被包装成“万能方案”。多层设计的价值，恰恰在于某个控制不完美时，其他控制仍然可以降低损害。

第一层：从可信设备环境开始

Senvra 的保护模型面向运行受支持、及时更新、未越狱 iOS，并且设置了设备密码的 iPhone。

这个边界不能含糊。越狱会削弱正常 iOS App 共同依赖的沙盒、代码签名和进程隔离能力。当攻击者取得操作系统级控制后，他可能读取 App 私有目录、插桩正在运行的进程，或者在数据为正常使用而解密后截取密钥。越狱检测可以提高攻击成本，但 OWASP 同样明确指出，这类检测本身可以被绕过。任何 App 如果承诺能在操作系统已经完全失守时依然“绝对安全”，都是在作出无法兑现的承诺。

因此，最基础也最重要的动作是：

1. 及时更新 iOS。
2. 使用强设备密码并开启 Face ID。
3. 不在越狱设备上保存敏感数据。
4. 把一台已经解锁的手机视为更高风险环境。

Senvra 也主动缩小自己的信任面。保管库内容在设备端处理和保存；没有 Senvra 账号，没有托管云端保管库，也没有自动上传。生产版保管库操作不需要网络客户端、WebView、本地网络声明或后台网络权限。只有当用户主动打开 Support 时，App 才会交给系统浏览器；用户主动导出的副本，则由用户选择的目标位置接管。

离线优先并不意味着“不可能被攻击”。它移除的是一整类常见的服务端暴露：不存在一个集中式 Senvra 云端保管库，供攻击者、运营方或一次数据泄露批量获取。

第二层：隔离空间、密钥与文件

在 Senvra 里，加密不是一个宣传标签，而是一套职责分离的密钥层级。

每个私密空间都有独立生成的 256 位主密钥、密码盐和加密身份。密码先经过 PBKDF2-HMAC-SHA256 派生；当前生产参数为 600,000 次迭代。派生密钥负责解包空间主密钥，而不是直接拿同一个密码密钥去加密所有文件。

每个受保护项目使用 AES-256-GCM 认证加密。这里“认证”同样重要：它不仅隐藏内容，也能发现内容是否被修改。媒体分块、元数据、缩略图、密钥信封，以及它们所属的空间和对象身份，都通过认证数据绑定。把某个密文组件挪到错误空间，并不会让它在新位置变成有效数据。

flowchart LR
    P[空间密码] --> K[PBKDF2-HMAC-SHA256<br/>600,000 次 + 独立盐]
    R[32 字节访问密钥] --> H[HKDF-SHA256<br/>独立恢复域]
    K --> M[被包装的 256 位空间主密钥]
    H --> M
    M --> I[相互独立的项目密钥信封]
    I --> G[AES-256-GCM 媒体分块]
    I --> T[认证元数据与缩略图]

一个密码，一个空间，没有列表

很多保管库会先展示“你有哪些保险箱”，再让用户选择并输入密码。这一步本身就在泄露信息：旁观者即使看不到内容，也会知道私密空间存在、共有几个，以及它们叫什么。

Senvra 采用相反的流程。App 首先呈现普通的 Everyday 空间；私密空间不出现在可浏览列表中。用户只面对一个统一入口，输入哪个空间的密码，就直接进入哪个空间。不同密码对应不同空间，入口不会预先展示私密空间的名称、封面或真实数量。对肩窥、临时检查或他人短暂拿到已解锁手机的场景而言，这减少了“这里还藏着其他空间”的可感知线索。

这不只是一层界面隐藏。持久化目录使用固定的四个目录槽位，并用填充描述符和填充文件补足未使用的位置，从外观上弱化真实空间数量的差异。解锁时，Senvra 会遍历真实密码空间并补齐统一的密码派生与掩蔽工作，不会因为提前命中某个空间就立即返回。错误尝试也采用一致处理；每累计三次失败后，等待时间依次提升为 1 分钟、5 分钟、30 分钟、1 小时和 24 小时。

这项设计降低的是界面与目录元数据暴露，不应被误解为“隐藏就等于加密”，也不承诺在越狱设备或专业取证条件下绝对不可发现。真正的内容保护仍由独立密钥、认证加密和可信设备环境承担。

同一套密钥层级也让项目彼此隔离。大视频按有界分块认证；一个项目损坏，并不意味着其他无关文件也应被信任或一起失效。Security Center 可以在不导出整个资料库的情况下认证受保护文件并定位完整性问题。

iOS 自身的保护仍然是这一层的一部分。敏感目录使用 Complete File Protection；设备绑定的包装材料保存在 WhenUnlockedThisDeviceOnly Keychain 中。Senvra 增加了应用层加密，但不会假装底层平台无关紧要。

第三层：让找回、备份和故障过程同样安全

只有保密、没有恢复，并不是完整的数据安全。人会忘记密码，设备会损坏，磁盘会写满，进程也可能在最不合适的时候被终止。Senvra 把这些情况当作设计输入，而不是异常备注。

用户持有的访问密钥，而不是服务器重置

每个私密空间可以拥有一枚随机 32 字节访问密钥。它能够恢复访问、重设密码，也可以在验证旧密钥后完成轮换。Senvra 不存在服务端“忘记密码”后门。

这也形成了清晰的责任边界：如果密码和访问密钥同时丢失，Senvra 无法替用户解密空间。访问密钥应保存在手机之外的可信位置。

备份必须同时满足两份独立凭据

当前 V3 便携备份使用双凭据：

• 私密空间备份需要空间访问密钥和独立的备份密码。
• 公共空间备份需要新生成的随机备份密钥和独立的备份密码。

备份密码使用 PBKDF2-HMAC-SHA256 进行 600,000 次派生；凭据密钥与密码派生材料再通过带域分离的 HKDF 组合。组合密钥只负责认证并解包随机生成的归档密钥。真正的归档数据被写成相互独立认证的 AES-256-GCM 帧，帧序号和记录类型也会进入认证数据。

因此，只拿到备份文件、只知道备份密码，或者只持有保存的密钥，都不足以打开备份。

flowchart TB
    A[访问密钥或随机备份密钥] --> C[带域分离的密钥组合]
    B[备份密码<br/>PBKDF2-HMAC-SHA256] --> C
    C --> D[认证并解包随机归档密钥]
    D --> E[用 AES-256-GCM 加密有界数据帧]
    E --> F[校验标签、字节数、项目摘要、清单摘要]
    F --> G[原子发布完整 .senvrabackup]
    F -. 任一失败 .-> X[拒绝并删除未完成输出]

V3 外层头部不会暴露空间名称、项目名称、源标识、缩略图或作用域细节。只有当所有认证帧、字节数、项目摘要、清单摘要和最终结束标记全部一致时，备份才会被接受。导入还会检查备份作用域是否与目标空间匹配，并记录来源，避免同一内容被静默重复导入。

主保管库明确排除在普通 Apple 设备备份之外。只有完整、强加密、匿名命名的恢复容器可以进入 Apple 恢复路径。用户也可以手动把加密备份保存到 Files 或其他自己控制的位置。

Senvra 支持在不导入内容的情况下验证备份。我们建议在重要内容变更后执行验证，并定期进行恢复演练。一个从未验证过的备份，只能算愿望，不能算证据。

录制数据按阶段提交，而不是最后一次性加密

录制场景经常让隐私与可靠性发生冲突。如果先写一整个明文视频，最后才开始加密，中间会留下很大的风险窗口。Senvra 会在录制片段到达时直接写入受保护数据。

录制开始前，Senvra 会创建受文件保护的日志并预留收尾空间。每个已经接收的片段会先加密、同步到持久化存储，再写入原子更新的日志。只有当片段结构、字节数和 SHA-256 摘要全部一致后，最终元数据才会提交；待定目录也只有在验证完成后才会移动到正式项目位置。

如果 App 被中断，下一次启动时可以发现并恢复已经提交的受保护片段。这并不承诺突然断电时，仍停留在硬件或系统缓冲区里的最后一帧也一定存在；它意味着故障不应迫使 Senvra 丢弃此前已经加密并完成持久化的所有有效片段。

同一事务模式也用于其他关键写入：先写待定位置，完成验证与同步，再原子发布。未完成的工作不会被伪装成完整数据。

重要访问会留下可验证痕迹

打开空间和关键敏感操作会进入一条加密、只追加的活动链。每条事件都连接上一条事件；独立 Keychain 锚点用于帮助发现活动链被截断、替换或回滚到旧版本。

这不是实时入侵通知，也不能证明具体是谁执行了某个动作。它提供的是比“什么都没发生”更有价值的本地证据：空间主人可以查看重要访问记录，并检查这条历史在结构上是否一致。

第四层：保护人最容易忘记的瞬间

很多隐私泄露发生在认证成功之后：切换 App、接到电话、把手机放在桌上、开始录屏，或者单纯忘了关闭空间。安全功能必须足够顺手，才能在这些时刻真正工作。

因此，Senvra 会把 App 生命周期变化直接视为安全事件：

• App 变为非活跃状态时，隐私遮罩覆盖敏感内容，并清除临时明文。
• App 进入后台时，当前私密空间关闭，内存中的解锁状态被清理。
• 设备锁屏会关闭受保护访问，并停止敏感工作。
• 检测到屏幕捕获时显示隐私遮罩；只有完成安全过渡后才重新展示内容。
• 闲置锁定可设为 30 秒、1 分钟、2 分钟、5 分钟或 15 分钟。
• 快速关闭按钮可以立刻回到普通空间；可选的“摇一摇关闭”提供第二条退出路径。
• App 失活时，长时间运行的导入、导出、备份、完整性检查和本地索引会被取消或遮蔽。

当 iOS 告知 App 已经发生截图时，Senvra 也会响应，但边界必须说清楚：iOS App 无法可靠删除操作系统已经保存或同步的截图。Senvra 会关闭受保护内容并清除解锁状态，但不会宣称可以让时间倒流。

Face ID 或手势解锁属于便利入口，始终从属于空间的独立密码和恢复凭据。便利功能应该减少摩擦，而不是成为唯一恢复路径。

这套模型不承诺什么

安全表述必须可以被验证。Senvra 不会宣称：

• 在越狱或操作系统已经完全失守时仍能提供绝对保护；
• 拿着一台已经解锁手机的人永远不可能看到内容；
• iOS 已经完成的截图一定可以被召回；
• 用户导出明文副本后，目标位置仍受保管库控制；
• 提供远程擦除、自动云同步或服务端密码找回；
• 已经取得尚未发生的第三方独立安全认证。

如果设备和所有可用备份一起丢失，Senvra 也无法阻止数据丢失。加密、完整性与恢复彼此相关，但不能互相替代。

一份可执行的安全设置清单

为了获得最强的实际保护：

1. 保持 iOS 更新，不要越狱设备。
2. 使用强设备密码并开启 Face ID。
3. 为每个空间使用唯一密码；Senvra 最低要求 12 个字符，建议 16 个字符以上。
4. 把访问密钥保存在 Senvra 之外，也不要只存在同一台手机上。
5. 使用独立密码创建加密备份，并把备份文件和两项必要凭据保存在适当隔离的可信位置。
6. 在资料库发生重要变化后运行 Verify，并定期进行恢复演练。
7. 选择自己能够接受的最短闲置锁定时间，并开启能够稳定执行的快速关闭方式。
8. 记住：导出的明文副本已经不再受保管库约束。

为什么我们要这样做 Senvra

我们不希望“保护隐私”意味着先把私密内容上传到另一家公司的服务器，也不希望用户为了持续访问自己的数据而永久付费，更不希望全部安全只依赖一个锁屏页面。Senvra 一次性购买、没有广告、没有订阅；核心保管库可以离线工作，因为数据所有权和恢复能力应该留在持有数据的人手里。

最终结果不是一句“无法破解”，而是一组边界清楚的屏障：可信的平台、相互独立的加密域、面向故障的恢复流程，以及能够快速结束暴露的交互。所谓“安全地留在手机里”，应该意味着更少的信任对象、诚实的能力边界，以及一条在真正需要之前就可以验证的恢复路径。

延伸阅读

• NIST：纵深防御
• OWASP MASVS：移动应用安全验证标准
• OWASP MASTG：越狱检测及其边界
• Apple Platform Security