C2PA相机经不起现实的考验：Android端可被root攻击伪造签名

C2PA 相机经不起现实的考验

你可能听说过，C2PA 是一项能奇迹般地让我们免遭 AI 伪造泛滥之害的技术，它让相机对拍摄的图像进行密码学签名。密码学万岁！

抱歉，这行不通。这里涉及的问题很多，所以我尽量直奔主题：

• Android 平台上的 C2PA 相机应用依赖 密钥认证（Key Attestation）和/或 Google Play Integrity，以防止用户篡改应用来对任意文件进行签名（而非来自设备图像传感器的数据）。

• 能够对任意文件进行签名会破坏 C2PA 的信任模型。

• Root 权限提升漏洞会破坏 Android 的密钥认证安全模型，Play Integrity 同样如此。

• Android 设备可以通过低成本硬件故障注入攻击被 root。

• 现有设备中的硬件漏洞无法被修补（这里有细微之处，稍后讨论）。

• 因此，Android 平台上的 C2PA 已被攻破，且无法以现实可行的方式修补。

• 以上没有一个是“0day”，并且至少在 90 天前就已报告给相关方（但任何头脑清醒的人本应早就预见到，正如许多人已经预见的那样）。

但等等，还有更多！部分拜 LLM 所赐，root LPE 的产出速度已经超过了 Google 发布补丁的速度。在撰写本文时，一键 root 漏洞利用已在完全打过补丁的 Google Pixel 设备上于真实环境中存在（经由 CVE-2026-43499）。有了这些，任何人都能在无需硬件攻击的情况下伪造 C2PA。在本文后面，我会提供这样做的操作说明。

如你所见，我这里聚焦于 Android。我会让 Google 来解释原因：

Pixel Camera 应用达到了保证等级 2，这是 C2PA 合规计划目前所定义的最高安全评级。对于移动应用而言，保证等级 2 目前仅在 Android 平台上才可能实现。

也就是说，我攻击的是“最强”的实现，只是为了说明一个观点。下面是一张 AI 生成的垃圾图像，而 C2PA 却称它是直接出自 Pixel Camera 应用的真实未编辑照片：（悬停可取消模糊，点击可“验证”它）

而且，这里有一个 Youtube 视频，其信息框称它是“用相机拍摄的”（剧透警告：并不是）。

编辑，2026-08-25T19:12:16Z：Google 似乎已从视频描述中移除了“使用相机拍摄”部分，大概是手动操作的。这没什么用——继续往下读，了解如何为你自己的媒体签名。另外我还把 URL 换成了另一个。伪造会一直持续，直到士气好转为止。

顺便一提，Apple 据传闻正在开发他们自己的媒体来源溯源方案，但目前还不存在。等它问世后，我会告诉你我对它的看法。我怀疑他们的垂直整合会给他们带来显著优势，这可能会把最容易得手的攻击转移到光学领域（比如拍摄屏幕等）。

总之，让我们进入细节。

root LPE 是如何破解“硬件支持”的密钥认证的？

认证只能证明某些事项，包括：

• 引导加载程序是否已锁定。
• AVB 密钥是否为厂商自己的。
• 设备是否运行最新的安全更新。

给 Android 设备 root 的“常规”做法是解锁 bootloader 并刷入修改过的固件镜像，而这一过程会强制设备恢复出厂设置。认证机制会标记出 bootloader 已解锁，Google 将拒绝为你的设备配置 C2PA 密钥（而且 Netflix 不会向你提供高清内容，你的银行应用也无法使用，等等等等。）

到目前为止一切顺利（如果你好这一口的话。）

然而，如果你通过漏洞利用来 root 设备，认证机制就没有可靠的办法“察觉”到。bootloader 仍处于锁定状态，AVB 密钥未被修改，设备仍运行着它最初启动时的那个安全更新。这样一来，Google 的服务器就会欣然为这台已被攻陷的设备配置密钥。

C2PA 密钥仍受硬件安全保护，存放在 StrongBox 内（在较新的 Pixel 设备上是 Titan M2 中）。这确实能阻止攻击者提取出密钥，即便拥有 root 权限也不行。然而，攻击者并不需要原始密钥材料！ 凭借 root 权限，他们可以让 StrongBox 使用这些密钥来签署任意数据，从而伪造出 C2PA（或者解密你的 Signal 收件箱，以及其他种种坏事）。

认证机制设计背后的理论是：已知的软件 LPE 应当被修补，然后依赖方（即验证认证报告的主体）可以要求用户安装更新，此后更新过的设备就无法再被 LPE 利用了。

CVE-2026-43499证明了及时补丁并非总是可用，但我们不妨给所有人一个善意的假设，假装针对未修补漏洞的公开利用程序从不存在。还剩两个问题：

1. 任何资金尚可的实体，从政府到移动取证公司，都能囤积一批私有漏洞利用程序（他们也确实这么做了）。而这些恰恰是你最不希望去伪造 C2PA 签名的那些群体。

2. 低成本硬件漏洞利用是存在的，无论补丁级别如何。

我是如何给演示图片和视频签名的？

最初，我使用了一种硬件攻击手段。这是我在早前研究基础上的延续：只用一个打火机就能获取 root 权限吗？

我原本打算在这里深入写一写这件事，但坦率地说，纯软件的漏洞利用路径抢了我的风头。软件漏洞利用只要存在，就方便得多，所以我会把完整的硬件细节留到以后再说。不用着急，因为硬件漏洞利用在大多数情况下是无法修补的。

如果你想复现我今天的发现，我推荐使用 Root My Pixel 工具。（注意：虽然它目前支持大多数 Pixel 设备最新的 8 月安全更新，但你需要从 main 构建才能启用该支持。我个人已在 Pixel 8a 和 9a 上测试过。）

获取 root 之后，攻击的其余部分就只是管道工程了。我做了一个工具来简化这一过程：keystork。Keystork 采用客户端/服务器架构，允许客户端代码冒充任意已安装应用，对 KeyStore API 执行任意操作。“服务器”（keystorkd）运行在已 root 的设备上，客户端则是任何能说我自创的线路协议的东西（默认通过 ADB 转发的 unix domain socket 传输）。参考客户端是一个带有对应 CLI 接口的 python 库，但理论上 Android 应用也可以与它通信，Shizuku 风格（不过你需要先构建一个认证/权限层）。

这是一个针对 Pixel Camera 应用的“签名任意图像”PoC 脚本：https://gist.github.com/DavidBuchanan314/fa0ffdaaaa31594e6a511118c1cea1e0

软件漏洞可以并且终将被修补，但硬件漏洞是永恒的。真的是这样吗？

硬件攻击能被缓解吗？

理论上可以，实践中并不尽然。

我最初的策略（翻转 PTE 中的位）至今在 Pixel 设备上仍然有效。然而，它在三星设备上不起作用！

我最初的一些测试是在一台三星 A07 设备上进行的（因为它们便宜）。该漏洞利用在当时是有效的，但在一次安全更新之后就失效了（我认为时间上只是巧合）。那次更新启用了三星的“RKP”缓解机制（Real-time Kernel Protection，不要与 Remote Key Provisioning 混淆……）

除其他措施外，三星的缓解机制使用 EL2 hypervisor 对某些内存区域施加额外保护（有点类似微软的 HVCI）。我仍然可以利用硬件漏洞来翻转 PTE 中的位，但即使我通过 glitching 将一个 PTE 映射到用户空间，EL2 也不会让我覆写它（而这正是我最初设计的漏洞利用的一个关键部分）。

我有几套替代策略来绕过三星的缓解机制，但还没来得及实现它们。我的其中一个替代策略即使在存在硬件内存加密的情况下也应该有效。一旦我把它做出来，我想把这个策略打包成一个“通用 Android 硬件 root”工具——敬请期待？（我还想攻破 HVCI 来干扰反作弊，也敬请期待。）

在硬件层面，已有若干解决方案将外部 DRAM 视为完全不可信，从而在理论上至少能够缓解任何类型的总线故障攻击。例子包括 Intel MEE 以及 Apple 的 SEP Memory Protection Engine。然而，这些方案的性能不足以在实际中支撑整个 Android Linux 内核在其中运行（这也是为什么 Apple 只用它来保护 SEP 而非主 AP，而 Intel 在较新的 SGX 修订版中彻底放弃了该功能，从而导致了像 Battering RAM 这样的攻击）。

即便有最好的硬件级缓解措施，在 Android 上修复 C2PA 也需要对整个软件栈进行彻底重构。整个图像处理流水线，包括所有花哨的 AI 部分，都需要运行在一个具备强硬件内存保护的安全飞地内。

我认为 Google 不会做这一切，这很可能就是他们以“不予修复（不可行）”的状态关闭我的报告的原因。当你仍然无法阻止“对着屏幕拍照”这类攻击时，进行所有这些重构根本说不通。

顺便说一句，尽管结论是 WONTFIX，Google 还是因为这次提交给了我 7500 美元的赏金：

感谢您提交报告。虽然硬件故障注入和侧信道攻击不在我们漏洞赏金计划的范围之内，但我们的安全团队认为您的发现很有价值，您提供的数据将帮助我们改进该产品未来的迭代版本。

我原本没指望拿到赏金（我知道这在形式上属于范围之外），所以这是个不错的惊喜。它能覆盖我在研究过程中变砖的所有设备。但值得注意的是：

（在我看来）最明显的 C2PA 攻击向量不在 Google 的 VRP 范围内。因此，VRP 并未对 Android 的 C2PA 实现提供有意义的保护。

影响范围有多大？

我在这里一直聚焦于 Pixel Camera 应用，但 Android 上还有其他几款“C2PA Camera”应用。我调查过的所有这些应用，其安全性都依赖于 Key Attestation 或 Play Integrity。它们都以同样的方式被攻破，只不过它们并不局限于 Google Pixel 设备。这意味着你不需要 root 一台 Pixel 设备，你可以挑选整个 Android 生态中最便宜、最易受攻击的设备来运行你的漏洞利用程序。

它们都是 Google 就其平台安全有效性所做出的误导性营销宣传的受害者。你可以找到一份完整的“符合规范”的 C2PA 实现清单这里（所有包含Android_KeyAttestation或Google_PlayIntegrity在其attestationMethods列表中的实现都可能存在漏洞）

除了 C2PA 之外，我一直在用我的硬件故障注入策略来 root 各种 Android 设备，玩得挺开心，包括一台 Amazon Fire TV 电视棒和一台 Meta Quest 3s VR 头显（同样，我之后可能会写更多相关内容！）

题外话：Meta 已经在本月初为 Quest 头显修补了 CVE-2026-43499 LPE，以防止人们在 VR 视频游戏中作弊。让我觉得完全不可思议的是，Google 至今连他们的旗舰 Pixel 设备都还没有发布补丁。

谢谢

虽然我最近才涉足 C2PA 生态系统，但 Hacker Factor 的 Neal Krawetz 博士多年来一直在就此发出警告。他的文章是我接触这个主题的入门读物，他在与我讨论方面非常乐于助人，还帮助协调了漏洞披露事宜。

你可以在这里阅读他对这些漏洞的看法。

同样感谢来源与真实性标准评估工作组（PASAWG），他们也在研究 C2PA 的有效性。

哦，还有一件事……

在准备发布我的 PoC 时，我冒出了一个有趣的"但如果……会怎样？"的念头。顺着这条线索追下去，我发现了一个私钥泄露漏洞。我两天前向 Google 报告了它，他们似乎昨天已经修补了（这就是为什么我更喜欢硬件攻击，补丁毁了乐趣）。我以后可能会就此写更多内容。

如果我不是个胆小鬼，这里就是我粘贴 Pixel Camera C2PA 私钥及对应证书链的地方。但我决定不这么做。如果你是记者，想看一眼，告诉我。

我猜 Google 现在已经吊销了这个特定的密钥（我把它包含在了给他们的报告里）。然而大多数 C2PA 验证工具并不检查吊销状态。我相信他们很快也会修复这一点。