it-swarm.com.de

Wie funktionieren die Prozesse für digitale Zertifikate, Signaturen und SSL?

Ich habe versucht zu verstehen, wie SSL funktioniert. Betrachten wir anstelle von Alice und Bob die Client- und Serverkommunikation. Der Server verfügt über ein digitales Zertifikat, das von einer Zertifizierungsstelle erworben wurde. Es hat auch öffentliche und private Schlüssel. Der Server möchte eine Nachricht an den Client senden. Der öffentliche Schlüssel des Servers steht dem Client bereits zur Verfügung.

Angenommen, der SSL-Handshake ist abgeschlossen.

Server zu Client:

  • Der Server hängt seinen öffentlichen Schlüssel an die Nachricht an.
  • Führt die Hash-Funktion aus (Nachricht + öffentlicher Schlüssel). Die Ergebnisse sind als HMAC bekannt.
  • Verschlüsseln Sie HMAC mit seinem privaten Schlüssel. Das Ergebnis wird als digitale Signatur bezeichnet.
  • Senden Sie es zusammen mit dem digitalen Zertifikat an den Kunden.
  • Der Client überprüft das Zertifikat und stellt fest, dass es vom erwarteten Server stammt.
  • Entschlüsselt HMAC mit dem öffentlichen Schlüssel des Servers.
  • Führt die Hash-Funktion aus (Nachricht + öffentlicher Schlüssel), um die ursprüngliche Nachricht zu erhalten.

Client zu Server

  • Der Client führt die Hash-Funktion aus (Nachricht + öffentlicher Schlüssel) und verschlüsselt dann mit demselben öffentlichen Schlüssel.
  • Der Server entschlüsselt mit einem privaten Schlüssel und führt die Hash-Funktion für die resultierenden Daten aus, um die Nachricht zu erhalten.

Bitte lassen Sie mich wissen, ob mein Verständnis korrekt ist.

27
John

Es gibt ein paar Verwirrungen in Ihrem Beitrag. Erstens ist HMAC keine Hash-Funktion . Mehr über HMAC später.

Hash-Funktionen

A Hash-Funktion ist ein vollständig öffentlicher Algorithmus (kein Schlüssel darin), der Bit auf eine Weise zusammenfügt, die wirklich nicht zu entwirren ist: Jeder kann die Hash-Funktion für beliebige Daten ausführen, aber die finden Daten aus der Hash-Ausgabe scheinen weit über unseren Verstand hinauszugehen. Die Hash-Ausgabe hat eine feste Größe, typischerweise 256 Bit (mit SHA-256) oder 512 Bit (mit SHA-512). Die SHA- * -Funktion, die 160 Bit ausgibt, heißt SHA-1, nicht SHA-160, da Kryptographen, die sich selbst überlassen bleiben, nur so lange vernünftig bleiben können und sicherlich nicht über das fünfte Pint hinaus.

Signaturalgorithmen

Ein Signatur Algorithmus verwendet ein Schlüsselpaar, das mathematisch miteinander verknüpft ist, den privaten Schlüssel und den öffentlichen Schlüssel ( Das Neuberechnen des privaten Schlüssels aus dem öffentlichen Schlüssel ist theoretisch machbar, aber in der Praxis selbst mit Really Big Computers zu schwierig. Aus diesem Grund muss der öffentliche Schlüssel öffentlich gemacht werden, während der private Schlüssel privat bleibt. Unter Verwendung der mathematischen Struktur der Schlüssel ermöglicht der Signaturalgorithmus:

  • to generate eine Signatur für einige Eingabedaten unter Verwendung des privaten Schlüssels (die Signatur ist ein mathematisches Objekt, das relativ kompakt ist, z. B. einige hundert Bytes für eine typische RSA-Signatur);
  • to verify eine Signatur für einige Eingabedaten mit dem öffentlichen Schlüssel. Die Überprüfung verwendet als Parameter die Signatur, die Eingabedaten und den öffentlichen Schlüssel und gibt entweder "perfekt, Mann!" Zurück. oder "Alter, diese passen nicht zusammen".

Für einen sicheren Signaturalgorithmus ist es angeblich nicht möglich, einen Signaturwert und Eingabedaten so zu erstellen, dass der Überprüfungsalgorithmus mit einem bestimmten öffentlichen Schlüssel "gut" sagt, es sei denn Sie kennen den entsprechenden privaten Schlüssel, In diesem Fall ist es einfach und effizient. Beachten Sie das Kleingedruckte: Ohne den privaten Schlüssel können Sie einige Daten nicht heraufbeschwören und einen Signaturwert, der mit dem öffentlichen Schlüssel funktioniert, selbst wenn Sie die Daten und die Signatur nach Ihren Wünschen auswählen können.

"Angeblich nicht durchführbar" bedeutet, dass alle intelligenten Kryptographen der Welt mehrere Jahre daran gearbeitet haben und auch nach dem fünften Pint keinen Weg gefunden haben, dies zu tun.

Die meisten (eigentlich alle) Signaturalgorithmen beginnen mit der Verarbeitung der Eingabedaten mit einer Hash-Funktion und arbeiten dann nur mit dem Hash-Wert. Dies liegt daran, dass der Signaturalgorithmus mathematische Objekte in bestimmten Mengen benötigt, deren Größe begrenzt ist. Daher müssen sie an Werten arbeiten, die "nicht zu groß" sind, z. B. die Ausgabe einer Hash-Funktion. Aufgrund der Art der Hash-Funktion funktionieren die Dinge gut (das Signieren der Hash-Ausgabe ist genauso gut wie das Signieren der Hash-Eingabe).

Schlüsselaustausch und asymmetrische Verschlüsselung

Ein Schlüsselaustauschprotokoll ist ein Protokoll, bei dem beide Parteien mathematische Objekte aufeinander werfen, wobei jedes Objekt möglicherweise mit einigen geheimen Werten verknüpft ist, die sie für sie behalten, ähnlich wie public/private Schlüsselpaare. Am Ende des Schlüsselaustauschs können beide Parteien einen gemeinsamen "Wert" (ein weiteres mathematisches Objekt) berechnen, der dem Zugriff derjenigen, die die auf dem Draht ausgetauschten Bits beobachtet haben, völlig entgeht. Eine gebräuchliche Art von Schlüsselaustauschalgorithmus ist asymmetrische Verschlüsselung. Bei der asymmetrischen Verschlüsselung wird ein öffentliches/privates Schlüsselpaar verwendet (nicht unbedingt dieselbe Art wie bei einem Signaturalgorithmus):

  • Mit dem öffentlichen Schlüssel können Sie verschlüsseln ein Datenelement. Diese Daten sind normalerweise in ihrer Größe beschränkt (z. B. nicht mehr als 117 Bytes für RSA mit einem öffentlichen 1024-Bit-Schlüssel). Das Verschlüsselungsergebnis ist ein mathematisches Objekt, das in eine Folge von Bytes codiert werden kann.
  • Mit dem privaten Schlüssel können Sie entschlüsseln, d. H. Die umgekehrte Operation ausführen und die anfänglichen Eingabedaten wiederherstellen. Es wird angenommen, dass ohne den privaten Schlüssel Pech.

Dann läuft das Schlüsselaustauschprotokoll folgendermaßen ab: Eine Partei wählt einen zufälligen Wert (eine Folge von zufälligen Bytes), verschlüsselt diesen mit dem öffentlichen Schlüssel des Peers und sendet ihm diesen. Der Peer verwendet seinen privaten Schlüssel zum Entschlüsseln und stellt den zufälligen Wert wieder her, der das gemeinsame Geheimnis ist.

Eine historische Erklärung für Signaturen lautet: "Verschlüsselung mit dem privaten Schlüssel, Entschlüsselung mit dem öffentlichen Schlüssel". Vergiss diese Erklärung. Es ist falsch. Dies gilt möglicherweise nur für einen bestimmten Algorithmus (RSA) und andererseits nur für eine heruntergekommene Version von RSA, die tatsächlich keine angemessene Sicherheit bietet. Also nein , digitale Signaturen sind keine asymmetrische Verschlüsselung "in umgekehrter Richtung".

Symmetrische Kryptographie

Sobald zwei Parteien einen gemeinsamen geheimen Wert haben, können sie symmetrische Kryptographie verwenden, um weitere Daten auf vertrauliche Weise auszutauschen. Es wird als symmetrisch bezeichnet, weil beide Parteien den gleichen Schlüssel haben, d. H. Das gleiche Wissen, d. H. Die gleiche Leistung. Keine private/öffentliche Zweiteilung mehr. Es werden zwei Grundelemente verwendet:

  • Symmetrische Verschlüsselung : Wie man Daten entwirrt und später entwirrt.
  • Nachrichtenauthentifizierungscodes : eine "verschlüsselte Prüfsumme": Nur Personen, die den geheimen Schlüssel kennen, können den MAC für einige Daten berechnen (es ist wie bei einem Signaturalgorithmus, bei dem der private und der öffentliche Schlüssel identisch sind - also der "öffentliche" Schlüssel sollte besser nicht öffentlich sein!).

HMAC ist eine Art MAC, der auf intelligente Weise über Hash-Funktionen aufgebaut ist, da es viele nicht intelligente Möglichkeiten gibt, dies zu tun, und die aufgrund von subtilen Details , was eine Hash-Funktion bietet und bietet keine.

Zertifikate

Ein Zertifikat ist ein Container für einen öffentlichen Schlüssel. Mit den oben erläuterten Tools kann man sich vorstellen, dass der Server über einen öffentlichen Schlüssel verfügt, mit dem der Client einen Schlüsselaustausch mit dem Server durchführt. Aber wie stellt der Client sicher, dass er den öffentlichen Schlüssel des richtigen Servers verwendet und nicht den eines hinterhältigen Angreifers, eines Bösewichts, der sich schlau als Server ausgibt? Hier kommen Zertifikate ins Spiel. Ein Zertifikat wird signiert von jemandem, der auf die Überprüfung physischer Identitäten spezialisiert ist; es heißt Certificate Authority. Die Zertifizierungsstelle trifft den Server "im realen Leben" (z. B. in einer Leiste), überprüft die Serveridentität, holt den öffentlichen Serverschlüssel vom Server selbst und signiert das gesamte Los (Serveridentität und Öffentlicher Schlüssel). Dies führt zu einem raffinierten Paket, das als Zertifikat bezeichnet wird. Das Zertifikat stellt die Garantie dar von der Zertifizierungsstelle, dass der Name und der öffentliche Schlüssel miteinander übereinstimmen (hoffentlich ist die Zertifizierungsstelle nicht zu leichtgläubig, sodass die Garantie zuverlässig ist - vorzugsweise die Zertifizierungsstelle not Zertifikate nach dem fünften Pint unterschreiben).

Wenn der Client das Zertifikat sieht, kann er die Signatur des Zertifikats relativ zum öffentlichen CA-Schlüssel überprüfen und so das Vertrauen gewinnen, dass der öffentliche Serverschlüssel tatsächlich zum beabsichtigten Server gehört.

Aber Sie würden mir sagen, was haben wir gewonnen? Wir müssen noch einen öffentlichen Schlüssel kennen, nämlich den öffentlichen CA-Schlüssel. Wie überprüfen wir das? Nun, wir können ein anderes CA verwenden. Dies verschiebt das Problem nur, kann jedoch zu dem Problem führen, dass a priori ein eindeutiger oder eine Handvoll öffentlicher Schlüssel von Über-CAs bekannt ist, die von niemand anderem signiert wurden. Nachdenklich hat Microsoft etwa hundert solcher "öffentlichen Stammschlüssel" (auch als "Vertrauensanker" bezeichnet) tief in Internet Explorer selbst eingebettet. Hier entsteht Vertrauen (genau, Sie haben die Grundlage Ihres Vertrauens gegenüber der Firma Redmond verwirkt - jetzt verstehen Sie, wie Bill Gates zum reichsten Mann der Welt wurde?).

[~ # ~] ssl [~ # ~]

Lassen Sie uns nun alles im SSL-Protokoll zusammenfassen, das jetzt als TLS bekannt ist ("SSL" war der Protokollname, als es eine Eigenschaft von Netscape war Konzern).

Der Client möchte mit dem Server sprechen. Es sendet eine Nachricht ("ClientHello"), die eine Reihe von Verwaltungsdaten enthält, z. B. die Liste der vom Client unterstützten Verschlüsselungsalgorithmen.

Der Server antwortet ("ServerHello"), indem er mitteilt, welche Algorithmen verwendet werden. Anschließend sendet der Server sein Zertifikat ("Zertifikat"), möglicherweise mit einigen CA-Zertifikaten, falls der Client diese benötigt (keine Stammzertifikate, sondern Zwischenzertifikate für untergeordnete CA).

Der Client überprüft das Serverzertifikat und extrahiert den öffentlichen Serverschlüssel daraus. Der Client generiert einen zufälligen Wert ("Pre-Master Secret"), verschlüsselt ihn mit dem öffentlichen Serverschlüssel und sendet das an den Server ("ClientKeyExchange").

Der Server entschlüsselt die Nachricht, erhält den Pre-Master und leitet daraus geheime Schlüssel für symmetrische Verschlüsselung und MAC ab. Der Client führt dieselbe Berechnung durch.

Der Client sendet eine Bestätigungsnachricht ("Fertig"), die mit den abgeleiteten Schlüsseln verschlüsselt und MAC-fähig ist. Der Server überprüft, ob die Nachricht "Fertig" korrekt ist, und sendet als Antwort eine eigene Nachricht "Fertig". Zu diesem Zeitpunkt verfügen sowohl Client als auch Server über alle erforderlichen symmetrischen Schlüssel und wissen, dass der "Handshake" erfolgreich war. Anwendungsdaten (z. B. eine HTTP-Anforderung) werden dann unter Verwendung der symmetrischen Verschlüsselung und des MAC ausgetauscht.

Über den Handshake hinaus ist kein öffentlicher Schlüssel oder Zertifikat an dem Prozess beteiligt. Nur symmetrische Verschlüsselung (z. B. 3DES, AES oder RC4) und MAC (normalerweise HMAC mit SHA-1 oder SHA-256).

38
Tom Leek

Nach viel Kampf. Ich habe im Folgenden die Unterschiede zwischen SSL, Asymmetric Key Encryption, Digital Certificate (DC) und Digital Signature (DS) verstanden.

Was ist ein digitales Zertifikat, auch als Public-Key-Zertifikat bekannt?

DC ist ein elektronisches Dokument, das eine digitale Signatur verwendet, um einen öffentlichen Schlüssel mit Identitätsinformationen wie Name, Adresse usw. Zu binden

Inhalt des Zertifikats: Zertifikat mit öffentlichem Schlüssel

Am wichtigsten sind der Signaturalgorithmus, der Aussteller und der öffentliche Schlüssel.

Was ist eine asymmetrische Schlüsselverschlüsselung und digitale Signatur?

Anhand eines Beispiels erklärt.

Beide Computer verfügen über ein Paar kryptografischer Schlüssel - einen öffentlichen Verschlüsselungsschlüssel und einen privaten Entschlüsselungsschlüssel.

Maschine-A hat Zugriff auf den öffentlichen Schlüssel und das Zertifikat von Maschine-B.
Maschine-B hat Zugriff auf den öffentlichen Schlüssel und das Zertifikat von Maschine-A.

Maschine-A bis Maschine-B

Bei Maschine A:

  • Hash_function (Daten) = Hash
  • Verschlüsseln (Hash) mit dem privaten Schlüssel von Machine-A = DS
  • Daten an DS und DC = Daten + DS + DC) anhängen
  • Verschlüsseln (Daten + DS + DC) mit dem öffentlichen Schlüssel von Machine-B.
  • Senden Sie es an Maschine-B.

Bei Maschine B:

  • Entschlüsseln (Daten + DS + DC) mit dem privaten Schlüssel von Maschine B.
  • Überprüfen Sie DC, um die Maschine-A zu authentifizieren.
  • Entschlüsseln (DS) mit dem öffentlichen Schlüssel von Machine-A = Hash # 1
  • Hash_function (Data) = Hash # 2
  • if (Hash # 1 == Hash # 2) Daten und Signatur sind gültig.

Maschine-B zu Maschine-A

Der Prozess ist jetzt genau umgekehrt.

Was ist SSL/TLS?

Mit dem TLS-Protokoll können Client/Server-Anwendungen über ein Netzwerk so kommunizieren, dass Abhören und Manipulationen verhindert werden. In den meisten Client-Server-Kommunikationen muss nur der Server authentifiziert werden. TLS optimiert die Verschlüsselung mit asymmetrischen Schlüsseln, um dieses Phänomen effektiv zu nutzen. Secure Sockets Layer

Client- und Server-Beispiel.

Der Server verfügt über ein digitales Zertifikat, das von einer Zertifizierungsstelle erworben wurde. Es hat auch öffentliche und private Schlüssel.

Der Benutzer klickt auf eine URL, die mit beginnt

https: //

Für diese Sitzung ist eine sichere Verbindung erforderlich. Der Browser stellt eine TCP -Verbindung auf dem HTTPS TCP Port 443) her.

  1. Client> Server: SYN
  2. Client <Server: SYN + ACK
  3. Client> Server: ACK

    SSL-Handshake bei neuer TCP-Verbindung:

  4. Client> Server: CLIENT_HELLO

    Der Client sendet einen CLIENT_HELLO-Befehl an den Server, der Folgendes umfasst:

    • Die höchste vom Client unterstützte SSL- und TLS-Version.
    • Vom Client unterstützte Chiffren. Die Chiffren sind in der Reihenfolge ihrer Präferenz aufgelistet.
    • Datenkomprimierungsmethoden, die vom Client unterstützt werden.
    • Die Sitzungs-ID. Wenn der Client eine neue SSL-Sitzung startet, lautet die Sitzungs-ID 0.
    • Zufällige Daten, die vom Client zur Verwendung bei der Schlüsselgenerierung generiert werden.
  5. Client <Server: SERVER_HELLO

    Der Server sendet einen SERVER_HELLO-Befehl an den Client, der Folgendes umfasst:

    • Die SSL- oder TLS-Version, die für die SSL-Sitzung verwendet wird.
    • Die Verschlüsselung, die für die SSL-Sitzung verwendet wird.
    • Datenkomprimierungsmethode, die für die SSL-Sitzung verwendet wird.
    • Die Sitzungs-ID für die SSL-Sitzung.
    • Zufällige Daten, die vom Server zur Verwendung bei der Schlüsselgenerierung generiert werden.
  6. Client <Server: ZERTIFIKAT (ÖFFENTLICHER SCHLÜSSEL)

    Der Server sendet den Befehl CERTIFICATE. Es enthält das Serverzertifikat.

  7. Client <Server: SERVER_DONE

    Der Server sendet den Befehl SERVER_DONE. Dieser Befehl zeigt an, dass der Server diese Phase des SSL-Handshakes abgeschlossen hat.

  8. Client> Server: CERTIFICATE_VERIFY

    Der Client informiert den Server darüber, dass er das Zertifikat des Servers überprüft hat

  9. Client> Server:

    Unter Verwendung aller bisher im Handshake generierten Daten erstellt der Client (in Zusammenarbeit mit dem Server, abhängig von der verwendeten Verschlüsselung) das Pre-Master-Geheimnis für die Sitzung und verschlüsselt es mit dem öffentlichen Schlüssel des Servers (aus dem Serverzertifikat) ) und sendet dann das verschlüsselte Pre-Master-Geheimnis an den Server.

    Der Server verwendet seinen privaten Schlüssel, um das Pre-Master-Geheimnis zu entschlüsseln, und führt dann eine Reihe von Schritten aus, um das Master-Geheimnis zu generieren.

    Der Client führt auch dieselbe Reihe von Schritten für das Pre-Master-Geheimnis aus, um dasselbe Master-Geheimnis zu generieren.

    Hinweis: In Situationen, in denen der Client authentifiziert werden muss, signiert der Client auch ein anderes Datenelement, das für diesen Handshake eindeutig ist und sowohl dem Client als auch dem Server bekannt ist. In diesem Fall sendet der Client sowohl die signierten Daten als auch das eigene Zertifikat des Clients zusammen mit dem verschlüsselten Pre-Master-Geheimnis an den Server.

  10. Client <> Server:

    Sowohl der Client als auch der Server verwenden das Hauptgeheimnis, um die Sitzungsschlüssel zu generieren. Hierbei handelt es sich um symmetrische Schlüssel, mit denen während der SSL-Sitzung ausgetauschte Informationen verschlüsselt und entschlüsselt und deren Integrität überprüft werden.

    Hinweis: Von nun an ist es eine symmetrische Schlüsselverschlüsselung.

  11. Client> Server:

    Der Client sendet eine Nachricht an den Server, in der er darüber informiert wird, dass zukünftige Nachrichten vom Client mit dem Sitzungsschlüssel verschlüsselt werden.

  12. Client> Server: BEENDET

    Der Client sendet dann eine separate (verschlüsselte) Nachricht, die angibt, dass der Teil des Handshakes beendet ist.

  13. Client <Server:

    Der Server sendet eine Nachricht an den Client, in der er darüber informiert wird, dass zukünftige Nachrichten vom Server mit dem Sitzungsschlüssel verschlüsselt werden.

  14. Client <Server: BEENDET

    Der Server sendet eine separate (verschlüsselte) Nachricht, die angibt, dass der Teil des Handshakes beendet ist.

    Der SSL-Handshake ist jetzt abgeschlossen und die Sitzung beginnt. Der Client und der Server verwenden die Sitzungsschlüssel, um die Daten, die sie untereinander senden, zu verschlüsseln und zu entschlüsseln und ihre Integrität zu überprüfen.

4
John

Für eine detailliertere Erklärung "unter der Haube" kann ich auch den folgenden Artikel vorschlagen: Die ersten paar Millisekunden einer HTTPS-Verbindung von Jeff Moser. Der Artikel verwendet Paketerfassungen einer HTTPS-Kommunikationssitzung, um die Funktionsweise des Protokolls zu veranschaulichen. Es ist interessant, die Dinge, über die wir sprechen, in Aktion zu sehen und viele "dunkle" Flecken zu beseitigen.

2
George

Nicht ganz; Die Zertifikate kommen nur während des ersten SSL-Handshakes oder während einer SSL-Neuverhandlung ins Spiel. Danach wird eine symmetrische Verschlüsselung wie AES, (3) DES oder RC4 verwendet. Krypto mit öffentlichem Schlüssel ist im Allgemeinen teurer als Krypto mit symmetrischem Schlüssel, daher wird sie im Allgemeinen verwendet, um zu Beginn einen symmetrischen Schlüssel zu vereinbaren.

1
Steve Dispensa