開発者ツール · SHA ハッシュ計算ツール
一致するチェックサムは署名ではない: 完全性と信頼性
· なぜそれが重要なのか
しゃ-256 暗号化 セキュリティ
公開された SHA-256 を使用すると、ユーザーは破損したダウンロードを検出できますが、攻撃者がページを制御している場合、チェックサムも制御します。この投稿では、整合性と信頼性を区別し、署名によって追加されるものについて説明します。
ダウンロードと同じページのチェックサム — 破損からは保護されるが、侵害されたホストからは保護されない理由
ソフトウェア リリースは、ダウンロードと同じページで SHA-256 チェックサムとともに公開されます。ユーザーはアーカイブを取得してハッシュし、結果を公開された値と比較できます。それらが一致する場合、ダウンロードは破損していません。これは完全性の検証であり、実際に有用なチェックです。ただし、攻撃者がリリースをホストしている Web サーバーを侵害すると、バイナリを置き換え、その SHA-256 を再計算し、ページ上のチェックサムを更新する可能性があります。ユーザーがチェックサムを確認すると、攻撃者のマルウェアが発行元からのものであることがわかります。システムは設計どおりに正確に機能しましたが、ユーザーが尋ねていると考えていた質問には答えられませんでした。
これはチェックサム自体の障害ではありません。これは、チェックサムが何を行うか、何を行わないかについての正しい観察です。チェックサムは、データの 2 つのコピーが同一であることを証明します。誰がデータを作成したかを証明するものではありません。これが完全性と信頼性の区別であり、これらを混同することは、リリース検証において最も一般的なセキュリティ上の間違いの 1 つです。多くのシステムが壊れるのは、チェックサムが間違っているからではなく、ユーザーが答えられない質問に答えてくれると信頼しているからです。
ハッシュが証明するもの — 2 つの入力が同じバイトであり、誰がそれらを生成したかについては何もない
整合性はデータ自体の特性です。ファイルとその SHA-256 があり、そのファイルが変更されていない場合、ハッシュは一致します。ハッシュは、すべてのバイトが計算時から変わっていないことを証明します。送信エラー、ディスク障害、またはネットワーク ケーブルのビット反転によってファイルが破損した場合、ハッシュは一致しません。これはチェックサムがうまく機能することです。彼らは事故やランダムな汚職を発見することに優れています。ハッシュを計算できる敵に対しては失敗します。
信頼性は、データの作成者に関する主張の特性です。 「このファイルは私が信頼する発行元からのものですか?」という質問「このファイルは変更されましたか?」という質問とは根本的に異なります。ハッシュは誰でも計算できるため、ハッシュだけでは信頼性の問題に答えることはできません。ファイルを変更する攻撃者は、正規の発行者と同じように簡単に新しいハッシュを計算して投稿できます。ハッシュ化は対称的です。防御側も攻撃側も同じ計算能力を持っています。
信頼できるチャネルの要件 — チェックサムがどこから入手したかによってのみ信頼できる理由
信頼できるチャネルの要件が重要な洞察です。チェックサムは、それが通過したチャネルと同じくらい信頼できます。発行者の公式 CDN からソフトウェア バイナリをダウンロードし、同じサーバーからチェックサムをダウンロードする場合、それらは同じパスをたどることになります。サーバーを侵害するということは、攻撃者が両方を制御することを意味します。チェックサムは、配信中の破損 (破損したファイルは一致しません) に対しては防御しますが、ソースを制御する攻撃者に対しては防御できません。チェックサムとファイルは単一障害点を共有します。
チェックサムが別のサーバー上で別のアクセス制御で個別に公開された場合、より強力な防御が提供されます。プライマリ サイトを侵害する攻撃者は、一致するペアを偽装するために両方の場所を侵害する必要があります。これはより優れていますが、依然として 2 つの独立したコントロール ポイントが安全に保たれていることに依存しています。攻撃者は 1 つではなく 2 つのシステムに侵入する必要があるため、攻撃コストが増加します。しかし、それはまだ信頼性の証明にはなりません。それは、よりコストのかかる攻撃にすぎません。
署名はハッシュを ID にバインドします - 秘密鍵を使用してダイジェストに署名することで信頼性がどのように追加されるか
デジタル署名は、暗号化を使用してデータを ID にバインドすることでこの問題に対処します。発行者はキーペア、つまり秘密に保つ秘密キーと公開キーを生成します。彼らはダイジェストを計算し、そのダイジェストを秘密キーで暗号化することによってファイルに署名します。その結果がサインです。ユーザーは、発行者の公開キーを使用して署名を復号化し、その結果が受信したファイルの計算されたダイジェストと一致することを確認することによって署名を検証します。暗号化により、チェックサムでは達成できない非対称性が生じます。
これが機能する場合、データは発行者が署名したダイジェストと一致し、データの署名に使用された秘密鍵は公開鍵と一致するという 2 つのことが証明されます。これは、攻撃者が作成したというだけではなく、発行者が作成したことを証明します。公開キーは安全なチャネル (通常は信頼できる認証局からの証明書) を介して取得する必要がありますが、公開キーを取得すると、その発行者からの署名を無期限に検証できます。この攻撃には秘密キーを盗む必要がありますが、これは Web サーバーを侵害するよりもはるかに困難です。
実用的な例 — 3 つの脅威シナリオ (破損したミラー、侵害されたページ、悪意のある内部関係者) とそれぞれがキャッチするチェックサムと署名
3 つの脅威シナリオで違いを説明します。シナリオ 1: ダウンロード ミラーがランダム エラーによって破損しました。チェックサムがそれをキャッチします。署名がそれをキャッチします。どちらも攻撃者を倒す必要がないため、どちらも同様に機能します。シナリオ 2: ファイルとチェックサムを置き換える攻撃者によってミラーが侵害されます。チェックサムは保護できません。攻撃者は秘密キーを持っておらず、有効な署名を偽造できないため、署名は引き続き機能します。攻撃者は何でも投稿できますが、署名はそれが発行者からのものではないことを証明します。
シナリオ 3: CDN が侵害されましたが、署名は別のチャネルを通じて公開されました。 CDN のチェックサムは信頼できませんが、整合性チェックはチャネルではなく発行者のキーに暗号的に関連付けられているため、署名の検証は引き続き機能します。攻撃者は署名を偽造する必要がありますが、これには秘密キーが必要です。署名は、サーバーが侵害されても生き残る唯一の検証です。これが、信頼性を確保するために署名が必要な理由です。これらは、チャネルが侵害されても身元を証明できる唯一のツールです。
TLS の役割とその制限 — トランスポート セキュリティは、発行者のサーバーではなく、送信中のダウンロードを保護します。
トランスポート セキュリティは、証明書で指定されたホストへの接続を保護します。これにより、パス上のオブザーバーがダウンロード バイトを置き換えるのを防ぐことができますが、侵害された発行元のオリジンを正直にすることはできません。そのオリジンが変更されたアーカイブと新たに計算されたチェックサムを有効な TLS 経由で提供する場合、両方とも無傷で到着し、攻撃者が制御するコンテンツを記述したままになります。
これが、トランスポート、完全性、および信頼性が別個のレイヤーである理由です。 TLS はチャネルを保護し、ダイジェストはバイトを比較し、署名は検証結果を秘密キーの制御に結び付けます。リリース ワークフローが 3 つすべてを賢明に組み合わせている場合でも、レイヤーが別のレイヤーによって提供されるプロパティを証明するものとして記述されるべきではありません。
これでカバーされないもの — 署名の難しい部分である鍵の配布と信頼ルート
キーの配布は、このダイジェスト計算機が越えることのない厳しい境界です。署名検証者には依然として、本物の公開鍵または証明書チェーンと、ローテーション、失効、および許容可能なアルゴリズムのポリシーが必要です。信頼できないキーでの数学的に有効な署名は、その信頼できないキーの所有者がバイトに署名したことのみを証明します。
したがって、実行されたシナリオは、信頼できるキーがすでに利用可能な場所で停止します。証明書の固定、公開鍵インフラストラクチャ、または鍵リリースの儀式については規定していません。これらの展開の選択肢には、独自に検討された設計が必要です。 ToolAcre は、ID の検証に使用されるトラスト ルートではなく、署名できるプレーン ダイジェストを提供します。
要点: 整合性のチェックサム、信頼性の署名 — ToolAcre SHA ハッシュ計算ツールがダイジェストを計算します。誰が公開したかを確認するのは別のステップです
ToolAcre SHA ハッシュ計算ツールは、この検証の整合性側を計算します。これを使用して、ダウンロードしたファイルをハッシュし、公開された値と照合します。それらが一致する場合、ダウンロードは破損していません。しかし、攻撃者が両方を書き換えたためにそれらが一致した場合、整合性検証だけでは検出できません。このツールはこの制限について誠実であり、信頼性を検証するとは主張しません。整合性だけを考えれば、チェックサムは高速で良好です。本物であるためには署名が必要です。 TLS は、ダウンロード自体にトランスポート セキュリティを提供します。サーバーへの接続は暗号化され認証されるため、ネットワーク上の攻撃者が転送中にファイルを変更することはできません。ただし、サーバー自体が侵害された場合、TLS は役に立ちません。侵害されたサーバーは、安全な TLS 接続を介してあらゆるファイルを提供できます。このため、アプリケーション レベルの検証 (チェックサムと署名) がトランスポート セキュリティとは別に重要になります。
ソフトウェア リリースの一般的なパターンは、チェックサムと署名の両方を公開することです。チェックサムは便利です。ユーザーは、1 行のシェル コマンドを使用してそれらをすぐに確認できます。署名は、発行者の公開キーを持っているユーザーに信頼性を提供します。ユーザーは、最初にチェックサムをチェックして迅速な整合性パスを確認し、次に GPG キーリングに保存されているキーと照合して署名を検証して信頼性を確認する場合があります。 2 つのチェックは異なる目的を果たし、多層防御のために階層化できます。署名の難しい部分は、鍵の配布と信頼です。発行者の公開キーが必要であり、それが本当に発行者のものであると信頼する必要があります。これは、認証局が解決しようとしている問題です。認証局は発行者の証明書に署名し、ルート CA 証明書はブラウザとオペレーティング システムにプリロードされています。小規模なプロジェクトの場合は、別の強化された Web サイトまたは公開キー サーバーで GPG キーを公開することもできます。チェックサムは簡単に検証できます。署名には信頼ルートの管理が必要です。複雑さが増すと、信頼性が犠牲になります。