苹果私有云计算PCC：AI安全设计的突破与隐患

PCC：重大进步，但仍存缺陷

——Trail of Bits博客

2024年6月14日 | 机器学习

本周，苹果宣布了私有云计算（简称PCC）。若缺乏对人工智能（AI）和机器学习（ML）安全最新进展的深入背景，一些明智的设计选择可能令人惊讶。相反，与此设计相关的某些风险隐藏在细则中。在本博客文章中，我们将回顾苹果的公告，包括其优点和缺点，重点关注AI/ML安全的背景。我们推荐Matthew Green在X上的优秀线程，以获取此公告的更一般安全背景：https://x.com/matthew_d_green/status/1800291897245835616

免责声明： 此分析仅基于苹果的博客文章，因此可能存在对措辞的潜在误解。我们尚未获得代码访问权限，但期待苹果公开PCC虚拟环境版本以进一步检查！

回顾总结

此设计在传统非ML安全方面非常出色。苹果似乎正在尽一切可能使PCC成为一个安全、以隐私为导向的解决方案。然而，安全研究人员能够进行的审查量将取决于发布的代码内容，而苹果以保密著称。

在AI/ML方面，识别的关键挑战切中要害。这些挑战源于苹果希望为当前计算密集的ML工作负载提供额外处理能力，这 incidentally 需要从设备端数据处理转向云端。同态加密（HE）是机密ML领域的一大希望，但目前无法扩展。因此，苹果选择在其云端大规模处理数据需要解密。此外，PCC的保证 vary 取决于苹果是否将PCC环境用于模型训练或推理。最后，由于苹果正在引入其自定义AI/ML硬件，导致信息泄漏的实现缺陷 likely 在PCC中出现，当这些缺陷在领先的AI/ML供应商设备中已被修补时。

运行评论

我们将按发布帖子的文本顺序，逐节进行，仿佛在阅读和评论，暂停在特定段落。

引言

当我第一次阅读此帖子时，我承认我误解了此段落，以为苹果开始宣布他们已在机器学习中实现了端到端加密。这将比实际公告更大的新闻。

那是因为苹果需要使用同态加密在ML上下文中实现完整的端到端加密。HE允许计算一个函数，通常是ML模型，而无需解密底层数据。HE一直在稳步进展，是机密ML的未来候选（例如参见这篇2018年论文）。然而，这将是一个重大公告和ML安全格局的转变，因为HE仍被认为太慢，无法在云规模和复杂函数如ML中部署。更多关于此 later on。

注意，多方计算（MPC）——允许多个代理，例如服务器和边缘设备，计算函数如ML模型的不同部分并 privately 聚合结果——将是一个在服务器和边缘设备上的分布式方案，与此处 presented 的不同。

术语“requires unencrypted access”是PCC设计挑战的关键。苹果可以继续在设备上处理数据，但这意味着遵守移动硬件限制。苹果希望卸载的复杂ML工作负载，如使用大型语言模型（LLM），超出了电池供电移动设备的 practical 范围。苹果希望将计算移至云端以提供这些扩展能力，但HE目前无法扩展到该水平。因此，为了目前提供这些新服务能力，苹果需要访问未加密数据。

尽管如此，苹果的PCC设计 exceptional，开发此解决方案所需的 effort 极高，超越了迄今为止大多数其他云AI应用。

因此，当审计员 only 访问模型时，云端ML模型的安全和隐私是一个未解决且活跃的研究领域。

这些困难的一个好例子可以在机器遗忘中找到——一种允许从模型中移除数据的隐私方案——被证明仅通过查询模型无法 formally 证明。因此，遗忘必须在算法实现级别证明。

当苹果PCC的底层完全自定义和专有技术栈被考虑在内时，外部审计变得 significantly 更复杂。Matthew Green指出，不清楚苹果将发布堆栈和ML代码和二进制文件的哪部分以审计ML算法实现。

这也 definitely true。Trail of Bits的ML保证团队成员自2021年以来一直在发布攻击，这些攻击在运行时修改ML软件堆栈。我们的攻击利用了广泛使用的pickle VM用于传统RCE后门和Microsoft的ONNXRuntime上的恶意自定义ML图运算符。我们最近的攻击Sleepy Pickles使用运行时攻击在模型加载时动态交换ML模型的权重。

这也 true；苹果 later 引入的设计 far better 比许多其他现有设计。

设计私有云计算

从ML perspective，此 claim 取决于PCC的 intended 用例，因为它不能 generally hold true。如果PCC仅用于模型推理，此 claim 可能 true。PCC帖子的其余部分 only 提到推理，这表明PCC目前 not used for training。

然而，如果PCC用于训练，那么数据将被保留，无状态计算不留痕迹 likely impossible。这是因为ML模型在训练中保留编码在权重中的数据。这就是为什么上述机器遗忘研究领域存在。

苹果需要回答的大问题是，是否将在未来使用PCC训练模型。正如 others noted，这是一个容易滑入的斜坡。

非目标性是一个 really interesting 设计想法，以前未应用于ML。它 also 缓解硬件泄漏漏洞，我们将在 next 看到。

引入私有云计算节点

正如 others noted，使用安全飞地和安全启动 excellent，因为它确保 only legitimate 代码运行。GPU likely 继续在AI加速中扮演重要角色。苹果一段时间以来一直在构建自己的GPU，其M系列现已第三代，而不是使用在ML中更普遍的Nvidia。

然而，飞地和证明将 only 提供有限保证给最终用户，因为苹果 effectively 拥有证明密钥。 Moreover，飞地和GPU曾有漏洞和侧信道，导致在ML中可 exploitable 泄漏。苹果GPU在AI领域尚未像Nvidia那样经过 battle-tested；因此，这些加速器可能有其Nvidia对应物没有的安全问题。例如，苹果的自定义硬件曾经并且仍然受到LeftoverLocals漏洞的影响，当Nvidia的硬件没有时。LeftoverLocals是Trail of Bits今年早些时候发布的GPU硬件漏洞。它允许攻击者在 vulnerable 设备上与受害者 collocated 监听受害者的LLM输出。苹果的M2处理器在撰写本文时仍然 currently impacted。

尽管如此，PCC设计的非目标性属性 may help 缓解PCC的LeftoverLocals，因为它防止攻击者识别和实现与受害者设备的 collocation。

这 important，因为Swift是一种编译语言。Swift thus not prone 影响如Python等更普遍在ML中的语言的动态运行时攻击。注意Swift likely only 用于CPU代码。GPU代码 likely 用苹果的Metal GPU编程框架编写。更多关于动态运行时攻击和Metal在下一节。

无状态计算和可执行保证

苹果的解决方案不是端到端加密，而是基于飞地的解决方案。Thus，它不代表HE for ML的进步，而是 established 技术的 well-thought-out 组合。这，再次，impressive，但数据在苹果服务器上解密。

如引言 presented，使用编译Swift和签名代码 throughout 堆栈 should prevent 对ML软件堆栈的运行时攻击。Indeed，ONNXRuntime攻击通过加载 adversary-built 共享库对象定义了一个后门自定义ML原始运算符，而Sleepy Pickle攻击依赖于Python的动态特性。

即时（JIT）编译代码 historically 是远程代码执行漏洞的稳定来源。JIT编译器 notoriously 难以实现，并通过设计创建新的可执行代码，使它们成为 highly desirable 攻击向量。这可能 surprise 大多数读者，但JIT广泛用于ML堆栈以加速 otherwise 慢的Python代码。JAX，一个ML框架，是苹果自己的AXLearn ML框架的基础，是一个 particularly prolific JIT用户。苹果通过不使用它避免JIT的安全问题。苹果的ML堆栈 instead 用Swift构建，一种内存安全的提前编译语言，不需要JIT以获得运行时性能。

如我们 said，GPU代码 likely 用Metal编写。Metal不强制执行内存安全。没有内存安全，像LeftoverLocals的攻击 possible（对攻击者有限制，如机器 collocation）。

无特权运行时访问

这是一个 interesting 方法，因为它显示苹果愿意 trade off 基础设施监控能力（并 thus potentially 减少PCC的可靠性）以获取额外安全和隐私保证。为了 fully 理解此解决方案的好处和限制，ML安全研究人员需要知道在结构化日志中捕获了哪些 exact 信息。因此，完整分析 depends on 苹果愿意或不愿意发布这些日志的模式和预定义字段。

Interestingly，限制日志类型可能通过防止ML团队收集足够信息来管理这些风险而增加ML模型风险。例如，收集的日志和指标选择可能 insufficient 让ML团队检测分布漂移——当输入数据不再匹配训练数据且模型性能下降时。如果我们的理解 correct，大多数收集的指标将是用于SRE目的的指标，意味着数据漂移检测将 not possible。如果收集的日志包括ML信息，意外数据泄漏 possible but unlikely。

非目标性

这 excellent，因为ML堆栈的较低级别，包括物理层，有时在ML威胁模型中被 overlooked。

术语“metadata”在这里 important。Only 元数据可以以苹果描述的方式被过滤掉。然而， virtually no ways 过滤出所有发送到LLM的主体内容中的PII。任何在主体内容中的PII将被LLM未加密处理。如果PCC仅用于推理，此风险通过结构化日志记录 mitigated。如果PCC also 用于训练，苹果尚未澄清，我们建议当可以避免时，不要与像这样的系统共享PII。

攻击者可能 obtain 识别信息在存在侧信道漏洞时，例如， linked to 实现缺陷，泄漏一些信息。然而，这 unlikely 在实践中发生：对手同时利用负载均衡器和侧信道的成本将对非国家威胁行为者 prohibitive。

具有此级别控制的对手应该能够 spoof 节点的统计分布，除非审计和统计分析在网络级别完成。

可验证透明度

这 nice to see！当然，我们不知道这些是否需要通过广泛逆向工程分析，这对苹果的自定义ML硬件将 difficult， if not impossible。对于此规模的项目，这仍然是一个 commendable rare occurrence。

PCC：安全胜利，ML问题

苹果的设计从安全 standpoint excellent。ML方面的改进 always possible。然而，重要的是记住这些改进 tied to 一些开放研究问题，如同态加密的可扩展性。Only 未来漏洞研究将 shed light on 硬件和软件中的实现缺陷是否将影响苹果。最后，Only 时间将告诉苹果是否 continuously 承诺安全和隐私，通过仅使用PCC进行推理而不是训练，并在同态加密足够可扩展时尽快实施。

如果您喜欢此帖子，分享它： Twitter LinkedIn GitHub Mastodon Hacker News