C2PA 能证明视频是真的吗？——签名有效、来源可信与内容真实为什么是三件事

C2PA 不是“鉴伪检测器”。

C2PA（Coalition for Content Provenance and Authenticity）是一个制定开放规范的联盟，规范的目标是让数字内容的来源与变更信息可以通过密码学机制进行验证。这类信息称为溯源信息（provenance）。这里需要看清验证的对象：它是关于材料的受保护数据，并不意味着摄像机前发生的一切，以及拍摄后的全部历史，都已自动得到证实。 [1, §§1.1–1.3; 2.3.1–2.3.4]

与这项技术相关的另一个名称是内容凭证（Content Credentials）。在规范术语中，Content Credential 是 C2PA 清单（C2PA Manifest）面向非技术用户的称呼：它是一组结构化的溯源数据，并带有保护这些数据的机制。在更宽泛的用法中，这个名称也指代整项技术。因此，Content Credentials 并不只是界面上显示在视频旁边的一个图标。 [1, §2.3.6]

理解后面的分析，只需先区分一件事：

C2PA 帮助验证哪些声明受到保护、它们归属于哪一签名方，以及它们与哪份材料关联。这不等于确认视频中呈现的事件是否真实发生。 [1, §10.2.2; §15.10.3.1; §14.3.3; 2, §7.2.2]

例如，平台可以验证一项关于视频转码的受保护声明，并把结果关联到发布的文件。这是一个有具体内容的正向结果。问题在于，如何从验证环节一直到用户界面保留它的依据，而不是在这个过程中把它变成“画面中的事件确实发生过”。

1. C2PA 在整体视频/CDN 架构中的位置

在分析 C2PA 内部对象之前，先明确这个机制在生产级视频/CDN 系统中的位置。

这样的系统至少有三项逻辑上不同的职责：

在下文的文件式 VOD 场景中，平台固定文件版本后，通过源站/CDN 发布的仍是同一个未改变的对象。转码已由发布方在平台接收文件之前完成。整体系统中可能存在的媒体准备、打包组件，均位于本例选定路径之外：它们不表示被验证的视频在此流程中又经历了这些转换。

本文讨论的问题不在 CDN 分发路径本身。在我们的场景中，CDN 可以正确交付 X:v1，返回预期的 HTTP 响应，并提供正常的 QoE。错误位于 E1 → 平台声明这一转换处：正确的验证证据被转换成了一个在语义上强于现有依据的声明。这是对结果进行解释的边界，并不表示它必须发生在视频交付之后。

在这个模型中：

• 数据/分发平面交付 X:v1；
• 验证平面生成 E1；
• 平台策略/声明评估决定，根据 E1 可以作出什么声明。

这是逻辑上的职责划分，不是要求建设三个独立的物理子系统。但这种区分在架构上至关重要：交付正确性、溯源验证和面向用户的声明，不能被压缩成一个类似 trusted=true 的状态。图中展示的分发路径，也不会把 C2PA 的验证结果扩大为对后续每一次 CDN 响应的认证。

接下来，来看这个流程中的具体对象。

2. 一个文件，成功的检查，两种不同的声明

考虑一个用于说明问题的视频点播发布场景，即 VOD。

对我而言，这类错误并不只是理论问题。在生产实践中，我遇到过这样的情况：系统某一部分在技术上正确的结果，被解释成了比它实际能够提供的更强的保证。例如，在 SSAI 系统插入广告内容时，就出现过类似的边界问题。

这里有意不使用那些生产系统的具体细节。下面的例子是一个独立设计的简化场景，专门用于分析 C2PA 的边界。它不是对生产事故的重建，也不是 SDK 运行报告。

下文所有适用检查均成功，是这个案例的前提。协议层面的分析以 C2PA Technical Specification 2.4 为依据。

在文件进入平台之前，发布方打开已有材料 U1，使用工具 T 对其转码，并生成已签名的成品 MP4。文件关联着 C2PA 清单 M1；签名方由凭证（credential）K_pub 表示。源材料 U1 没有关联的 C2PA 清单。这限制了可获得的前序历史，但不改变本例的验证对象：平台接收并验证的是输出文件。

平台接收文件时，将其固定为不可变版本 X:v1。这是平台在收到材料后分配的标识，不是发布方预先写入签名记录的字段。

从接收到发布，平台不再对文件转码，也不修改容器或元数据。发布记录 VOD1 必须发布与验证结果 E1 对应的同一 X:v1，且文件逐字节保持不变。U1 到输出文件的转换此前已经完成；这里没有把源材料的验证结果继承到输出文件上。

本例中，针对当前清单及声明对象、签名及凭证、断言（assertion）引用、动作与输入素材（ingredient）上下文，以及与被验证视频数据的关联，所有必要检查均已成功。签名凭证已在给定的信任上下文中被接受。不能用一条“签名正确”的消息替代这一整组检查。

现在，平台显示 True Video，而且这项标记有一个明确含义：

Q_EVENT：“X:v1 中呈现的设备故障确实在物理世界中发生过。”

这是本例平台的虚构标记，不是 C2PA 的官方状态。它也不只是表示“凭证已被接受”或“验证任务已完成”。

真正需要传递给结果使用方的正向结果是另一件事：签名方作出了一项关于使用工具 T 进行转码的受保护声明；该声明的归属，以及它与所发布视频版本关联的依据，均已通过检查。下文把这一结果的完整契约称为 Q_PROV。

要区分 Q_PROV 与 Q_EVENT，不能只给图标换一个更谨慎的用词。必须知道验证了哪些对象，以及每项检查结果支持结论中的哪一部分。

3. 到底验证了什么，验证针对哪个对象

已签名的声明对象、承载记录的断言与所选记录

验证 X:v1 时，使用的是它的标准类型的活动清单 M1，而不是任意找到的一份清单。 [1, §2.3.7; §15.5; §15.12]

M1 中有一个已签名的对象：CM1，即 C2PA 声明对象（C2PA claim）。它包含指向溯源数据的可验证引用。不要把这个协议对象与平台声明混为一谈：Q_PROV 和 Q_EVENT 是由验证结果的使用方表述的。 [1, §§2.3.1–2.3.4; §10.3.2.4]

本例使用类型为 c2pa.actions.v2 的 A1_assertion，其中包含动作记录。我们选中的是其中动作值为 c2pa.transcoded 的 A1_record。这是表示转码，也就是改变材料编码方式的标准动作名称。所选记录的 softwareAgent 字段包含 name = T，表示声明中使用的操作工具。 [1, §18.15.1, Table 8; §18.15.4.4]

对象关系是：CM1.created_assertions → A1_assertion → A1_record。created_assertions 列表引用的是承载记录的断言，而不是直接引用其中嵌套的动作记录。

这个区别有实际意义。created_assertions 所引用的断言归属于签名方；断言出现在 gathered_assertions 中，并不带来相同的归属。不能仅仅因为元数据位于已验证数据旁边，就把文件的全部元数据都称为当前签名方的声明。 [1, §10.2.2]

对于同一个固定的 CM1 和正在验证的 K_pub，令 (a^) 表示所选的 A1_assertion，C 表示 CM1.created_assertions 所引用的断言集合。R、I 和 S 是同一论域中的断言集合，分别对应引用解析成功、引用中指定的哈希校验成功，以及 CM1 签名的密码学验证成功。仅有 (a^ \\in C) 还不够；这条路径的必要条件需要同时满足：

a

∗

∈

C

∩

R

∩

I

∩

S

a^* \\in C \\cap R \\cap I \\cap S

a∗∈C∩R∩I∩S

这是本文对归属及完整性保护所需条件的简写，不是 C2PA 的规范公式，也不是整个验证过程成功的充分判据。因此，E1 不应只保存“已使用工具 T 转码”这一字符串，还要保存承载它的断言、指向该断言的引用、记录的唯一明确选择方式，以及这条路径的检查结果。 [1, §15.10.3.1]

最终验证的是签名方作出的受保护声明。softwareAgent.name = T 不会因此成为对“T 确实运行过，并正确完成了转码”的独立观测。“签名方声明”是所确认属性的一部分，不是精简文字时可以删掉的附带说明。 [1, §18.15.4.4; 2, §7.2.2]

初始动作分支与已知历史的边界

所选的转码记录不能替代清单的其余结构。在本例的内容生产上下文中，第一个动作是 c2pa.opened：它包含且仅包含一个指向 I1 的哈希 URI（hashed-URI）引用。I1 是类型为 c2pa.ingredient.v3、关系为 parentOf 的断言，表示源材料 U1。下一条记录才是所选的 c2pa.transcoded。这些是本分支必要的关联关系，不是构造有效清单的完整配方。 [1, §18.15.2; §15.10.3.2.3(2)(1–3)]

本例不声明动作历史完整：allActionsIncluded = false。I1 没有 activeManifest，也不会为它构造虚假的 validationResults。对于所选的输入素材上下文，规范规定了信息性结果 ingredient.unknownProvenance，该结果保留在 E1 中。 [1, §18.15.3; §15.11.3.3(6.1.3); §18.16.12.4.3]

这个结果既不表示 U1 的全部前序历史已经验证成功，也不表示当前 M1 验证失败，更不是“视频为假”的诊断。验证输入素材断言及其引用，也不意味着对 U1 原始字节进行了独立验证。当前文件的适用检查是否成功，与其前序历史是否完整，是两个不同的问题。 [1, §15.11.3.3; 2, §7.2.1]

与视频数据的关联：内容绑定

即便 CM1 的签名已正确通过验证，也不足以把结果归于当前视频。还需要验证内容绑定（content binding），即机制所规定的溯源数据与材料本身数据之间的关联。本例验证的正是 X:v1，而不只是单独的一份 M1。 [1, §14.3.3; §15.12.2]

对于所选的完整、非分片 MP4，使用文件级 BMFF 绑定 c2pa.hash.bmff.v3。将具体的绑定断言记为 B_X1，将其覆盖的数据范围记为 Cov_X1。 [1, §§18.6.1–18.6.3]

不能把 Cov_X1 简化成“MP4 的每一个字节都已签名”。它由具体断言、其中的排除项和具体文件的结构共同决定。因此，正向结论仅限于已经验证的绑定覆盖范围。哈希计算与排除项的细节不是本文主线，但它们仍然属于验证依据的一部分。 [1, §18.6.2; Appendix A.5.6]

尤其要区分两项保证：C2PA 内容绑定将 M1 与 X:v1 中被覆盖的数据关联；从验证到发布之间文件保持不变，则由平台保证。后者不会扩大前者的密码学覆盖范围。

凭证被接受与来源可信

将使用的信任策略记为 TP1，使用它时的上下文记为 Ctx1。Ctx1 包含所用的信任输入、规则和验证的时间依据。本例中，K_pub 在满足适用要求后被接受；平台不能用任意自定策略取消标准要求的必要检查。Ctx1 是本次评估的上下文，它既不证明拍摄时间，也不使结果自动适用于任何新的上下文。 [1, §§14.4–14.5; §§15.7–15.9]

这里接受的是凭证，并不是独立证明签名方就是某台摄像机、身份已核实的组织或采集源。发布方这一角色由示例前提给定。K_pub 被接受，也不意味着其每项声明在事实上都诚实可信。 [1, §2.1.3; §14.2; 2, §§7.2.2; 7.2.4]

**签名通过密码学验证，并不意味着签名方可信；签名方可信，也不意味着其声明内容属实。**这三个层次回答的是不同问题。但这不允许我们把规范中的验证结果建模为任意组合的独立标志。清单状态之间存在依赖关系，§15.7 的流程也将信任评估与后续报告 claimSignature.validated 的条件关联起来。Q_PROV 所需的是所有适用检查的整体结果，而不是某一个孤立的成功代码。 [1, §§14.3.2–14.3.6; §15.7; §15.9]

4. 如何把已验证的声明关联到发布的视频

现在可以把有用的结果组织起来。下面描述的是本文提出的平台契约，不是 C2PA 规定的服务、数据库或 API 设计。

E1 保留结果使用方所需的依据：已验证的 X:v1、M1 和 CM1；具体的 A1_assertion 与选中的 A1_record；完整性检查结果与归属依据；B_X1 以及可复现 Cov_X1 的依据；K_pub 及其被接受的上下文。关于 U1 前序历史限制的信息也保留在记录中。

在保留这些依据并满足发布条件时，完整的 Q_PROV 表达以下含义：

对于发布的版本 X:v1，已在 Cov_X1 范围内验证其与 M1 之间适用的内容绑定。由凭证 K_pub 表示的签名方，通过受保护的 A1_assertion，在 A1_record 中声明：准备该视频时使用工具 T 进行了转码。CM1 的签名，以及通向承载该记录的断言的完整性路径均已验证；K_pub 已在 Ctx1 中依据 TP1 被接受。平台的不可变对象契约将评估结果关联到 VOD1 发布的同一 X:v1。

这段表述较为详细，是因为其中各部分有不同的依据。检查架构时，可以把它们明确对应起来：

这项组合结论在协议层面的依据，是引用、签名及信任的检查，动作记录，以及内容绑定。与发布对象的关联，则是本例流程中另一项独立的架构条件。 [1, §10.2.2; §15.7; §15.10.3.1; §15.12.2; §18.15.1; §18.15.4.4]

为什么只有一个视频链接还不够

发布对象之间的逻辑关系应当是：

E1.subject → X:v1
VOD1.media_ref → X:v1
VOD1.assessment_ref → E1

这些是本文模型中的示意性关联，不是 C2PA 规定的必填字段名。它们表达一项具体职责：用户打开的版本，必须正是界面所显示的评估结果对应的版本。

视频名称相同，或逻辑 asset_id 相同，都不能保证这一点。针对某个文件的正确结果，本身并不足以支持在另一个码流版本旁显示相同评估。因此，本例流程不包含验证后的转换，也不承诺 E1 会自动继承到派生版本。

为使内容绑定可复现，平台保留不可变对象本身，或稳定指向其可访问字节的引用，以及包含全部排除项的具体 B_X1、已使用的规则和结果。只要可以从这些数据中唯一还原覆盖范围，就不必再额外复制一张包含全部偏移量的表。配置档名称、可变 URL，或无法访问的文件所对应的哈希，都不能替代这些依据。

这样，E1 就不再是另一个 trusted=true，而是一条可以还原结果含义的记录。我们不需要为每项检查建立独立服务；需要的是结果使用方在形成声明时，不丢失对象、归属、范围和上下文。

界面可以使用更简短的表述，也可以另行展开细节。但精简不能改变确认的对象：“已验证转码声明的保护与归属”不等于“已独立确认转码实际发生”。否则，技术结果刚被转换成用户可读文字，其依据就已经丢失了。

5. 这个结果能够支持的结论止于何处

回到同一个 E1 和同一 X:v1。签名没有损坏，凭证未被拒绝，内容绑定已通过验证，评估结果也没有被关联到另一个文件。不必破坏其中任何一个条件，就能发现 True Video 的问题。

E1 中具备关于转码声明的依据：声明内容、保护、归属、与视频的关联，以及凭证被接受的上下文。**但其中没有能够确认设备故障确实在物理世界中发生的依据。**官方 Explainer 明确区分了溯源信息与对内容是否真实、准确、符合事实的判断。 [2, §7.2.2]

因此，对于同一个 E1，可以作出以下区分：

**“未确立”不等于“为假”。**我们没有识破伪造，也没有证明故障未曾发生。要对事件作出判断，需要其他依据，以及针对该问题的独立评估；这些不在本例契约之中。 [2, §7.2.2]

这并不是因为 U1 没有清单

信息性结果 ingredient.unknownProvenance 必须保留，但不能把整个论证建立在它上面。即便从推理中去掉这一限制，受保护的转码声明也不会变成对事件的独立确认。

可获得的历史不一定完整。但即使转换历史被完整描述，这件事本身也不能回答画面中的事件是否发生。同样，数据相对于被验证状态保持不变，并不证明该状态下呈现的内容属实。这里验证的是不同属性，而不只是对同一个结果持有不同程度的信心。 [2, §§7.2.1–7.2.2; 1, §18.6.2]

也不能悄悄把凭证被接受提升为采集源可信，再提升为该来源的所有信息都属实。即使是规范中标记为 Trusted 的清单，也不是“事件已确认”这一状态。 [1, §14.3.6; 2, §§7.2.2; 7.2.4]

最后，转换历史的描述也不是现成的发布许可结论。它是平台针对具体问题进行评估的输入。内容准入规则与对内容声明的证明承担不同职责；本文不选择具体的准入策略。 [1, §14.1; 2, §7.2.2]

Content Credentials 的官方用户体验建议支持透明地呈现溯源信息，帮助用户作出知情判断。这些是界面建议，不是一个具有唯一含义的强制性协议标记。在本例中，True Video 这一具体声明的责任，仍然属于作出它的平台。 [3, §§2–2.1]

总结：关于具体发布视频的可验证声明

C2PA 的有用结果，既不是“一切都已证明”，也不是“什么都不能说”。在本例中，平台获得一项具体的、受保护的转码声明，验证其归属及与材料的关联，保留凭证被接受的上下文，并把评估结果与同一文件版本一起发布。

这里有三项不同的职责。密码学检查为受保护数据及其与材料的关联提供依据。平台保持被验证版本与发布版本一致。结果使用方只表述这些依据能够支持的结论。

实用的检查标准很简单：对于 UI/API 中每一个实质性陈述，都能指出哪项检查或哪个流程条件支持它。如果受保护的转换声明变成了对物理事件的确认，问题并不是签名还不够可靠，而是平台在没有相应依据的情况下，回答了另一个问题。

参考资料

**[1] C2PA. Content Credentials: C2PA Technical Specification，2.4 版。**主要技术来源；具体章节标在相应陈述旁。解释性定义和注释不被提升为新的强制要求。 https://spec.c2pa.org/specifications/specifications/2.4/specs/C2PA_Specification.html

**[2] C2PA. C2PA and Content Credentials Explainer，2.4 版。**信息性来源；其中 §§7.2.1–7.2.2 讨论溯源信息的完整性与事实真实性的边界，§7.2.4 讨论身份识别。 https://spec.c2pa.org/specifications/specifications/2.4/explainer/Explainer.html

**[3] C2PA. User Experience Guidance for Implementers，2.2 版。**辅助性的用户体验建议，不是要求界面采用唯一方案的规范性规定；§§2–2.1。 https://spec.c2pa.org/specifications/specifications/2.2/ux/UX_Recommendations.html