审查摘要

该设计在传统非机器学习安全方面表现卓越。苹果似乎正在尽一切努力使PCC成为安全、以隐私为导向的解决方案。然而，安全研究人员能够进行的审查量将取决于发布的代码内容，而苹果向来以保密著称。

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

实时评论

我们将按顺序逐节跟踪发布帖文的文本，就像我们在阅读和评论时暂停在特定段落一样。

引言

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

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

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

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

话虽如此，苹果的PCC设计非常出色，开发此解决方案所需的努力极高，超越了迄今为止大多数其他云AI应用。

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

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

当考虑到苹果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训练模型。正如其他人所指出的，这是一个容易滑入的斜坡。

非目标性是一个真正有趣的设计理念，以前从未应用于ML。它还可以缓解硬件泄漏漏洞，我们接下来会看到。

引入私有云计算节点

正如其他人所指出的，使用安全飞地和安全启动是极好的，因为它确保只运行合法代码。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。

无状态计算和可执行保证

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

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

即时（JIT）编译代码历来是远程代码执行漏洞的稳定来源。JIT编译器 notoriously 难以实现，并且设计上会创建新的可执行代码，使其成为高度理想的攻击向量。这可能让大多数读者感到惊讶，但JIT在ML栈中被广泛用于加速原本缓慢的Python代码。JAX（一个ML框架，是苹果自家AXLearn ML框架的基础）是JIT的特别多产用户。苹果通过不使用JIT来避免其安全问题。苹果的ML栈改用Swift构建，Swift是一种内存安全的提前编译语言，不需要JIT来实现运行时性能。

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

无特权运行时访问

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

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

非目标性

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

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

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

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

可验证透明度

很高兴看到这一点！当然，我们不知道这些是否需要通过广泛的反向工程来分析，这对于苹果的定制ML硬件来说将是困难的（如果不是不可能的话）。对于这种规模的项目来说，这仍然是一个值得称赞的罕见情况。

PCC：安全胜利，ML问题

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