検証は二層で、一層だけ見れば必ず一つ通してしまう

一言でいうと

ハッシュは合っているのに署名が壊れる場合と、署名は合っているのにハッシュがずれる場合は、原因も対応もまったく違い、その2つを区別するには、2つの層を両方見なければなりません。

なぜ必要なのか

「検証を通過した」という言葉は、思ったよりあいまいです。何を通過したのかと尋ねると、たいてい2つのうち1つだけが返ってきます。ハッシュを突き合わせたとか、署名を確認したとか。ところが、この2つは、それぞれ別のものを守ります。

ファイルのハッシュが守るもの: マニフェストが言うそのファイルで合っているか。媒体で移す途中で壊れたか、途中で誰かがファイルを変えたかを捕まえます。

署名が守るもの: そのマニフェストを、私たちが知っている人が作ったか。一覧そのものが変わったかを捕まえます。

1つの層だけを見るとどうなるかが、この記事の要点です。

ファイルのハッシュだけを見る場合。誰かがファイルを変え、見つからないようにマニフェストの該当行まで新しいハッシュに書き換えたとします。ファイルのハッシュの突き合わせは、すべて通過します。書き換えられた一覧を基準に突き合わせたからです。検証は何も捕まえられません。

署名だけを見る場合。マニフェストと署名には手を付けず、ペイロードのファイル1つだけを変えます。署名の検証は通過します。マニフェストがそのままだからです。変えられたファイルは、そのままインストールされます。

そのため、2つの層を両方見る必要があり、順序も決まっています。

どう動くのか

受け取る側の順序はこうです。

1) 번들 전체 해시   매체에서 옮기다 깨졌는가.        틀리면 그 자리에서 끝.
2) 서명 검증        이 목록을 아는 사람이 만들었는가.  틀리면 파일은 볼 것도 없다.
3) 파일별 해시      목록이 말한 그 파일들이 맞는가.

なぜステップ2がステップ3より先なのか。ステップ3を先に行うと、まだ真正性が確認されていないマニフェストを基準に突き合わせることになります。書き換えられた一覧で突き合わせれば、当然すべて合います。順序を変えるだけで、検証が無力になります。これが、このモジュールで最もよく間違える点です。

そして、もう1つあります。公開鍵がバンドルの中に入っていると、署名の検証は何も守れません。バンドルを手にした人が、自分の鍵ペアを作って、ペイロード・マニフェスト・署名・公開鍵を一度にすり替えると、受け取る側は、そのバンドルの中の公開鍵で、そのバンドルの中の署名を検証して、通過させます。署名に意味を持たせるには、信頼の起点の1つは、別の経路で来なければなりません。公開鍵は、バンドルとは別の経路で渡し、受け取る側は、あらかじめ知っているフィンガープリントと突き合わせてから使います。

現場での姿

2つの失敗は、重さが違います。署名は合っているのにファイルのハッシュが1つずれた場合は、転送中の破損の可能性が高いです。もう一度受け取ってみれば、たいてい解決します。反対に、ファイルのハッシュはすべて合っているのに署名が壊れている場合は、一覧がまるごと変わったということなので、受け取り直して終わる問題ではありません。報告の体系が変わります。そのため、持ち込み記録には、「検証失敗」ではなく、どの層で壊れたかを書きます。

秘密鍵の置き場所が、よく事故を起こします。署名の作業ディレクトリをまるごと圧縮して渡したところ、秘密鍵が一緒に出てしまった事故があります。秘密鍵は権限を600にし、バンドルに何が入ったかは、tar -tzfで必ず目で確認します。入れていないと思っていることと、一覧にないことは、別の事実です。

ハッシュファイルとバンドルは、一緒に古くなります。バンドルを束ね直すと、ハッシュが変わります。文書に書いておいた値、ハッシュファイル、実際のバンドル、この3つがいつも同じでなければなりませんが、束ね直した瞬間に3つが分かれます。束ねることとハッシュを取ること、文書の更新を1つの手順にまとめておかなければ、必ずずれます。

次のラボですること

同じバンドルを2つ展開して、それぞれ別の改ざんを入れます。1つはバイナリの1バイトだけを変え、もう1つは同じ改ざんに加えて、マニフェストの該当行まで新しいハッシュに書き換えます。そして、2つとも署名の検証とファイルのハッシュの突き合わせをかけて、どちらがどこで壊れるかを、数字で確認します。2つの結果が正反対に出るのを自分で見ることが、このラボの核心です。