it-swarm.com.de

Wie wird der nicht kurzlebige Diffie-Hellman-Schlüsselaustausch in SSL beeinträchtigt, wenn der private RSA-Schlüssel durchgesickert ist?

Nach meinem Verständnis ist einer der Hauptgründe, warum wir Diffie-Hellman Ephemeral (z. B. DHE oder ECDHE) gegenüber nicht kurzlebigem DH für SSL/TLS empfehlen, dass ein Angreifer den Kompromiss des privaten RSA-Schlüssels (dh des privaten Zertifikats) zulässt zuvor erfasste Gespräche entschlüsseln. Im Gegensatz dazu sollte kurzlebig die Entschlüsselung verhindern, es sei denn, der Angreifer besitzt den Schlüssel zu der Zeit des Gesprächs.

Wie funktioniert diese Entschlüsselung des nicht kurzlebigen Diffie-Hellman-Schlüsselaustauschs in diesem Zusammenhang? Geht es einfach darum, die unverschlüsselten Grundelemente zu beobachten, die über den Draht ausgetauscht werden? Wenn ja, wozu dient DH, wenn es keine zusätzliche Sicherheit für die Verschlüsselung des Schlüssels mit RSA bietet und RSA bereits die Authentifizierung des Servers bereitstellt?

27
Polynomial

Stellen wir zunächst sicher, dass wir über dasselbe sprechen. In SSL gibt es "kurzlebige DH-Chiffresuiten" (DHE) und "nicht kurzlebige DH-Chiffresuiten" (DH).

Bei DHE ist der private Serverschlüssel (der permanente, der in einer Datei gespeichert ist und dessen öffentlicher Schlüssel im Serverzertifikat enthalten ist) vom Typ RSA (DHE_RSA Cipher Suites) oder DSS = (DHE_DSS-Verschlüsselungssuiten) und wird nur für Signaturen verwendet. Der Server generiert ein neues zufälliges DH-Schlüsselpaar (der private Schlüssel wird nicht gespeichert werden, so wird perfekte Vorwärtsgeheimnis erreicht: Ein privater Schlüssel kann danach nicht gestohlen werden, wenn er noch nie gespeichert wurde) und sendet den öffentlichen Schlüssel an den Client in Eine Nachricht, die der Server mit seinem RSA oder DSS privater Schlüssel) signiert.

Bei DH-Chiffresuiten ist der private Schlüssel des permanenten Servers ist ein privater DH-Schlüssel. Das Serverzertifikat enthält den öffentlichen DH-Schlüssel. Der Server kann nicht sehen, dass sein RSA-Schlüssel gestohlen wird, da der Server keinen RSA-Schlüssel hat. Der Server hat nur einen DH-Schlüssel. Wenn eine Cipher Suites "DH_RSA") heißt, bedeutet dies, dass "der Serverschlüssel ein DH-Schlüssel ist und das Serverzertifikat von einer Zertifizierungsstelle, die verwendet, ausgestellt (dh signiert) wurde ein RSA-Schlüssel " .

Der Diebstahl des privaten DH-Schlüssels einer Partei, die an einem DH-Schlüsselaustausch beteiligt ist, ermöglicht genau wie RSA eine hintergründige Rekonstruktion des gemeinsamen Geheimnisses. In "ephemeral DH" wird das PFS durch "ephemeral" erhalten, nicht durch "DH". Technisch wäre es möglich, "kurzlebiges RSA" zu haben, dies wird jedoch in der Praxis nicht durchgeführt (*), da das Generieren eines neuen RSA-Schlüsselpaars etwas teuer ist, während das Erstellen eines neuen DH-Schlüsselpaars billig ist.

(*) Vergängliche RSA-Schlüssel waren mit alten SSL-Versionen als Teil der "Export" -Cipher-Suites möglich, die den US-Exportbestimmungen vor 2000 entsprechen sollten: Der Server könnte eine 1024-Bit Signatur haben RSA-Schlüssel, und generieren Sie ein kurzlebiges 512-Bit-RSA-Schlüsselpaar für den Schlüsselaustausch, das im Verschlüsselungsmodus verwendet wird. Ich erinnere mich jedoch nicht, dass ich das jemals in freier Wildbahn gesehen habe, und es ist ein strittiger Punkt, seit die US-Exportbestimmungen für Schlüsselgrößen aufgehoben wurden.


Es gibt nicht kurzlebige DH-Verschlüsselungssuiten, damit Server mit DH-Zertifikaten betrieben werden können. DH-Schlüssel im Zertifikat existieren, weil in früheren Zeiten RSA patentiert wurde, DH jedoch nicht. Daher drängten Standardisierungsgremien, insbesondere NIST, DH als den Standard, der implementiert werden muss.

Die Realität hat das jedoch eingeholt. Ich habe noch nie einen SSL-Server mit einem DH-Zertifikat gesehen. Jeder benutzt RSA. Das RSA-Patent ist ohnehin vor einem Jahrzehnt abgelaufen.

23
Tom Leek

Für SSL/TLS benötigen wir zwei Dinge:

1) client needs to authenticate the server.
2) client and server need to compute a symmetric session key.

Einige Möglichkeiten, beides zu tun:

Am häufigsten: TLS_RSA_WITH_AES _...

RSA is used for both 1 (authentication) and 2 (computing symmetric key).

Bevorzugt: TLS_DHE_RSA_WITH_AES _... oder TLS_ECDHE_RSA_WITH_AES _...

RSA is used for 1 (authentication) and for signing the DHE keys.
DHE is used for 2 (computing symmetric key).

Bevorzugt, da Sie Perfect Forward Security (PFS) erhalten

Nicht üblich: DH_RSA _... (dies ist der nicht kurzlebige DH in der Frage von OP)

DH is used for both 1 (Authentication) and 2 (computing symmetric key).

Der Fall, auf den Sie sich beziehen, ist der dritte ("nicht häufig"). Wie Sie sehen können, wird RSA weder für 1 (Authentifizierung) noch für 2 (Berechnung des symmetrischen Schlüssels) verwendet, sodass kein Verlust des privaten RSA-Schlüssels in Frage kommt . Der RSA in DH_RSA könnte irreführend sein, aber wie Tom Leek erwähnte, stellt der Administrator des Servers einer Zertifizierungsstelle (Certificate Authority) Anmeldeinformationen und ihren öffentlichen DH-Schlüssel zur Verfügung, der dann den öffentlichen DH-Schlüssel mit dem privaten RSA-Schlüssel der Zertifizierungsstelle signiert.

4
Babu Srinivasan