it-swarm-eu.dev

Grundlegendes zu 2048-Bit-SSL und 256-Bit-Verschlüsselung

Auf der Seite von DigiCert wird ein 2048-Bit-SSL mit einer 256-Bit-Verschlüsselung angekündigt: http://www.digicert.com/256-bit-ssl-certificates.htm

Was genau ist hier der Unterschied und warum wird auf zwei Verschlüsselungsbits verwiesen?

Hier ist ein Screenshot der Anzeige:

(

In der Premium-SSL-Anzeige von Geotrust wird Folgendes beworben:

Security: domain control validation, strong 256-bit encryption, 2048-bit root

Was ist der Unterschied zwischen 256-Bit-Verschlüsselung und 2048-Bit-Root?

Hoffe das klärt die Frage.

63
JohnJ

Das 2048-Bit handelt vom RSA-Schlüsselpaar: RSA-Schlüssel sind mathematische Objekte, die eine große Ganzzahl enthalten, und ein "2048-Bit-Schlüssel" ist ein Schlüssel, bei dem die große Ganzzahl größer als ist. 22047 aber kleiner als 22048.

Bei 256 Bit geht es um SSL. In SSL wird der Serverschlüssel nur verwendet, um einen zufälligen 256-Bit-Schlüssel () zu übertragen, der keine mathematische Struktur hat, sondern nur ein Bündel von Bits); Grob gesagt generiert der Client einen zufälligen 256-Bit-Schlüssel, verschlüsselt ihn mit dem öffentlichen RSA-Schlüssel des Servers (der im Serverzertifikat enthalten ist und ein "2048-Bit-Schlüssel" ist) und sendet das Ergebnis an den Server. Der Server verwendet seinen privaten RSA-Schlüssel, um den Vorgang umzukehren und so den vom Client ausgewählten 256-Bit-Schlüssel zu erhalten. Anschließend verwenden Client und Server das 256-Bit-System, um symmetrische Verschlüsselungs- und Integritätsprüfungen durchzuführen, und RSA wird für diese Verbindung nicht weiter verwendet.

Siehe diese Antwort für weitere Details. Dieses Setup wird häufig als "Hybridverschlüsselung" bezeichnet. Dies geschieht, weil RSA nicht für die Massenverschlüsselung geeignet ist, die symmetrische Verschlüsselung jedoch nicht das anfängliche öffentliche/private Geschäft ausführen kann, das für den Start erforderlich ist.

(SSL kann den Schlüsselaustausch mit anderen Algorithmen als RSA durchführen, daher habe ich die Beschreibung im obigen Text etwas vereinfacht, aber das ist der Kern der Idee.)

69
Thomas Pornin

Um ein wenig mehr Details hinzuzufügen, wird der 2048-Bit-RSA-Schlüssel als asymmetrische Kryptographie bezeichnet. Es wird zur Überprüfung der Identität (Signatur) und zur Sicherstellung verwendet, dass nur ein vorgesehener Empfänger auf die gesendeten Informationen zugreifen kann (Verschlüsselung). Es besteht aus zwei Teilen, einem öffentlichen Schlüssel und einem privaten Schlüssel. Die Schlüssel sind tatsächlich miteinander verwandt, aber da sie durch zwei sehr große Pseudo-Primzahlen (Primzahlen im Verhältnis zueinander) verbunden sind, ist es sehr schwierig, den privaten Schlüssel aus der Öffentlichkeit herauszufinden.

Da der Algorithmus auf etwas basiert, das einfach nur schwer herauszufinden ist (aber lösbar ist), ist er weniger sicher als ein symmetrischer Algorithmus, der auf einem gemeinsamen Geheimnis basiert, das mathematisch nicht lösbar ist und nicht auf der Komplexität beruht eines mathematischen Problems für die Sicherheit (dazu später mehr). Aus diesem Grund ist der Schlüssel so viel größer als das symmetrische Gegenstück (das nur 256 Bit beträgt). Um die Gleichung schwer zu lösen, ist der viel größere Schlüssel erforderlich. Je mehr Informationen mit dem asymmetrischen Schlüssel übertragen werden, desto wahrscheinlicher ist es, dass er beschädigt wird (außerdem ist die Verschlüsselung/Entschlüsselung prozessorintensiver).

Aus diesem Grund verwendet SSL RSA nur für die Validierungs- und Schlüsselaustauschphasen. Stattdessen wird ein symmetrischer Schlüssel (in diesem Fall 256 Bit, wenn er vom Browser auf dem Client unterstützt wird) generiert und über RSA-Verschlüsselung an den Server zurückgesendet. Anschließend werden die restlichen Daten über den gemeinsam genutzten Schlüssel und einen symmetrischen Algorithmus ausgetauscht.

Dies geschieht, indem der Client zuerst die Antwort auf eine Herausforderung entschlüsselt, die der Server mit seinem privaten Schlüssel verschlüsselt. Der Client kann dann den öffentlichen Schlüssel des Servers anzeigen (der von einem bekannten Stammschlüssel signiert ist, den die Zertifizierungsstelle (in diesem Fall DigiCert) ) war in den meisten Browsern enthalten). Wenn die dekodierte Antwort der Herausforderung entspricht, weiß der Client, dass der Server auf die Anforderung geantwortet hat (obwohl möglicherweise ein mittlerer Mann sie weiterleitet). Der Client generiert dann den symmetrischen 256-Bit-Schlüssel, verschlüsselt ihn mit dem öffentlichen Schlüssel des Servers und sendet ihn an den Server. Da der Schlüssel mit dem öffentlichen Schlüssel des Servers verschlüsselt ist, kann ihn nur der Server (der den privaten Schlüssel kennt) entschlüsseln. Dies bedeutet, dass jeder mittlere Mann im vorherigen Schritt den neuen freigegebenen Schlüssel nicht kennen kann. Der Client kann nun darauf vertrauen, dass alle über den gemeinsam genutzten Schlüssel gesendeten Informationen nur vom vorgesehenen Server stammen.

15
AJ Henderson

Nur um den vorhandenen Antworten einige Details hinzuzufügen ...

meine Frage ist, wie würde der Client wissen, um einen zufälligen 256-Bit-Schlüssel zu generieren? (Warum nicht 128?).

Dies hängt von der ausgehandelten Verschlüsselungssuite ab. Die Liste der als Teil von TLS 1.1 definierten befindet sich in RFC 4346 Anhang A.5 . Beispielsweise TLS_RSA_WITH_AES_128_CBC_SHA verwendet einen 128-Bit-Schlüssel, während TLS_DHE_RSA_WITH_AES_256_CBC_SHA verwendet einen 256-Bit-Schlüssel.

Welche Cipher Suite ausgehandelt wird, hängt von der Client- und Serverkonfiguration ab, nicht vom auf dem Server installierten Zertifikat. Wenn der Client die Verbindung mit einem Client Hello Nachricht sendet es eine Liste der unterstützten Chiffresuiten. Der Server wählt dann den gewünschten aus und sagt dies in seinem Server Hello Botschaft.

Diese Verschlüsselungssuite bestimmt dann, wie diese symmetrischen Schlüssel schließlich gemeinsam genutzt werden. Der unmittelbare Zweck des SSL/TLS-Handshakes besteht darin, ein gemeinsames Pre-Master-Geheimnis zwischen dem Client und dem Server herzustellen. Dies wird allgemein als Schlüsselaustausch (siehe RFC 4346 Anhang F.1.1) bezeichnet.

Dies fällt in zwei Kategorien (ohne anonymen Schlüsselaustausch):

  • RSA-Schlüsselaustausch (z. B. TLS_RSA_WITH_AES_128_CBC_SHA): Der Client verschlüsselt das Pre-Master-Geheimnis mit dem öffentlichen Schlüssel des Servers (im Zertifikat enthalten).
  • DH (E) -Schlüsselaustausch (z. B. TLS_DHE_RSA_WITH_AES_256_CBC_SHA): Es findet ein Diffie-Hellman-Schlüsselaustausch statt. Der Server signiert seine DH-Parameter und der Client überprüft die Signatur anhand des öffentlichen Schlüssels im Serverzertifikat. (Ein RSA-basiertes Zertifikat bedeutet keinen RSA-Schlüsselaustausch.)

Am Ende des Handshakes, unabhängig davon, welcher dieser beiden Schritte verwendet wurde, besitzen der Client und der Server ein gemeinsames Pre-Master-Geheimnis von von denen sie ein Hauptgeheimnis ableiten (siehe RFC 4346 Abschnitt 8.1 ).

Aus diesem Hauptgeheimnis können beide Parteien die Verschlüsselungsschlüssel (und MAC-Geheimnisse) ableiten, wie in RFC 4346 Abschnitt 6. beschrieben .

Außer dem Schlüsseltyp (RSA oder DSS) gibt es nichts, was die Größe des Verschlüsselungsschlüssels vom Zertifikat abhängig macht. Darüber hinaus verfügen beide Typen über Cipher Suites, die 256-Bit-Schlüssel verwenden: zum Beispiel TLS_DHE_DSS_WITH_AES_256_CBC_SHA und TLS_DHE_RSA_WITH_AES_256_CBC_SHA. (DSS ist ein Nur-Signatur-Algorithmus, sodass Sie keinen RSA-ähnlichen Schlüsselaustausch erhalten würden, um das Pre-Master-Geheimnis zu verschlüsseln.)

Die Größe des Schlüssels im Zertifikat ist nur wichtig, um eine Fälschung des Schlüsselaustauschs zu verhindern (oder um den aufgezeichneten Datenverkehr zurück zu entschlüsseln): Wenn jemand den privaten Schlüssel aus dem öffentlichen Schlüssel im Zertifikat finden konnte, könnte er als solcher fungieren ein MITM, das sich als der reale Server ausgibt, oder das in der Lage wäre, das verschlüsselte Pre-Master-Geheimnis (und damit den aufgezeichneten Verkehr) bei Verwendung eines RSA-Schlüsselaustauschs zu entschlüsseln (DHE-Chiffresuiten sind genau darauf ausgelegt, den Zugriff auf das Pre-Master-Geheimnis zu verhindern , selbst wenn der Angreifer den privaten Schlüssel und den aufgezeichneten Verkehr erhält, siehe diese Frage ). Aus diesem Grund ist ein ausreichend großer asymmetrischer Schlüssel wichtig.

Zertifizierungsstellen neigen dazu, "256 Bit" auf ihre Websites zu setzen, da dies aus Marketing-Sicht gut aussieht.

Es ist nicht falsch, aber es kann für Leute irreführend sein, die nicht verstehen, dass es darauf ankommt, wie Ihr Server eingerichtet ist und was Ihre Kunden unterstützen.

9
Bruno