PCC：重大进步，但并非完美无缺

——Trail of Bits博客

Adelin Travers
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硬件，导致信息泄露的实现缺陷很可能在PCC中出现，而这些缺陷在领先的AI/ML供应商设备中已被修补。

运行评论

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

引言

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

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

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

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

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

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

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

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

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

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

设计私有云计算

从ML perspective，此声明取决于PCC的 intended 用例，因为它不能 generally 成立。如果PCC仅用于模型推理，此声明可能成立。PCC帖子的其余部分仅提到推理，这表明PCC目前未用于训练。

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

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

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

引入私有云计算节点

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

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

尽管如此，PCC设计的非目标性属性可能有助于缓解PCC的LeftoverLocals，因为它防止攻击者识别并实现与受害者设备的共置。

这很重要，因为Swift是一种编译语言。因此，Swift不易受动态运行时攻击的影响，这些攻击影响在ML中更普遍的语言（如Python）。注意，Swift likely 仅用于CPU代码。GPU代码 likely 用苹果的Metal GPU编程框架编写。更多关于动态运行时攻击和Metal的内容在下一节。

无状态计算和可执行保证

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

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

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

如我们所说，GPU代码 likely 用Metal编写。Metal不强制执行内存安全。没有内存安全，像LeftoverLocals这样的攻击是可能的（对攻击者有限制，如机器共置）。

无特权运行时访问

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

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

非目标性

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

术语“元数据”在这里重要。只有元数据可以以苹果描述的方式被过滤掉。然而，实际上没有方法过滤出发送到LLM的正文内容中的所有PII。正文内容中的任何PII将被LLM未加密处理。如果PCC仅用于推理，此风险通过结构化日志记录缓解。如果PCC also 用于训练（苹果尚未澄清），我们建议在可避免时不要与此类系统共享PII。

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

具有此级别控制的对手应能欺骗节点的统计分布，除非审计和统计分析在网络级别进行。

可验证透明度

这 nice to see！当然，我们不知道这些是否需要通过广泛的反向工程分析，这对苹果的自定义ML硬件将困难，如果不是不可能。对于此规模的项目，这仍然是 commendable rare occurrence。

PCC：安全胜利，ML问题

从安全 standpoint，苹果的设计 excellent。ML方面的改进 always possible。然而，重要的是记住这些改进与一些开放研究问题相关，如同态加密的可扩展性。只有未来的漏洞研究将揭示硬件和软件中的实现缺陷是否会影响苹果。最后，只有时间能告诉苹果是否通过仅将PCC用于推理而非训练并在同态加密足够可扩展时实施它来持续承诺安全和隐私。

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

页面内容
近期帖子
用Deptective调查你的依赖项
系好安全带，Buttercup，AIxCC的评分回合正在进行中！
使你的智能合约超越私钥风险成熟
Go解析器中意外的安全隐患
我们从审查Silence Laboratories的首批DKLs23库中学到了什么
© 2025 Trail of Bits。
使用Hugo和Mainroad主题生成。