web-dev-qa-db-ja.com

パスワードハッシュに対するタイミング攻撃

タイミング攻撃は、シークレットが関係するシナリオで壊滅的な影響を与える可能性があり、バイト単位の配列比較が使用される場合がよくあります。

現在、シークレット自体を比較するときだけでなく、シークレットから導出されたデータが比較されるあらゆる状況で、一定の時間配列比較を使用してアドバタイズするものがあります。理論的根拠は「申し訳ありませんが安全です」です。これは問題ありませんが、本当に本当に必要なのかと私はまだ疑問に思っています。

一定時間の配列比較はおそらく不要だと思う傾向がある特定のケースは、保存されたパスワードハッシュをユーザーが提供したハッシュと比較することです。たとえばbcryptを使用して、パスワードが適切に保存されていると仮定します。アプリケーションが短絡配列比較を使用する場合、攻撃者は応答にかかる時間を評価することにより、任意に選択されたパスワードの「正しいビット数」に関する情報を入手する可能性があります。

私の質問は、これを「ブルートフォースよりも優れた」攻撃に変換できるかどうかです。漸進的な攻撃の可能性はありますか？つまり、ブルートフォース推測を使用する以外に、nの正しいビットを持つパスワードからn + 1の正しいビットを持つパスワードを構築することは可能ですか？

以下に興味があります。

  • そのような攻撃がnotを行う一方向の（圧縮）関数に対して（非）実行可能であることを証明する理論的な結果の存在-=ハッシュ関数が（疑似）ランダムであると仮定する
  • MD5、SHA-1などの実際のハッシュ関数の否定/肯定結果.
cryptographyhashbrute-forcetiming-attack
22
emboss

Short version：saltが攻撃者に隠されていれば、saltされたパスワードのハッシュのショートカット比較を行う危険はないと思います。

ロングバージョン：

この場合にタイミング攻撃を使用しても、実際にハッシュとソルトが格納されている場合に知っている以上のことを攻撃者に伝えることは決してできません。そしてハッシュを知っていても、bryptのセキュリティパラメータ（反復回数指数）を選択する必要があります。 saltは攻撃者にパスワードを導出するのに十分な利点を与えません（パスワードをブルートフォースで強制する必要があるため）。

一方、攻撃者が使用されたソルトも格納されたハッシュも知らない場合、計算されたハッシュと格納されたハッシュの比較のタイミングは、すべての（1ビットでも）の変更であるため、まったく情報を提供しないと思います。パスワード入力は完全に異なるハッシュになります。 （これは、bcryptだけでなく、すべての疑似ランダム関数に適用されます。実際に必要なのは アバランシェ効果 ここだけです。）より正式な詳細については、以下を参照してください。

これ以外には、通常、ハッシュプロセス自体が測定に含まれます。これは最後の最後の比較よりはるかに時間がかかるため、測定された合計時間を支配します。ただし、このハッシュ時間がどれだけ変化するかはわかりません。

数学バージョン：

私の質問は、これを「ブルートフォースよりも優れた」攻撃に変換できるかどうかです。漸進的な攻撃の可能性はありますか？つまり、ブルートフォース推測を使用する以外に、nの正しいビットを持つパスワードからn + 1の正しいビットを持つパスワードを構築することは可能ですか？

したがって、関数c_h(y)があります。これは、H(s, y)とhの間で一致する先行ビットの数です。 mをHの出力のビットの総数とする。

攻撃を実行できるアルゴリズムA、つまりハッシュh（Aには不明）と特定のメッセージxでc_h(x) = nを使用し、メッセージ_x'_とc_h(x) >= n+1、nの指数関数よりも時間的に優れています。 （nの単純な総当たりのハッシュは指数関数的です。）このアルゴリズムには、任意のyに対するc_h(y)へのO(1) Oracleアクセス権）があると想定できます。

次に、この構成から、特定のハッシュhおよびソルトsに対してpreimage attackを実行するアルゴリズムBを作成できます。つまり、H(s,z) = hでメッセージzを検索します。次のように機能します。

  • Oracle for Aは、H(s,y)を計算し、それをhと比較して、最初の不一致までの正しいビットをカウントすることで簡単に実行されます。
  • 任意のメッセージ_x_0_を選択し、n_0 = c_h(x_0)を計算します。
  • I> 0ごと：
    • x_(i-1)をAに渡し、n_i = c_h(x_i) > n_(i-1)で_x_i_を返します。
    • _n_i = m_の場合、停止して_z = x_i_を返します。

Bの出力は_(s, h)_のプリイメージです。

各_n_i_が前のものよりも大きいので、これはループを最大でm通過し、各パスは最大でo(exp(n_i))時間、つまり合計o(exp(m))かかります。このようにして、サブ指数関数のプレイメージ検出アルゴリズムを得ました。

これは、Oracleとして一致の長さが与えられた場合、[Hがプリイメージ耐性があると仮定して、短い部分一致から長い部分一致を効率的に生成するアルゴリズムがないことを示しています。

（タイミングの近似値を少し改善できると思います。）

コメントに関する注意：

コメントスレッドがかなり長くなっているので、ここで重要なポイントを再開しようとします：

  • 脆弱なパスワードを使用すると、パスワードハッシュに対するオフライン辞書攻撃が実行可能になります。これは、アルゴリズム[〜＃〜] b [〜＃〜]になります。これが、十分高いbcrypt作業係数を選択したい理由です。

    それでも、高速[〜＃〜] b [〜＃〜]（与えられたソルトを使用したオフラインのプリイメージ攻撃）から高速[〜＃〜] aに移行する方法はありません。 [〜＃〜]（ハッシュプレフィックス長Oracleからのオンライン部分プリイメージファインダー）アルゴリズム。

    Preimage-brokenである関数でさえ、それらが avalanche基準 に適合している限り、オンライン攻撃を取得する簡単な方法はないと予想します。

  • 実際のハッシュ関数は実際にはランダムではありませんが（これは反復的な設計が原因です）、ブロックサイズより短い入力で機能するパスワードハッシュの適合性には影響しません。

  • ここで重要な特性は、衝突耐性ではなく、プリイメージ耐性です。 （ すべての衝突耐性関数は2番目のプリイメージ耐性であり、2番目のプリイメージ耐性の関数はプリイメージ耐性です -通常、（2番目の）プリイメージ攻撃に対する耐性は、この衝突耐性からのこの減少よりも高いと予想されますが、これは、衝突を検出するための一般的な誕生日攻撃によるものです。）これは、プリイメージ攻撃がない限り、この証明がMD5（衝突ごとに壊れている）に適用されることを意味します。

  • 上記の証明は、ハッシュ関数がランダムなOracleであることに依存せず、c_h(y)へのOracleアクセスを使用するだけで、

23
Paŭlo Ebermann