
2026/10/04 3:52
C2PA を活用して時間をハックする方法
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
C2PA メタデータにおける重大な脆弱性について、David Buchanan 氏は 2026 年 10 月に公開しており、「タイムハッキング」と呼ばれる現象を可能にしています。これにより、画像を未来的なタイムスタンプで検証できるようになり、例えばユーロミリオンの宝くじ結果を実際に発表される数日前に主張することが可能になります。この攻撃は、「spec footgun」として知られる任意のファイル除外機能に基づいており、悪意のある行為者は全体ファイルを空文字列で署名することができます(例:0 バイトのみをハッシュ化しながら、画像データの全体を除外)。これにより、署名検証や TSA の存在証明を回避できます。以前 Dr. Neal Krawertz 氏がこの「Large exclusion range」という欠陥を発見していましたが、現在の検証ツールはこのシナリオが無効であることを検出しません。Google は将来的なデバイスに対して信頼できるオンデバイスタイムスタンプの使用を目指す方針をとっていますが、ユーザーが偽造されたメディアを受容する限り、堅牢な完全性の維持は依然としてリスクに晒されています。偽の存在証明を防ぐため、業界標準は現在のような制限(空ファイル除外による改ざんの検出不能)に依存するのではなく、許可されているバイト範囲を明示的に定義するように進化させる必要があります(例えば PNG の CRC32 チェックサムを適切に扱うなど)。
Text to translate
**: A critical vulnerability in C2PA metadata, published by David Buchanan in October 2026, enables "time-hacking" where images can be verified with future timestamps—such as claiming Euro Millions lottery results days before they occur. This exploit stems from a "spec footgun" allowing arbitrary file exclusions: malicious actors can sign an empty string over the entire file (e.g., hashing 0 bytes while excluding the full image data), bypassing signature checks and TSA proofs of existence. Although Dr. Neal Krawertz previously identified this "Large exclusion range" flaw, current verification tools do not flag this scenario as invalid. While Google's policy for future devices aims to use trusted on-device timestamps, robust integrity remains at risk if users accept forged media. To prevent false proofs of existence, industry standards must evolve to explicitly define allowed byte ranges (such as handling PNG CRC32 checksums) rather than relying on current limitations that fail to detect tampering over empty-file exclusions.
本文
C2PA メタデータの「除外機能」を悪用したハッキング:ロト数字詐欺の再現
映画『カンフー・ファッリ』でタイムマシンを制御する「ハックーマン」が歴史的な過ちを是正する姿は記憶に新しいですが、もし私が時間を改ざんする能力を持っていたとしたら、単に過去の自らの当選ロト数字を記憶に埋め込むだけであります。
幸いなことに、画像に付与されたC2PA メタデータには暗号技術的に偽造不可能なタイムスタンプが含まれており、まさにその行為が証明されています。実際にはロト番号の詐欺は行っておりませんが、以下ではその技術的な背景と脆弱性について解説します。
検証方法と前提条件
C2PA(Content Authenticity)メタデータには通常、以下の 2 つの署名が含まれます。
- クレーム(主張)署名: 「GPS 座標・時刻とともに撮影された写真である」といった主張を記述するもの(主にカメラアプリが付ける)。
- 注: これは実質的に自由に記述可能であり、価値が低い場合があります。
- タイムスタンプ権限者(TSA)署名: RFC 3161 プロトコルを用いて遠隔サーバーに問い合わせ、データが存在した時刻を証明するもの。
- サーバーからの署名により、「指定された時刻以前にデータが存在したこと」が独立した目撃者として証明されます。
※本解説では TSA が仕様通り機能することを前提としています。Google Pixel 10 などでのオンデバイス・トラストドタイムスタンプの実装については、現時点で懐疑的です。
「時間をハッキング中」:仕様の落とし穴(Spec Footgun)
C2PA のメカニズムを安全と仮定した場合、どのようにして時間を「ハッキング」できるでしょうか? これには**「仕様の落とし穴(Spec Footgun)」**と呼ばれるバグカテゴリが関係しています。
- 除外範囲(Exclusions)の機能: C2PA では、署名計算から特定のバイト領域を除外することを許可しています。つまり、署名生成時に無視する領域を設定できる仕組みです。
- 現状の問題: 仕様上は許容されているこの機能が、大規模な除外範囲を意図的に設定することで悪用されています。
- Neal Krawertz 氏(2025 年)も、**「大規模な除外範囲」**により署名計算から極めて大きなバイト範囲を除外し、変更を検知しないという脆弱性を指摘しています。
- 最大級の攻撃: 例外として、ファイルの全領域を除外することで、空文字列に対する有効な署名を生成することも可能です。
時刻ステータス:ハッキング完了
実際に行われた操作の流れは以下の通りです。
- ロト券の写真を撮影し、有効な C2PA 署名と信頼できる TSA タイムスタンプを付与する。
- マニフェストを意図的に設計し、ファイル全体を除外域とする。
- 当選番号が公表された後に Photoshop で画像加工を行っても(質は低いですが)、改ざんを検知する署名が無効化されないようにする。
技術的根拠:ダンプされたマニフェスト例
c2patool -d コマンドを使用して POC ファイルのマニフェストをダンプすると、以下のような構造になっています。
"c2pa.hash.data": { "exclusions": [ { "start": 0, "length": 3995383 } ], "name": "jumbf manifest", "alg": "sha256", "hash": "47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=", "pad": [] },
: 除外開始位置がファイルの先頭。"start": 0
: 除外長がファイル全体の長さ。"length": 3995383- ハッシュ値:
は空文字列の SHA256 ハッシュです。47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
$ openssl sha256 -binary /dev/null | base64 47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
検証ツールの現状
クレーム署名はこの空文字列のハッシュ値に対して付与され、TSA タイムスタンプ署名はそれを対象にします。つまり、本質的には何も署名していません。しかし、現時点で入手可能なすべての C2PA 検証ツールがこれを異常として検知できておらず、正常と誤認されています。
修正可能か?
「ファイル全体を除外」するケースを検出し、それを無効にするのは比較的容易ですが、問題は**「一部だけを除外」**する場合です。
- 難易度: 無害な除外なのか、改ざんによって画像外観が変えられている危険な除外なのかを見極めるのが困難です(例:MD5 ハッシュ衝突の POC)。
- 除外機能が存在する理由: サポートされているすべてのファイル形式に対して適切に定義されていないことが原因です。
- 具体的には、PNG ファイルのように各チャンクに CRC32 チェックサムがある場合、署名を埋め込んだ後に CRC32 の値を正しく保つ必要があります。
- この制約を回避するには、CRC32 を署名の範囲から除外するなどの巧妙な数学的工夫が必要となります。
適切な解決策
単純に機能を削除するのではなく、以下の対応が求められます。
- 明確な定義: サポートされている各ファイル形式に対して、「どの部分ファイルを除外してもよいのか」を厳密かつ慎重に定義する。
- 検証側の厳守: 検証ツールが上記の制約を必ず守らせる仕組みを導入する。