拆解 AI 图片凭证：签名有效为何仍报错
作者检查一张 OpenAI 生成的 PNG，在 caBX 数据块中找到 C2PA 凭证，并用 Python 读取生成来源字段。验证结果显示签名、内容哈希及时间戳通过，但签名凭证不受信任，说明整体 Invalid 不能直接等同于文件被篡改。
AI 深度解读
一张 AI 生成的 PNG，可能自带可验证的来源凭证；把它转成 JPEG，或者截个图，这份凭证就可能消失。作者拆解了一张 OpenAI 生成的图片，发现判断图片来源时，最先该读的是文件里的证据。
对做图片上传、内容审核或 AI 检测工具的程序员，更有用的是两条边界：凭证缺失不能证明图片由真人创作，验证结果为 Invalid 也不能直接等同于图片遭到篡改。
文件里哪一项真的说明了 AI 来源
作者生成的 PNG 尺寸为 1536×1024。除了常见的 IHDR、IDAT、IEND 数据块，文件里还多了一个约 21 KB 的 caBX 数据块。
其中存放的是 C2PA 内容凭证（Content Credentials），封装在 JUMBF box 中。可以把它理解为随文件携带的一份来源声明，带有签名和完整性校验信息。
作者用官方 Python 绑定读取它：
import c2pa
with c2pa.Reader("sample.png") as r:
print(r.json())
这里要注意 r.json()：它展示的是凭证内容，判断时还要继续看具体字段与校验结果。
这份文件记录的签署者是 OpenAI OpCo, LLC，生成服务是 OpenAI Media Service API。创建动作中的数字来源类型为：
http://cv.iptc.org/newscodes/digitalsourcetype/trainedAlgorithmicMedia
真正直接回答「是否由生成式 AI 制作」的是这个来源类型。trainedAlgorithmicMedia 中的 trained 很关键：去掉它，algorithmicMedia 表示的是程序生成的计算机图形，不能直接归为模型生成。
为什么 Invalid 不等于图片被改过
作者读到的整体 validation_state 是 Invalid，但展开检查后，情况比这个总状态复杂：
| 检查项 | 结果 | 对应含义 |
|---|---|---|
claimSignature.validated |
通过 | 声明签名校验通过 |
assertion.dataHash.match |
通过 | 内容哈希与签署时匹配 |
timeStamp.validated |
通过 | 时间戳校验通过 |
signingCredential.untrusted |
失败 | 签署证书未被信任列表认可 |
signingCredential.invalid |
失败 | 证书缺少要求的扩展密钥用途 EKU |
在这个样本里，内容和签名声明保持完整，失败的是签署证书的信任与规范要求。
「签署后是否被修改」和「签署者是否受信任」必须分别展示。
对前端结果页来说，这会直接影响提示文案。把所有 Invalid 都渲染成「图片已被篡改」，就会把证书问题错误地解释成内容问题。原文也没有进一步说明，这张图片的证书为何缺少所需 EKU，不能替作者补出原因。
转成 JPEG 后，证据就不见了
作者用 macOS 自带的 sips 把图片重新保存为 JPEG，随后用 strings 检查，没有找到任何 c2pa 引用，原有 manifest 已经消失。
原文没有给出完整转换命令，也没有测试其他转换工具。作者还指出，截图以及多数社交、聊天平台的重新编码也会造成凭证丢失，但没有列出逐个平台的实测结果。
这里最重要的是推理方向：
可信且校验通过的来源凭证可以支持来源判断，缺少凭证却不能支持相反结论。
截图保留了画面，却未必保留原文件携带的来源证据。群聊转发图、平台下载图到了检测环节，很可能已经失去这一层信息。
因此，作者采用的检查顺序是：先读签名凭证，再看 IPTC 来源类型、软件标签等可编辑元数据，最后才用模式识别模型，并把模型输出当作概率。
作者把这套顺序做进了浏览器工具 Image or AI。凭证和元数据通过 @contentauth/c2pa-web 的 WebAssembly 在客户端读取，这两个步骤不需要把图片传出设备。原文没有交代模型检测阶段的数据流，不能据此推断整个工具都在本地运行。
我的判断
这篇最有价值的部分，是把「检测结果」拆成了可以解释的证据。签名凭证、可编辑标签、模型概率，各自回答的问题不同，界面应该让用户看见差别。
不过，它是一张图片的文件拆解，加上作者对工具流程的经验判断。原文没有给出检测准确率、误报率，也没有拿这套流程与直接使用分类模型做对照实验。因此，「所有检测器都该这样排才更准」还缺数据支持。
和直接给一个「AI 概率」相比，先检查凭证能提供更明确的判断依据；局限也很清楚：一旦原文件丢失，或者凭证被转换过程移除，这条路径就无法回答来源问题。此时合理的结果应当是证据不足，而不是自动判为真人作品。
能拿来做什么
- 做前端图片检查功能时，可以优先在客户端读取凭证和元数据，并明确展示结论来自签名、标签还是模型推断。
- 设计校验结果页时，把内容完整性、签署者信任状态和来源声明分开展示，避免用一个
Invalid包办所有错误提示。 - 排查图片处理链路时，可以对原始文件和转换产物分别检查凭证，确认压缩、转格式、上传环节是否保留了来源信息。
- 给用户提供上传说明时，建议提交原始文件；收到截图或转发图后，应允许返回「未发现来源凭证，无法据此判断」。