web-dev-qa-db-ja.com

SSL / TLSハンドシェイクにクライアントとサーバーがランダムに配置されているのはなぜですか？

SSLハンドシェイクでは、クライアントとサーバーの両方がそれぞれの乱数を生成します。次に、クライアントは事前マスターシークレットを生成し、それをサーバーの公開鍵で暗号化します。しかし、なぜクライアントは事前マスターシークレットを生成してサーバーに送信できないのでしょうか。なぜクライアントとサーバーがランダムに必要なのですか？それはマスターシークレットのエントロピーに寄与するためですか、それともDHなどの他の鍵交換アルゴリズムとの均一性のためですか？

tlsnonce
20
George Robinson

From HTTPS接続の最初の数ミリ秒 ：

マスターシークレットは、クライアントとサーバーのランダム関数です。

master_secret = PRF(pre_master_secret, 
                    "master secret", 
                    ClientHello.random + ServerHello.random)

クライアントとサーバーの両方がマスターシークレットを計算できる必要があります。クライアントでプレマスターシークレットを生成し、justサーバーに送信すると、クライアントがマスターシークレットを見つけることができなくなります。

なぜプリマスターを使わないのですか？

これは、キー生成ルーチン全体がクライアントが生成した値に基づいていたことを意味します。中間者攻撃がハンドシェイクを再生した場合、同じプレマスターシークレットが送信され、接続に使用されます。サーバーにランダムな値（ServerHello.random）は、MACシークレットがClientHello.randomが繰り返されるため、MACキーと暗号化キーが異なり、 リプレイ攻撃 が防止されます。

28
SilverlightFox

セッションの再開時に役立ちます

TLSでは、マスターシークレットはPRF関数のサーバーとクライアントのランダムバイトで使用され、キーブロックを計算します。

    key_block = PRF(SecurityParameters.master_secret,
                    "key expansion",
                    SecurityParameters.server_random +
                    SecurityParameters.client_random)

次に、キーブロックが分割され、さまざまな操作に使用される6つのキーが提供されます。

  • 2つの暗号化キー
  • 2つのMACキー
  • 2 IV（暗号化プリミティブで必要な場合）

セッションを再開すると、同じマスターキーがキーブロックの生成に使用されます。したがって、クライアントとサーバーのランダムバイトを使用することで、すべてのハンドシェイクでキーブロックが異なることが保証されます。

0
chamoute

それはマスターシークレットのエントロピーに貢献することですか...

はい。これにより、両方の当事者がマスターシークレットに貢献することが保証されます。

マスターシークレットは、一括暗号化と認証に使用される後続のキーを取得するために使用されるシードです。

...またはDHなどの他の鍵交換アルゴリズムとの均一性のために？

いいえ。Diffie-Hellmanは、ランダムなシークレット値a（またはb）を選択し、相手はA=G^a（またはB=G^b）。貢献行動はDiffie-Hellmanに組み込まれています。

他のキー合意スキームがあります。 RSAはキー転送方式ですが、サーバーがプリマスターシークレットに貢献する機会はありません。つまり、RSAキー転送に固有の寄与動作はありません。

RSAキートランスポートの場合、両方の当事者がマスターシークレットに貢献するようにする方法は次のとおりです。

master_secret = Transform(premaster_secret + client_random + server_random)

寄与動作が解決する実際的な問題は、壊れているか役に立たない乱数発生器を持つIoTデバイスを想像してみてください。寄与動作は、クライアントがランダム性を欠いている場合でも、チャネルが[ほとんど]安全であることを保証します。

0
user29925