iCloud E2E Sync, Demystified: What Apple Can and Cannot Read About Your Vault
CloudKit Private Database, Advanced Data Protection, envelope encryption — the actual line between "Apple stores your data" and "Apple can read your data". Concrete answers, no marketing fog.
Published: 2026-05-05 · 11 min read
没人愿意直接回答的问题
如果你的密码管理器走 iCloud 同步，每个有隐私意识的用户首先会问的问题是：
"Apple 能不能看到我的密码？"
诚实的回答是有条件的，取决于三件事：
- App 用了 CloudKit 哪个存储等级（Public / Private / Shared）
- App 是上传前自己加密，还是依赖 Apple 的加密
- 用户的 Apple ID 上有没有开启高级数据保护（Advanced Data Protection, ADP）
本文逐一拆解每种情况下 Apple 能看到什么，ByteGuard 具体怎么做，"Apple 看不到"的边界究竟在哪。
CloudKit 存储等级
Apple 的 CloudKit 框架提供三种存储范围：
| 等级 | 谁能读 | Apple 静态加密 | 端到端加密 |
|---|---|---|---|
| Public Database | 该 App 的所有用户 | 是（TLS + 静态 AES） | 否 |
| Private Database | 仅 iCloud 用户本人 | 是 | 默认：否。开 ADP 后：多数字段是。App 自己加密：是。 |
| Shared Database | 所有者 + 受邀用户 | 是 | 同 Private + 共享密钥 |
"Apple 静态加密"的意思是：Apple 存储服务器把磁盘上的字节加密。但 Apple 持有加密密钥。Apple 内部经授权的员工能解密。法院命令、NSL 或任何强制 Apple 披露的法律程序也能。
"端到端加密"的意思是：数据用只有用户持有的密钥加密。Apple 存的是密文。Apple 解不了 — 员工解不了，法院也解不了。
这就是 iCloud Private Database 默认与 Advanced Data Protection 之间的真实差别。ADP 在 iOS 16.2 推出，把多数 iCloud 数据类别从"标准保护"（Apple 持密钥）升到"高级"（仅用户持密钥）。但 ADP 是 opt-in，默认关闭，且不是所有 iCloud 数据类别都支持。
ByteGuard 怎么做
ByteGuard 选择最强配置 — 无论用户有没有开 ADP。策略：
- 用 CloudKit Private Database（用户级范围，绝不用 Public）
- 把每个敏感字段在设备上用 AES-256-GCM 加密，再交给 CloudKit
- 用一个 vault 级 Vault DEK（数据加密密钥），由 KEK（从主密码 + Secret Key 派生，永不上传 Apple）封装
- 只把密文上传到 CloudKit。Apple 看到的只是 blob。
这就是应用层加密：我们不依赖 Apple 的传输或静态加密做安全工作，自己在数据离开设备前就加密好。
为什么不直接靠 ADP
三个原因：
- ADP 默认关闭。Apple 自己的数据显示大多数用户没启用。我们不能让安全依赖一个多数人不会改的设置。
- ADP 不覆盖一切。即使开了 ADP，部分元数据仍在标准保护下（Apple 持密钥）：iCloud 邮件、通讯录、日历。Apple 理论上随时可以扩展这个清单。
- 多重防御。如果未来某个 iOS 漏洞临时降级了 ADP，我们的应用层加密不受影响。Vault DEK 从未进入 Apple 的密钥圈。
Apple 具体能看到什么
即使有我们的应用层加密，Apple 仍然能看到：
- 记录元数据：哪个 iCloud 用户拥有该记录、何时创建、何时最后修改、记录类型（"登录" vs "卡片" vs "笔记"）、记录大小
- 同步时间戳：你大致何时新增 / 编辑了条目
- 你使用了该 App 的事实：ByteGuard 是注册的 CloudKit 容器；Apple 知道你用它（通过 Apple ID）
- 密文 blob：没有 Vault DEK，与随机字节无法区分
Apple 看不到：
- 你的主密码或 Secret Key（永不上传）
- Vault DEK（CloudKit 里只有封装形式，解封 KEK 仅本地）
- 任何字段内容：用户名、密码、URL、备注、自定义字段、TOTP 密钥
- 标签名、文件夹名、条目标题（这些也作为字段加密）
所以一份泄露的 Apple iCloud 数据库、一张法院命令、一个内部恶意员工 — 谁都拿不到明文登录信息。他们拿到的只是密文 blob 和时间戳。
"等等 — 你把封装的 DEK 上传到 iCloud？"
是。这是关于信封加密最常被问的问题，所以正面回答。
是，封装的 Vault DEK（KEK 加密的 Vault DEK）确实存在 CloudKit 里。这就是多设备同步的原理 — 你在第二台 iPhone 上装 ByteGuard 时，从 CloudKit 拉封装的 DEK，本地问你主密码 + Secret Key，派生 KEK，解封 DEK。
问题："那 Apple 不就有 Vault DEK 了？"
答案：没有，因为 Apple 没有 KEK。
CloudKit 里的 Vault DEK 用 AES-256-GCM 封装，密钥是 KEK。KEK 派生路径是 HKDF-SHA256(MasterKey, info="vault-kek-v1")，其中 MasterKey = Argon2id(MasterPassword + SecretKey, salt)。MasterPassword / SecretKey / MasterKey / KEK 四个值都不会接触 CloudKit。四个全部在设备上派生，使用，然后清零。
攻击者只偷到封装的 DEK，得暴力破解 KEK。要破 KEK，得破主密码 + Secret Key。仅 Secret Key 单独就是 128-bit 随机 — 那是 2¹²⁸ 个候选 KEK。AES-256-GCM 错密钥会失败 GCM 校验，所以攻击者甚至无法通过尝试就知道是否猜对 — 每次猜都得跑一次完整 Argon2id 派生。
这就是为什么"信封加密 + 独立 KEK"是 1Password、Bitwarden、ProtonMail、Signal 以及所有端到端加密系统都用的同一种架构模式。封装密钥放服务器没问题，前提是封装够强。
用户开了 ADP 之后会怎样
如果用户开了高级数据保护，Apple 自己也解不了封装的 DEK，因为 ADP 下的 CloudKit Private Database 在 Apple 自己的层也是端到端加密的。
所以开 ADP 后，Apple 在两层都读不了：
- 我们的应用层密文（我们从没给过 Apple 密钥）
- CloudKit 存储层（ADP 把它加密了）
这是"双重加密" — Apple 配合我们的模型而非绕过它。推荐启用。
不开 ADP 的话，Apple 的 CloudKit 层 Apple 自己能解，但他们也只看到我们的密文 blob。从用户视角看安全保证一样，只是少了一层纵深防御。
对比：其他密码管理器怎么处理 iCloud 同步
| 产品 | iCloud 同步 | 应用层加密 | Apple 能读？ |
|---|---|---|---|
| Apple Keychain | 原生（自有管线，非 CloudKit） | iCloud Keychain 用 E2E 加密 + 设备信任圈密钥 | 否（按 Apple Platform Security Guide） |
| 1Password | 可选（自有服务器 + 历史上的 iCloud 选项） | 是（Secret Key + 信封） | 否 |
| Bitwarden | 自有服务器（或自托管） | 是（PBKDF2/Argon2id + 信封） | 不适用 — 不用 Apple 服务器 |
| ByteGuard | iCloud Private Database | 是（Argon2id + 信封，应用层 AES-256-GCM） | 否 — Apple 只能看到密文 blob |
关键要点
- "iCloud 同步"不自动等于"Apple 能读"。App 架构比存储后端更重要。
- ByteGuard 在上传前就做应用层 AES-256-GCM，无论用户有没有开 ADP。ADP 是加分项，不是前提。
- CloudKit 里的封装 DEK 是 32 字节密文 blob。Apple 持有它；没有 KEK（Apple 永不接触），它毫无价值。
- Apple 能看到元数据：记录类型、时间戳、同步事件、你用了该 App。Apple 看不到内容。
- 如果你在 Apple ID 上启用 ADP，你会得到第二层独立的 E2E 加密。多重防御 — 推荐高威胁模型用户启用。
具体的密钥派生、IV 处理、每条目密钥隔离在 安全白皮书 里逐步记录。