セキュリティを始めようとしており、SSL ハンドシェークのシナリオについて読んでいます。この投稿では、返信者は、対称キーがブラウザーで生成され、サーバーの公開キーを使用して暗号化され、サーバーに送信されると述べています。
ただし、他の記事では、プリマスター シークレットが生成され、代わりに対称キーの計算のために送信されたと述べています。
どちらが正しい説明なのか、このプリマスター シークレットはどのように生成され、対称キーを生成するために使用されるのかを教えてください。
セキュリティを始めようとしており、SSL ハンドシェークのシナリオについて読んでいます。この投稿では、返信者は、対称キーがブラウザーで生成され、サーバーの公開キーを使用して暗号化され、サーバーに送信されると述べています。
ただし、他の記事では、プリマスター シークレットが生成され、代わりに対称キーの計算のために送信されたと述べています。
どちらが正しい説明なのか、このプリマスター シークレットはどのように生成され、対称キーを生成するために使用されるのかを教えてください。
ブラウザーが対称鍵を生成すると言うのは、単純化したにすぎません (少なくとも、証明書を使用して暗号化が行われると言うよりはましです)。詳細については、Security.SE のこの回答に興味があるかもしれません。
次に、暗号スイートは、これらの対称鍵が最終的にどのように共有されるかを決定します。SSL/TLS ハンドシェイクの当面の目的は、クライアントとサーバーの間でプリマスター シークレットの共有を確立することです。これは、より広く鍵交換と呼ばれます (RFC 4346 の付録 F.1.1 と、おそらくセクション 7.4.7 を参照してください)。
これは、次の 2 つのカテゴリに分類されます (匿名の鍵交換を除く)。
TLS_RSA_WITH_AES_128_CBC_SHA
): クライアントは、サーバーの公開鍵 (証明書に含まれる) を使用してプリマスター シークレットを暗号化します。TLS_DHE_RSA_WITH_AES_256_CBC_SHA
): Diffie-Hellman 鍵交換が行われます。サーバーはその DH パラメータに署名し、クライアントはサーバー証明書の公開鍵に対して署名を検証します。(RSA ベースの証明書を持っていても、RSA 鍵交換を意味するわけではありません。)ハンドシェイクの最後に、これら 2 つのステップのどちらが使用されても、クライアントとサーバーは共通のプレマスター シークレットを所有し、そこからマスターシークレットを導出します( RFC 4346 セクション 8.1を参照)。
そのマスター シークレットから、 RFC 4346 セクション 6.3で説明されているように、両当事者は暗号化キー (および MAC シークレット) を取得できます。
以下は、SSL/TLS ハンドシェイクについて説明している優れた記事へのリンクです (クライアントとサーバーの両方がプレマスター シークレットを使用してマスター シークレットを生成し、MAC と暗号化用のセッション キーのセットを生成するために使用されます)。 ):
リンク先の投稿の説明は、プロトコルの簡単な説明にすぎません。
クライアントはプリマスター シークレットを生成し、ハンドシェイク プロセスの一部としてサーバーの公開鍵で暗号化します。次に、両方の側で、 RFC 6101の方法に従って、IV および MAC キーを含む対称キー マテリアルを導出します。