概要
サーバーとクライアントが、クライアントごとに異なり、しかも決定論的なリクエストごとに一意の IV を生成できるようにする方法を考え出そうとしています。決定論的とは、サーバーが開始シーケンスのみを知っている将来のリクエストの IV を計算できることを意味します。
この機能が必要な理由は、AES 暗号化を使用してワンタイム パスワード (OTP) スキームを実装しているためです。クライアントがサーバーにログインすると、シードが与えられます。最初の OTP は、このシードを暗号化することによって生成されます。後続の各リクエストに対して、クライアントはサーバーとクライアントの間で共有された AES キーを使用して最後の OTP を暗号化します。したがって、攻撃者が共有キーなしで最後の OTP を傍受したとしても、次の OTP を取得することはできません。OTP は CBC モードの AES で暗号化されています。サーバーとクライアントが同期していない場合に問題が発生します。これに対処するために私が計画していた方法は、サーバー側で将来に向けていくつかの OTP を生成し、それらのいずれかがクライアントのものと一致するかどうかを確認することでした。でも、
提案するソリューションに入る前に、AES、IV、CBC、および ECB についての私の理解を表明させてください。そうすれば、私の基礎に誤解があれば、指摘して修正することができます。
仮説
ECB
ECB は、同じキーで暗号化されたプレーンテキストの同一のブロックに対して同じ出力を生成することを知っています。したがって、データを統計的に分析することで平文に関する情報を識別できるため、複数のデータ ブロックに使用しないでください。これに基づいて、データが常に 16 バイト (128 ビット) 未満であることを保証できれば、統計的攻撃の問題が解消されるように思われます。さらに、同じ平文を同じ鍵で暗号化していないことを保証できる場合、同じ出力が得られることはありません。したがって、システムが常にこれらの非常に厳しい基準を満たしていると仮定すると、ECB を使用することは安全であると思われます。
CBCおよびIV
私は、CBC がこれらの問題の両方を排除することを意図していることを知っています。ブロックを連鎖させることで、ECB のマルチブロック統計攻撃を排除します。同じ AES キーに同じ IV を使用しないことで、同じ平文を同じキーで同じ出力に暗号化するという問題を解消できます。
キーの一意性
各クライアントが生成された AES キーを取得した場合、複数のユーザーが同じキーを持っている可能性はわずかですが、可能性は非常に低くなります。したがって、2 つのクライアントが同じ AES キーを使用することはないと想定しても安全です。
提案されたソリューション
私が提案する解決策は、各クライアントに一意の AES キーを与えることです。キーが生成されると、カウンターが乱数に初期化されます。何かを暗号化する必要があるたびに、カウンターは 1 ずつ増加します。この番号はブロックにパディングされ、ECB モードで AES を使用して暗号化されます。これの出力は、CBC を使用してデータを暗号化するための私の IV になります。
サーバーが同じキーを持ち、ECB が IV を必要としないためにクライアントのカウンターと同期しなくなった場合、データを復号化できるものが見つかるまで IV を生成し続けることができます。
私の考えでは、この IV は AES のブロック サイズに等しいため、統計的攻撃から安全です。さらに、各ユーザーは一意のキーを持ち、カウンターは常に増加するため、毎回ユーザーごとに異なります。明らかに、AES キーは安全に送信する必要があります (現在、クライアントは生成されたキーをサーバーの公開 RSA キーで暗号化しています)。
私の質問
提案されたソリューションで説明されているテクノロジに関する基本的な理解は正しいですか? 提案されたソリューションに明らかに問題がありますか? 提案された方法で IV を生成し、CBC を使用して暗号化するために同じキーを使用するセキュリティ上の欠陥はありますか?
暗号化は非常に難しいため、最後の質問は答えるのが難しい/不可能である可能性があることを認識していますが、洞察をいただければ幸いです。
前もって感謝します。