最近 Apple 的一系列更新中的一项新的安全特性是 iCloud 的 Advanced Data Protection， 大概看了一下还是挺有意思的。

概念上，该特性的做法是把受密码保护、保存在 Apple 数据中心的 available-after-authentication 密钥（该访问控制是在服务器端进行的， 换言之如果服务器被攻陷，或是 Apple 愿意配合的话，可以获得这些密钥）删除，这样一来，理论上后者就无法再访问这些加密的用户数据了。

现有文档我的理解和一些观察如下：

1. 采用 Recovery Key 时，系统会反复确认用户确实拥有该 key。

这个设计是很合理的（想象通常水准的用户在丢掉 key 时绝望地狂 cue 客服的场景），不过有些方面做的有些过火。 举例来说，呈现该key时不能复制该字符串，我猜测该决策的考虑是用户会把这些敏感数据粘贴到不该粘贴的地方（比如， 这些用户可能在干这事之前忘记了关闭 universal clipboard）， 不过一个知道自己错了的正常思考的人类难道会不知道重新生成一个新的吗？

出于显而易见的原因，不应选择任何 recovery contact，尽管这个 设计 的考虑还是很周到的：解密用的密钥（随机生成）以秘密分享协议由恢复联系人和 Apple 分别掌握一半 （这一设计防止了 recovery contact 或 Apple 独自恢复数据）。创建 recovery contact 的过程中， 用户设备生成解密所需的秘密之后，把Apple持有的那一半上传到Apple，recovery contact 的那一半则加密并保存到其 iCloud Chain 中。 此过程中 Apple 声称并不知道 recovery contact 是谁。同时，Apple 和 recovery contact 还会收到内容相同的、 用于验证事主身份的验证信息并保存以备后续使用。

恢复过程中，事主需要寻求 recovery contact 的帮助，后者的设备会生成一个code， 该code用于在 SPAKE2+ 协议中建立两台设备之间的安全连接，之后 recovery contact 的设备将之前保存的那部分恢复密钥， 以及身份验证信息发给事主，后者用身份验证信息说服 Apple 完成账户恢复流程，这包括将 Apple 保存的那一半密钥发给事主，并且在其设备上和由 recovery contact 提供的那一半密钥合并用来解密数据。

2. 启用此功能要求用户名下的所有设备均在运行最新版本的操作系统

由于这基本上意味着我必须得和 2012 年的 MacBook Pro （之前已经在 macOS Monterey 时被 Apple 宣布了定期报废）说再见了。

3. 加密的范围

根据 HT202303，绝大多数，即除了 iCloud Mail、通讯录和日历之外的其他数据， 均只能被受信设备访问。这和之前的 iCloud 状态相比是一项显著的改善。

比较值得注意的是 Apple 提供了一个允许通过 Web 访问 iCloud 数据的选项（该选项在启用 Advanced Data Protection 时会自动关闭）。 根据文档的说法，启用该选项时，用户需要在受信设备上确认一次授权，该授权会在一个小时的时间内允许设备向 Apple 提供 service key； 并非所有的服务都可以通过 icloud.com 访问。

从文档的描述来看，这个过程中 Apple 的服务器是可以直接访问数据的；在此设计中采取了一些补救措施（例如使用了一个专用于此次会话的临时key去加密）， 但这些措施看起来并不解决根本问题。

总体上，这次发布的 Advanced Data Protection 比之前的 iCloud 为用户数据提供了更多的保护。 不过，这些设计在安全性和易用性之间做出了不少妥协（大部分情况下用户可以选择前者），并且和其他产品类似，一个形状上大致上没什么问题的设计依然依赖于实现的正确性。

最后的题外话：根据 这篇， 比较新（采用了 T2 SoC 的 Intel Mac 和 M 系列处理器的 Apple Silicon Mac）的 Mac 上的本地存储是用硬件 UUID + Secure Enclave 加密的了。这样做的优点是内部存储从一开始就是全盘加密的，但缺点是我们无法容易地确认其初始主密钥的生成是不是没问题了（启用 File Vault 时， 系统会丢掉之前的旧 key，但这是用于解密主密钥的 key，由于 M 系列的 Mac 在完全复位之后需要在线激活。当然，安全是一个关于信任的话题， 人们最终总归还是需要相信硬件制造商在一定程度上是可信的，大部分人最终总归也得相信自己使用的操作系统制造商做的事情是对的， 但我认为这个设计没有让我打消一些疑虑）。