PDFエディターのAES-256はどのように問題を引き起こしているのでしょうか？

PDFエディターはAES-256を使用して暗号化するが、実際のキーは9ビットのエントロピーのみで、ランダム数の生成に問題があるため、暗号化が脆弱になる。

どのPDFソフトウェアがこの問題に影響を受けていますか？

MuPDF、Foxit PDF Reader、OpenPDF、iTextなどのPDFソフトウェアがこの問題に影響を受けています。

修正はどのように進んでいますか？

MuPDFは修正されていますが、他のソフトウェアの修正状況は各社の公式発表をご確認ください。過去に生成されたファイルは修正されても脆弱なままです。

Hot Tracking 029｜9ビットAESキー：PDF暗号化によるランダム数の危機

何が起こったか

PDF文書を暗号化する際、ユーザーのパスワードは文書の内容自体を直接暗号化しません。実際のプロセスは2段階に分かれています。まずソフトウェアは32バイトのファイルキーをランダムに生成し、AESで本文を暗号化します。次に、ユーザーのパスワードから派生したキーを使用してこのファイルキーを暗号化して保存します。文書を開く際には、まずパスワードを使って派生キーを計算し、ファイルキーを復号化し、その後ファイルキーを使って本文を解読する必要があります。この設計自体に問題はなく、多くの文書暗号化ソフトウェアで一般的な方法です。問題は、ファイルキーの品質が暗号化プロセスの基盤であるという点です。もしファイルキーが簡単に推測できるものであれば、AES-256アルゴリズムがどれほど強力であっても無駄になります。

V12の研究者Rick de Jagerの監査では、少なくとも4つの一般的なPDF実装でファイルキーの生成に重大な問題が見つかりました。問題はアルゴリズム名が不十分であることではなく、キーを生成するランダムなソースが暗号学的安全基準を満たしていないことです。

まずMuPDFの旧バージョン(<1.28.5>)を見てみましょう。これはdrand48線形合同生成器を使用し、シードはUnixタイムスタンプで、状態ビット17-24からのみバイトを取ります。状態の低16ビットは0x330eに固定されているため、実際には9ビットのタイムスタンプビットが出力に影響を与えます。512秒の差異内の異なるタイムスタンプが同じキーストリームを生成する可能性があります。最適化されていないPythonの暴力スクリプトを使用すると、約11ミリ秒で全512の可能性を試すことができます。攻撃者が文書を手に入れると、正しいファイルキーをすぐに特定できます。さらに警戒すべきは、MuPDFの/IDフィールドも同じLCGを使用して生成され、明文字で保存されている点です。これは追加の検証基準として機能し、検索空間をさらに絞り込むことができます。

次にFoxit PDF Reader 2026.1.3.36551を見てみましょう。ファイルキーは「現在のタイムスタンプ+32バイトの未初期化バイト+定数」のハッシュから得られます。未初期化バイトとは実際にはゼロ埋めであり、ランダム性がないことになります。V12のRust実装では、32スレッド搭載のRyzen 9 7950Xで毎秒3.70-3.76億のタイムスタンプをテストでき、10年前の文書は約0.84秒で解読できました。Unix epochからの検索も約4.85秒です。Foxitの/Permsブロックには既知の明文字が含まれており、検証は一度のハッシュ加算とAESブロックの復号化だけで済みます。これにより攻撃のコストがさらに低減されます。

OpenPDF 3.0.5とiText 9.7.1は別の問題です。これらはIVGeneratorを使用して、暗号学的安全なランダム数生成器が提供すべき内容をARC4ストリームに置き換えます。ARC4シードはミリ秒級のタイムスタンプとJVMの空きメモリで構成され、/U、/Oに保存されている32バイトのsaltは明文字として存在し、タイムスタンプとメモリ値を逆算するために使用できます。これは、攻撃者がキー空間全体を網羅する必要がなく、文書に公開された情報に基づいてシードを復元するだけで済むことを意味します。

V12では、Foxitの問題コードパターンは2014年5月に公開されたPDFiumの最初のリリースに遡ることが示されており、PDFiumのファイルヘッダーでFoxitに感謝の言葉が記されていることから、このパターンはFoxitから来ており、10年以上前から存在している可能性があります。つまり、この問題は最近導入されたものではなく、PDFエコシステムに長期にわたって存在する歴史的な問題です。さらに心配なのは、これらの実装が多くの下流プロジェクトや商業製品に依存しており、基盤となるモジュールの欠陥がコードの再利用を通じてより広範なシーンに拡散する可能性があることです。

メーカーと修正

問題は関連するメーカーに報告されています。現在の公開進捗は以下の通りです：

MuPDFは修正され、影響を受けたバージョンは1.28.5以前のものです。
Foxit、OpenPDF、iTextの修正状況は各社の公式発表をご確認ください。
V12ではMuPDFとFoxit向けのデジタルエンコーダがリリースされ、この脆弱性が実際に利用可能であることが証明されました。

強調すべき点は、既に生成された暗号化されたPDFファイルは後から保護することはできないということです。たとえ今日ソフトウェアが修正されても、過去にこれらのバージョンで生成されたファイルは依然として破壊可能な状態である可能性があります。これは一般的な脆弱性パッチとは異なります：パッチは新しいファイルが被害を受け続けるのを防ぐだけであり、古いファイルの修復方法は信頼できるツールで再び暗号化または変換することです。

ここにはまた、責任の境界に関する問題も関わっています。PDFの暗号化標準自体は、実装が暗号学的に安全なランダムな数値を使用することを強制しておらず、ランダムな数値生成器がどのようなエントロピーレベルを達成するかも強制していません。標準はアルゴリズムのフレームワークのみを規定しており、具体的な実装はメーカーが決定します。その結果、異なるメーカーの実装の質はまちまちであり、ユーザーはインターフェースや機能名から安全性の違いを判断することが難しいです。文書属性に「AES-256」と記載されている場合、一般的なユーザーはそれが十分に安全だと考えます。この情報の非対称性により、「暗号化」という概念はマーケティング上の表現と実際の効果の間に大きなギャップが生じています。

もう一つの注目すべき点は、この種の問題は通常、従来の脆弱性スキャンプログラムでは発見されないことです。なぜなら、コードは確かにAES-256を呼び出し、キーを標準フォーマットで保存しているが、ランダムな数値のソース自体が安全ではないからです。静的分析やブラックボックステストでは、「キーのエントロピーが不足している」といった意味レベルの欠陥を特定するのは困難であり、専門のセキュリティ監査が必要です。

別の観点から見ると、この公開はコードの再利用によるリスクも明らかにしています。PDFエコシステムには多くの共有実装や参照コードが存在し、ある基礎モジュールがランダムな数値の処理を十分に厳格に行っていない場合、その後に構築されるツールも同じ問題を持つ可能性があります。PDF暗号化で機密情報を保護する企業にとって、これは有名なメーカーや成熟したプロジェクトの名前を単純に信頼することはできず、具体的な実装が現代の暗号学の要求に適合しているかを積極的に確認する必要があることを意味します。

コメント欄の意見

Hacker Newsの高評価コメントはtptacekからで、彼は真の問題は「キーが9ビットだけ」ということではなく、キー自体が暗号学的に安全なランダムな数値ではないという点にあると指摘しています。この区別は非常に重要です：AES-256自体は破られていません。破られているのはキーを生成するランダムなソースです。「9ビットのAESキー」という表現は比喩的なものですが、読者を誤解させやすく、AESアルゴリズムにエラーがあると誤解されがちです。アルゴリズムの名前は理論上の上限を提供するものであり、実装の詳細が実際の下限を決定します。

他の議論は、PDF暗号化エコシステムの歴史的な問題に焦点を当てています。多くの人が、PDF標準は暗号化を複雑に設計しているように見せかけていますが、長期にわたって暗号学的に安全なランダム数の使用を強制していないため、様々な実装上の脆弱性が繰り返し発生していると考えています。PDF暗号化規格は、文書保護のニーズから生まれたものであり、現代の脅威モデルではありません。そのため、多くの曖昧な点が残されています。

他の人々は、一般ユーザーが「AES-256 をサポート」と見て安全だと思いがちですが、実装レベルのランダム数、鍵生成、塩値処理のどのステップでも問題が発生すると、強力なアルゴリズム名は形骸化してしまいます。また、このような脆弱性の暴露は、PDF暗号化を利用する組織に自らの仮定を見直すよう促すものであり、単に特定のメーカーに責任を押し付けるのではないと指摘するコメントもあります。さらに、多くのプロジェクトが暗号化ソリューションを選択する際に「その機能があるか」だけを気にし、実装が監査されているかどうかは気にしないという態度は、それ自体が潜在的なリスクの原因です。

また、一部のコメントでは修正の実際の困難さにも注目しています。PDFファイルが生成された後は、後から保護することはできないため、企業は大量の歴史的文書を再暗号化する必要があり、これはストレージやプロセスにとって追加の負担になります。そのため、この事件の影響はすぐには消えず、数ヶ月またはそれ以上続く可能性があると考える人もいます。また、将来のPDF規格の改訂では、暗号学的に安全なランダム数の使用を強制すべきだと提案する人もいます。そうでなければ、同様の問題が繰り返されるだけです。

一般ユーザーができる3つのこと

「AES-256」というラベルだけを見ないこと。暗号化の安全性は、鍵生成、鍵派生、ランダムなソースなど、多くの要素に依存します。もしツールがアルゴリズム名だけを強調し、実装の詳細について曖昧な説明をしている場合は、警戒する必要があります。本当に重要な内容については、PDF暗号化に加えて独立した暗号化層を追加することを検討してください。例えば、監査済みのファイル暗号化ツールを使用することです。そうすれば、PDF暗号化に実装上の欠陥があっても、文書内容が直接漏洩することはありません。
自分が披露されたバージョンで生成された敏感なPDFを使用しているかどうかを確認すること。もしそうであれば、修正されたバージョンのツールを使用して再暗号化するか、古いファイルのPDFパスワード保護に頼らず、監査済みの他の暗号化方法を使用することをお勧めします。特に注意すべき点は、文書属性を変更したり、保存を再開したりすることは修正とは異なり、ファイルの鍵を再生成し、本文を再暗号化する必要があることです。企業にとっては、このステップは文書バージョン管理とバックアップ戦略と組み合わせることが最善であり、再暗号化の過程で内容が失われたり、権限が制御不能になったりすることを避けるためです。
企業にとっては、PDF暗号化をセキュリティベースラインの検査に組み込むこと。ランダム数の源、鍵派生関数、塩値処理方法に焦点を当てることです。単に「AES-256」にチェックを入れたかどうかだけを見るのではなく。同時に、文書ライフサイクル管理を構築し、どのファイルが既知の問題があるバージョンで生成されたかをマークし、これらのファイルに対して優先的に再暗号化または移行を行います。さらに、セキュリティチームは定期的にPDF処理ツールのセキュリティアナウンスに注目し、暴露が発生したらすぐに影響範囲を評価することができます。

結論

「9ビットAESキー」事件が再び示しているのは、暗号化製品の安全性はアルゴリズムの名前ではなく、実装の詳細によって決まるということです。AES-256は理論上高いセキュリティレベルを提供できますが、32バイトのキーが実際にエントロピーが9ビットしかないランダムなソースから得られている場合、その実際の強度は9ビットに過ぎません。さらに厄介なことに、PDFの暗号化標準は暗号化用の安全なランダムな数値の使用を強制していません。これにより、問題は異なる実装において繰り返し発生します。一般ユーザーにとって最も実用的な行動は、他人のファイルを解読するのではなく、自分が問題のある古いバージョンで機密文書を生成しているかどうかを確認し、より信頼性の高い暗号化方法にタイムリーに移行することです。技術的な話題は過ぎ去りますが、文書のセキュリティは自動的に修正されません。真に責任ある行動は、この暴露をデジタル資産のセキュリティ状態を整理する機会として捉えることです。PDF暗号化によって核心資料を保護している組織にとって、この事件は警鐘です。アルゴリズムがどれほど強力であっても、ランダムな数値の怠慢を救うことはできません。「名前」ではなく「実装」を暗号化製品を評価する核心基準として考えることで、同様のリスクが再発するのを防ぐことができます。

参考文献

V12 Security社ブログ：9ビットAESキーの事件（2026-10-27）
Hacker Newsディスカッションレーン、objectID 50280722（2026-10-28）