【ITニュース解説】What a failed hash check actually tells you about your file

ハッシュチェックとは、ファイルやデータの完全性を確認するための重要な技術である。これは、ある時点のファイルが、別の時点で本当に同じ状態を保っているか、あるいは改ざんされていないかを検証するために用いられる。特にシステム開発やソフトウェアの配布において、この検証は不可欠な役割を果たす。

ハッシュは、ファイルを構成するすべてのバイト、つまりデジタルデータを入力として、特定の計算アルゴリズム（例えばSHA-256）によって生成される、固定長の短い文字列のことである。この文字列は、そのファイルの「デジタル指紋」のようなもので、入力データが少しでも変われば、生成されるハッシュ値はまったく異なるものになるという特性を持つ。例えば、ファイルのたった1ビットが変更されただけでも、ハッシュ値は大きく変化し、元のハッシュ値とは一致しなくなる。

ハッシュチェックの仕組みはシンプルである。あるファイルのハッシュを計算し、そのハッシュ値を記録しておく。その後、同じファイルを再度チェックしたい時にハッシュを再計算し、記録しておいたハッシュ値と比較する。もし両方のハッシュ値が一致すれば、そのファイルは記録時とまったく同じバイト列を保っていると判断できる。逆に、ハッシュ値が一致しなければ、ファイルに何らかの変更があったと判断される。

ここで重要なのは、ハッシュチェックが実際に何を確認しているかという点である。ハッシュチェックが答えるのは、「これらの正確なバイト列が、過去に記録されたバイト列と一致するか」という問いのみである。つまり、ハッシュはファイルの「内容」が同じであるかや、そこに記録された「情報」が意図せず変更されたかといった、より高レベルな意味合いを直接判断することはできない。ハッシュは純粋にバイト列の同一性だけを認識するのだ。

そのため、ハッシュチェックの結果が不一致になった場合、「ファイルが改ざんされた」と短絡的に結論付けるのは早計である。実際には、ファイルの内容や意図した情報がまったく変わっていなくても、ハッシュ値が変化してしまうケースは頻繁に発生する。これは、多くの一般的なツールが、ファイルの内容とは直接関係のない「メタデータ」をファイルに含めて処理するためである。

具体的な例をいくつか見てみよう。 まず、ファイル圧縮ツールであるgzipは、圧縮ファイルの中に元のファイル名や圧縮を実行した日時などの情報をヘッダーとして記録する。もし、まったく同じ内容のファイルを、異なる日時にそれぞれgzipで圧縮した場合、圧縮日時が異なるために、生成される二つのgzipファイルのバイト列は異なり、結果としてハッシュ値も不一致となる。しかし、ユーザーから見れば、元のファイルの内容は何も変わっていない。 次に、tarアーカイブも同様である。tarは、複数のファイルを一つのアーカイブにまとめる際に、各ファイルの最終更新日時（mtime）や所有者情報、ディレクトリ内のファイル順序などを記録する。同じソースコードを複数のマシンでそれぞれtarアーカイブした場合、これらのメタデータやファイルがディスクから読み取られる順序の違いによって、見た目は同じアーカイブでも、異なるバイト列、そして異なるハッシュ値が生成されることがある。 さらに、バージョン管理システムであるGitも、core.autocrlfのような設定が有効になっていると、WindowsとLinux/macOS間で改行コードを自動変換することがある。この場合、あるマシンでアンカーされたテキストファイルと、別のマシンでチェックアウトされた同じテキストファイルは、エディタ上では同じように見えても、バイト列としては改行コードが異なるため、ハッシュ値は一致しない。 他にも、zipファイルもエントリごとにタイムスタンプを記録するなど、同様の現象は様々なツールで起こり得る。

これらの事例はすべて「改ざん」によるものではなく、ツールの一般的な動作によって引き起こされる。しかし、ハッシュチェックの観点から見れば、これらはすべて「不一致」として検出される。

一方で、ハッシュが一致した場合は非常に強力な証明となる。もしハッシュ値が一致すれば、それはそのファイルがアンカーされた時点と「完全に同じバイト列」であることを意味する。異なる内容のファイルから同じSHA-256ハッシュ値が偶然生成される可能性は、極めて低く、事実上不可能であるように設計されているため、ハッシュが一致した場合はファイルの完全性が保証されると言える。

このように、ハッシュチェックは非対称な特性を持つ。「ハッシュが一致すれば多くを語るが、ハッシュが不一致であっても、その理由についてほとんど何も教えてくれない」のである。不一致の原因が意図しないメタデータの変更なのか、それとも悪意のある改ざんなのかを判断するには、ハッシュチェック以外の情報や詳細な調査が必要となる。

筆者が開発したProofLedgerのようなハッシュアンカーサービスでは、この非対称性から設計上の重要な判断を迫られる。もしサービス側が、圧縮ヘッダーのタイムスタンプを除去したり、アーカイブ内のファイルを常に特定の順序でソートしたりといった「正規化」処理を行ってからハッシュを計算すれば、ユーザーが意図しないハッシュ不一致は減るかもしれない。しかし、その場合、ユーザーはサービス独自の正規化ロジックを知り、同じ処理を自分の環境で再現できなければ、アンカーされたハッシュ値を自分で検証できなくなる。

ProofLedgerは、誰でも標準的なsha256sumのようなツールを使って、サービスに依存せず、公開されたハッシュ値と自分のファイルのハッシュ値を比較できるという検証の独立性を重視した。そのため、ProofLedgerはファイルの内容を解釈せず、純粋に「バイト列そのもののハッシュ」をアンカーする設計を選んだ。この設計の代償は、ファイルが意図せず変更されてハッシュ不一致が起こる可能性への対処が、サービスではなくユーザー側にかかるという点である。

したがって、システム開発者側は、どの「バイト列」を正確な記録としてアンカーし、そのバイト列を将来にわたって再現可能にするかということを、アンカーする前に明確に決定する必要がある。例えば、ソフトウェアのビルド成果物をアンカーする場合、「後で再ビルドすれば同じものが手に入るだろう」と安易に考えてはならない。ビルドプロセスが完全に同じバイト列を出力する「決定論的ビルド」でなければ、たとえ同じソースコードからビルドしても、異なるハッシュ値を持つファイルが生成される可能性があるからである。

この問題を解決するためには、ビルドプロセス自体を工夫する必要がある。例えば、gzip -nオプションを使用して圧縮ヘッダーにタイムスタンプを含めないようにしたり、tarコマンドで--sort=nameや--mtimeオプションを使ってアーカイブ内のファイルの順序や更新日時を固定したりする。こうした対策をビルドプロセスに組み込むことで、毎回同じハッシュ値を持つ成果物を確実に生成できるようになり、真に再現可能な記録をアンカーすることが可能になる。

自分のビルドパイプラインが決定論的であるかを確認する簡単な方法がある。それは、同じソースコードリポジトリから、異なるディレクトリに、同じコマンドを使ってビルドを2回実行し、生成された成果物それぞれのハッシュを比較することである。 例えば、sha256sum build-a/release.tar.gz build-b/release.tar.gzのようにコマンドを実行し、ハッシュ値が一致するかどうかを確認する。もしハッシュが異なれば、生成物が毎回同じではないことを意味する。さらに、zcat build-a/release.tar.gz | sha256sumのように、圧縮を解除した中身のハッシュを比較することで、違いが圧縮ヘッダーにあるのか、それともtarアーカイブの中身にあるのかといった具体的な原因を特定できる。

ハッシュチェックはファイルやデータの完全性を保証する上で極めて強力な技術だが、その仕組みと限界を正しく理解し、開発プロセスにおいて「再現可能なバイト列」を常に意識することが、その真価を最大限に引き出すために不可欠なのである。