サーバーまたはクライアントの公開キーを使用して対称セッション キーを暗号化する代わりに、Deffie Hellmen (キー交換) を使用するのはなぜですか?

サーバーまたはクライアントの公開キーを使用して対称セッション キーを暗号化する代わりに、Deffie Hellmen (キー交換) を使用するのはなぜですか?

クライアントが対称セッション キーを生成し、それをサーバーの公開キーで暗号化してサーバーに送信すると、サーバーだけがその暗号化されたセッション キーを秘密キーで復号化できます。逆の場合も同様です。

答え1

このような鍵交換方法は確かに存在する。実際、長い間これが主流だった。主要なこれは SSL/TLS で鍵が交換される方法であり、同様の方式が SSHv1 (現在は廃止) 内で唯一利用可能な交換方法でした。

しかし、どちらのシステムも移行しておりからDH への暗号化ベースの鍵交換。

あなたが説明したメカニズムには大きな問題が1つあります。サーバーの秘密鍵が盗まれた場合、それを使って復号化することができます。あらゆるつながり以前にその鍵ペアで作成された、または今後作成される鍵ペア。(言い換えれば、欠けている前方秘匿性

HTTPS証明書は5年、10年発行されていたのに対し、SSHは依存するホストキーが一度作成されると変更されない場合、これはかなりのリスクになる可能性があります。(たとえば、同じ攻撃者がデータセンターのネットワーク トラフィックを監視している場合や、PRISM や XKeyscore などの監視プログラムに参加している国に住んでいる場合など)。

(SSHv1 は、キー交換の目的で一時的な RSA キーを生成することでこの問題を軽減しようとしましたが、これにより、暗号化に「既知の」サーバー キーを使用する利点が完全に無効になります。また、RSA キーの生成には大量の処理が必要であるため、数時間ごとにしか実行されず、一時的なキーは 768 ビットに制限されていました。)

もう一つの問題は、暗号化機能を必要とすることであるキーアルゴリズムの選択を制限する私の理解が正しければ、非対称デジタル署名(DH鍵交換を認証する)は、非対称暗号化よりも実装が容易であり、できた両方を行う – 全員ができるわけではありません。

例えば、EC鍵は暗号化に直接使用することはできず、署名と鍵交換にのみ使用できます。EC鍵で暗号化を実装するスキーム(ECMQVなど)がありますが、実際にはECDH 鍵交換に基づいています。それなら、DH を使ったほうがいいかもしれません。

関連情報