C2PAカメラは現実との接触に耐えられない

C2PAカメラは現実との接触に耐えられない デビッド・ブキャナン（別名retr0id）著、2026年8月25日 C2PAは、カメラがキャプチャした画像を暗号署名することで、蔓延するAIによる偽造から私たちを救ってくれる奇跡の技術だと聞いたことがあるかもしれません。暗号技術万歳！ 残念ながら、それはうまくいきません。ここでは多くのことが起こっているので、できるだけ早く要点にたどり着こうと思います。 Androidプラットフォーム上のC2PAカメラアプリは、Key AttestationやGoogle Play Integrityに依存して、ユーザーがアプリを改ざんして任意のファイル（デバイスのイメージセンサーからのデータとは対照的に）に署名することを防いでいます。任意のファイルに署名できることは、C2PAの信頼モデルを破壊します。 ルート権限昇格のエクスプロイトは、AndroidのKey AttestationセキュリティモデルとPlay Integrityを破壊します。Androidデバイスは、低コストのハードウェアフォルトインジェクション攻撃によってルート化される可能性があります。既存のデバイスのハードウェアの脆弱性はパッチ適用できません（これについては後で詳しく説明します）。したがって、Androidプラットフォーム上のC2PAは、現実的にパッチ適用できない方法で壊れています。 上記のいずれも「ゼロデイ」ではなく、少なくとも90日前に適切な関係者に報告されています（しかし、頭が正常な人なら誰でも、多くの人がすでにそうしているように、これが起こることを予見できたはずです）。 しかし、待ってください、まだあります！ LLM（大規模言語モデル）のおかげで、ルート権限昇格のエクスプロイトは、Googleがパッチをリリースするよりも速く登場しています。執筆時点では、完全にパッチ適用されたGoogle Pixelデバイス（CVE-2026-43499経由）に対して、インザワイルドでワンクリックルートエクスプロイトが存在します。これらを使用すると、ハードウェア攻撃を必要とせずに、誰でもC2PAの偽造を生成できます。この記事の後半で、その方法を説明します。 ご覧のとおり、ここではAndroidに焦点を当てています。Googleがその理由を説明させてみましょう。 Pixel Cameraアプリは、現在C2PAコンフォーマンスプログラムによって定義されている最高のセキュリティ評価であるアシュアランスレベル2を達成しました。モバイルアプリのアシュアランスレベル2は、現在Androidプラットフォームでのみ可能です。 つまり、私は「最も強力な」実装を攻撃して、ポイントを説明しているのです。 これは、C2PAによれば、Pixel Cameraアプリから直接撮影された、編集されていない実際の写真であるとされているAI生成のゴミ画像です。 （ホバーしてぼかしを解除し、クリックして「検証」してください） そして、これは、インフォボックスに「カメラで撮影された」と記載されているYouTube動画です（ネタバレ：そうではありません）。 編集、2026-08-25T19:12:16Z：Googleは、おそらく手動で、「カメラで撮影された」セクションを動画の説明から削除したようです。それはあまり意味がありません。自分のメディアに署名する方法を学ぶために読み進めてください。また、別のURLに置き換えました。士気が向上するまで偽造は続きます。 ちなみに、Appleも独自のメディアの出所ソリューションに取り組んでいると噂されていますが、まだ存在しません。それが存在したら、私の考えをお知らせします。彼らの垂直統合は、彼らに大きな利点をもたらし、最も容易な攻撃を光学ドメイン（画面の写真を撮るなど）に移行させる可能性があると推測しています。 とにかく、詳細に入りましょう。 ルート権限昇格は、どのように「ハードウェアバックアップ」キーアテステーションを破壊するのでしょうか？ アテステーションは、以下を含む特定の事柄のみを証明します。 ブートローダーがロックされているかどうか。 AVBキーがベンダー固有のものであるかどうか。 デバイスが最新のセキュリティアップデートを実行しているかどうか。 Androidデバイスをルート化する「通常の」方法は、ブートローダーのロックを解除し、変更されたファームウェアイメージをフラッシュすることです。このプロセスでは、デバイスの工場出荷時リセットが強制されます。アテステーションはブートローダーがアンロックされていることをフラグ付けし、GoogleはあなたのデバイスにC2PAキーをプロビジョニングすることを拒否します（そしてNetflixは高解像度コンテンツを提供せず、銀行アプリは機能しませんなど）。 ここまでは順調です（そういうものが好きなら）。 しかし、エクスプロイトによってデバイスをルート化した場合、アテステーションメカニズムは「気づく」信頼できる方法がありません。ブートローダーはロックされたままで、AVBキーは変更されておらず、デバイスは最初に起動したときのセキュリティアップデートを実行したままです。 これで、Googleのサーバーは、侵害されたデバイスに喜んでキーをプロビジョニングします。 C2PAキーは、ルート権限があっても、StrongBox（Titan M2内、新しいPixelデバイスの場合）内でハードウェアセキュリティによって保護されたままです。これにより、攻撃者はキーを引き抜くことができません。 しかし、攻撃者は生のキーマテリアルを必要としません！ ルート権限があれば、StrongBoxにこれらのキーを使用して任意のデータを署名するように依頼し、C2PAの偽造（またはSignalの受信トレイの復号化など、その他の悪いこと）を生成できます。 アテステーションメカニズムの設計の理論は、既知のソフトウェア権限昇格はパッチ適用され、その後、信頼できるパーティ（アテステーションレポートを検証するエンティティ）はユーザーにアップデートをインストールするように要求でき、その後、更新されたデバイスはもはや権限昇格できなくなるということです。 CVE-2026-43499は、タイムリーなパッチが常に利用可能ではないことの証拠ですが、皆に好意的に解釈して、パッチが適用されていないバグの公開エクスプロイトが存在しないと仮定しましょう。 残りの問題は2つあります。 政府からモバイルフォレンジック企業まで、適度に資金力のあるエンティティは、プライベートエクスプロイトの在庫を構築できます（そして実際にそうしています）。これらは、C2PA署名を偽造してほしくないグループです。 ハードウェアエクスプロイトは、パッチレベルに関係なく存在します。 デモ画像と動画にどのように署名したのですか？ 当初はハードウェア攻撃を使用しました。それは私の以前の研究の継続でした：「タバコライターだけでルートを取得できますか？」 ここでは詳細に書きたいと思っていましたが、正直なところ、ソフトウェアのみのエクスプロイトパスが私の雷を奪いました。ソフトウェアエクスプロイトは、存在する場合、はるかに便利なので、完全なハードウェアの詳細は別の機会に保存します。 ハードウェアエクスプロイトは、ほとんどの場合、パッチ適用できないため、急ぐ必要はありません。 今日私の発見を再現したい場合は、Root My Pixelツールをお勧めします。 （注：これは今日のほとんどのPixelデバイスの最新の8月セキュリティアップデートをサポートしていますが、そのサポートを有効にするにはmainからビルドする必要があります。私は個人的にPixel 8aと9aでテストしました。） ルートを取得した後、攻撃の残りは単なる配管作業です。 これを容易にするためのツールを作成しました：keystork。 Keystorkはクライアント/サーバーアーキテクチャを備えており、クライアントコードが任意のアプリになりすましながら、KeyStore APIに対して任意の操作を実行できるようにします。 「サーバー」（keystorkd）はルート化されたデバイスで実行され、クライアントは私が作成したワイヤプロトコルを話すことができるものなら何でも構いません（デフォルトではADB経由で転送されるUnixドメインソケットで転送されます）。 リファレンスクライアントは、対応するCLIインターフェースを持つPythonライブラリですが、理論的にはAndroidアプリもShizukuスタイルでそれに話しかけることができます（ただし、最初に認証/権限レイヤーを構築したいでしょう）。 これは、Pixel Cameraアプリに対する「任意の画像に署名」PoCスクリプトです。 https://gist.github.com/DavidBuchanan314/fa0ffdaaaa31594e6a511118c1cea1e0 ソフトウェアエクスプロイトは（最終的には）パッチ適用される可能性がありますが、ハードウェアエクスプロイトは永遠です。それとも？ ハードウェア攻撃は軽減できますか？ 理論的にははい、実際にはあまり。私の最初の戦略（PTEビットの反転）は、今日のPixelデバイスでも機能します。しかし、Samsungデバイスでは機能しません！ 私はSamsung A07デバイス（安価なため）で初期テストの一部を行いました。エクスプロイトはその時は機能しましたが、セキュリティアップデート後に機能しなくなりました（タイミングは偶然だと思います）。アップデートにより、Samsungの「RKP」緩和策（Remote Key Provisioningと混同しないように）が有効になりました。 Samsungの緩和策は、とりわけ、EL2ハイパーバイザーを使用して特定のメモリ領域に追加の保護を適用します（MicrosoftのHVCIのようなものです）。 私はまだハードウェアエクスプロイトを使用してPTEビットを反転させることができますが、たとえグリッチングによってPTEをユーザー空間にマッピングしたとしても、EL2はそれを上書きすることを許可しません（これは私のエクスプロイトの不可欠な部分でした）。 Samsungの緩和策が存在する場合でも機能するはずの、代替戦略のいくつかの計画がありますが、まだ実装に至っていません。私の代替戦略の1つは、ハードウェアメモリ暗号化が存在する場合でも機能するはずです。それが機能したら、この戦略を「ユニバーサルAndroid h」にパッケージ化したいと思います。