备份真正有用的那一天：Senvra 如何让私密数据回来

真正需要备份的那一天，通常不是一个好日子。

也许手机丢了，也许 App 被误删了，也许设备已经无法开机。到了那一刻，设置页里曾经出现过的绿色对勾并不重要。重要的只有两件事：你手里的备份文件还能不能被验证，以及你还能不能把里面的数据带回来。

这也是我们为什么愿意单独写一篇文章谈备份。对私密数据来说，“有备份”远远不够。备份必须在离开 Senvra 之后仍然保密，必须能发现损坏，还必须在真正出事之前被实际验证过。

我们最后把恢复所需的东西收敛成两样

现在创建一份 Senvra 备份后，你需要保管：

1. 一个 .senvrabackup 加密文件；
2. Senvra 为这份文件生成的 Backup Key。

没有额外的 Backup Password，也不需要记住创建备份时的空间密码。

Backup Key 不是 UUID，也不是由时间、设备型号或空间信息拼出来的字符串。它由系统安全随机数生成器产生，包含 20 个随机字节，也就是 160-bit 随机熵。界面把它显示成五组八位十六进制字符，只是为了更容易阅读和核对，随机强度并没有因此改变。

每创建一份新备份，都会得到一枚新的 Backup Key。它只负责这一份文件。

flowchart LR
    V[当前空间] --> B[创建新备份]
    B --> F[加密文件<br/>.senvrabackup]
    B --> K[独立 Backup Key<br/>160-bit 随机熵]
    F --> R[恢复]
    K --> R

这不是“双因素备份”，我们也不会把它包装成双因素。它是一份高强度、不可猜测的密码学秘密。安全边界很清楚：只有文件打不开；只有 Key 也没有数据；文件与 Key 同时落入别人手中，备份就可能被打开。

所以，真正重要的动作不是“再想一个密码”，而是把文件和 Key 分开保存。

为什么我们删掉了 Backup Password

一开始，最直觉的方案确实是 Backup Key 再加一个 Backup Password。看上去多一道输入，就多一层安全。

但备份面对的风险与日常登录不太一样。日常登录可以重试，可以重设；离线备份一旦丢失凭据，没有服务器能够帮你找回。多一项需要多年记住的秘密，也多一个让整份备份永久失效的机会。

更关键的是，随机生成的 160-bit Backup Key 本身就不是人类密码。它没有字典词、生日、键盘规律，也不依赖用户是否擅长设计密码。攻击者面对的是一个规模为 2^160 的随机空间，而不是常见的短密码猜测。

因此我们做了一个刻意的取舍：不用第二个人脑密码制造“看起来更复杂”的安全感，而是使用一枚强随机、每份备份独立的 Key，让恢复流程只剩下一个不能丢、也不能泄露的秘密。

这降低了使用负担，但没有降低保管责任。Senvra 不会保存 Backup Key 的可恢复副本。你确认已经保存后，它才会继续创建备份；如果 Key 丢失，Senvra 也无法打开那份文件。

Space Access Key 与 Backup Key 是两把完全不同的钥匙

这里最容易混淆，也最值得讲清楚。

私密空间已经打开，并不意味着任何拿到这台手机的人都应该能把全部内容导出去。因此，创建私密空间备份前，Senvra 仍会要求你输入创建该空间时保存的 Space Access Key，并在手机本地验证它确实属于当前空间。

页面会为这次操作单独生成 Backup Key，但在所有权验证通过前，不会创建任何备份文件。

验证通过后，Space Access Key 就完成了任务。它不参与备份文件加密，不会写入备份文件，也不是日后恢复所需的 Key。真正保护文件的是那枚独立生成的 Backup Key。

flowchart TB
    A[Space Access Key] --> O[本地验证空间所有权]
    K[生成独立 Backup Key] --> C[准备备份凭据]
    O -->|通过| E[允许创建加密备份文件]
    C --> E
    E --> R[日后仅凭 Backup Key 验证或恢复]
    A -. 不写入文件<br/>不参与文件加密 .-> E

这样分开有三个实际好处：

• 即使手机当时已经解锁，缺少正确 Space Access Key 仍不能全量导出私密空间；
• Backup Key 泄露不会直接变成打开私密空间或重置空间密码的凭据；
• Space Access Key 日后轮换，也不会让以前已经妥善保存的备份失效。

公共空间没有这道所有权复核，但仍然会为每份备份生成独立 Backup Key。

Backup Key 如何真正保护文件

Backup Key 的文本会被解析为原始 20 字节随机数据，再通过 HKDF-SHA256 和每个备份独立的 32 字节随机盐，派生出用于包装密钥的 256-bit Key。

Senvra 同时生成一枚新的随机 256-bit Archive Key。真正的内容由 Archive Key 加密，Backup Key 派生出的 Key 只负责认证检查并包装 Archive Key。

这样做不是为了把“160-bit”宣传成“256-bit”。安全强度仍由原始 Backup Key 的 160-bit 随机熵决定。分层的意义是让用户凭据、归档密钥和内容加密各自承担单一职责，也让每份备份拥有独立的随机上下文。

文件内部使用 AES-256-GCM 认证加密。Manifest、项目元数据、缩略图、合集、标签和内容都在加密层内。外层只保留解析文件所需的最少信息，例如格式版本、创建时间、随机容器 ID、随机盐和功能标记。

文件大小、文件存在以及 .senvrabackup 扩展名仍可能被存储服务看到。内容加密可以保护里面是什么，但不能假装文件本身从未存在。

大视频不会先变成一个明文压缩包

我们不希望备份过程在磁盘上留下一个等待“稍后加密”的明文 ZIP。

Senvra 会逐项读取数据，通过受限内存缓冲区切成 4 MiB 数据帧，立即使用随机 Archive Key 加密并写入容器。大型视频不需要先以完整明文副本的形式落到临时目录。

每个加密帧都会绑定格式版本、容器 ID、Header 上下文、帧序号和帧类型。读取时还会核对每个项目的字节数、分块数量和 SHA-256 内容摘要，以及整个归档的项目总数、总字节数和 Manifest 摘要。

这意味着改动一个数据块、调换帧顺序、把文件截短、替换帧类型，或者在末尾偷偷追加内容，都会导致验证失败。

进度到 100%，还不能算备份完成

这是整个设计里我们很在意的一点。

Senvra 先把内容写进受文件保护的 pending 文件。写入完成后，它不会立刻把文件交给用户，而是从头到尾重新读取一遍，认证所有加密帧，并确认读出的 Manifest 与准备写入的内容完全一致。只有这一步通过，pending 文件才会被原子发布为完成的备份。

随后你会通过“文件”或其他位置保存它。但复制过程同样可能失败，所以 Senvra 还会比较 App 内已验证文件与外部副本的 Header、字节数和完整文件 SHA-256。两份文件完全一致后，Security Center 才会把它记录为当前备份。

sequenceDiagram
    participant D as 当前数据
    participant P as Pending 密文
    participant F as 用户保存的文件
    participant S as Security Center

    D->>P: 逐帧读取并立即加密
    P->>P: 从头回读并认证全部内容
    P->>F: 用户保存外部副本
    F->>S: 比较 Header、大小与完整文件摘要
    S-->>D: 一致后才记录为当前备份

所以“文件生成了”和“安全副本已经保存”是两个状态。我们不想用一个绿色对勾把它们混在一起。

恢复演练不是形式检查

很多备份真正失败的原因，不是从来没有创建，而是从来没有试过恢复。

Senvra 的恢复演练不会向当前空间导入任何项目。它会要求对应的 Backup Key，打开被包装的 Archive Key，认证 Header，读取每一帧，验证 Manifest、项目关系、内容摘要和归档结束标记，并确认末尾没有多余数据。

备份中还保存了一份受加密保护的来源内容指纹。这样 Senvra 能区分两件事：

• 这是一份密码学上完整、仍然可以打开的旧备份；
• 这是一份完整并且仍与当前空间内容一致的最新备份。

两者都可能有价值，但它们不是同一种状态。只有第二种会被记为当前空间最近一次有效的恢复演练。

恢复不会覆盖当前空间

Senvra 的恢复更接近“把可信内容导入这里”，而不是“把手机回滚到某个历史快照”。

备份只能导入相同类型的当前空间。恢复不会重建来源空间列表，不会暴露那里曾经有几个私密空间，也不会替换当前空间的名称、皮肤、密码、Space Access Key、Face ID 或手势设置。

在真正落盘前，Senvra 会先完整验证备份。随后每个项目单独进入受保护临时目录，使用当前空间的新项目密钥重新加密，回读验证后再原子发布。

如果导入中途被打断，已经存在的内容不会被破坏。再次选择同一份备份时，Senvra 会识别已经完成的项目并跳过，而不是再复制一份。

Backup Key 也只会短暂停留在剪贴板

为了让保存过程不那么痛苦，Senvra 允许临时复制 Space Access Key 和 Backup Key。但复制时会把剪贴板标记为仅限本机，不参与跨设备通用剪贴板，并设置 120 秒过期时间。

如果 120 秒内你又复制了别的内容，Senvra 不会粗暴地把新内容一起清掉。它只会在剪贴板仍然是刚才那份 Key 时执行主动清理。

这不是让剪贴板变成保险箱。它只是尽量缩短敏感文本暴露的时间。保存 Key 时仍应避免使用会上传剪贴板或输入内容的第三方工具。

我们建议你这样保存

最实用的做法其实很简单：

1. 创建备份时，先把 Backup Key 保存到可信位置，再确认继续。
2. 不要把 Backup Key 写进备份文件名，也不要与 .senvrabackup 文件放在同一条聊天消息、同一封邮件或同一个未加密文件夹。
3. 至少保留两份已经验证的备份文件，放在彼此独立的位置。
4. 重要内容变化后创建新备份，并让 Senvra 完成外部副本确认。
5. 定期执行恢复演练。新备份通过验证前，不要删除最后一份已知可用的旧备份。

Senvra 本身不需要网络权限，也不会替你上传备份。通过“文件”选择的目标位置是否联网同步，由对应的存储服务决定。

可选的 Apple Recovery Copy 同样是一份需要 Backup Key 才能打开的加密容器。Senvra 可以验证副本并让它进入系统备份路径，但无法保证 Apple 设备备份一定存在、保留多久或最终一定能够恢复。

最后，把边界说清楚

如果只有备份文件，没有 Backup Key，Senvra 无法替你找回。

如果只有 Backup Key，没有备份文件，同样没有数据可以恢复。

如果两者一起泄露，备份的保密性也就失去了。这套设计不会假装能解决错误保管、已越狱设备或已经被控制的操作系统。

我们能做的是把每一步都变成可验证的工程事实：导出私密空间前重新证明所有权；为每份备份生成独立随机 Key；不落明文中间包；认证每个数据帧；创建后完整回读；保存后核对外部副本；恢复前允许真正演练。

对我们来说，这比一句“您的备份已加密”更有意义。

想了解这些设计如何与离线运行、隐藏空间和日常隐私控制配合，可以继续阅读 Senvra 如何保护 iPhone 中的私密数据 和 Senvra 产品指南。

延伸阅读

• RFC 5869：HKDF
• NIST SP 800-38D：GCM 认证加密
• Apple Platform Security
• OWASP MASVS-STORAGE-1