固定処理時間を使用してタイミング攻撃を防ぐことは妥当ですか
SSL/TLSトンネル内で暗号化操作を実行するシステムがあります。私の懸念は、暗号化、復号化、またはハッシュするときにタイミング情報を漏らす可能性があることです。
パート1
- これらの暗号化操作を実行するときに、処理時間を固定（またはその増分）することは良い考えですか？
- これはどの操作に適用する必要がありますか（暗号化/復号化またはハッシュ）？
- 一部の操作は、タイミング情報の漏洩に敏感ではありませんか？ （ファイルの暗号化解除、パスワードのハッシュ、PGP、RSA、AESなどを使用）
例えば：
ユーザーが入力したデータを秘密鍵に暗号化する場合、全体の操作には常に2秒かかります
ファイルを復号化するとき、合計時間が0.5秒の倍数に達するまでスレッドは戻りません
パート2
- 「倍数」アプローチを使用する場合、倍数の適切な値は何ですか？ 0.5、0.005秒？
固定処理時間は、タイミング攻撃から防御するための最も基本的で徹底的な方法です。タイミングを通じて漏洩するデータの悪用を回避するために、漏洩しないでください。ただし、言うのは簡単です。最近の "Lucky Thirteen" は、ターゲットが攻撃者の近く（同じLAN上）にある場合に、マイクロ秒の精度でタイミングの違いを検出できることを示しています。攻撃の詳細は、SSL実装に残っていた小さなリークを悪用し、タイミング攻撃に関してがパッチされました-これらの実装は、復号化によって適切なパディングが得られなかった場合でもMACを計算していました正確に、達成可能な限り固定された処理時間を得るため。しかし、1マイクロ秒の変動は避けられませんでした。
固定の「全体的な」処理時間（たとえば、各要求に対して1秒）を適用すると、マルチタスクオペレーティングシステムで問題が発生します。メイン処理の後の実装がsleep()呼び出しだけの場合、CPUは他の要求を自由に処理できます。これは見た目は良いですが...攻撃者が他の要求を同時に送信してワークアウトできるため、データがリークします。サーバーがビジーかどうか。一般的に言って、サーバーに大量のリクエストを送信することにより、攻撃者は各リクエストの処理時間を任意に長くし、固定制限を超えることができます。処理時間を固定粒度の整数倍に制限する場合（たとえば、処理時間は常にn×0.1秒で、n整数である場合）攻撃者にとってタスクが少し難しくなる "しきい値"がありますが、不可能ではありません-攻撃者を助けることさえできます。実際、「ラッキーサーティーン」攻撃は、このようなしきい値（SHA-1およびSHA-256が64バイトのブロックでデータを処理する方法に対応）の活用が「フェーズ」を必要とし、統計的状況をより明確にする方法を示しています。
現在のところ、最善の防御策は数ミリ秒のランダムな遅延を追加することです。これにより、画像がぼやけ、分析が妨げられます...また、攻撃者に許可しないでくださいサーバーと同じLANに接続します。言うまでもありません。
タイミング攻撃の基本的な本質は、サーバーに異なるデータサンプルを送信し、入力の処理にかかった時間を調べて、異なる入力が異なるコードパスを生成するかどうかを確認することです。タイミング攻撃に対する最善の防御策は、入力に関係なく、コードを同じ実行パスに保つことです。
これは言うよりもはるかに簡単です。 memcmp()のような単純な関数は、最初のバイトが一致しないと終了するため、同じコードパスを保証しません。入力が異なると、異なるポイントから終了します。自然な応答は、カスタムmemcmp()- esque関数を作成することですが、そうすることは 単純ではない です。
最大の問題は、エラーと検証の処理方法です。前処理/検証/健全性チェックのエラーに関係なく、後で出力が破棄されることがわかっている場合でも、同じコードを実行する必要があります。 実用的なタイミング攻撃 を見ると、頻繁に現れる例はMAC検証の時間の変化です。 raw暗号プリミティブのタイミングは、実際には問題ではありません。 AESやSHA2などのビットマングル操作は、取得する入力文字列に関係なく、同じ時間かかります。主な焦点は、エラー、特殊なケース、およびデータ比較の処理方法です。
オペレーションの固定時間は、必ずしも最善の防御とは限りません。攻撃者は、一定のウォールタイムインクリメントのしきい値で操作時間を正確に入力するように入力を作成し、どの操作がしきい値を超えて操作をプッシュするかを確認することにより、それをバイパスできる可能性があります。ほとんどの状況での理想的なアプローチは、入力に関係なくまったく同じコードを実行することです。
ただし、お客様の正確な状況や機密を保持しようとしている正確な情報はわかりませんので、上記は一般的なものです。たとえば、コードの実行を同じに保つアプローチでは、処理されるデータの量に関する情報が漏洩し、それが問題であるかどうかはわかりません。多くの場合、攻撃者はデータのサイズをすでに知っています（データサイズを提供したため）が、それが問題であるかどうかはわかりません。