研究者がAndroidのC2PA写真証明を破る、Googleは修正しない方針

セキュリティ研究者のDavid Buchanan氏は2026年8月25日、ある報告を公開した。Android端末に、 実際のカメラで撮影したかのように偽の写真を署名させられるという内容である。これは、この技術が 存在する唯一の目的そのものを壊す。Googleは調査結果を確認し、7,500ドルのバグ報奨金を支払い、 報告を「Won't fix (infeasible)」、つまり修正は不可能として終了した。

この技術はC2PAと呼ばれる。Coalition for Content Provenance and Authenticityの略である。写真に 署名付きの記録を付け、これをContent Credentialと呼ぶ。その記録には、どの端末やアプリが画像を 生成したかが記される。目的は、本物のカメラ写真と、生成AIモデルが作り出した画像を区別することだ。 Buchanan氏の結論は率直である。「AndroidプラットフォームにおけるC2PAは壊れており、現実的に パッチを当てられない形で壊れている」

GoogleがPixel実装について保証していたこと

Googleは、すべての写真にContent Credentialsを組み込んだ最初の携帯電話シリーズとしてPixel 10を 発表した。その投稿は2025年9月10日付で、Eric Lynch氏とSherif Hanna氏によるものだ。投稿によれば、 Pixel Cameraは「Assurance Level 2、C2PA Conformance Programが現在定義する最高のセキュリティ 評価」に達した。

Googleの投稿は、その評価を支えるハードウェア検証の連鎖を説明している。Android Key Attestationは、 署名鍵が保護されたチップの内部で作られたことを証明する。セキュリティチップTitan M2は、ソフトウェアが 読めない形で鍵を保存する。Remote Key Provisioningは、Googleが「Play Protect Certified version of Android」と呼ぶものにだけ証明書を発行する。チップTensor G5の内部の時計は、ネットワークがなくても 写真に時刻を刻む。Googleはさらに「One-and-Done」と呼ぶ方式を使う。各鍵はちょうど1枚の画像だけを 署名するので、2枚の写真を同じ端末に結び付けられない。

連鎖が切れた場所

Buchanan氏が狙ったのは鍵の保存ではなく、証明の段階である。報告によれば、Android Key Attestationと Google Play Integrityはどちらも突破できる。したがって、侵害された端末でもGoogleのサーバーに 信頼できると思わせ、有効な署名証明書を受け取れる。それを実現した攻撃は2つある。

1つ目はソフトウェアだ。Buchanan氏は、CVE-2026-43499として管理されるワンクリックのroot exploitが 証明の検査を無効化すると報告している。端末は完全に侵害されているのに、信頼できるものとして通る。 2つ目の攻撃はハードウェアのフォールトインジェクションである。端末のDRAMメモリに電磁的な グリッチを与え、選んだ瞬間にチップを誤動作させる。Buchanan氏は、この方法でハードウェア セキュリティモジュールStrongBoxを回避したと報告している。

検証した端末	報告された手法
Pixel 8a	ソフトウェアのroot exploit
Pixel 9a	Root-My-Pixelによるワンクリックroot
Samsung A07	証明の回避
Amazon Fire TV Stick	証明の回避
Meta Quest 3S	証明の回避

ソフトウェアの穴はパッチを当てられる。ハードウェアの穴は、Buchanan氏がこの問題を恒久的だと 言う理由である。メモリチップへのグリッチは、すでに利用者の手元にあるシリコンへの物理攻撃だ。 ソフトウェア更新でそのシリコンは変わらない。それがGoogleの「infeasible」という判断の背景にある 隔たりだ。

失敗がどこにあるかに注意したい。どちらの攻撃も、端末が証明書に値するかを判断する検査そのものを 狙っている。本来は資格がない端末が、正規の鍵を発行してもらえる。その後は何でも署名できる。

開発者にとっての意味

有効なContent Credentialは、現実についての証明ではなく、ソフトウェアについての手掛かりとして 扱うこと。それは署名が証明書チェーンに対して検証されたことを示す。カメラが実在の場面に 向けられていたことは示さない。審査パイプライン、報道用ツール、アップロードを検査する マーケットプレイスを作るなら、証明が通ったからといって画像を自動承認するコードパスを書かない こと。省こうとしていた手動レビューの段階は残すべきだ。

検証ライブラリが実際に何を返すのか確認すること。Assurance Level 2は撮影アプリの適合性に関する 記述であり、場面に関する記述ではない。すべてを真偽値にまとめず、その段階と発行元証明書を自分の ログと画面に出すこと。「Pixel Camera, Assurance Level 2」を見られる審査者はそれを重み付けできる。 緑のチェックだけを見る審査者にはできない。

この非対称性は設計に織り込む価値がある。否定の方向では、C2PAは今も有用だ。証明が欠けている、 または無効であることは、何かが除去、編集、生成されたという本物の信号である。存在して有効な 証明には、示せる内容の上限がいまや判明した。信頼の信号をそれに応じて順位付けし、端末の誠実さに 依存しないものを少なくとも1つ残すこと。たとえばアップロード時に自分で記録した出所である。

最後に、exploitと同じくらい開示の結末を見ておきたい。Googleは報奨金を支払い、修正は断った。 これは否認ではなく誠実な回答である。そしてこの標準の脅威モデルが、破られないハードウェアを 前提にしていたことを教えてくれる。製品ロードマップに「Content Credentialsで検証」が信頼の マイルストーンとして書かれているなら、その行は出荷前に書き直す必要がある。