fingerprint ファイルハッシュ検証ツール star

ソフトウェア配布元がチェックサムを公開する理由

LinuxのISOイメージ、オープンソースのバイナリ、あるいは署名付きインストーラーをダウンロードすると、ダウンロードページには通常、ファイルの横にa94a8fe5ccb19ba61c4c0873d391e987982fbbdのような短い文字列 — チェックサムが記載されています。この文字列は、ファイルのすべてのバイトに対して暗号学的ハッシュ関数を実行した結果です。ファイル内のたった1ビットでも変化すれば、ハッシュはまったく異なるものになります。配布元がこの値を公開しているのは、ファイルをダウンロードしたあとに、あなた自身が同じハッシュ関数を実行し、その結果を公開されている値と比較できるようにするためです。2つの文字列が完全に一致すれば、ディスク上のコピーが配布元がビルドしてアップロードしたバイトとまったく同じであると確信できます — 何も追加されず、何も欠けておらず、何も変更されていません。

チェックサムは、まったく性質の異なる2種類の問題を検出します。1つ目はありふれたものです。ネットワーク接続は転送の途中で切断されることがあり、プロキシは大きなファイルを途中で打ち切ることがあり、ディスクは時折不良セクタに書き込みます — これらのいずれによっても、見た目には完全(サイズは正しく、明らかなエラーもなく開ける)なのに、実際には元のファイルとわずかに異なる破損したバイトを含むファイルが手元に残ることがあり、それだけでインストーラーがクラッシュしたり、後になってデータが静かに壊れたりするのに十分な場合があります。2つ目は悪意によるものです。攻撃者がミラーサーバーを侵害したり、転送中のダウンロードを傍受してマルウェアを仕込んだ改変済みバイナリにすり替えたりした場合、公式で信頼できるページに公開されている値とチェックサムを比較することは、それを実際に検出できる数少ない手段の1つです — ファイル名やファイルサイズを偽装するのは簡単ですが、正確に一致するハッシュを再現するには、まったく同じ元のバイト列を持っている必要があります。

チェックサムは暗号化ではない

用語が混同されがちなので、チェックサムが正確に何を検証しているのかを明確にしておく価値があります。ハッシュ化は一方向で不可逆な処理です。SHA-256はファイルを固定長64文字の16進数文字列に変換しますが、その文字列を元のファイルに戻す処理は存在しません。この一点だけでも、これが暗号化ではないことが分かります — 暗号化は正しい鍵があれば元に戻せるように設計されているのに対し、ハッシュ化はそもそも決して元に戻せないように設計されています。チェックサムが検証するのは完全性であって、機密性ではありません。手元にあるバイト列が、ハッシュ化されたバイト列と同じであることを確認するだけです。ファイルにアクセスできる人は誰でも、その内容をそのまま読むことができます。ハッシュ化は内容を隠すものではまったくありません。ハッシュ化が保証するのは、たとえ意図的であれ偶発的であれ1バイトでも変更されれば、計算したハッシュはもはや公開されている値と一致しなくなり、何かが異なることをすぐに知ることができる、という点です。

この区別はアルゴリズムの選択においても重要です。SHA-1は2017年、GoogleとCWIアムステルダムの研究者が「SHAttered」攻撃を発表したことで、暗号学的な安全性という観点で正式に破られたとされました。これは、同一のSHA-1ハッシュを生成するように意図的に作られた2つの異なるPDFファイルによるもので、十分な動機を持つ攻撃者であれば、正規のファイルと同じチェックサムを持つ悪意あるファイルを作成できることを証明しました。この結果を受けて、SHA-1はTLS証明書、デジタル署名、意図的に衝突を作り出そうとする敵対的な攻撃者への防御など、セキュリティ上重要な用途からは引退することになりました。しかし、このツールが対象とするはるかに一般的なケース — 不安定な接続によってダウンロードが破損していないかを確認する用途 — においては、SHA-1は今でも実用上問題なく機能します。なぜなら、誰もあなたの特定の破損したダウンロードを狙ったハッシュに一致するように意図的に作り込んでいるわけではなく、偶発的な破損はランダムなビット反転であって、意図的な衝突の構築ではないからです。とはいえ、配布元が選択肢を用意している場合、SHA-256は計算コストが余分にかかることなくこの懸念を完全に解消するため、より安全なデフォルトの選択肢と言えます。