ダウンロードを検証するためのファイルチェックサムを提供する意味は何ですか？[複製]

Question

バイナリを提供する多くのプロジェクトは、それらのバイナリのハッシュ（SHA256など）も提供し、.ASCファイルとして、またはバイナリの近くのWebページで直接提供します。これは、TCPプロトコルによって保証されているため、ネットワークによって引き起こされる破損から保護するためのものではありません。

バイナリとハッシュが同じサーバーからダウンロードされるとすると（非常に機密性の高いソフトウェアのbitcoin-core例）、この手法はどのような攻撃シナリオを防ぎますか？

攻撃者がバイナリを改ざんできた場合、なぜ同じ方法でチェックサムを変更できないのでしょうか。攻撃者がMITMを実行し、転送中にダウンロードを改ざんする場合も同様です。

公開鍵/秘密鍵の署名について話しているのではないことに注意してください。攻撃者は署名者の秘密鍵も取得する必要があるため、はるかに安全です。私はダウンロードと一緒にチェックサム/ハッシュを提供することのポイントについて話しているだけです。これはbitcoin-core、秘密鍵でファイルに署名するメカニズムとオーディエンスの両方を備えた、にとってさらに奇妙なことです。

_{私がすることができます想像署名ファイルに（その小さなサイズ与えられた）分ごとにダウンロードしてチェックすることができ、別々の、秘密、監視ボットは完全に別のシステム上でホストされていること、それを改ざん、私はこれが行われるので聞いていません。}

Answer 1

信頼できないチャネルを介してバルクデータを配布できます。

たとえば、USBスティックを渡して、安価なDSL接続を使用して一晩ダウンロードするように依頼し、Webページからチェックサムを取得することができます（高価な従量制接続でラップトップをプルアップしました）。ファイル名を認識し、「ダウンロード済みの大きなファイル」フォルダを調べたら、そこにあるので、USBスティックにコピーします。

あなたはすぐにファイルを手に入れます、そしてあなたはこれが機能するために私を信頼する必要はありません。

Answer 2

ダウンロード可能なファイルをホストしている組織が、ファイルのチェックサムをファイルと一緒に投稿するだけであれば、その通りです。攻撃者がなんとかサーバーを侵害し、ダウンロード可能なファイルを悪意のあるファイルに置き換える場合、攻撃者が元のチェックサムを悪意のあるファイルのチェックサムに置き換えることは簡単です。

これが、ほとんどの組織がさらに一歩進んで、チェックサムのデジタル署名も投稿する理由です。デジタル署名は、組織に関連付けられ、オフラインで保存される秘密署名キーを使用して作成されます。たとえば、https://releases.ubuntu.com/focal/Ubuntuの秘密署名鍵を使用して作成されたUbuntu画像のデジタル署名用。このように、攻撃者がなんとかサーバーを侵害し、ダウンロード可能なファイルを悪意のあるファイルに置き換えたとしても、秘密の署名キーが（うまくいけば）に保存されていないため、攻撃者はファイルの有効な署名を作成できません。サーバー。

Answer 3

ダウンロードしたファイルが破損していないことを確認するために、TCPプロトコルに関して有効なポイントを上げます。「攻撃者のシナリオ」については、これを包括的ステートメントとして使用しますが、提案した方法で署名を改ざんすることはできません。また、バイナリを改ざんすることも、署名を同じにすることもできません。エンドユーザーはファイルをハッシュします。例えば：

ウェブサイトは、インストーラーがのSHA256ハッシュを持っているABCと教えてくれます（ダウンロードリンクのすぐ隣にこれを教えてくれることがよくあります）。そのファイルをダウンロードし、そのSHA256ハッシュを生成すると、ハッシュがであることがわかります123。私は今、インストーラーがサーバーが私に提供していたものと一致しないことを知っています-何らかの理由で。

あなたはこれらすべての背後にある基本的な考え方以上のものを理解しているようですが、提供されているチェックサム/ハッシュの考え方と、それを改ざんできなかった理由（私があなたを誤解していない限り）に固執しています。理論的には、「攻撃者」がWebサイトも侵害し、改ざんされたファイルのハッシュと一致するようにハッシュを変更できれば（123この例に戻ります）、攻撃は成功します。しかし、その速度では、ファイルのインライン改ざんをやめ、独自の悪意のあるバイナリをホストすることもできます。

これはすべて、ソフトウェアの配布でよく使用される署名付きバイナリまたは副署署名を考慮に入れていません。

Answer 4

あなたは、すべてのセキュリティ対策が本質的にある種の攻撃を防ぐと想定しているようです。

これはかなり一般的な誤解です。すべてのセキュリティ対策は、ある種の攻撃の難易度を高めますが、特定の種類の攻撃を本当に不可能にするのはごくわずかです。

攻撃をより困難にすることは本質的にそれが実際に起こる可能性を減らすので、これは重要です。攻撃を行うことは、成功の認識された価値に比べて攻撃者にとって難しすぎるか費用がかかりすぎる場合、攻撃を試みないだけです（または途中で諦めます）。

ダウンロード用のハッシュを提供する場合、次のセキュリティ上の利点があります。

• MitM攻撃は、もう少し複雑になります。手遅れになるまで攻撃が検出されないようにするには、1つだけではなく、2つ（または場合によってはそれ以上）の要求を傍受して変更する必要があります。
• アクセス時にハッシュが実行されない場合、サーバーへの攻撃は複数のファイルを置き換える必要があります。または、2つの完全に異なるネットワークの場所にあるものを置き換える必要がある場合もあります（ハッシュを別の場所に保存するサイトを見たことがあります）この理由でファイル）。

また、次の2つのセキュリティ以外の利点もあります。

• ユーザーは、ダウンロードしたファイルが、攻撃がなかった場合に取得するはずだったものであると確信できます。IOWは、サーバーの保存時のデータ破損やサーバーまたはローカルシステムのメモリ不良などが原因で、ファイルが破損するのを防ぎます。
• これは、中間プロトコルがデータを壊さなかったという妥当な程度の信頼性を提供します。TCPの種類はこれから保護します（ただし、潜在的に1k +バイトの2バイトのチェックサムは多くの潜在的な衝突を引き起こします）が、すべてがTCPを使用するわけではなく、ユーザーはオリジンサーバーからファイルを取得していない可能性があります（Simonを参照）この例に対するリヒターの答え）。

したがって、全体として、発生する可能性のあるいくつかの問題に対して、いくつかの制限されたセキュリティ上の利点といくつかの制限された保険を取得します（ファイルを含む古いusenetとBBの投稿を見ると、これらの投稿にチェックサムが表示されることがあります同じ非セキュリティ上の理由）。対照的に、サーバーオペレーターのコストは基本的にゼロであり、ユーザーに新たな問題を引き起こすことはありません。したがって、セキュリティはそれほど向上しませんが、オーバーヘッドが本質的に存在しないため、実行する価値があると簡単に判断できます。