原像攻撃とは？ 10分でわかりやすく解説

UnsplashのallPhoto Bangkokが撮影した写真      

原像攻撃（Preimage Attack）は、与えられたハッシュ値に一致する入力を見つけようとする攻撃です。ハッシュ関数は本来、入力から出力を求める計算は容易でも、出力から入力を逆算することは難しいという前提で使われます。ところが、入力の候補空間が狭い、パスワード保管の設計が弱い、古い方式を使い続けている、といった条件が重なると、攻撃者は一致する入力を探し当てられることがあります。

実務で問題になりやすいのは、ハッシュ関数そのものが直ちに破られる場面より、弱いパスワード、ソルトなしの保存、速すぎるハッシュ、照合APIの無制限な試行といった運用上の不備です。したがって、防御の中心も「強いアルゴリズムを選ぶ」だけでは足りず、用途に応じた保存方式、試行制御、移行計画まで含めて設計する必要があります。

原像攻撃とは何か

原像攻撃とは、あるハッシュ値 h が与えられたとき、それを生成する入力 m を見つけようとする攻撃です。ハッシュ関数の一方向性に対して正面から挑む攻撃だと捉えると整理しやすくなります。

定義

理想的な n ビットのハッシュ関数では、原像を見つけるには概ね 2ⁿ 規模の試行が要ると考えられています。したがって、十分な出力長を持つ現代的なハッシュ関数に対する純粋な原像攻撃は、一般に現実的ではありません。現場でリスクが高くなるのは、入力自体が推測しやすい場合や、ハッシュの使い方が弱い場合です。

仕組み

攻撃の進み方は単純です。まず、攻撃者が目標となるハッシュ値、または照合結果が得られる仕組みを入手します。次に、候補入力を大量に作ってハッシュを計算し、一致するものを探します。候補生成には総当たり、辞書攻撃、ルールベースの変形などが使われます。入力の候補が少ないほど、この探索は現実的になります。

誤解されやすい点

「ハッシュが破られた」という説明は、現場では複数の意味で使われます。パスワードハッシュの照合突破は、数学的な弱点を突くというより、候補を大量に試して一致する入力を見つける動きで成立することが少なくありません。一方、署名や改ざん検知で問題になるのは、原像攻撃だけではなく、第二原像耐性や衝突耐性の不足である場合もあります。ここを混同すると、防御策を選び違えやすくなります。

関連用語との違い

改ざんや署名の話をする場合、焦点が原像攻撃なのか、第二原像攻撃なのか、衝突攻撃なのかを分けた方が安全です。特にデジタル署名では、衝突耐性の弱さが直接問題になります。

原像攻撃が成立しやすい場面

パスワードのハッシュ保管

典型例は、漏えいしたパスワードハッシュに対する探索です。パスワードが短い、単純、使い回されている、あるいは保存時にソルトが付いていない場合、攻撃者は一致する入力を見つけやすくなります。ハッシュ関数の数式上の強さだけでなく、入力の弱さがそのまま突破率へ効く点が厄介です。

短いトークンや推測しやすい識別子のハッシュ化

APIキー、再設定用トークン、識別子などをハッシュ化して保存していても、その値自体が短い、生成規則が推測しやすい、候補数が少ない場合は探索されやすくなります。ハッシュ化は平文保存より望ましい方法ですが、元の値に十分なランダム性と長さがなければ、秘匿手段としては不十分です。

ハッシュだけで正当性を判断している仕組み

改ざん検知を「ハッシュ値が一致するか」だけで行う設計は、攻撃モデルによっては弱くなります。攻撃者がハッシュ値の配布経路や保存先も改ざんできるなら、比較そのものが信用できません。改ざん検知やメッセージ認証では、鍵付きの方式やデジタル署名を使う場面が多くなります。

危険性をどう捉えるべきか

認証突破

一致する入力が見つかれば、攻撃者は正規ユーザーとしてログインできる可能性があります。管理者アカウントや特権系アカウントで起きた場合、設定変更、ログ消去、横展開へ進む足場になります。この種の被害は、ハッシュ関数の理論上の破綻よりも、保存方式や認証周辺の設計不備で起きることが多くあります。

機密情報の再現

機密情報をハッシュ化して保存していても、元データの候補が少なければ探索される余地があります。社員番号、短いPIN、形式が固定されたコードのように候補空間が狭いデータは、ハッシュ化だけで秘匿したつもりにならない方が安全です。

改ざん・署名では別の性質も効く

改ざんや署名の話になると、原像攻撃だけを見ても足りません。デジタル署名で特に重いのは衝突耐性で、既知データを別内容へすり替える論点では第二原像耐性も関わります。したがって、ハッシュ関連リスクと一括りにせず、どの性質が前提になっている設計なのかを見分ける必要があります。

防御策

一般用途では現代的なハッシュ関数を選ぶ

一般的なハッシュ用途では、SHA-2 や SHA-3 のような現代的な方式を選び、十分な出力長を確保します。MD5 は衝突耐性が求められる用途で使えず、SHA-1も新しい設計で積極的に選ぶ段階ではありません。旧方式が残っている場合は、用途を棚卸ししたうえで移行計画を作った方が安全です。

パスワード保管は専用方式で行う

パスワード保管では、一般用途の高速なハッシュをそのまま使わず、Argon2idのようにパスワード向けに計算コストを上げられる方式を使います。少なくとも、各利用者ごとに一意なソルトを付け、攻撃者が大量試行しにくい設定にする必要があります。可能なら、ログイン試行の制限、監視、多要素認証も組み合わせた方が突破されにくくなります。

ソルトを正しく使う

ソルトは、同じ入力でも異なるハッシュ値になるよう付加するランダム値です。これにより、事前計算された表を使う攻撃や、同一パスワードの横並び解析が効きにくくなります。特にパスワード保管では、固定ソルトではなく、各レコードごとに異なるソルトを使う必要があります。

レインボーテーブル前提の攻撃を通しにくくする

ソルトがない、または固定されている保存方式では、レインボーテーブル攻撃のような事前計算型の攻撃が通りやすくなります。ソルトを正しく使えば万能というわけではありませんが、同じハッシュ値を横断的に再利用する攻撃には効きます。

改ざん検知には鍵付き方式を使う

メッセージが正しい送信者から来たことや、転送途中で書き換えられていないことを確かめたいなら、単なるハッシュでは足りないことがあります。共有秘密に基づくHMACのような鍵付き方式を使うと、攻撃者が鍵を持たない限り正しい値を作れません。したがって、改ざん検知やメッセージ認証では、ハッシュ単体ではなく、鍵管理を含めた設計で考える必要があります。

移行は段階的に進める

旧方式からの切り替えでは、すべてを一度に置き換えるより、対象を棚卸しして順番に移す方が失敗を避けやすくなります。パスワードなら、認証成功時に新方式へ再計算して更新する方法があります。トークンや照合値なら、新旧を一定期間だけ併存させ、撤去期限を決めておくと後戻りしにくくなります。

実装と運用も見直す

原像攻撃の現実的な脅威は、アルゴリズムだけでは決まりません。照合APIにレート制限がない、ログへ機密値が出る、乱数生成が弱い、旧方式が例外運用として残り続ける、といった実装や運用の弱さでも被害は起きます。したがって、方式選定の後には、依存ライブラリの更新、設定レビュー、監視、撤去計画まで確認する必要があります。

まとめ

原像攻撃は、与えられたハッシュ値に一致する入力を探し出す攻撃です。現代的なハッシュ関数に対する純粋な原像攻撃は一般に難しい一方、実務では、弱い入力、ソルトなしの保存、高速ハッシュの流用、無制限な試行といった運用上の不備からリスクが立ち上がります。

対策では、一般用途とパスワード保管を分けて考える方が安全です。一般用途ではSHA-2やSHA-3を選び、パスワードでは専用の保存方式とソルト、試行制御、多要素認証を組み合わせます。改ざん検知やメッセージ認証では、ハッシュ単体で済ませず、鍵付き方式や署名まで含めて設計した方が誤解が少なくなります。

FAQ