NTTドコモR&Dの技術ブログです。

トップ > セキュリティ > 生成AI時代に重要になりそうなCAI/C2PA（コンテンツの来歴証明技術）を読み解いてみた

生成AI時代に重要になりそうなCAI/C2PA（コンテンツの来歴証明技術）を読み解いてみた

セキュリティ AI・機械学習 アドベントカレンダー2023 注目記事

第0章 はじめに

この記事は「NTTドコモ R&D Advent Calendar 2023」24日目の記事です。

いよいよ今年も残すところあと1週間と年の瀬が迫ってきましたが、みなさんは今年の技術トレンドと言えば何が思い浮かぶでしょうか？ Web3？ゼロトラスト？はたまた量子コンピューティング？

私はやはりGPT-4, DALL·E3, GitHub Copilot Xなどに代表される生成AIの普及が強く印象に残っています。 実際、「新語・流行語大賞2023」には「生成AI」「チャットGPT」がノミネートされているということで、世間でも大きなインパクトを残しているようです。 www3.nhk.or.jp

ただ、今年の生成AI関連のニュースを振り返ると、必ずしも良いニュースばかりではなかったように思います。 春ごろには画像生成AI Midjourneyの登場で多くの人がこぞって様々な画像を生成し、「大喜利」的な状況に盛り上がりを見せましたが、著作権の問題が指摘されるようになり、pixivなどで生成AIによる作品の投稿が禁止されることとなりました。 www.itmedia.co.jp

また直近でも生成AIによる音声を用いたとされる総理大臣のフェイク動画が拡散したことが問題視されました。 www.itmedia.co.jp

このように生成AIという魅力的な技術の出現の裏側では、デジタルコンテンツの真実性や帰属性をどのように担保していくか、つまりこのコンテンツは誰が作成したのか・どんな素材をもとに作成したのか、また実際に起きた現象を観測したものなのか・AIなどで巧妙に作成されたフェイクなのか、といった課題が影を落としつつあります。 足元ではこうした課題に対処するための技術がまさに出現しつつ*1あり、G7でも「広島AIプロセス」として電子透かしをはじめとする技術による対処方針が言及されました。 www.meti.go.jp

今回ご紹介するContent Authenticity Initiative (CAI)とCoalition for Content Provenance and Authenticity (C2PA)の両団体が取り組んでいる技術もまさにこの課題にアプローチするものの1つです。

比較的新しい技術のため日本語情報も非常に少なく、我々も技術の理解に苦労しました。 本記事では、IPAの応用情報技術者相当のセキュリティ知識がある方を想定読者として、我々の理解の過程で得た知見を含める形でCAI / C2PAの技術を解説していきます。

なお、次章はCAI / C2PAに関する概況の説明となっていますので、純粋に技術的側面のみに興味がある方は第2章 CAI / C2PAを使ってみたの章から読み進めていただければと思います。

第1章 CAI / C2PAとは

それぞれの団体の位置付けについて見た後、現在の普及状況や利用できるツールを確認していきましょう。

C2PA

Coalition for Content Provenance and Authenticity (C2PA) はネット上での誤った情報の氾濫を防ぐことを目的に、デジタルコンテンツの来歴（作成者や作成日時、その後の加工歴など）を証明する技術仕様を策定する団体です。 デジタルコンテンツに暗号技術を用いて来歴情報を付与することによって、その帰属や真実性の判断材料を明示し、前述の課題に対応しようというものになっています。

主な参画企業としては、Adobe、BBC、intel、Microsoft、Amazon (aws)、arm、Leicaなどの他、日本からもSony、Canon、NHK、Nikonなどが参画しており、コンテンツの作成デバイスや作成・編集ツール、配信、メディアなどデジタルコンテンツ流通の上流から下流まで多様な企業が関わっていることがわかります。

CAI

Content Authenticity Initiative (CAI) はその名の通り、デジタルコンテンツの信憑性・出所に関する標準仕様の利活用を推進する団体です。「デジタルコンテンツの信憑性・出所に関する標準仕様」は（少なくとも現時点では）実質的にC2PAの技術仕様を指しています。

こちらも参画企業はデジタルコンテンツの上流から下流まで幅広く、C2PAと重複する部分も多いものの、AFP通信社、AP通信、Reuters、Getty Imagesといったメディア系企業がより多く加入しているほか、NVIDIAやQualcommなどの半導体メーカーも加入している点が特徴的です。

CAIとC2PAの共通点・相違点

共通点

CAI / C2PAとも暗号技術により保証された来歴情報を用いるというアプローチで、デジタルコンテンツの信憑性の問題に対応しようとしている点は共通しています。 つまり、CAI / C2PAによる来歴情報が付与されたデジタルコンテンツであれば、その来歴情報を参照することでコンテンツの出元や加工有無を確認でき、信用するに値するコンテンツであるかを判断できるような世界観ですね。

例えば、前述のような総理大臣が物議をかもすような発言を行っている動画が出てきた際、来歴情報が付与されていれば、何かしらの加工を経た動画なのか、あるいは特に加工されていない上に新聞社などの信頼できるニュースソースが情報源となっているのかが容易に確認できるようになり、コンテンツの信憑性を手軽に判断しうるということです。

相違点

CAI / C2PAの両者は似た目標を掲げ、かつCAIに至ってはC2PAの仕様を実質的に担いでいるということで、なぜ分離しているのか不思議に思う方もいらっしゃるかもしれません。 これには経緯があり、もともとCAIは2019年にAdobeがNew York TimesやTwitterと設立した団体として仕様を検討していましたが、その後2021年2月に近い目的意識を持っていたProject Origin*2と呼ばれる団体と共同で取り組みを進めるため、標準の技術仕様策定に関してはC2PAで取り組むという座組に変化したようです。*3

そのため、現在C2PAではデジタルコンテンツの来歴証明のための技術仕様を策定する一方で、CAIはその技術仕様に準拠したツールやSDKをOSSとして提供したり、業界横断での事例創出を行うなどの形で、標準仕様の普及促進に注力しているという役割分担となっています。*4

普及状況

このようにC2PAが策定し、CAIが普及を図っている技術ですが、実はすでに商用化が始まっています。

例えば、AdobeのPhotoshop, LighthouseなどではすでにC2PAの来歴情報の作成・編集機能が備わっています。*5
加えてAdobeが提供している画像生成AIサービスFireflyで生成した画像には、自動的にC2PAの来歴情報が付与されるようになっています。 blog.adobe.com

Adobe以外にもQualcommは生成AIへの対応強化を謳っている「Snapdragon 8 Gen 3」において、あわせてC2PAへの対応も行っており、スマホのカメラにおいて今後ハードウェアレベルでC2PAの来歴情報証明が付与されるようになることが想定されます。 k-tai.watch.impress.co.jp

また、LeicaもC2PAに対応したデジタルカメラ「Leica M11-P」を発表しており、カメラでの撮影時に来歴情報としてカメラの機種とメーカー、また撮影日時や撮影者といった撮影の詳細情報を付与できるようになっています。 実際に以下のページからLeica M11-Pで撮影した画像の来歴情報を確認できるようですので試してみるとイメージが湧くかと思います。（「→コンテンツ認証情報を検証する」のリンクよりご確認ください） leica-camera.com

さらに、実証実験段階ではあるもののつい最近SONYはAP通信とカメラ内のハードウェアチップセットで画像にC2PAの来歴情報を付与して報道ワークフローで活用した旨を発表しており、国内外を問わず大企業の動きが活発になっている状況です。 www.sony.co.jp

関連ツールについて

大企業も大きく動き始めているということで敷居が高いと感じてしまう部分もあるかもしれませんが、実は我々でも比較的簡単に体験できるツールが整っています。

もっとも簡単な入口としてはC2PAが公開しているWeb上のGUI操作でC2PA準拠の来歴情報を読み込んで検証できるサイトが挙げられます。先ほどのLeica M11-Pの画像の来歴情報確認もこのサイトを利用しています。 contentcredentials.org

また、CAIからはより開発者向けのツールがOSSの形で複数提供されています。

https://opensource.contentauthenticity.org/docs/getting-started/#how-to-use-cai-tools-and-libraries https://opensource.contentauthenticity.org/docs/getting-started/#how-to-use-cai-tools-and-libraries

上図中央のc2patoolはコマンドラインからC2PAの来歴情報の読み込み・検証・編集が可能なツールで、図示されているようなサーバーからの利用だけでなく、直接手元でC2PAの仕組みを試すうえでも便利な存在です。

その他にもCAIは各アプリケーションで容易にC2PA仕様に対応できるよう以下のようなSDKを提供しています。

  • JavaScript SDK：JavaScript向け。C2PAの来歴情報の読み込みと検証のみが可能。（編集不可）
  • Rust SDK：Rust向け。C2PAの来歴情報の読み込み、検証、編集が可能。

上記の通り、現状ではC2PAの来歴情報が作成できるアプリケーションを開発する場合Rustを使う必要がある状況ではありますが、他にもすでに早期プレリリース版の扱いで、C/C++、Python、Node.js向けの実装も出てきているようです。

では、ここまでで一通りCAI / C2PAの概況を見てきましたので、いよいよ次章では、c2patoolと上の来歴情報の検証サイトを使ってCAI / C2PAの技術がどういったものかを見ていきましょう。

第2章 CAI / C2PAを使ってみた

それではc2patoolを使用して、実際に自分が撮影した以下の某オフィスビルの写真にC2PA準拠の来歴情報を埋め込んでいきたいと思います。

皆さんもぜひ何かお好みの画像をお手元に用意して、一緒に手を動かしてみてください。 一度実際に使うことで動作のイメージがつき、標準仕様を読み解くハードルが下がるかと思います。

なお、本ガイダンスは基本的に以下のページの公式ガイダンスの記載内容をベースに進めていきます。
https://opensource.contentauthenticity.org/docs/c2patool/

※C2PAの各用語に関しては本章ではわかりやすさのために概要の説明までとしています。詳細は次章で説明します。

筆者の構築環境

システム バージョン
OS macOS Ventura 13.1
Rust 1.74.0
c2patool 0.7.0

※Windowsでも軽く動作を確認済みですので、Windowsをご使用の方も同様の手順にて確認いただけるかと思います。是非試してみてください。

Step1. 必要ソフトウェアのインストール

最初にc2patoolの動作に必要なソフトウェアをインストールしていきましょう。
※c2patoolを動作する為に必要なソフトウェアを記載していますが、あくまでご自身の判断でインストールお願いします。

Rust

以下の公式サイトのインストールページから、手順に従いインストールしてください。
https://www.rust-lang.org/ja/tools/install

c2patool

Rustの環境構築が完了した状態でターミナルを開き、以下コマンドを実行してください。

cargo install c2patool

エラーの発生が無く終了すれば、c2patoolのインストールは完了です。*6

Step2. マニフェスト定義ファイルの作成

次にマニフェスト定義ファイルと呼ばれる来歴情報の中身を記載するJSONファイルを作成します。 急にマニフェストという用語が出てきましたが、一旦マニフェスト＝来歴情報の理解で問題ありません。

ここでは公式から提供されているサンプルファイルを使用します。 https://github.com/contentauth/c2patool/blob/main/sample/test.json

{
    {
    "alg": "es256",
    "private_key": "es256_private.key",
    "sign_cert": "es256_certs.pem",
    "ta_url": "http://timestamp.digicert.com",

    "claim_generator": "TestApp",
    "title": "My Title",
    "assertions": [
        {
            "label": "stds.schema-org.CreativeWork",
            "data": {
                "@context": "https://schema.org",
                "@type": "CreativeWork",
                "author": [
                    {
                        "@type": "Person",
                        "name": "Joe Bloggs"
                    }
                ]
            }
        },
        {
            "label": "c2pa.actions",
            "data": {
                "actions": [
                    {
                        "action": "c2pa.opened"
                    }
                ],
                "metadata": {
                    "reviewRatings": [
                        {
                            "code": "c2pa.unknown",
                            "explanation": "Something untracked happened",
                            "value": 4
                        }
                    ]
                }
            }
        },
        {
            "label": "my.assertion",
            "data": {
                "any_tag": "whatever I want"
            }
        }
    ]
　}
}

マニフェスト定義ファイルを使って、来歴情報を埋め込みする前にJSONファイルの内容についてもピックアップして確認していきます。

Key 解説
alg 使用する署名アルゴリズムを指定します。
private_key JSONファイルから見た署名に使う秘密鍵の相対ファイルパスを記載します。
sign_cert JSONファイルから見た署名に使う証明書の相対ファイルパスを記載します。
ta_url タイムスタンプを取得する為のurlを記載します。
claim_generator 署名するシステム名を記載します。
title C2PA検証サイト上での表示名を記載します。
assertions 来歴情報としてユーザが埋め込みたい情報を記載するフィールドです。（詳細は3章で説明）
C2PA仕様で定義済みのstandard assertionsやユーザ独自で定義するcustom assertionsが存在します。
Standard assertionsにない情報を記載したい場合は、上記のmy.assertionのように自らラベルを追加し、独自の情報を埋め込んできます。

今回はc2patoolに内包されている証明書と秘密鍵を使用したいのでtest.jsonから以下の記載を消してください。
こうする事でデフォルトで設定されているファイルパス上の証明書と秘密鍵が使用されるようになります。

"private_key": "es256_private.key"  
"sign_cert": "es256_certs.pem"

Step3. 写真への来歴情報の埋め込み

では実際に写真に来歴情報を埋め込んでみましょう。
ターミナルから以下コマンドを実行してください。

c2patool 写真のファイルパス -m マニフェスト定義ファイルのファイルパス -o 来歴情報を埋め込んだ写真のファイル名

これで来歴情報の埋め込みは完了です。

Tips
来歴情報を写真に埋め込む以外にも以下オプションを使用する事により別の対応も可能です。
--remote/-r :来歴情報をサーバに配置
--sidecar/-s:来歴情報を外部ファイルに出力
詳細はUsageに記載されていますので必要に応じて確認してください。

Step4. 来歴情報の検証

写真に来歴情報が埋め込まれているか実際に確認してみます

C2PAのサイトで確認する場合

１章でも紹介したC2PAのサイトを利用して確認してみましょう 以下サイトにアクセスしてください
https://contentcredentials.org/verify

サイトが表示されたら来歴情報を埋め込んだ写真をサイト上にドラック＆ドロップしてみてください。

来歴情報が埋め込まれている事が確認できましたが、一部表示されていないデータも存在していますね。本サイト上では表示できる情報は決まっているようです。では全て表示したい場合はどうすれば良いでしょうか。

c2patoolで確認する場合

埋め込んだ情報を全て確認したい場合やサイトを使用したくない場合はc2patoolを使用して確認することもできます。 ターミナルを開き以下コマンドを実行してください。

c2patool 来歴情報を埋め込んだ写真のファイルパス

ターミナル上から全ての来歴情報が埋め込まれて事が確認できました。

Step5. 独自の署名を行う（Option）

先ほどはc2patoolに内包された証明書と秘密鍵にて署名を行いました。

実際には各自が各々の証明書と秘密鍵にて署名を行うことになりますので、ここでは証明書と秘密鍵を独自に作成して来歴情報の署名として適用してみましょう。 内容的には少し発展的なものになるとともに、他の箇所とも独立しておりますので、不要な方は読み飛ばしていただいても大丈夫です。

なお、以下の内容を実施するにはOpenSSLが追加で必要になりますので、公式サイト等からダウンロードし、インストールするようお願いします。（筆者はver3.2.0にて動作を確認）
https://www.openssl.org/source/

証明書と秘密鍵の生成

C2PAでは来歴情報を埋め込む際、来歴情報の発行元をデジタル署名により証明しています。 公式のガイダンスではGlobal Signから証明書を購入していましたが、今回は手元で簡単に確認するためOpenSSLを利用して必要な証明書と秘密鍵を準備します。

プライベート認証局の作成

証明書を署名する為にプライベート認証局を作成していきましょう。まず以下のフォルダ構成を任意の場所に作成します。
※openssl.cnfについてはOpenSSLの構成ファイルになります。OpenSSLインストール時に含まれてるファイルをコピーして格納ください。またdemoCAフォルダ配下以外のフォルダ名や構成は自由に変更頂いて問題ございません

Advent_Calendar_2023/
　├ demoCA/
　│　└ certs/
　│　└ crl/
　│　└ newcerts/
　│　└ private/
　└ openssl.cnf

Advent_Calendar_2023フォルダ配下に移動し、その他必要なファイルを作成します。

例：
echo 00 > ./demoCA/serial
echo 00 > ./demoCA/crlnumber
touch ./demoCA/index.txt

Tips（Windows環境で以降の操作がunabele to load numberエラーとなる場合）
PowerShellを使用していないでしょうか？ PowerShellはデフォルトでUTF-16でエンコードされるようですが、OpenSSLでUTF-16は使用できず、ASCIIでエンコードする必要が有ります。 以下のようにOut-Fileコマンドを使用することでASCIIエンコードを指定できるので、こちらを使って上記ファイルを作成してみてください。
例："00" | Out-File -encoding ascii -NoNewline "serial"

demoCAフォルダ配下に移動し以下コマンドを実行します

例：openssl req -new -x509 -newkey rsa:2048 -out cacert.pem -keyout private/cakey.pem -days 365

実行後パスフレーズの設定と確認を要求されるため任意の値を入力しましょう。
その後証明書情報の入力を求められるので以下の値を入力します。
※一部必須ではない値については空欄のままにしています。

Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Advent Calendar 2023
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:Dec24
Email Address []:

これでプライベート認証局の作成は完了です。

Tips（openssl.cnfが見つからないというようなエラーが出る場合 ）
-configオプションを付与しopenssl.cnfのファイルパスを指定すると解消されます。
例：openssl req -new -x509 -newkey rsa:2048 -out cacert.pem -keyout private/cakey.pem -days 365 -config ../openssl.cnf

諸々の説明をかなり省いてしまっていますが、簡単に言うとopenssl.cnfに記載されている[ CA_default ]の定義内容に従って必要ファイル等を用意しています。 興味がある方はopenssl.cnf中身を確認したり、OpenSSLのドキュメント等をご確認ください。

構成ファイルの修正

続いてc2patoolで使用する証明書と秘密鍵を作成していきます。

デフォルトの証明書の設定のままではc2patoolで使用出来ない為、C2PAの仕様に合わせてopenssl.cnfを変更しましょう。
※C2PAで使用出来る証明書の詳細については"15.4.1.1. Certificate Profile"に記載されています。必要に応じてご確認ください。

以下[ usr_cert ]内のコメントアウトされているkeyUsageとextendedKeyUsageを有効にし記載を変更してください。
またkeyUsageとextendedKeyUsageを[ v3_req ]内に追加してください

[ usr_cert ]
keyUsage = critical, nonRepudiation, digitalSignature
extendedKeyUsage = critical, emailProtection

[ v3_req ]
keyUsage = critical, nonRepudiation, digitalSignature
extendedKeyUsage = critical, emailProtection

以上でopenssl.cnfの変更は終わりです。

秘密鍵の作成

次にAdvent_Calendar_2023フォルダ配下にc2patoolフォルダを作成し、c2patoolフォルダ配下に移動します。 その後、秘密鍵を作成します。

例：openssl genrsa -out c2patoolkey.pem 2048

これで秘密鍵c2patoolkey.pemが作成できました。

証明書署名要求の作成

作成した秘密鍵を使用して、証明書署名要求を作成します。

例：openssl req -new -sha256 -key c2patoolkey.pem > c2patoolcsr.pem -config ../openssl.cnf

証明書情報の入力を求められるので以下を入力します。

Country Name (2 letter code) [AU]:JP
State or Province Name (full name) [Some-State]:Tokyo
Locality Name (eg, city) []:
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Advent Calendar 2023
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:Dec24
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

これで証明書署名要求c2patoolcsr.pemが作成できました。

証明書の作成

最後に証明書を作成します。Advent_Calendar_2023フォルダ配下に移動し、以下のコマンドを実行しましょう。

例：openssl ca -in ./c2patool/c2patoolcsr.pem -out c2patoolcert.pem -config ./openssl.cnf

コマンド実行後パスフレーズを確認されるので入力します。 その後署名について確認されるので"y"と入力します。

これで証明書c2patoolcert.pemの作成まで完了しました。

Tips
以下コマンドで証明書の中身を確認出来ます。実際の内容を確認したい場合試してみてください。
例：openssl x509 -inform REM -in 証明書のファイルパス -text

マニフェスト定義ファイルの変更

作成した証明書と秘密鍵が署名に使用されるようtest.jsonの中身を一部以下の通り変更しましょう。

Key 変更前 変更後
alg es256 ps256
private_key es256_private.key test.jsonから見たc2patoolkey.pemの相対ファイルパス
sign_cert es256_certs.pem test.jsonから見たc2patoolcert.pemの相対ファイルパス

algの値については今回はsha256WithRSAEncryptionの署名アルゴリズムを使用しているのでps256としています。
その他使用出来る署名アルゴリズムと記載方法についてはSignature typesに記載されています。

独自署名の適用と確認

変更したtest.jsonファイルを使って、Step3. 写真への来歴情報の埋め込みと同様に来歴情報を写真に埋め込みましょう。

その後、Step4. 来歴情報の検証に記載のいずれかの方法で発行元を確認してみてください。発行元が"C2PA Test Signing Cert"から"Advent Calendar 2023"に変化していれば成功です。

おまけ

クリスマスなのでAdobe FireFlyを使用して、画像もクリスマスっぽく変更してみました。生成AIによって画像が変更された場合もどうなるか見てみましょう。

C2PAのサイトで確認した結果は以下になります。

使用したAIツールにAdobe FireFlyと記載あるのが分かると思います。Adobe FireFlyについては、利用されたタイミングで来歴情報が埋め込まれるようになっています。今はコンテンツが生成されるタイミングで来歴情報が埋め込まれるようなサービスは数少ないですが、C2PAに準拠するサービスが増えていくと私たち自身でコンテンツの信頼性の確認が容易になる将来が待っているかも知れません。

実際に手を動かして来歴情報を埋め込んだことで、C2PAの利用イメージが掴めたと思います。 記載内容以外にもマニフェスト定義ファイルを変更したり、自分で色々試してみるとより理解が深まると思いますので是非いろいろ触ってみてください。 ある程度C2PAがどんなものかイメージができた所で、次章ではいよいよ標準仕様を一緒に読み解いてみましょう。

第3章 C2PAを読み解いてみた

それではC2PAの技術仕様を読み進めていきましょう。 記事執筆時点（2023年12月上旬）で最新版のv1.4に基づいて見ていきます。 c2pa.org

なお、以下の解説では関連しているC2PA技術仕様本編へのリンクを多数含みますが、原文に当たる際は、最初のうちは細かい具体の部分は読み飛ばし、まずは大枠の感覚をつかむことを優先すると理解しやすくなるかと思います。*7

構成要素の概要

まずはC2PAの技術仕様で中心的な要素を把握していきましょう。

とはいえ、仕様書をいきなり前から眺めてもなかなか理解しきれない部分も多いと思いますので、まずはC2PAの目的を振り返って、必要そうな要素を整理してみましょう。 C2PAの公式HPのトップには、以下の記載があります。

The Coalition for Content Provenance and Authenticity (C2PA) addresses the prevalence of misleading information online through the development of technical standards for certifying the source and history (or provenance) of media content.

"through"以下の手法にかかわる部分がまさにC2PAの技術仕様でやりたいことになります。 つまり、C2PAを通じて、コンテンツがなにものか、どのように作成・生成されたか、またどういった加工・編集等の操作をこれまでに受けてきたかといった来歴情報を保証したいのです。

そうすると、まずコンテンツの来歴情報を示す要素は必ず必要になりそうですね。 また、そうした来歴情報があちこちバラバラに記載されていては後から読み出すことが難しくなってしまうので、来歴情報のありかをまとめた一覧のようなものも必要になりそうです。 さらに、こうした来歴情報を保証したいとなると、改ざんされていないことを証明するため、デジタル署名も必要そうです。

まとめると、以下の3要素は少なくとも必要になりそうだということが見えてきました。

  1. コンテンツの来歴情報
  2. 来歴情報のありかをまとめた一覧
  3. デジタル署名

これらの要素はC2PAの技術仕様ではどのように表現されているのでしょうか？実は、それぞれ以下の名称の要素として定義されています。

  1. Assertion(s)
  2. Claim（厳密には来歴情報のありか一覧をデジタル署名したもの）
  3. Claim Signature（厳密にはデジタル署名に使った証明書）

また、これらの3要素をまとめた構造体をC2PA Manifestと呼んでいます。*8
このC2PA Manifestこそが、C2PAにおける「コンテンツの来歴情報」を管理するための最小単位です。

https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_technical_overview https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_technical_overview

なお、詳細は後述しますが、複数のC2PA Manifestを格納するための構造体として、C2PA Manifest Storeという概念も定義されており、各コンテンツに対してはこのC2PA Manifest Storeが1対1で対応するようになっています。

これにより、例えばポスター作成などで複数の画像を組み合わせて新しい画像を作成するといった場合も、組み合わせ元の画像の来歴情報も含めて記録が可能になります。

例

ざっくりとC2PAの構成要素を把握できたところで、少し例を考えてみましょう。

例えばC2PA対応カメラで写真を撮影する場合、まずは通常通りに画像を作成します。Exifなどの画像のメタデータ（具体的にはカメラ自体の情報やレンズの情報、色空間、位置情報や撮影時刻など）も通常通りに一緒に作成します。その後、この撮影された画像に対して、「画像を生成したというアクション」や「画像が持っているメタデータ」などをAssertionとして記録し、Claimとして一覧化したうえで署名することでManifestを作ることになります。

さらに、撮影画像を後でC2PA対応の画像編集ソフトで編集すれば、「どこを切り抜いた」「どういったフィルタをかけた」「ほかにどんな素材を使った」といった加工情報をAssertionとして記録したManifestを編集後の画像に付与することになります。

このように、コンテンツに関する操作が行われたタイミングで、操作を記録したAssertionを含むManifestを作成し付与していくことで、コンテンツの来歴を記録していくことになります。

各構成要素の詳細と相互関係

ここまででC2PAにおいて中心的な要素の概要・位置づけを押さえましたので、それぞれをもう少し詳しく見てみましょう。

Assertion

Assetについて

始めに少し余談ですが、これまで「コンテンツ」と呼んでいるものは、もう少し厳密には仕様上はAssetと表現されているもので、大きく分けてメタデータを表すAsset metadataと、コンテンツそのものを指すDigital contentからなるものとして定義されていますので、以降はこれらの用語を用いて説明していきたいと思います。

Assertionの定義と例

さて、AssertionはAssetの来歴情報を表現するものでした。

1つのAssertionは情報の種類を示すラベルと具体的な情報を表すデータのペアで表現されます。 例えば、Assetに対する加工・編集等の操作を表すラベルc2pa.actionsと、実際に行われた操作に関する情報、といった形になります。

ラベルはこの例のようにアルファベットから始まる大小英数字をピリオドでつないだ形式で表現します。 c2pa.から始まるラベルはC2PA Standard AssertionとしてC2PAの仕様で規定されているAssertionで使用するものになります。 具体的には"19.5. Standard C2PA Assertion Summary"に一覧表があるので参考にするとイメージがわくかと思います。

一方、各ラベルに対応する具体的なデータはそれぞれのラベルごとにフォーマットが決まっているので、各Assertionの定義を確認するようにしましょう。 なお、仕様中で出てくるStandard Assertions以外にも独自でAssertionを定義することも可能です。（すでに2章でmy.assertionというラベルを持ったAssertionが定義できることを見ましたね。）

先ほどのStandard Assertionsの一部を抜粋して紹介すると、以下のようなものがあります。

  • Assetがどのように生成されたか（c2pa.metadataの一部）
    • カメラで撮った画像なら、カメラのメーカーやモデル名、レンズ、解像度、シャッター速度、ISO感度などのExif情報相当など
  • Assetに対してどういった加工・編集が施されたか（c2pa.actions）
    • 画像であれば、色補正や切り抜きなど
  • Assetのサムネイルや構成要素（c2pa.thumbnail.claim, c2pa.thumbnail.ingredient, c2pa.ingredient）
    • ポスター作成などで複数の画像を組み合わせて新しい画像を作成するといった場合に組み合わせた元画像をIngredients、組み合わせた結果の画像をComposed assetと仕様内では表現しています。
  • どのAssetに紐づく情報であるか
Content Binding

先の例の中でも特に最後に挙げたAssertionは、この来歴情報がどのAssetに対するものであるかを表現するため、非常に重要です。 この「Assetとの紐づけ」のことを仕様上では(Content) Bindingと呼んでいます。

Bindingを行うにはAssetを要約しつつも一意に他と区別できるような情報があればよいので、AssetのHash値をAssertionとして保持することにより実現できます。 Hash値の取り方は複数存在するため、その方法に応じてc2pa.hash.data, c2pa.hash.bmff.v2, c2pa.hash.boxes, c2pa.hash.collection.dataといったラベルを使い分けてBindingのAssertionを表現します。 なお、C2PAにおいて認められているHash値の計算アルゴリズムは（Bindingに限らず）決まっており、"14.1. Hashing"で規定されているので、実装する際には気を付けましょう。

ここでは詳細は割愛しますが、C2PAでは上述のHash値による方法以外のBindingもサポートしており、それらはSoft Bindingと呼ばれ、Hash値による方法であるHard Bindingと区別されています。

なお、特定のAssetに着目しているとき、そのAssetにBindingにより紐づくManifestのことを特にActive Manifestと強調して呼ぶことがあるので、認識しておきましょう。*9

Credential

Assertionの中にはAssetの作成者（個人だけでなくグループや組織も含む）など、何かしらの主体を記録することができるものもあります。 もちろん、単に名前などを記載するのみでもよいのですが、他にも主体に関する属性情報があったり、更にはそうした属性情報と主体との結びつきを証明するような情報、すなわち証明書などのCredentialが記録されているとAssertionの信頼性を推し量るうえで望ましそうです。 こうしたCredentialはこれまではアカウントを発行しているドコモなどの各サービス事業者が管理しているものが典型的でしたが、最近ではこうした第三者の管理を受けずに個人情報たる自身の属性情報は自分で管理するという考えが広がり、Verifiable Credential (VC)と呼ばれる、内容の検証がオンラインで可能な自己主権型のCredentialが普及しつつあります。

C2PAにおいても、Assertionの一部としてVCを記録できるようになっており、特定のサービス事業者に依存せず、Assetに関連する主体の情報を盛り込めるようになっています。*10

VCはそれ自体で奥が深いので、ここでは詳細は割愛しますが、気になる方はぜひ"9. W3C Verifiable Credentials"の章も確認してみてください。

なお、C2PAにおいてこのVCは、あくまでAssertionに含まれる主体情報を補強するために使われていることを認識しておきましょう。 後ほど詳述するClaimの署名・検証などとは関係がないため注意が必要です。

Assertionの記述方法

Assertionの章の最後に、どのようにAssertionを記述するのかについて触れておきたいと思います。

Assetは複数の来歴情報を持ちうるので、Assetには複数のAssertionが紐づく可能性があります。 これらのAssertionをひとまとめにしたものをAssertion Storeと呼びます。

このAssertion StoreとAssertionの記述の仕方については、"12.1.4.3 Assertion Store"の章に記載があります。 記述の仕方については細かい部分になってきますので基本的に割愛させていただきますが、ざっくりというと、Assertion Store全体をJPEG Universal Metadata Box Format (JUMBF)と呼ばれるフォーマットで記述し、その中のデータ部に相当するJUMBF Content Box(es)に各Assertionを格納しています。 この各AssertionもまたJUMBFにより記述することになっており、それぞれをC2PA Assertion boxと呼びます。 各C2PA Assertion boxはそれ自体JUMBFで記述されますが、その中のJUMBF Content Boxにおいて具体的な来歴情報を記載することになります。 各来歴情報の記載フォーマットはそれぞれ決まっているのでそちらに従う形になります。

なお、ここまでAssertionを直接Manifestの一部として書き込むような標準的な場合を想定して記載してきましたが、Manifestの外にAssertionの内容を置いておき、そちらを参照させることも許容されています。 詳しくは"6.6. Embedded vs Externally-Stored Data"をご参照ください。

Claim & Claim Signature

さて、ひと通りAssertionを作成し、Assertion Storeとしてまとめることができれば、基本的にはClaimの作成準備は整っています。*11

Hashed URI

ClaimではAssertionのありかの一覧が必要でした。 では、Assertionのありかはどのように明示すればよいでしょうか？それがHashed URIになります。 これがどんなものかはスキーマの例を見ると簡単に分かるかと思います。

{
  "examples": [
    {
      "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.actions",
      "alg": "sha256",
      "hash": "hoOspQQ1lFTy/4Tp8Epx670E5QW5NwkNR+2b30KFXug="
    }
  ],
}

つまり、Hashed URIは以下の3つのフィールドによって定義されています。

  • url：Assertionのありかを表現するフィールド
  • hash：Assertionの具体的なデータに対するHash値を表すフィールド
  • alg：Hash値の計算アルゴリズムを示すフィールド（オプション）

urlフィールドは参照先が同じManifest Store内か外かで記述フォーマットが変わりますが、Manifest Store外なら単純にHTTP/HTTPSのURL（http/https URI reference）、Manifest Store内ならself#jumbf=から始まる、各階層のラベルをスラッシュで繋げたようなもの（JUMBF URI reference）になっています。 一部ラベルではなくurn:uuid:から始まるUUID URN名前空間によって表記される部分がありますが、これはManifestの指定箇所であり、Manifestを一意に識別するために付与されたUUIDを使ってManifestを指定しています。 "12.1.4.2. Manifest Store"の最終段落にこの指定方法について記載があるので、気になる方はご参照ください。

hashフィールドは、AssetとのHard Bindingを表現する際にHash値を用いたのと同様に、ClaimからAssertionを参照するのにHash値を用いています。 AssertionのHash値算出は、つまりJUMBFで表現されたC2PA Assertion boxのHash値の算出になりますが、その詳細に関しては"8.3.1.3 Hashing JUMBF Boxes"を参照ください。

なお、ここではあくまでClaimにおいてAssertionを参照することを念頭にHashed URIを説明しましたが、Hashed URI自体はClaimでの利用に限らず、Manifestの情報を参照する際全般で用いられますので、他の文脈で出てきても驚かないようにしましょう。

Claimにおいては、assertionsフィールド内で各AssertionのHashed URIの配列を記述することで、Assertionのありかの一覧を実現しています。 以下がその例になります。

{
  "assertions" : [
    {
      "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",
      "hash": b64'U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8='
    },
    {
      "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.thumbnail.claim.jpeg",
      "hash": b64'G5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c='
    },
    {
      "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.claim.ingredient",
      "hash": b64'Yzag4o5jO4xPyfANVtw7ETlbFSWZNfeM78qbSi8Abkk='
    }
  ]
}
デジタル署名

Claimへのデジタル署名を通じて来歴情報の保証を行う必要があります。 基本的には単にデジタル署名を行えばよいのですが、少しだけ注意点があります。

1つは、ClaimからAssertionを参照したのと同様、どのデジタル署名が用いられることを意図しているか、指定する必要があります。 これは"11.3.2.3. Connecting the Signature"に記載のように、Claim内のsignatureフィールドにJUMBF URI reference（Hashed URIのurlフィールドで出てきた形式）で記述することになります。

2つ目の注意点は、Claimの署名に使える証明書にはいくつかの制約がある点です。具体的な制約は細かい内容になってしまうので、"11.3.2.4. Signing a Claim"や"11.3.2.5. Time-stamps"をご参照ください。

以下がClaimに関するここまでの内容を手順としてまとめた図になっています。

https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_single_claim https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_single_claim

ClaimとClaim Signatureの記述方法

最後に、ClaimとClaim Signatureの記述方法も軽く確認しておきましょう。

Claimはc2pa.claim、Claim Signatureはc2pa.signatureのラベルを持ち、どちらもJUMBFにより記述される点、具体のデータはCBOR形式により記述される点は共通しています。（"12.1.4.4. Claim and Claim Signature"）

また、Claimの具体のデータは"11.2. Syntax"に記載の以下のような内容をCBORによりエンコードしたものになっています。（一部省略）

{
  "alg" : "sha256",
  "claim_generator": "Joe's_Photo_Editor/2.0 (Windows_10)",
    "claim_generator_info" : [
        {
            "name": "Joe's Photo Editor",
            "version": "2.0",
            "schema.org.SoftwareApplication.operatingSystem": "Windows 10"
        }
    ],
  "signature" : "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.signature",
  "dc:format": "image/jpeg",
  "assertions" : [
    {
      "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.hash.data",
      "hash": b64'U9Gyz05tmpftkoEYP6XYNsMnUbnS/KcktAg2vv7n1n8='
    },
    {
      "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.thumbnail.claim.jpeg",
      "hash": b64'G5hfJwYeWTlflxOhmfCO9xDAK52aKQ+YbKNhRZeq92c='
    },
    {
      "url": "self#jumbf=c2pa/urn:uuid:F9168C5E-CEB2-4faa-B6BF-329BF39FA1E4/c2pa.assertions/c2pa.claim.ingredient",
      "hash": b64'Yzag4o5jO4xPyfANVtw7ETlbFSWZNfeM78qbSi8Abkk='
    }
  ]
}

上の例で初出のフィールドについては以下のような位置づけです。*12

  • dc:format：Assetのメディアタイプを表現するフィールド
  • claim_generator：カメラや編集ソフトなどClaimを生成したシステム（Claim Generator）をUser-Agent形式で表現するフィールド
  • claim_generator_info：Claim Generatorに関するより詳細な内容（名称、バージョン、アイコン）を表現するフィールド

このほかにも任意のフィールドが複数ありますが、そちらについては細かい内容になってきますので、直接仕様で定義を確認してみてください。

Manifest & Manifest Store

最後にManifestとManifest Storeについて触れますが、これ自体はすでに一部触れてしまっている部分でもあり、非常に単純です。（入れ子のややこしさを除けば……）

つまり、Manifest StoreはJUMBF形式（ラベルはc2pa）で表現され、ManifestsはManifest StoreのJUMBF Content Boxesとして表現されつつ、各Manifest自身はやはりJUMBF形式で表現されることになります。*13

また、Manifestは原則ただ1つのHard Bindingを（そのAssertion内に）持ちます。 ここで"原則"と断ったのは一部例外があり、紐づけ先のAssetには変更がないがManifestのAssertionのみに変更がある場合はAssetとの紐づきに変化がないためHard Bindingが不要です。 このようなManifestをUpdate Manifestと呼び、それと対比して原則通り1つだけHard Bindingを持つManifestをStandard Manifestと呼びます。*14

また、Manifestのラベルはそのタイプに応じて3種類固定のもの（c2ma, c2cm, c2um）が予め定義されていますが、これを使うとManifestを一意に識別できないため、識別する必要がある場合には、すでにHashed URIの箇所で触れたとおり、UUID URN名前空間によって表記する必要があります。

ここまでの内容をまとめると、Manifest Storeの内容は以下の図のように構造化されて記述されることになります。

https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_manifest_store https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_manifest_store

こうして作成したManifest Storeですが、これをどのようにAssetのファイルに埋め込んでいくかは、Assetの形式によって異なります。 完全に各論になってしまうので、ここでは割愛しますが、詳細は"12.3. Embedding manifests into various file formats"をご確認ください。 各Assetフォーマットごとに埋め込み方が記載されています。

なお、Assertionの時と似たように、場合によってはManifestをAssetに埋め込まないことも選択肢になりえます。 このあたりについては"12.4. External Manifests"をご確認ください。

Ingredient Manifests

ここまでですでに単純な場合の来歴情報の構成については、十分に扱ってきました。 ここからは少し複雑なパターンを扱っていきたいと思います。

Assertionの章の例を思い出していただきたいのですが、その中で他の画像（Ingredients）を組み合わせて新しい画像を作るComposed Assetに関するシチュエーションに触れました。 このComposed Assetやもう少し一般化されたDerived Assetのパターンを最後に触れたいと思います。

とはいえ、単にComposed AssetやDerived Assetを考慮すること自体はそこまで複雑ではなく、元のAsset、すなわちIngredientがC2PA Manifestを持つ場合は、当該Assertion（c2pa.ingredient）内でそのC2PA Manifest（Ingredient Manifestと呼ぶ）をHashed URIにより参照したうえで、Ingredient Manifest自体を新しいAssetのManifest Store内に含めるだけでOKです。 図にすると以下の通りとなります。

https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_ingredient_storage https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_ingredient_storage

なお、Manifest StoreにおいてIngredient ManifestsとActive Manifestには配置順序があり、Composed AssetやDerived Assetに対応したActive Manifestが末尾に、組み合わせ元のIngredient Manifestsは先頭から配置されます。

Redaction

さて、Composed AssetやDerived Assetが複雑になる最大の要因は、これから扱うRedactionになります。

RedactionとはIngredient Manifestに含まれるAssertionの一部を削除することです。*15

なぜわざわざRedactionという概念が定義されているかというと、一度付与したAssertionであっても、後から削除したい場合に備えての仕様です。 例えばプライバシー保護の観点で後から来歴情報から作成者などの個人情報を削除したいといったシチュエーションで必要になることが想定できます。*16

とはいえ、やたらめったら削除できるわけではなく、以下の制約が設けられています。

  • Assetに対する操作を表すc2pa.actionsAssertionについてはRedaction不可。
  • Redactionしたassertionは、そのHashed URIをActive manifest側のClaim（redacted_assertionsフィールド）に記載することが必須。
    • またActive Manifest側のAssertionとしてc2pa.redactionのActionを追加することが推奨

1点目は仮にAssetに対する操作を削除できてしまうと、加工された画像にもかかわらず、実際に現実を撮影した画像であるかのように嘘のManifestをいつでも構成できてしまうので、こういった制約が必要そうだと理解できます。
2点目についても、元々Assertionが無かったのか、それとも何らかの理由で特定のAssertionがRedactionされたのかを区別できることで、そのRedactionの適切性を推し量りやすくなるため、やはりこちらの制約についても必要性があると理解できます。

なお、このRedactionはあくまでIngredient ManifestのAssertionに対するものであることに注意してください。 Active Manifestに対するRedactionは許容されていません。

このように、Composed AssetやDerived AssetにおけるRedactionの操作は、Manifest/Claim/Assertionの各レイヤに影響を与える複雑なものになっていますが、まとめると以下の図のようにしてComposed AssetやDerived AssetのManifest Storeを作成することになります。

https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_multiple_claims https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_multiple_claims

各構成要素のまとめ

以上でC2PAにおいて重要な構成要素はひと通り押さえることができました（長かった......）ので、最後に以下の"2.5. Overview"の図で俯瞰しておきましょう。（なお、公式の図の更新が間に合っていない様子で、v1.3基準で章番号が記されているようです。）

https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_overview_2 https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_overview_2

基本的にすでに触れたものばかりかと思います。
Asset metadataとDigital Contentから構成されるAssetに対して、AssertionsとClaim、Claim SignatureからなるManifestをContent bindingにより紐づけています。 紐づけられたManifestはAssetのActive Manifestとして区別されるのでした。 また図中ではActive Manifestに対してIngredient Manifestsが存在しています。

ここで初出の定義にはなりますが、それらIngredient Manifestsを含めたManifest全体をProvenance dataと呼び、Provenance dataとAssetにより実現される、Assetにまつわる様々な履歴の理解を指す概念のことをProvenanceという単語で表現しています。 なお、Originに関してはv1.4では記載が消滅しているので、ここでも説明を省略します。*17

他に構成要素の概観に適した図として、以下もあります。 すでにほとんど等価な内容を説明済みですので、詳しい説明は割愛しますが、各構成要素がそれぞれどのように関係（参照or包含）しているかがわかりやすく図示されているので、それぞれの関係性を思い出したいときに参照するとよいでしょう。

https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_entity_diagram https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_entity_diagram

来歴情報の検証

ここまででどのように来歴情報、つまりManifestsあるいはManifest Storesを構成するかを見てきました。

一方で、こうした来歴情報が付与されたコンテンツを入手した際には、来歴情報が（C2PA的に）有効なものなのかはきちんと確認する必要があるでしょう。
つまり、きちんとC2PA仕様に準拠している「正しい」ものか、また信用に足るものかを検証する必要があります。

以下ではこの検証手順を確認していきます。
大きく分けてManifestの検証とAsset Contentの検証の2観点があるのでそれぞれ順にみていきましょう。

Manifestの検証

先に結論を述べてしまうと、Manifestの検証手順は大まかに以下になります。

  1. Active Manifestの取得
  2. Claimの取得（Active Manifest中）
  3. Claimの検証
    1. Signatureの検証
    2. Time-Stampの検証
    3. Credential Revocation Informationの検証
  4. Assertionの検証

それぞれもう少し詳しく見ていきましょう。
なお、いずれもあくまで処理の概要に触れるのみであり、細かいエラー処理などについては触れませんので、そういった情報は上記のリンクより直接技術仕様の各章をご確認ください

1. Active Manifestの取得

まずは検証しようとしているManifestをAssetから取得する必要があります。 特にAssetと直接紐づくActive Manifestを取得できれば、他に紐づくIngredient Manifestなどの情報は芋づる式に特定できるため、Active Manifestの取得に注目します。

Active ManifestはManifest Storeの中で必ず末尾に配置されることが決まっているため、Manifest Storeが見つかれば取得は容易です。

Manifest StoreがAssetに埋め込まれている場合は、すでに触れたように"12.3. Embedding manifests into various file formats"に定義されている、既定の埋め込み箇所を見に行けばすぐにManifest Storeを取得可能です。

一方で、Manifest StoreはAssetに埋め込まないことも許容されていました。 この場合、Assetに対応するManifest Storeの置き場所を確認していくことになります。 置き場所の候補などに関しては"16.2.2. By Reference or URI"をご確認ください。

2. Claimの取得

取得したManifestにおいて、ClaimがAssertionのありかの一覧を成しており、中心的な役割を果たしているので、まずはClaimの検証を行えるよう、Claimを取得しましょう。

Claimの取得は単純で、1.で取得したActive Manifestのなかでc2pa.claimのラベルを持つJUMBF形式の領域を参照すればよいです。

3. Claimの検証

Claimにはデジタル署名が施されていましたので、Claim Signatureの情報と合わせてまずこの署名を検証しましょう。

Signatureの検証

まずClaim Signatureの取得に関しては、Claim内のsignatureフィールドに対応するClaim SignatureのURIが記載されているので、URIの参照先から取得しましょう。

検証にあたっては最初に、取得したClaim Signatureで使用されているCredential*18がきちんと信頼できるものか、要件を満たしているかを確認します。 このあたりのC2PAにおける信頼の考え方に関しては"15. Trust Model"にきちんとまとまっているのでご確認いただければと思いますが、基本的な考え方は通常のPKIと同じような考え方になります。*19

続いて署名自体の検証に入りますが、"14.2. Digital Signatures"で課されている署名の要件を満たしているかを確認したうえで、Hash値の比較といったいわゆるデジタル署名の検証として行われる内容を実施します。

Time-Stamp, Credential Revocation Informationの検証

Claim & Claim Signatureの章では割愛してしまいましたが、実はClaim SignatureにはTime-stampの付与や失効情報の付与が可能です。

もし、これらの情報が付与されている場合、付与されたTime-stamp情報の有効性や署名当時における証明書の有効性なども検証する必要があります。

4. Assertionの検証

ClaimとClaim Signatureに関する検証が完了しましたので、最後にAssertionの検証です。

ここでは、Claimに記載されているAssertionがきちんと意図した場所に格納されているか、またそのHash値が意図したものになっており改ざんを受けていないかを主に確認していますが、そのほかにもStandard / Update ManifestにおけるAssertionの制約やRedactionを行った際のAssertionに対する各種制約等についてもきちんと満たされているか確認します。

以上で、Manifestの検証は完了です。 ここまでの内容を整理した図が以下の図になります。

https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_visual_look_of_validation https://c2pa.org/specifications/specifications/1.4/specs/C2PA_Specification.html#_visual_look_of_validation

なお、図のグレーのboxで示されている通り、Ingredient Manifestが含まれる場合は上記のActive Manifestに関する検証と似た検証をIngredient Manifestに対しても実施することがあります。 詳細は"16.8. Recursively Validating Integrity of Ingredients"をご参照ください。

Asset Contentの検証

Asset Contentに関しても検証を行います。

こちらは非常に単純で、対応するManifestのHard BindingのHash値とAsset ContentのHash値が一致することを確認し、Manifest付与後Asset Contentが改ざんを受けていないことを確認します。 詳細は16.11. Validate the Asset’s Content

Attestation

だいぶ長い道のりになりましたが、ここまででC2PAの技術仕様がどのようにしてデジタルコンテンツの来歴情報に関する技術を規定しているか一通りご理解いただけたのではないかと思います。 ここまでの説明で、すでに十分Assetの来歴情報を適切に保証できるように思えるのではないでしょうか。

しかし、振り返ってみると、来歴情報の信頼性はあくまでClaimのデジタル署名に使用している証明書の発行者（人や組織）の信頼性に基づいていました。 確かにこれだけでも十分有用ではあるものの、この点は少し心許ない気もします。

というのも、同じ人・組織であってもAssetやManifestなどを作成・編集する環境（デバイスやOS、アプリなど）が異なれば、環境が持つ脆弱性次第では信頼性の低い来歴情報が付与されるなどのリスクが想定されるためです。

そこでC2PAではv1.4より、そうしたAssetやManifestなどの処理環境の構成を証明する技術であるAttestationに関する技術仕様が追加されました。*20 c2pa.org

C2PAにおけるAttestationの考慮方式としては大まかには以下の2種類が規定されています。

  • Implicit Attestation
    • 信用できるデバイスのみに搭載され、信用できるアプリケーションからのみ使用可能な署名鍵を用いてClaimを署名する方式
  • Explicit Attestation
    • 最初にAttestationを考慮せずに作成・署名したClaimを、Attestationの対象として指定し、生成された構成証明をAssertionに加え直し、改めてManifestを作成する方式

ここではこれ以上深入りしませんが、このように処理環境の構成証明を含めることでさらに来歴情報の信頼性を高めることができるようになっていますので、気になる方はぜひAttestationの技術仕様にも目を通してみてください。

その他の補足

以上で、C2PAの技術仕様をContent Credentials, Attestationとも一通り概観できました。*21

最後に、ここまでで触れていないものの、参考になりそうな情報をいくつかご紹介してこの章を終えたいと思います。

  • Explainer
    • C2PAの技術仕様の背景となる考え方や"行間"的な部分を補足しているドキュメントです。C2PA Specificationsの中のInformative Documentsの扱いです。現時点でv1.3が最新。
  • Implementation Guidance
    • C2PAの技術仕様を実装する上でのポイントや補足が記載されたガイドラインです。C2PA Specificationsの中のInformative Documentsの扱いです。現時点でv1.3が最新。
  • Guidance for Artificial Intelligence and Machine Learning
    • C2PAの技術仕様をAIや機械学習においてどのように活用しうるかに関する補足です。実装上C2PA Specificationsの中のInformative Documentsの扱いです。現時点でv1.3が最新。
  • 17. User Experience
    • C2PAの技術仕様の17章でUXに関する推奨事項やガイダンスが記載されています。
  • 18. Information security
    • C2PAの技術仕様の18章でセキュリティに関する考慮事項が記載されています。
  • 20. Open Topics
    • C2PAの技術仕様の20章で今後技術仕様で対処予定の項目について記載されています。

第4章 おわりに

生成AIを取り巻く課題を切り口にCAI/C2PAをご紹介しましたが、いかがでしたでしょうか。 本記事がみなさんにとってデジタルコンテンツの真実性・帰属性を考える入口、またCAI/C2PAを理解する一助となれていれば幸いです。

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

最後になりましたが、本記事はNTTドコモ デバイステック開発部の森下・坂井、ドコモ・テクノロジ 携帯事業部の樋口により執筆されました。 私たちはドコモグループにおいてスマホをはじめとするデバイスの基盤技術に関わるアプリケーションの開発などを行っております。 今後もデバイスの基盤技術に関して先進的な取り組みを行っていきますので、ぜひドコモのデバイス関連の取り組みに注目いただければと思います。

*1:本稿の主な内容は電子透かしとの関連性が薄いので詳しくは扱いませんが、Google Deepmindが画像生成AI「Imagen」向けに電子透かし技術SynthIDの導入を2023/8/29に発表し、のちに2023/11/16に同社が発表した音楽生成AI「Lyria」向けにも適用を拡大したほか、Amazonも2023/11/29にAWS re:Invent 2023の中で発表した画像生成AI「Titan」向けに電子透かしを導入していることを明らかにしています。

*2:BBC, CBC Radio Canada, Microsoft, New York Timesによって2019年に設立

*3:https://c2pa.org/about/about/

*4:https://contentauthenticity.org/our-members

*5:https://helpx.adobe.com/photoshop/using/content-credentials.html

*6:Windowsで動作確認した際は"failed to run custom build command for 'openssl-sys'"が発生しました。ベストプラクティスでは無いと思いますが、筆者の場合はStrawberryPerlをインストールすると解消しました。解消にある程度時間を持って行かれたので備忘として記載します。

*7:最初のうちは本技術仕様で参照される様々な外部仕様（エンコード方式やファイルフォーマットなど）にも当たりながら読み進めていましたが、それによって理解が阻害された部分が結構あったので教訓として

*8:C2PA Manifestとほぼ同義で使われることのある用語としてContent Credentialというものがあります。 リンク先の記載の通り、C2PA Manifestが仕様で厳密に定義されているテクニカルタームであるのに対し、Content Credentialはより一般向けの用語であるとともに、複数形のContent Credentialsは単にC2PA Manifestを集めたものだけでなくC2PAという技術全体を指すことがあります。

*9:なぜ強調して呼び分けるニーズがあるかというと、後ほど詳述しますが同一Manifest Store内に紐づけ先Assetの異なる複数のManifestが格納されることがあるためです。

*10:より具体的には、Manifest内にCredential Store (VCStore)という領域を設け、そこにVCの情報を格納します。

*11:ここで「基本的に」としているのは、Hard BindingのHash値を予め確定できないAssetのフォーマットが存在するためです。詳しくは"11.4. Multiple Step Processing"をご参照ください。

*12:algは厳密にはclaimのフィールドとしては触れていませんが、Hashed URIの時とほぼ同様のため省略します。

*13:なんでこんなややこしいことになるのにJUMBFを使ったんだという気持ちになる方もいらっしゃるかもしれませんが、そのあたりの選定理由については"12.1. Use of JUMBF"に記載があるので一度目を通してみてもよいかもしれません。

*14:Hard Bindingを持たないUpdate ManifestにおいてどうやってAssetとの紐づきを表現するのかというと、すぐ後に出てくるIngredient ManifestとしてUpdate前のManifestを持つことで、Ingredient Manifest側のHard BindingでUpdate ManifestとAssetの紐づきを表現することになります。

*15:削除の仕方については、Assertion自体を丸ごとAssertion Storeから削除してしまう方法、具体のデータのみ0に置き換えてしてしまう方法のいずれも許容されています。

*16:ここまで、ClaimをAssertionのありかの一覧として説明してきましたが、実際にはおそらくこのRedactionに対応するためにClaimが定義されています。同じAssertionの一覧ということで単にAssertion Storeに直接デジタル署名を行ってClaimを代替させてしまうと、Redactionを行った途端、Assertion Store全体のHash値が変化し、全Assertionの信頼性を損なってしまいます。Claimに一覧の機能を切り出し、そちらにデジタル署名を施すことで、各Assertion単位でRedactionに対応できるようになっているのです。

*17:気になる方はv1.3の記載を参照ください。

*18:少なくともv1.4時点ではX.509証明書と同義だという認識で大丈夫です。またVCとは関係がない点もお忘れなく。

*19:そのため、C2PAにおける来歴情報の保証とは、あくまでClaimのデジタル署名に使用された証明書の発行者の信頼性に基づく、来歴情報の信頼性の保証になります。

*20:Attestation以外の仕様はまとめてContent Credentialsの技術仕様という括りになっています。

*21:なお、Content Credentials側の技術仕様においては、Compressed ManifestやEndorsementに関しては完全に記載を省きましたので、完全な仕様理解や実装を目指す方は直接ご確認ください。