MD5とは何か:仕組み・脆弱性・実務での注意点と移行戦略

はじめに

MD5は、1991年にRonald Rivestが設計したハッシュ関数で、広くファイルの整合性確認やパスワードのハッシュ化などに使われてきました。出力は128ビット(16バイト)のダイジェストであり、かつては軽量で普及していましたが、今日では衝突(collision)攻撃が実用的に可能になったため、安全性の面で重大な問題があります。本稿ではMD5の仕組み、歴史的経緯、既知の脆弱性、実務への影響、移行・対策の具体的方針を詳しく解説します。

MD5の基本仕様とアルゴリズム概要

MD5はメッセージを512ビット(64バイト)ブロックごとに処理する反復ハッシュ関数で、出力は128ビットです。内部状態は4つの32ビットワード(A,B,C,D)からなり、それぞれ初期値は次の通りです:A=0x67452301、B=0xEFCDAB89、C=0x98BADCFE、D=0x10325476。

主な処理の流れは以下の通りです:

  • パディング:メッセージの末尾に'1'ビットと必要な'0'ビットを付加し、最後に64ビットで元のメッセージ長を追加する(MD5はリトルエンディアンで長さを付加)。
  • ブロック処理:512ビットごとに16個の32ビットワードに分割し、4ラウンド、計64ステップの圧縮関数で内部状態を更新。
  • 出力:最終的なA,B,C,Dを組み合わせて128ビットダイジェストを生成。

圧縮関数は非線形関数と定数テーブル(各ステップの加算定数は正弦関数に基づく)を用います。アルゴリズム全体はMerkle–Damgård構造に基づき、長さ拡張攻撃(length-extension attack)に対して脆弱性があります。

セキュリティ特性と既知の脆弱性

暗号学的ハッシュ関数に求められる基本特性は以下の3点です:

  • 整合性(collision resistance):異なる入力が同じハッシュになることが難しいこと。
  • 第一原像困難性(preimage resistance):与えられたハッシュから元の入力を見つけることが難しいこと。
  • 第二原像困難性(second-preimage resistance):ある入力に対して同じハッシュを持つ別の入力を見つけることが難しいこと。

MD5に関しては特に衝突耐性が破られています。2004年にWangらによって実用的な衝突生成手法が示され、その後の研究で計算コストはさらに低下しました。さらに、選択プレフィックス衝突(chosen-prefix collision)といったより危険な攻撃も実装され、攻撃者が制御した2つの異なるプレフィックスに対して同じハッシュを作ることが可能になりました(研究者:Marc Stevensら)。

長さ拡張攻撃も重要な問題です。Merkle–Damgård構造のため、ハッシュ値だけが知られていても追加データを付けて正しいハッシュを計算できる状況があり、単純に"secret || message"をハッシュ化するだけの認証機構は危険です。

なお、第一原像および第二原像攻撃に関しては、衝突攻撃ほど実用的な完全破壊は報告されていませんが、理論的・実践的な改善が続いており、将来的なリスクは高いと評価されています。

実際に起きた問題事例

  • 1990年代後半〜2000年代:MD5衝突の理論的破綻が報告され、徐々に実証研究が進展。
  • 2008年:研究者らによる実用的な改ざん可能なX.509証明書(いわゆる"Rogue CA")作成のデモが示され、MD5を用いた証明書発行の危険性が明確に。これにより多くのCAがMD5利用を停止。
  • 2012年:マルウェア作成者がMD5の脆弱性を悪用して署名や証明書の偽造に成功した事例(Flameなど)が公表。

MD5をまだ見かける場面とリスク評価

現場では古いシステムやレガシーなツール、古いドキュメントやAPIでMD5が使われていることがあります。ファイル整合性確認のためだけにローカルで使用する場合のリスクは限定的ですが、次の点では重大な問題になります:

  • セキュアな認証やデジタル署名、TLS/証明書関連の用途。
  • 公開されるコンテンツの整合性検証(攻撃者が改ざん可能)。
  • パスワードハッシュとしての利用(単体では不可)。

特にインターネット経由で不特定者が関与する環境や、証明書・署名に関わる場面ではMD5は使用してはなりません。

現実的な対策と移行方針

MD5を安全に使うことは難しく、以下の移行・対策を推奨します:

  • 新規設計ではMD5を使わない。代替としてSHA-256/512(SHA-2)、SHA-3、BLAKE2/3などを採用。
  • パスワード保存には決して単純なハッシュ(MD5等)を使わず、Argon2、bcrypt、scrypt、PBKDF2などの専用KDFを使用する。
  • 認証コードやMACにはHMAC(例:HMAC-SHA256)を用いる。HMAC-MD5は理論上は耐性があるが推奨されないためHMAC-SHA256等に移行。
  • 既存のMD5ベースの証明書や署名は速やかに廃止・再発行する。CAや証明書発行フローの見直しを行う。
  • APIやプロトコルで"secret || message"をハッシュしている実装は長さ拡張攻撃に脆弱なので、HMACや構造化された認証方式に置換する。

運用におけるチェックポイント

移行・監査時に確認すべき項目:

  • ソースコード、スクリプト、ビルドシステムにMD5ライブラリ呼び出しが残っていないか。
  • 外部から受け取るコンテンツの検証にMD5を使用していないか。
  • CAやTLS証明書のダイジェストアルゴリズムがMD5になっていないか。
  • ログやメタデータにMD5ハッシュを採用している箇所の用途とリスク評価。

簡単なコマンド例

システム上でのMD5確認はよく行われますが、確認するだけなら問題ありません。例:

  • Linux/macOS: md5sum ファイル名
  • OpenSSL: openssl dgst -md5 ファイル名

ただし、外部に公開する整合性チェックやセキュリティ用途にはMD5ではなくSHA-256等を使ってください(例:sha256sum ファイル名)。

まとめと推奨事項

MD5は歴史的に重要であり多くのシステムで長年使われてきましたが、衝突攻撃が実用化されている現在では暗号学的に安全とは見なせません。新規開発ではMD5を使用せず、既存システムも優先度を付けてより安全なハッシュ関数や適切な鍵導出・MAC方式に移行してください。運用面ではMD5の使用箇所を洗い出し、影響度に応じて直ちに対処することが重要です。

参考文献