開発者ツール · SHA ハッシュ計算ツール
長さ拡張攻撃: SHA-256(秘密 + メッセージ) が MAC ではない理由
· なぜそれが重要なのか
しゃ-256 暗号化 セキュリティ
メッセージの前にシークレットを追加してハッシュすることは認証のように見えますが、SHA-256 の構造により、攻撃者はシークレットを知らずにメッセージを拡張できます。この投稿では、攻撃と修正について説明します。
自家製のリクエスト署名 — ハッシュ(秘密 + 本文) とそれが安全だと感じる理由
開発者はメッセージ認証が必要ですが、HMAC の知識が不足しているため、シークレットとメッセージを連結し、結果をハッシュします。このアプローチは最初は安全に見えます。出力は固定サイズのフィンガープリントであり、誰かがメッセージを変更すると変更されるはずです。ただし、SHA-256 には長さ拡張と呼ばれるアーキテクチャ上の欠陥があり、攻撃者が秘密を知らなくてもメッセージにデータを追加して有効なダイジェストを計算できます。 ToolAcre SHA ハッシュ計算ツールは、この区別が実際のセキュリティにとって重要であるため、キー認証ではなくプレーン ダイジェストのみを計算します。
ハッシュを再計算できるのはシークレット保持者のみであるため、ハッシュの前にシークレットを付加することは直感的に魅力的です。メッセージが変更されるとハッシュも変更されるため、信頼性の証明のように見えます。 API は、共有シークレットとリクエスト本文を連結し、結果をハッシュしてそのハッシュをリクエストに含めることによってリクエストに署名する場合があります。サーバーは本文を受信し、シークレットのコピーを使用してハッシュを再計算し、それが一致するかどうかを確認します。攻撃者が本文を変更すると、ハッシュは一致しなくなります。開発者はそう考えています。
Merkle-Damgård はその状態を漏洩します - 最終ダイジェストは内部状態であるため、攻撃者は停止したところからハッシュを続けることができます
SHA-256 は、Merkle-Damgård ハッシュ関数と呼ばれるファミリーに属します。これらの関数は、固定サイズのブロックで入力を処理し、前の状態と現在のブロックを取得して新しい状態を出力する圧縮関数を連鎖させます。圧縮関数は内部の唯一の暗号化プリミティブです。チェーン戦略とパディング スキームにより、構築全体が機能します。最終ダイジェストは、最終状態を 16 進数で出力したものです。これは偶然ではありません。出力は内部状態です。ダイジェストを見た人は誰でも、その時点からハッシュを続行するために必要な正確な状態を知ることができます。
メッセージを拡張するために、攻撃者は、観察された Secret +original_message のダイジェストから開始し、それを新しい圧縮関数呼び出しの状態変数として扱います。追加したいデータを追加し、新しいメッセージ全体の長さに合わせて正しくパディングし、ダイジェストを計算します。サーバーが独自のシークレットとハッシュを先頭に追加することによってこの偽造ダイジェストを検証すると、最初のシークレットが吸収された後、計算は攻撃者の計算と同じように進みます。サーバーは同じダイジェストを計算し、攻撃者が秘密をまったく知ることなく、偽造されたメッセージが受け入れられます。
拡張機能の仕組み — パディングと追加データを追加して、より長いメッセージの有効なハッシュを偽造する
アルゴリズムが異なれば、長さの拡張による影響も異なります。 SHA-1 には脆弱性があり、攻撃者は SHA-1 ダイジェストを監視し、メッセージを拡張する可能性があります。 SHA-256 もまったく同じように脆弱です。 SHA-512 も拡張機能攻撃に対して脆弱です。 SHA-384 は、384 ビットに切り捨てられた SHA-512 として構築されているため、長さの拡張に耐えられます。圧縮関数の出力は公開されたダイジェストよりも長いため、攻撃者はハッシュを続行するのに十分な情報を持っていません。 SHA-3 に使用されているスポンジ構造は、内部状態を漏洩しないため耐性があります。
どのアルゴリズムが脆弱であるかを理解するには、圧縮関数のサイズと公開されたダイジェストのサイズについて知っておく必要があります。 SHA-256 は 256 ビットを公開し、圧縮関数の状態も 256 ビットであるため、ダイジェストは状態全体になります。攻撃者は続行するために必要なものをすべて備えています。 SHA-384 は 384 ビットを公開しますが、SHA-384 は SHA-512 の上に構築されているため、基礎となる圧縮関数の状態は 512 ビットになります。ダイジェストでは、512 ビットのうち 384 のみが明らかになり、128 ビットは攻撃者に知られません。これは、この抵抗を提供する SHA-384 の意図的な設計プロパティです。
サポートされている SHA-1、SHA-256、および SHA-512 構造は完全な状態を公開します。 SHA-384 切り捨てにより拡張境界が変更される
共有シークレットを使用してメッセージを認証するための修正は、キー付きハッシュ メッセージ認証コードである HMAC です。 HMAC はシークレットとハッシュを先頭に追加しません。代わりに、内部パッドと外部パッドと呼ばれる特定のパディング スキームを使用して、2 つのネストされたハッシュ操作でシークレットを適用します。構造は HMAC(secret, message) = SHA256(secret_XOR_outer_pad, SHA256(secret_XOR_inner_pad, message)) です。このネストされたアプローチにより、攻撃者が内部ハッシュのダイジェストを持っていたとしても、シークレットなしではハッシュを続行できないため、長さ拡張のギャップが解消されます。
ダイジェスト操作と HMAC 操作を分けておく理由は、2 つを同じ意味で扱うというよくある間違いを避けるためです。両方を実行するツールを通じてハッシュについて学習した開発者は、コードを作成するときにどちらを使用しているかを忘れてしまう可能性があります。ダイジェスト計算を分離しておくと、選択が明確になり、認証には HMAC または署名が必要であるという学習が強化されます。 ToolAcre SHA ハッシュ計算ツールはプレーン ダイジェストに明確にラベルを付けており、ドキュメントでは HMAC がまったく異なる操作であると説明されています。
修正としての HMAC — ギャップを埋めるネストされた構造と、それが標準的な答えである理由
長さ拡張の概念的な例は、よく知られたテスト ベクトル abc で機能します。 ASCII テキスト abc で SHA-256 を計算すると、ダイジェスト ba7816bf8f01cfea414140de5dae2223b00361a396177a9cb410ff61f20015ad が生成されます。このダイジェストがシークレット + abc の結果であり、5 バイトのシークレットでハッシュされ、合計 8 バイトの入力になるとします。 SHA-256 は 64 バイトのブロックで入力を処理するため、最初で唯一のブロックにはメッセージ長とその他のパディング バイトが埋め込まれます。攻撃者はダイジェストを見て、abc で始まり、その後に追加のデータが続くメッセージを偽造しようとします。
ハッシュ内に追加された正確なパディングがわからないため、abc に直接追加することはできません。ただし、完全なパディングされたメッセージが何である必要があるかを計算することはできます。つまり、abc に、64 バイトのブロックへの 8 バイト入力に必要なパディングを加えたものです。次に、追加のデータを追加し、新しい全長のパディングを計算し、観察されたダイジェストを開始状態として扱うことによって組み合わせをハッシュします。結果は有効な SHA-256 ダイジェストであり、サーバーはシークレットを先頭に追加して同じハッシュを計算するため、これを受け入れます。
実用的な例 — ライブターゲットを使用せずに署名付きメッセージを拡張する概念的なウォークスルー
実際のシステムでこの攻撃を防ぐには、開発者はプレーン ハッシュから認証を構築しようとしないでください。 HMAC が標準的な回答であり、ToolAcre SHA ハッシュ計算ツールは、整合性チェック、コンテンツ ハッシュ、および同様の非認証目的でプレーン ダイジェストを計算するためのツールです。プレーンな SHA-256 ダイジェストの安全な使用例には、攻撃者がファイルとダイジェストの両方を制御できないファイル チェックサムが含まれます。コンテンツアドレス指定可能なストレージ。ハッシュが検索キーになります。デジタル署名と署名を組み合わせたもので、署名によって認証が提供されます。
この問題の全範囲には、ブラウザーが提供する他のアルゴリズムが含まれます。 SHA-1 は長さの拡張に対して脆弱であり、それが問題になる前にすでに暗号が破られていました。 ToolAcre 計算ツールは SHA-1 をレガシー専用としてラベル付けし、新しいアプリケーションに適さない原因となった衝突攻撃について説明します。新しいアプリケーションの場合、プレーン ダイジェストには SHA-256 が賢明な選択であり、認証が必要な場合は SHA-256 を備えた HMAC が答えです。 SHA-384 と SHA-512 は両方とも脆弱ですが、SHA-384 は切り捨てによって保護されています。
これで説明されないこと — ToolAcre 計算ツールは、HMAC ではなくプレーン ダイジェストを計算します。この投稿では、その区別がなぜ重要なのかを説明しています
ハッシュ関数のメンタル モデルを構築する場合、メルクル・ダムガード構造と長さの拡張が重要な概念になります。ハッシュ関数は、任意の入力長を処理し、固定の出力を生成する必要があります。これを行う方法は、圧縮関数をブロックごとに連鎖させることであり、最終状態を出力に変換する方法が非常に重要です。最終状態が完全に出力される場合、その出力にはハッシュを続行するために必要なすべての情報が含まれます。最終状態が切り捨てられた場合、その部分は非表示になります。
長さ拡張攻撃について初めて読む開発者にとって、問題は、それが自分たちのユースケースに影響を与えるかどうかをどうやって知るかということです。ハッシュへの入力が公開定数であり、ハッシュが検索キーまたはフィンガープリントとして使用される場合、長さの拡張は無関係です。双方が秘密を共有するときにハッシュを使用してメッセージを認証する場合、長さの拡張は重大な脆弱性であり、HMAC が修正です。 ToolAcre SHA ハッシュ計算ツールはダイジェストとバイト数を表示し、これらが認証メカニズムではなく計算出力であることを明確にします。
要点: 認証には MAC を使用します。ToolAcre SHA ハッシュ計算ツールは整合性ダイジェスト用です。認証には HMAC または署名が必要です
これを運用システムに適用すると、原則は単純です。シークレットが関係する場合は、認証にベア ハッシュを決して使用しないでください。 HMAC は、長さ拡張攻撃ベクトルを完全に遮断する標準構造です。 SHA-256 と SHA-384 は両方とも、正しく使用すれば、本来の目的に対して安全です。 3 つの重要なポイント (Merkle-Damgård はダイジェストで状態を明らかにすること、SHA-384 は切り詰めて状態の一部を隠すこと、HMAC は拡張を防ぐためにネストされた構造を使用すること) を理解することにより、開発者は正しい選択を行うためのツールを得ることができます。
ToolAcre SHA ハッシュ計算ツールは、この教えを体現しています。学習用および正当な非認証使用のためにプレーン ダイジェストを提供し、SHA-1 をレガシーとしてラベル付けし、その操作が別のコンテキストに属するため HMAC を実装しません。開発者がリクエストを認証するために単純なハッシュ計算ツールに手を伸ばすとき、ツールの位置付けとドキュメントは、HMAC と署名を適切なツールとして導くものです。 ToolAcre ツールキットは、ブラウザーの Web 暗号化が直接提供するものに焦点を当て、各プリミティブが適切な境界について説明します。