データ整合性チェック（ハッシュ/署名/チェックサム）
ファイル配布やバックアップ転送で「壊れていない？」「すり替えられていない？」を手早く確かめるためのメモです。
役割の違い
偶発的な破損を検出することと、信頼する配布元のファイルか確かめることを区別します。検証は書き換え自体を防ぐ機能ではなく、受け入れてよいか判断するための機能です。
比較表
| 手法 | できることと条件 |
|---|---|
| SHA-256などのハッシュ | 内容を期待値と照合する。期待値も攻撃者に差し替えられるなら配布元の証明にならない。 |
| CRC32などのチェックサム | 偶発的な伝送エラーの検出に使う。攻撃者による意図的な変更への対策には使わない。 |
| デジタル署名 | 信頼する鍵と署名方式で、署名対象の変更と署名者を検証する。鍵や署名者の信頼の確認が必要。 |
配布・受信時の基本手順
ダウンロードやバックアップ転送で壊れ・改ざんを最小化する手順です。
取得したファイルを照合する
- 信頼する配布元の正しいドメインで、対象バージョン・OS・ファイル名に対応するSHA-256などの期待値を入手する。HTTPSだけで配布元自体の信頼性が保証されるわけではない。
- 取得したファイル全体を同じアルゴリズムで計算し、期待値と照合する。不一致なら実行せず、対象ファイルや取得経路を確認する。
- 配布元が指定する署名検証手順を実施する。公開鍵の指紋や署名者IDなど、方式に応じた信頼の基準も確認する。「署名が有効」だけで期待する配布元だと判断しない。
- ZIPなどの配布アーカイブは、まずそのアーカイブに対応する期待値で照合する。展開後の各ファイルを検証する場合は、別途信頼できるファイル別一覧と照合する。値を計算するだけでは破損は判定できない。
期待値と検証方法を提供する
- 少なくともSHA-256のハッシュを公開し、MD5/SHA-1のみの掲載は避ける。
- 署名を提供する場合は、検証方法と信頼できる鍵の指紋・署名者IDの確認方法も示す。鍵サーバーで見つけた鍵や複数サイトの一致だけで本人の鍵と断定しない。
- ファイル別・分割別の一覧を提供する場合は、名前・順序・サイズ・アルゴリズムを明確にし、一覧自体も署名などで保護する。各断片のハッシュを並べた値は、ファイル全体のハッシュとは異なる。
ハッシュ選定の目安
セキュリティと性能のバランスを考えます。
選び方
- 配布物の照合ではSHA-256が広く使われる。配布元と同じアルゴリズム・対象バイト列で比較する。
- 署名では採用する署名方式・ライブラリ・運用規格に従う。ハッシュの出力長だけでは、鍵の信頼性や署名方式全体の安全性は決まらない。
- MD5/SHA-1は衝突耐性を必要とする新しい用途に選ばない。互換用に掲載する場合も、SHA-256など安全な照合方式を併せて案内する。
よくある落とし穴
整合性チェックは「値を出すだけ」で終わらない点に注意します。
チェックポイント
- 攻撃者がファイルと期待値の両方を差し替えられるなら、ハッシュ一致だけでは防げない。信頼できる経路の期待値や、信頼する鍵による署名が必要。
- 通常のファイル内容のハッシュには、ファイル名・更新日時・権限ビットは含まれない。改行の変更は内容のバイト列を変える。TARなどのアーカイブはメタデータを内部に格納するため、権限や日時の違いがアーカイブ全体のハッシュに影響する場合がある。
- S3のマルチパートアップロードのETagはファイル全体のMD5ではない。暗号化方式によっても扱いが異なる。専用チェックサムを使う場合も、全体の値かパートからの合成値かを確認して照合する。
- 署名検証は公開鍵の正当性確認（Web of Trustや鍵ピニング）がセット。鍵がすり替われば無意味。
まとめ
期待値・対象バイト列・アルゴリズムをそろえて照合します。署名は信頼する鍵や署名者の確認と組み合わせます。共有鍵を使うHMACも認証の方法ですが、鍵を持つ全員が生成できるため、公開検証できる電子署名とは役割が異なります。有効な署名も、ソフトウェアが無害であることまでは保証しません。