PCC：重大进步，但仍存缺陷 - Trail of Bits博客

引言

本周苹果宣布推出私有云计算（Private Cloud Compute，简称PCC）。若缺乏对人工智能（AI）和机器学习（ML）安全最新进展的深度背景了解，某些合理的设计选择可能令人惊讶。相反，该设计相关的部分风险隐藏在细则中。本文将从AI/ML安全背景出发，全面评析苹果公告的优缺点。推荐阅读Matthew Green在X平台的精彩讨论获取更广泛的安全背景：链接

免责声明： 本文分析仅基于苹果博客文章，可能存在措辞误解。我们尚未获得代码访问权限，期待苹果公开PCC虚拟环境后进行深入验证！

综述摘要

该设计在传统非ML安全方面表现卓越。苹果似乎竭尽全力使PCC成为安全、隐私导向的解决方案。但安全研究人员能进行的审查程度取决于发布的代码范围，而苹果以保密著称。

在AI/ML方面，识别的关键挑战切中要害。这些挑战源于苹果希望为计算密集型ML工作负载提供额外处理能力，这 incidentally 需要从设备端数据处理转向云端。同态加密（HE）是机密ML领域的重要希望，但目前尚未实现规模化。因此，苹果选择在云端大规模处理数据需要解密操作。此外，PCC的保证效力取决于苹果将PCC环境用于模型训练还是推理。最后，由于苹果采用自定义AI/ML硬件，当主流AI/ML供应商设备已修复漏洞时，PCC仍可能出现导致信息泄露的实现缺陷。

逐段评析

我们将按发布文章顺序进行分段评注，如同实时阅读并评论，重点关注特定段落。

引言

初读此文时，我曾误认为苹果宣布实现了机器学习中的端到端加密——这将是比实际公告更重大的新闻。

因为苹果需要采用同态加密（HE）才能在ML场景实现完全端到端加密。HE允许在不解密底层数据的情况下计算函数（通常是ML模型）。HE持续取得进展，是机密ML的未来候选方案（例如参见这篇2018年论文）。但这本应成为ML安全领域的重大公告和转变，因为HE仍被认为速度过慢，无法在云规模和复杂函数（如ML）中部署。后续将详述。

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

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

尽管如此，苹果的PCC设计卓越非凡，开发该解决方案所需投入极高，超越了迄今大多数其他云AI应用。

因此，当审计员仅能访问模型时，云端ML模型的安全和隐私仍是未解决且活跃的研究领域。机器学习遗忘（Machine Unlearning）——允许从模型中移除数据的隐私方案——被证明无法仅通过查询模型进行形式化验证，就是这些困难的好例子。因此必须在算法实现层面证明遗忘能力。

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

这也完全正确。Trail of Bits的ML保障团队成员自2021年以来持续发布在运行时修改ML软件栈的攻击。我们的攻击利用了广泛使用的pickle VM实现传统RCE后门，以及在微软ONNXRuntime上的恶意自定义ML图运算符。我们最近的攻击Sleepy Pickles使用运行时攻击在模型加载时动态交换ML模型权重。

这也正确；苹果后续引入的设计远优于许多现有设计。

设计私有云计算

从ML视角看，此声明取决于PCC的预期用例，因为它不能普遍成立。如果PCC仅用于模型推理，该声明可能成立。PCC文章其余部分仅提及推理，表明PCC当前未用于训练。

但如果PCC用于训练，数据将被保留，无状态计算（不留痕迹）很可能无法实现。这是因为ML模型在训练过程中会将数据编码保留在权重中。这就是前述机器学习遗忘研究领域存在的原因。

因此苹果需要回答的重大问题是未来是否会使用PCC训练模型。正如他人指出，这很容易滑向该方向。

不可针对性（Non-targetability）是非常有趣的设计理念，此前未应用于ML。它还能缓解硬件泄漏漏洞，接下来我们将看到。

引入私有云计算节点

正如他人指出，使用安全飞地（Secure Enclaves）和安全启动（Secure Boot）非常优秀，因为它确保仅运行合法代码。GPU可能继续在AI加速中扮演重要角色。苹果自研GPU已有一段时间，其M系列现已发展到第三代，而非使用在ML中更普遍的Nvidia GPU。

然而，飞地和认证只能为终端用户提供有限保证，因为苹果实际拥有认证密钥。此外，飞地和GPU存在漏洞和侧信道，导致ML中可利用的泄漏。苹果GPU在AI领域的实战检验尚不及Nvidia，因此这些加速器可能存在Nvidia对应产品没有的安全问题。例如，苹果自定义硬件曾经且仍然受LeftoverLocals漏洞影响，而Nvidia硬件未受影响。LeftoverLocals是Trail of Bits今年早先发布的GPU硬件漏洞，允许与受害者共置在易受攻击设备上的攻击者窃听受害者的LLM输出。截至本文写作时，苹果M2处理器仍受影响。

尽管如此，PCC设计的不可针对性特性可能有助于缓解PCC的LeftoverLocals漏洞，因为它阻止攻击者识别并实现与受害者设备的共置。

这很重要，因为Swift是编译型语言。因此Swift不易受动态运行时攻击影响，而这些攻击在ML中更普遍的影响Python等语言。注意Swift可能仅用于CPU代码。GPU代码可能用苹果的Metal GPU编程框架编写。下一节将详细讨论动态运行时攻击和Metal。

无状态计算和可执行保证

苹果的解决方案不是端到端加密，而是基于飞地的解决方案。因此它不代表HE在ML中的进步，而是成熟技术的精心组合。这再次令人印象深刻，但数据在苹果服务器上解密。

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

即时编译（JIT）代码历来是远程代码执行漏洞的稳定来源。JIT编译器以难以实现和按设计创建新可执行代码而闻名，使其成为极受欢迎的攻击向量。可能让大多数读者惊讶的是，JIT广泛用于ML栈以加速原本缓慢的Python代码。JAX（作为苹果自家AXLearn ML框架基础的ML框架）是JIT的特别多产用户。苹果通过不使用JIT避免其安全问题。苹果的ML栈改用Swift构建，这是一种内存安全的预编译语言，不需要JIT来实现运行时性能。

如前所述，GPU代码可能用Metal编写。Metal不强制执行内存安全。没有内存安全，LeftoverLocals等攻击是可能的（对攻击者有限制，如机器共置）。

无特权运行时访问

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

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

不可针对性

这非常优秀，因为ML堆栈的较低层级（包括物理层）有时在ML威胁模型中被忽视。

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

在存在侧信道漏洞（例如与导致某些信息泄漏的实现缺陷相关）的情况下，攻击者可能获取识别信息。但这在实践中不太可能发生：对手同时利用负载均衡器和侧信道的成本对非国家级威胁行为者而言将令人望而却步。

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

可验证透明度

这很好！当然，我们不知道是否需要通过广泛逆向工程分析这些，这对苹果自定义ML硬件将很困难（若非不可能）。对于这种规模的项目，这仍是值得称赞的罕见做法。

PCC：安全胜利，ML问题

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

如果您喜欢本文，请分享： Twitter LinkedIn GitHub Mastodon Hacker News