2024年のC2PA（コンテンツの来歴証明技術）の進化を追う　～C2PA 2.0&2.1の更新サマリ解説～

はじめに

こんにちは。ドコモ・テクノロジ 携帯事業部の樋口、NTTドコモ モバイルイノベーションテック部の坂井、森下です。

昨年に引き続きC2PAについての記事となります。本記事では昨年からの更新点について紹介していきます。

まず世の中の動向ですが、昨年の記事「生成AI時代に重要になりそうなCAI/C2PA（コンテンツの来歴証明技術）を読み解いてみた」で紹介した以降もC2PAは様々なサービスに取り入れられ始めています。

例えば、昨年末時点ではLeicaやSonyによる一眼カメラへのC2PA搭載がニュースになっていましたが、その後NikonやCanonのカメラにも実装が進んでいます。

またAIは絶えず進化していますが、ChatGPTやMicrosoft CopilotではAIが生成した画像に自動的にC2PAマニフェストが付与されるようになりました。これにより、ユーザーはこれらの画像がAIによって作られたものであることを認識できるようになりました。 他にもYouTubeやTikTokといったプラットフォームでもC2PAの情報が活用できるように対応が進んでいます。 そして報道分野ではNHKがC2PA対応を模索し始めている状況です。

C2PAのSpecification自体も最新バージョンが2.1となり新たに更新されています。昨年度のアドベンドカレンダー時点(バージョン1.4)から以下のように2度のバージョンアップがありました。

• バージョン2.0：actorの意味合いが狭まり、個人や組織を表すものではなくなりました。またバリデーター設定のTrust Listに加えて、新たにデフォルトのC2PA Trust Listが導入されるようになりました。
• バージョン2.1：セキュリティと信頼性を向上させる為に仕様や技術的な変更がされています。

それでは昨年度のアドベンドカレンダーの内容を前提にSpecificationの変更箇所について本記事を通して確認していきましょう。

変更点のサマリ

具体的な変更内容の補足をする前に各要素でどのような変更が行われたか抜粋して纏めます。

• Assertion

  • c2pa.asset-type、c2pa.hash.bmff.v3、c2pa.ingredient.v3、c2pa.metadataが追加
  • stds.exif、stds.iptc、c2pa.endorsement、stds.schema-org.ClaimReview、stds.schema-org.ClaimReviewが削除
  • c2pa.font.infoがfont.infoに名称が変更

• Credential

  • W3C Verifiable Credentialsの記載が削除
  • VC Store関連の記載の削除
  • actors fieldおよびMetadataのidentified humansの記載削除

• ClaimとClaim Signature

  • urn:c2pa新しいURNラベルの追加
  • c2pa.claim.v2の追加

• Manifest & Manifest Store

  • Time-stamp Manifestの追加
  • Manifestの付与できるファイルの追加

• 来歴情報の検証

  • ManifestとAssetに対する"Validation State"の追加
  • C2PA Trust Listの追加、全体的な記載の詳細化

参考までにAppendixにはDeprecatedになった構成要素をまとめた表が存在します。こちらのC.1. Deprecated Constructsも確認いただけるとより視覚的に分かりやすくなると思います。
(一部c2pa.hash.bmff.v3など変更があったものにも関わらずこの表にないものありますので、ご注意ください)

注意事項

本アドベンドカレンダーではv1.4⇒v2.1での重要な変更点に焦点を当てて解説していきます。
その為すべての変更内容を確認したい場合は以下のURLを参考に確認ください。

5.2. Version History 　※C2PA Specificationsの各バージョンの更新内容が記載されています

具体的な変更内容

昨年のアドベントカレンダーの流れに沿って変更内容の説明を行っていきます。

Assertionについて

AssertionにはStandard AssertionとCustom Assertionの2種類が存在すると説明していたと思います。
その内のStandard Assertionについて一部変更が行われています。

Type	Assertion	ステータス
Asset Type	c2pa.asset-type	追åŠ
BMFF-based Hash	c2pa.hash.bmff.v3	追åŠ
Actions	c2pa.actions.v2	追åŠ
Ingredient	c2pa.ingredient.v3	追åŠ
Endorsement	c2pa.endorsement	削除
Metadata	c2pa.metadata	追åŠ
Exif information	stds.exif	削除
IPTC Photo and Video Metadata	stds.iptc	削除
Claim Review	stds.schema-org.ClaimReview	削除
Claim Review	stds.schema-org.CreativeWork	削除

※以下では追加されているAssertionに絞って補足します。

c2pa.asset-type

Assetの種別を記載することができるAssertionです。
※クレームに存在したdc:formatよりも詳細にAssetの種別を規定する目的で追加されています。 つまり将来的にAI/MLのモデルやデータセットの出所を判別できるよう、C2PAマニフェストをAI/MLのモデルやデータセットに埋め込み、Assertionのc2pa.asset-typeでAssetの種別を規定することを可能にすることが変更の意図になります。

例えば以下の記載の例では、Assetはv2.11.0のTensorFlowのモデルファイルでSavedModel形式で保存されていることが表現できます。

{
  "types":
  [
    {
      "type": "c2pa.types.model.tensorflow",
      "version": "2.11.0"
    },
    {
      "type": "c2pa.types.savedmodel",
      "version": "2.11.0"
    }
  ]
}

c2pa.hash.bmff.v3

BMFFベースのAssetの際に使用するHash Assertionです。

C.1. Deprecated Constructsでは特に記載がありませんが、18.6. BMFF-Based Hashではc2pa.hash.bmff.v2 (deprecated)という表記になっています。 その為、基本的にバージョン2.1では最新のc2pa.hash.bmff.v3に従うのが望ましいと思われます。

スキーマとしてはfixedBlockSizeとvariableBlockSizesが追加されています。このfixedBlockSizeかvariableBlockSizesの値が存在する場合は値に従いマークルツリーのリーフノードのデータ分割を行います。処理の詳細はExample 7. A suggested example of a merkle mapをご確認ください。 例えば.mp4のような大きなサイズの本体データ(mdat)を持つデータをそのまま使用するとManifest Storeのサイズ増加に大きく影響してしまいます。そのため前述したマークルツリーを使用してサイズを抑えるような処理ができるようになっています。

更に詳しく知りたい場合はA.4.4. Auxiliary 'c2pa' Boxes for Large and Fragmented Filesに補足説明されていますのでそちらをご確認ください。

c2pa.ingredient.v3

Assetを構成する複数のAsset(Ingredients)が存在する場合などで使用されるAssertionです。
ここではc2pa.ingredient.v3が新たに定義されました。後のValidationでも記述しますが、これによりIngredientの詳細な検証が可能になっています。 以下ではv2からのスキーマの変更内容について触れます。

 "activeManifest": {
      "url": "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322",
      "hash": b64'1kjJTO108b71cL95UxgfHD3eDgk9VrCedW8n3fYTRMk='
  },
  "claimSignature": {
      "url": "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322/c2pa.signature",
      "hash": b64'85KAvU3+3YgtIjj6IV0fzKwj8si/85+gevVSK2Iw+S0='
  },
  "validationResults": {
    "activeManifest": {
      "success": [
      {
        "code": "claimSignature.validated",
        "url": "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322/c2pa.signature"
      },{
        "code": "signingCredential.trusted",
        "url": "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322/c2pa.signature"
      },{
        "code": "timeStamp.validated",
        "url": "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322/c2pa.signature"
      },{
        "code": "timeStamp.trusted",
        "url": "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322/c2pa.signature"
      },{
        "code": "assertion.hashedURI.match",
        "url": "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322/c2pa.assertions/c2pa.ingredient.v3"
      }
      ],
      "informational": [{
        "code": "signingCredential.ocsp.skipped",
        "url": "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322/c2pa.signature"
      }],
      "failure": []
    }

• Active Manifest：追加されるIngredientsのActive ManifestのURLとhashを示す
• Claim Signature：追加されるIngredientsのClaim SignatureのURLとhashを示す
• Validation Results：Ingredientsに対する検証の結果を示す
  　※各検証のcodeの内容については15.2.1. Standard Status Codesを参照ください。

c2pa.metadata

Assetのメタデータ情報を記載するAssertionです。
以前まではstds.exifとstds.iptcなどメタデータの規格ごとに個別にAssertionがありましたが、c2pa.metadataに統合されました。c2pa.metadataでサポートされているスキーマについては以下のリンクの内容を参照ください。 Appendix B: Implementation Details for c2pa.metadata

Soft Binding

Soft Bindingはフィンガープリントやデジタルコンテンツ内に埋め込まれた非表示のウォーターマーク等の情報をSoft Binding Assertionに記述し紐づけるBindingの方法になります。 前回から機能としては存在しましたが、新たに使用できるアルゴリズムの一覧が追加されておりますので、Soft Bindingを使用する際にはこちらも併せてご確認ください。

Credential関連

W3C Verifiable Credentialsの章が削除されています。明確な理由は記載されていませんが、同時にVerifiable Credentialsの情報を含んでいたactorオブジェクトも削除されています。推測にはなってしまいますが、個人を識別するというよりGenerative AIなどのサービスから署名が付与されるようなケースに焦点を合わせているのかもしれません。

Claim & Claim Signature

Hashed URI

URNの識別子がurn:uuidからurn:c2paに変更されています。それに伴ってHashed URIに記載するurlの内容も変更されています。

〇旧

"url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.actions"

〇新

・Manifest Store全体に対する相対パスを指定する場合

"url": "self#jumbf=/c2pa/urn:c2pa:F095F30E-6CD5-4BF7-8C44-CE8420CA9FB7/c2pa.assertions/c2pa.thumbnail.claim.jpeg" 

・現在のManifestに対して相対パスを指定する場合

"url": "self#jumbf=c2pa.assertions/c2pa.thumbnail.claim.jpeg"

urn:c2paに変更された理由としては、以前までの内容だとRFC 9562 (UUIDs)とRFC 8141 (URNs)のいずれにも準拠出来ていないことが判明したため変更されているようです。 より詳細に確認したい場合は8. Unique Identifiersをご確認ください

ClaimとClaim Signatureの記述方法

Claimã‚‚c2pa.claim.v2という新しい形式が追加されています。10.2. Syntaxに記載されている以下の形式で記載が可能になっています。

{
  "alg" : "sha256",
  "claim_generator_info" : {
    "name": "Joe's Photo Editor",
    "version": "2.0",
    "operating_system": "Windows 10"
  },
  "signature" : "self#jumbf=c2pa/urn:c2pa:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.signature",
  "created_assertions" : [
    {
      "url": "self#jumbf=c2pa/urn:c2pa:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",
      "hash": b64'U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8='
    },
    {
      "url": "self#jumbf=c2pa/urn:c2pa:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.thumbnail.claim.jpeg",
      "hash": b64'G5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c='
    },
    {
      "url": "self#jumbf=c2pa/urn:c2pa:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.ingredient.v3",
      "hash": b64'Yzag4o5jO4xPyfANVtw7ETlbFSWZNfeM78qbSi8Abkk='
    }
  ],
  "redacted_assertions" : [
    "self#jumbf=c2pa/urn:c2pa:5E7B01FC-4932-4BAB-AB32-D4F12A8AA322/c2pa.assertions/c2pa.metadata"
  ]
}

変更点は以下の通りです。基本的にc2pa.claimから大きな変更はありません。

• dc:format :こちらの記載が削除され、c2pa.asset-typeに役割が移行されています

Manifest & Manifest Store

Time-Stamp Manifest

新たなManifestの種類としてTime-stamp Manifestが追加されています。オフライン時にマニフェストが付与された場合にTSAからタイムスタンプを取得することができません。これに対処するためにタイムスタンプマニフェストc2tmを使用しTSAに接続できるようになった後の操作でタイムスタンプを追加することが可能になりました。

Embedding manifest

Manifestが埋め込めるAsset形式が追加にされています。(JPRG-XL,SVG,MOV,AAC等)
より詳細に知りたい場合はA.1. Supported Formatsを確認ください。

各構成要素

Entity Diagramも更新されています。 更新点のまとめは以下の通りです。

• Asset内のMetadataが削除(Bindingへの紐づけが消失)
  • Assetのメタデータに対しては署名をする必要が無くなっています。詳細な変更内容は9.2.5. Asset Metadata Bindingsをご確認ください。
• Manifest StoreにData Box Storeが増加
  • 以前からData Storageは存在していましたが、本バージョンからEntity Diagramにも記載されています。
• Manifest内のCredential Storeが削除
  • Credential関連で説明したようにVC周りの記載が削除されている為、Credential Storeも削除されています。
• Credentialの箱自体が削除
  • Credential関連で説明したようにVC周りの記載が削除されている為、Credential Storeも削除されています。
• Signerの箱が増え、Claim Signatureへの紐づけ追加
  • 仕様書整備の範疇だと思われます。以前からSignerという用語は存在していましたが、今回からClaim SignatureはSignerによって生成されるという事がより明示的にされているものだと思われます。
• IngredientがIngredient Assertionに名称が変更

出典：Figure 11. C2PA Entity Diagram

来歴情報の検証

Validate the Ingredients

Ingredientの検証プロセスが追加されています。検証については以下のフローに従って行われています。このフローを実行するためにc2pa.ingredient.v3が必要になっています。これにより再帰的な検証やClaim Signature Hashã‚„Manifest Hashからも検証が可能になりました。 詳細は15.11. Validate the Ingredientsをご確認ください。

出典：Figure 14. Ingredient Validation

Trust Model

Validation state

Validation stateの記載が追加され、中身としてManifest StateとAsset Stateが追加されています。
検証結果からManifestをいずれかのStateにWell-Formed、Valid、Trustedに分類可能になりました。
ManifestがValidかTrustedのいずれかである場合Asset StateはValidとなります。 各Manifest Stateの判定条件については14.3. Validation statesをご確認ください。

Trust List

C2PAから提供されるC2PA Trust Listが存在するようになりました。このC2PA Trust Listによって信頼された署名者であるかどうかを判断します。例えばContent CredentialのVerifyサイト上では、C2PA Trust Listのリスト以外の署名者による署名には「このコンテンツ認証情報は不明な発行元によって発行されました。」と警告表示されるようになっています。これによってユーザーからより信頼できる署名かどうかの判断がしやすくなりました。

一方で、C2PA Trust List以外に利用者側で追加のTrust Listを用意することも可能です。この場合、前述のVerifyサイトでは警告表示されてしまうことには注意してください。 詳細は14.4. Trust Listをご確認ください。

おわりに

重要と思われる更新点に絞って更新内容をご紹介させていただきましたが、いかがだったでしょうか。 specificationの原文は少々取っ付きにくい部分もあるため本記事が皆さんの理解促進のお役に立てば幸いです。

なお、記事の内容に関しては誤りがないよう最善を尽くしましたが、至らない部分があるかと思います。 もし記載の内容に誤りを見つけた際には、ぜひみなさんの記事等でお手柔らかに指摘いただけますと幸いです。

私たちはこれからもドコモグループのモバイル技術に対しての先進的な取り組みを行っていきます。ぜひ今後の取り組みにご注目いただければと思います。

最後までお読みいただきありがとうございました。