暗号学とコンピュータセキュリティにおいて、長さ拡張攻撃は、攻撃者がハッシュ(メッセージ1 )とメッセージ1の長さを使用して、攻撃者が制御するメッセージ2のハッシュ(メッセージ1 ‖ メッセージ2 )を計算できるタイプの攻撃であり、メッセージ1の内容を知らなくてもよい。ハッシュがハッシュ(秘密‖メッセージ)[1]とメッセージの構造を持つメッセージ認証コードとして使用されており、秘密の長さがわかっている場合、攻撃者は秘密を知らなくてもメッセージの末尾に追加情報を含めて有効なハッシュを生成できるため、これが問題になる。Merkle -Damgård構造に基づくMD5、SHA-1、およびほとんどのSHA-2などのアルゴリズムは、この種の攻撃の影響を受けやすい。[1] [2] [3] SHA-384やSHA-512/256を含むSHA-2の短縮バージョンは影響を受けません。[4] SHA-3アルゴリズムも同様です。 [5] HMACも異なる構造を使用しているため、長さ拡張攻撃に対して脆弱ではありません。[6]最後に、ハッシュ(メッセージ‖シークレット)を実行するだけで影響を受けなくなります。
説明
脆弱なハッシュ関数は、入力メッセージを受け取り、それを使用して内部状態を変換することによって機能します。すべての入力が処理された後、関数の内部状態を出力することによってハッシュ ダイジェストが生成されます。ハッシュ ダイジェストから内部状態を再構築することができ、その後、新しいデータを処理するために使用できます。このようにして、メッセージを拡張し、新しいメッセージの有効な署名であるハッシュを計算できます。
例
指定されたタイプのワッフルを特定の場所にいる特定のユーザーに配達するサーバーは、指定された形式のリクエストを処理するように実装できます。
元データ: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo オリジナル署名: 6d5f807e23db210bc254a28be2d6759a0f5f5d99
サーバーは、署名がユーザーに対して有効である場合にのみ、指定されたリクエスト (ユーザー「1」の指定された場所にエッグタイプのワッフル 10 個を配達する) を実行します。ここで使用される署名は、攻撃者に知られていないキーで署名されたMACです。 [注 1]
攻撃者は、要求されたワッフルを「eggo」から「liege」に切り替えることで、この例の要求を変更することができます。これは、クエリ文字列内の重複コンテンツによって後者の値が優先される場合、メッセージ形式の柔軟性を利用して実行できます。この柔軟性は、メッセージ形式の悪用を示すものではありません。メッセージ形式は、署名アルゴリズムの助けなしに、暗号的に安全になるように設計されたことはそもそもないからです。
必要な新しいデータ: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo &waffle=liege
この新しいメッセージに署名するには、通常、攻撃者はメッセージの署名に使用されたキーを知り、新しい MAC を生成して新しい署名を生成する必要があります。ただし、長さ拡張攻撃では、元の要求の長さがわかっている限り、ハッシュ (上記の署名) をハッシュ関数の状態に入力し、元の要求が中断したところから続行できます。この要求では、元のキーの長さは 14 バイトでしたが、これは、さまざまな想定された長さで偽造された要求を試し、どの長さの要求がサーバーによって有効として受け入れられるかをチェックすることで判断できます。
ハッシュ関数に入力されるメッセージは、多くの場合パディングされています。これは、多くのアルゴリズムが、長さが特定のサイズの倍数である入力メッセージに対してのみ機能するためです。このパディングの内容は、常に使用されるハッシュ関数によって指定されます。攻撃者は、偽造したメッセージにこれらのパディング ビットをすべて含める必要があります。そうしないと、メッセージの内部状態と元のメッセージが一致しません。したがって、攻撃者は、次のパディング ルールを使用して、わずかに異なるメッセージを作成します。
新しいデータ: count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo \x80\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\
x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00
\x00\x00\x00\x00\x02\x28&ワッフル=リエージュ
このメッセージには、ペイロードの前にハッシュ関数内で元のメッセージに追加されたすべてのパディングが含まれています (この場合、0x80 の後に 0x00 がいくつか続き、メッセージの長さは 0x228 = 552 = (14+55)*8 で、これは最後に追加されたキーと元のメッセージの長さです)。攻撃者は、元のメッセージのハッシュされたキー/メッセージ ペアの背後にある状態が、最後の "&" まで新しいメッセージの状態と同じであることを知っています。攻撃者はこの時点でハッシュ ダイジェストも知っています。つまり、その時点でのハッシュ関数の内部状態を知っているということです。その時点でハッシュ アルゴリズムを初期化し、最後の数文字を入力して、元のキーなしで新しいメッセージに署名できる新しいダイジェストを生成するのは簡単です。
新しい署名: 0e41270260895979317fff3898ab85668953aaa2
新しい署名と新しいデータを新しいリクエストに結合すると、署名はパスワードがわかっている場合に生成されるものと同じになるため、サーバーは偽造されたリクエストを有効なリクエストとして認識します。
注記
- ^ この例は、同じリクエストと署名を 2 度目に送信することで、リプレイ攻撃に対しても脆弱になります。
参考文献
- ^ ab Vũ, Hoàng (2012-03-30). 「MD5 長さ拡張攻撃の再考 - Vũ の内なる平和」。2014-10-29 時点のオリジナルよりアーカイブ。2017-10-27閲覧。
- ^ Duong, Thai; Rizzo, Juliano (2009-09-28). 「Flickr の API 署名偽造脆弱性」(PDF) 。2023 年 3 月 18 日閲覧。
- ^ Meyer, Christopher (2012-07-30). 「ハッシュ長拡張攻撃」 . 2017-10-27閲覧。
- ^ Bostrom, Michael (2015-10-29). 「size_t は重要: ハッシュ長拡張攻撃の説明」(PDF) 。2020-11-23閲覧。
- ^ Keccak チーム。「Keccak の強み - 設計とセキュリティ」 。2017年 10 月 27 日閲覧。SHA
-1 や SHA-2 とは異なり、Keccak には長さ拡張の弱点がないため、HMAC ネスト構造は必要ありません。代わりに、メッセージの先頭にキーを追加するだけで、MAC 計算を実行できます。
- ^ Lawson, Nate (2009-10-29). 「安全でないキー付きハッシュの使用をやめ、HMAC を使用してください」 。2017年 10 月 27 日閲覧。
