web-dev-qa-db-ja.com

認証された暗号化におけるHMACに対するタイミング攻撃？

私の別の質問への回答 では、認証された暗号化でHMACをチェックするときに標準の文字列比較関数を使用するクラスがHMACに対するタイミング攻撃に対して脆弱になることが指摘されました。

認証された暗号化のHMACに対するこのタイミングの攻撃がどのように問題になるかについて、頭を抱えることはできませんか？

まず第一に、実装は攻撃者に知られていると見なされるべきです（この特定のケースでは、ソースは単に公開されています）。そのため、唯一の秘密は鍵です。この推論に従って、実装の定数時間比較関数はどのようにして何かを保護しますか？ （攻撃者が同じコードを使用する場合でも、単純に削除することを期待します）。

2番目に、実装をブラックボックスと考える場合、比較はPBKDF2派生キーを使用したデータのHMACに対するものです。 HMACに対するタイミング攻撃を試みてはいけませんか？a）PBKDF2で保護されたパスワードをブルートフォースで試みるのと同じくらい遅いb）データを復号化する試みに役立つ情報を実際に開示していないのですか？ （HMACは暗号文に追加されていて、暗号化されたデータにアクセスできるすべての人が利用できます）。

それで、ここで何が欠けていますかなぜタイミング攻撃なのですかこのシナリオでは防御が必要なリスクと見なされますか？


クイックアップデート：
私はhowタイミング攻撃が機能することを理解していますが、復号化関数が次のようになっているシナリオでタイミング攻撃を採用することで何が得られるのか理解していません。

/**
 * @param binary $data Where $data = salt, IV, encrypted data, HMAC(salt, IV, encrypted data)
 * @param string $password The decrypt-password
 * @return string|null plain text if data was successfully decrypted, null otherwise
 */
function decrypt($data, $password) {
    ...
}
encryptionhmactiming-attack
18
Monika

リスクは、攻撃者がforgeデータを取得できることです。つまり、独自の暗号文を考え出し、期待されるHMACを把握して、システムが入力を有効であると受け入れるようにすることができます。

HMACの要点は、キーの所有者としてのyoのみがデータに「署名」できることです。ただし、アプリケーションが入力の予想されるHMACに関する情報を漏洩した場合、攻撃者は実際に自分のデータに「署名」できます。

簡単に言えば、次のように機能します。

攻撃者はデータを考え出し、システムがそれを受け入れることを望んでいます。そのために、彼らは正しいHMACを知る必要があります。攻撃者はキーを持っていないため、HMACを単純に計算することはできません。ただし、微妙な時間差を測定することで、期待値についてシステムに「質問」できます。

  • 攻撃者：「私はこのデータを持っています。私の推測では、HMACはバイト0x00で始まります。これは正しいです？"
  • あなた：「いいえ」
  • 攻撃者：「HMACは0x01で始まりますか？」
  • あなた：「いいえ」
  • ...
  • 攻撃者：「HMACは0xABで始まりますか？」
  • あなた：「はい、最初のバイトは正しいです。」
  • 攻撃者：「OK。次のバイトは0x00ですか？」
  • あなた：「いいえ」
  • ...

最後に、攻撃者はすべてのバイトを知っています。

問題は、アプリケーションが間違ったHMACを拒否しないことです。それは実際に攻撃者にHMAC すべきがどのように見えるかを伝えることで助けます。

アップデートを見ると、HMACの目的とそれがなぜ重要なのかを一般的に理解していないようです。

HMACがなかったとしましょう。その場合、データの機密性のみを保護し、それはintegrityではありません。人々は既存の暗号文を操作したり、独自の暗号文を考え出したりすることができ、あなたのアプリケーションはそれを何の平文でも発生するように喜んで変えます。多くの場合、これは深刻な問題です。ユーザーIDを含む暗号化されたセッションCookieを考えてみてください。ユーザーにそれを変更してほしくない。

したがって、HMACを一種の「署名」として追加して、ユーザーが暗号文を改ざんしないようにします。機密性が必要および整合性。ただし、ユーザーが任意のデータに適切なHMACを理解できる場合、全体の演習は無意味です。整合性保護を失い、単純な暗号化に戻ります。ここでも、誰でも暗号文をいじることができます。

14
Fleche

それは存在の偽造の可能性を考慮に入れます。攻撃者は、HMACキーを知らなくても、選択したメッセージに対して有効なHMACを作成できます。

基本的に、攻撃の仕組みは次のとおりです。

  1. 攻撃者はメッセージとHMAC（実際にはHMACと同じ長さのバイトシーケンスのみ）を送信し、復号化システムからの応答の時間を計ります。

  2. その後、攻撃者は同じメッセージと同じ疑似HMACを繰り返し送信しますが、HMACの最初のバイトの可能なすべての（256）値を反復処理する点が異なります。

  3. 復号化システムがバイト間の不一致を見つけるとすぐにエラーを返す場合、これらの反復の1つ（復号化システムによって計算された最初のバイト値が同じもの）はわずかに戻るのに時間がかかります。攻撃者がその違いを検出できる場合、復号化システムのHMACキーが与えられれば、攻撃者はメッセージの正しいHMACの正しい最初のバイトを知ることができます。

  4. 攻撃者は同じメッセージとHMACを送信しますが、今回は既知の正しい最初のバイトを使用し、2番目のバイトを繰り返し、復号化システムがエラーで応答するのに少し長くかかる原因となるバイトを再び見つけます。攻撃者は正しいHMACの2番目のバイトを知っています。

  5. 攻撃者が選択したメッセージであるsans keyに対して有効なHMACが生成されるまで、HMACの連続するバイトごとにすすぎ、繰り返します。

これが、HMAC比較が一定時間である必要がある理由です。応答を返す前に、送信されたHMACのバイトを計算されたHMACとall比較します。この方法では、不正なバイトの位置に関係なく、エラーが発生するまでの時間が常に同じになります。攻撃者は、不正なバイトが何であるか、またはどこにあるのかを知る方法がなくなりました。

更新

あなたが提示する特定のシナリオでは、HMACは整合性保護を提供するか、または「認証された暗号化」の「認証」部分です。攻撃者が偽造できる場合、知らないうちに暗号文が変更される可能性があり、認証された暗号化はなくなりましたが、事実上認証されていない暗号化となり、選択された暗号文攻撃に対して脆弱になります。

23
Xander