可変時間比較は常に暗号化コードのセキュリティリスクですか？
私は暗号化に遭遇しましたpythonパッケージ、そしてそれがセキュリティの脆弱性の報告について 以下 を持っていることに気づきました：
セキュリティの問題を考慮しない例：情報の開示に問題が生じる特定のプログラムを明確に示すことができない場合は、どこかで可変時間比較を使用します。
可変時間比較がないことは、暗号化実装が安全であることを保証するものの1つだと思いました。これはすべての安全な暗号化ライブラリの目標でしょうか？そうでない場合、一定の時間比較を使用するかどうかに関係なく、どのような条件下でセキュリティに影響を与えませんか？
いいえ、それらは常にリスクがあるとは限りません。実際、すべての関数が一定の時間である実用的な暗号ライブラリを構築することは不可能です。
たとえば、復号化関数を見てみましょう。実際の暗号化ライブラリでは、10ギガバイトのメッセージよりも10バイトのメッセージを解読する方が高速です。理論的には、サポートされているサイズのメッセージの復号化が一定時間であるライブラリを作成できますが、それは不合理です。そのため、復号化されるメッセージのサイズに関する情報を（役に立たない）リークする可変時間関数があります。これが問題ではない特定の理由の1つは、攻撃者がメッセージサイズに関する情報をセキュリティプルーフに組み込んでいる可能性があるという想定です。セキュリティプロパティは通常、特定のサイズのメッセージのセキュリティのみを想定して設計されており、異なるサイズのメッセージには適用されないため、メッセージサイズが機能の完了タイミングに影響を与える場合でも、システムの設計されたセキュリティに影響はありません。
他の場合では、タイミングは潜在的に敏感であるかもしれませんが、機能が攻撃者がその機能に対して使用することができるどんな情報も排除するように設計されるかもしれません。ダブルMACはこれの一例です。 MACの評価は、間違いなくタイミング攻撃に敏感な機能です。 （たとえば）暗号化してからMACスキームでは、暗号文で送信されたMACと暗号文に対して新たに計算されたMACを比較します。タイミング攻撃により、攻撃者は変更された暗号文/ MACの組み合わせを繰り返し送信し、有効なMACを繰り返し計算せずに正しい秘密鍵を知っている。ただし、すべての比較で、MACを一時キーで再MACして再比較する場合、タイミングの問題があるかどうかは問題ではありません。 2番目のMACの一時鍵は、後続の評価ごとに生成される新しい一時鍵が有効なビットを発見する努力を妨げるため、敵が正しいMACを繰り返し生成することを妨げます。
可変時間比較は情報をリークします。比較対象のデータを明らかにしても害がなければ、可変時間比較を使用しても問題はありません。秘密にしておくことが重要な場合は、一定時間の比較を使用してください。
理論的に悪用可能ないくつかの可変時間比較は、実際には悪用するのが難しい場合があります。ハッカーが収集できるタイミングデータの品質は、特定の現実世界のコンテキストでタイミング攻撃を成功させるには不十分な場合があります。
たとえば、秘密の情報を処理するソフトウェアが、一貫性のない予測不可能な実行時間（同一の入力に対して）をすでに持っているハードウェアで実行されている場合、タイミング攻撃はより困難になります。誰かがナノ秒の正確なタイミングデータにアクセスできる場合でも。
秘密情報もそれほど機密性が高くなく、寿命が短い場合、そのようなタイミング攻撃に関連するリスクは、心配するには小さすぎる可能性があります。
ただし、ノイズの多いタイミングデータを回避する方法があります。多分ハッカーは他のサイドチャンネルを使ってタイミングデータを補います。多分彼はあなたのサーバーにタイミングをより予測可能にする特定のリクエストを送ります。そしてもちろん、彼は何度も攻撃を実行し、ノイズを平均化することができます。
（開発者として、確信が持てない場合は、一定時間の操作を使用してください。悪用するのが難しすぎると考えないでください。）
可変時間アルゴリズムを使用して比較してはならないもの：
- 秘密（対称）鍵または秘密（非対称）鍵
- メッセージ認証タグ
- シークレットを含むメッセージ（またはメッセージのハッシュ）
- ハードコードされた（またはユーザーが構成可能な）シークレット
重要な場合と重要でない場合の例：
- 公開鍵
- 暗号文
- パブリックIPアドレス
- 公開識別子（個人を特定できる情報を除く）
ユーザーのプライバシーの侵害はセキュリティ上の問題となる可能性があることに注意してください。 （個人的には、ある種の情報を非公開にする必要があるとは思わない場合でも）。したがって、開発者は引き続き検討する必要がありますサイドチャネル攻撃。データを扱う場合でも、それほど機密性が高いとは思わないかもしれません。
まず、暗号法は広義の用語であり、Python cryptographyライブラリには、プリミティブだけでなく、X.509処理なども含まれています。
主な問題は、攻撃者がタイミングの問題を使用して秘密を取得したり、問題の複雑さを減らしたりして、秘密を攻撃に現実的な値にするまでの時間を短縮できるかどうかです。これは、攻撃者がそもそも十分な粒度で時間を測定できることを意味します。たとえば、これは通常、複雑なWebアプリケーションでは当てはまりません。ネットワークレイテンシやSQLクエリの実行時間などの変動により、暗号操作の小さなタイミングの違いがリモートから測定できなくなる可能性があります。 TLSハンドシェイクのように、暗号化の初期の使用はまだ影響を受ける可能性があることに注意してください。この初期の段階では、他のすべてのオーバーヘッドとアプリケーションのバリエーションはまだそれほど影響を受けていないためです。
また、攻撃者が最終的に秘密を抽出するために十分な実験を実行できることも意味します。詳細は、タイミングの違いから実際にどれだけの情報がリークされるかによって異なりますが、実際には実行できないことがよくあります。
そして、単純な攻撃が可能になる可能性があります。ローカルアプリケーションの場合は、ほとんどをブラックボックスとして扱うのではなく、リバースエンジニアリングする方が安上がりです。もちろん、アプリケーションがたとえば改ざん防止エンクロージャー（スマートカードなど）に含まれている場合、タイミング攻撃または他のサイドチャネル（放射、使用電力の変動など）が実際に唯一の方法である可能性があります。
要約すると、a）タイミングの違いを十分な粒度で測定でき、b）十分な実験を行うことができ、c）明らかに安価な攻撃が可能でない場合、タイミング攻撃に対する耐性が関係します。特にa）およびb）は実際のユースケースに大きく依存するため、暗号プリミティブはさまざまなユースケースで使用される可能性があるため、耐性があることがより重要です。
可変時間比較を回避する主な目的は、アプリケーションに対するタイミングベースの攻撃につながる意図しない情報開示を防ぐことでした。
たとえば、 パディングOracle攻撃 および 時間ベースのブラインドSQLインジェクション攻撃 を見てください。プログラム内のすべての可変時間比較をクリアすると、一定のコストがかかります。暗号化pythonパッケージは、それらのケースのために情報の開示が見られないため、回避しようとしています。
セキュリティ関連のコードのこのような使用例を見逃しがちなので、可変時間の比較は避けたいと思います。
漏えいした情報について重要なことは、特定の一連の状況を前提として、どの情報が漏えいしているか、攻撃者が何を知っているか、制御しているのかを識別することです。
たとえば、パスワードの確認を見てみましょう。古き良き時代の古い平文のパスワードは、セキュリティを考慮しないライブラリによって、一度に1文字ずつ比較されることがよくありました。つまり、パスワードの最初の文字を正しく取得した場合、最初の文字を間違えた場合よりも少し時間がかかります（2番目の文字を確認するのに時間がかかるため）。最初の文字をすべて試してから、正しい文字をヒットするまで続け、次にその最初の文字に加えて、可能なすべての2番目の文字を試すことができます。このようにして、必要な作業を64 ^ 6から64 * 6に減らすことができます（64の可能なシンボルのセットから6つのシンボルを想定）。
チェックする前にパスワードをハッシュしても、事前計算されたRainbowテーブルに同じように適用できます。バイト00で始まるハッシュでパスワードを見つけます。01で始まるパスワードよりもチェックに時間がかかる場合は、すべてのパスワードを削除できます。 01で始まらないハッシュ付き。
暗号化の例では、解読されるメッセージが攻撃者から提供された場合、その大きさがわかります。メッセージを2倍読むのに2倍かかると、そこから新しいことは何も学べません。
一方、KEYが異なる場合にメッセージの復号化に時間がかかる場合、メッセージの復号化にかかった時間が、攻撃者には知られていない鍵に関する情報を提供します。