it-swarm.com.de

Warum hat der SSL / TLS-Handshake einen zufälligen Client und Server?

Beim SSL-Handshake generieren sowohl der Client als auch der Server ihre jeweiligen Zufallszahlen. Der Client generiert dann ein Pre-Master-Geheimnis und verschlüsselt es mit dem öffentlichen Schlüssel des Servers. Warum kann der Client das Pre-Master-Geheimnis jedoch nicht einfach generieren und an den Server senden? Warum brauchen wir einen zufälligen Client und Server? Soll es zur Entropie im Hauptgeheimnis beitragen oder zur Einheitlichkeit mit anderen Schlüsselaustauschalgorithmen wie DH?

20
George Robinson

Von Die ersten paar Millisekunden einer HTTPS-Verbindung :

Das Hauptgeheimnis ist eine Funktion der Client- und Server-Zufälle.

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

Sowohl der Client als auch der Server müssen in der Lage sein, das Hauptgeheimnis zu berechnen. Das Generieren eines Pre-Master-Geheimnisses auf dem Client und das Senden von an den Server würde bedeuten, dass der Client das Master-Geheimnis nie herausfinden kann.

Warum nicht einfach den Pre-Master benutzen?

Dies würde bedeuten, dass die gesamte Routine zur Schlüsselgenerierung auf vom Client generierten Werten basiert. Wenn ein Man-In-The-Middle-Angreifer den Handschlag erneut abspielte, wurde dasselbe Pre-Master-Geheimnis gesendet und dann für die Verbindung verwendet. Lassen Sie den Server einen zufälligen Wert generieren (ServerHello.random) bedeutet, dass das MAC-Geheimnis anders ist, wenn das ClientHello.random wird wiederholt, und daher unterscheiden sich MAC- und Verschlüsselungsschlüssel, wodurch Wiederholungsangriff verhindert wird.

28
SilverlightFox

Nützlich beim Fortsetzen einer Sitzung

In TLS wird das Hauptgeheimnis mit zufälligen Server- und Client-Bytes in einer PRF-Funktion verwendet, um einen Schlüsselblock zu berechnen.

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

Dann wird der Schlüsselblock geteilt, um sechs Schlüssel bereitzustellen, die für verschiedene Operationen verwendet werden:

  • 2 Verschlüsselungsschlüssel
  • 2 MAC-Schlüssel
  • 2 IV (bei Bedarf durch Verschlüsselungsprimitiv)

Wenn Sie eine Sitzung fortsetzen, wird derselbe Hauptschlüssel zum Generieren des Schlüsselblocks verwendet. Die Verwendung von zufälligen Client- und Server-Bytes stellt also sicher, dass der Schlüsselblock bei jedem Handshake unterschiedlich ist.

0
chamoute

Soll es zur Entropie im Meistergeheimnis beitragen ...

Ja. Es stellt sicher, dass beide Parteien zum Hauptgeheimnis beitragen.

Das Hauptgeheimnis ist der Startwert, der zum Ableiten der nachfolgenden Schlüssel verwendet wird, die für die Massenverschlüsselung und -authentifizierung verwendet werden.

... oder zur Vereinheitlichung mit anderen Schlüsselaustauschalgorithmen wie DH?

Nein. Diffie-Hellman verlangt von beiden Parteien, einen Beitrag zu leisten, indem sie einen zufälligen geheimen Wert auswählen a (oder b) und dann den senden andere Partei die A=G^a (oder B=G^b). Mitwirkendes Verhalten ist in Diffie-Hellman eingebrannt.

Es gibt andere wichtige Vereinbarungen. RSA ist ein Schlüsseltransportschema, bietet dem Server jedoch nicht die Möglichkeit, zum Premaster-Geheimnis beizutragen. Das heißt, es gibt kein beitragsabhängiges Verhalten beim Transport von RSA-Schlüsseln.

Im Fall des RSA-Schlüsseltransports können Sie sicherstellen, dass beide Parteien zum Hauptgeheimnis beitragen:

master_secret = Transform(premaster_secret + client_random + server_random)

Ein praktisches Problem, das das beitragende Verhalten löst, ist die Vorstellung eines IoT-Geräts mit einem defekten oder nutzlosen Zufallszahlengenerator. Das beitragende Verhalten stellt sicher, dass der Kanal [meistens] sicher ist, auch wenn dem Kunden die Zufälligkeit fehlt.

0
user29925