Diffie-Hellman ist ein Schlüsselaustauschprotokoll, tut jedoch nichts gegen die Authentifizierung.

Es gibt eine konzeptionelle Möglichkeit auf hoher Ebene, dies zu erkennen. In der Welt der Computernetzwerke und der Kryptographie können Sie nur Nullen und Einsen sehen, die über einige Kabel gesendet werden. Entitäten können nur durch die Nullen und Einsen voneinander unterschieden werden, die sie senden können oder nicht. Somit ist der Benutzer "Bob" wirklich nur durch seine Fähigkeit definiert, Dinge zu berechnen, die Nicht-Bobs nicht berechnen können. Da jeder die gleichen Computer kaufen kann, kann Bob Bob nur sein, wenn er einen Wert kennt, den nur Bob kennt.

In dem von Ihnen präsentierten rohen Diffie-Hellman-Austausch sprechen Sie mit einer Entität, die angenommen wird um einen zufälligen geheimen Wert im laufenden Betrieb zu generieren und diesen zu verwenden. Jeder kann eine solche zufällige Erzeugung durchführen. An keiner Stelle im Protokoll gibt es eine Operation, die nur ein bestimmter Bob ausführen kann. Daher kann das Protokoll keine Authentifizierung erreichen - Sie wissen nicht, mit wem Sie sprechen. Ohne Authentifizierung ist ein Identitätswechsel möglich, und dazu gehört auch der gleichzeitige doppelte Identitätswechsel, besser bekannt als Man-in-the-Middle. Im besten Fall bietet Diffie-Hellman eine schwächere Funktion: Obwohl Sie nicht wissen, mit wem Sie sprechen, wissen Sie dennoch, dass Sie während der gesamten Sitzung mit derselben Entität sprechen.

Ein einziger kryptografischer Algorithmus bringt Sie nicht weit. Jedes signifikante Kommunikationsprotokoll stellt mehrere Algorithmen zusammen, so dass bestimmte Sicherheitsmerkmale erreicht werden. Ein Paradebeispiel ist SSL / TLS; Ein anderer ist SSH. In SSH wird ein Diffie-Hellman-Schlüsselaustausch verwendet, aber der öffentliche Teil des Servers (sein g ^{/ sup> mod p ) ist vom Server signiert . Der Client weiß, dass er mit dem richtigen Server kommuniziert, da sich der Client (aus einem vorherigen Initialisierungsschritt) den öffentlichen Schlüssel des Servers merkt (normalerweise vom Typ RSA oder DSA). In dem oben erläuterten Modell werden die rechtmäßigen Server definiert und von Nachahmern durch ihre Kenntnis des privaten Signaturschlüssels unterschieden, der dem öffentlichen Schlüssel entspricht, an den sich der Client erinnert. Diese Signatur liefert die Authentifizierung; Der Diffie-Hellman erzeugt dann ein gemeinsames Geheimnis, das zum Verschlüsseln und Schützen des gesamten Datenaustauschs für diese Verbindung verwendet wird (unter Verwendung einiger symmetrischer Verschlüsselungs- und MAC-Algorithmen).}

Während Diffie-Hellman dies nicht tut Alles, was Sie für sich selbst benötigen, bietet dennoch eine nützliche Funktion, nämlich einen Schlüsselaustausch, den Sie bei digitalen Signaturen nicht erhalten würden, und der das temporäre gemeinsame Geheimnis bereitstellt, das zum Verschlüsseln der tatsächlich ausgetauschten Daten erforderlich ist.

Tom hat eine gute Erklärung geliefert, warum Diffie-Hellman nicht vor Mann in der Mitte sicher sein kann. Dies beantwortet nun die ursprüngliche Frage des OP, lässt aber wahrscheinlich einige Leser mit der (vernünftigen) Folgefrage zurück: Warum verwenden wir nicht einfach die (asymmetrische) Kryptographie mit öffentlichem Schlüssel, um die Vertraulichkeit unserer Nachrichten zu gewährleisten, und löschen D-H insgesamt? Es gibt einige Gründe, dies nicht zu tun:

• Es gibt Algorithmen, die nur das Signieren, aber nicht das Verschlüsseln von Nachrichten unterstützen (z. B. ECDSA).
• Symmetrische Ver- und Entschlüsselung ist a viel schneller als asymmetrisch
• Wahrscheinlich am wichtigsten ist, dass wir Vorwärtsgeheimnis gewährleisten wollen. Schließlich ist es nicht unmöglich, dass der private Schlüssel eines Ihrer Kommunikationspartner irgendwann kompromittiert wird. Wenn Sie sich nur auf asymmetrische Verschlüsselung verlassen, können alle Nachrichten, die Sie jemals an diesen Partner gesendet haben, vom Angreifer im Nachhinein entschlüsselt werden. Wenn wir dagegen Diffie-Hellman verwenden - und genauer gesagt, kurzlebiges Diffie-Hellman , generieren wir für jede Kommunikationssitzung ein neues DH-Schlüsselpaar und werfen es anschließend weg (= nicht speichern) Dies bedeutet, dass es unmöglich ist, unsere Nachrichten zu einem späteren Zeitpunkt zu entschlüsseln.

Nach einem DH-Schlüsselaustausch wissen beide Parteien, welchen Schlüssel sie berechnet haben. Wenn kein Mann in der Mitte die Verbindung infiltriert hat, haben beide Parteien den gleichen Schlüssel. Wenn die Verbindung unterbrochen wurde, haben sie unterschiedliche Schlüssel. Wenn es ein Mittel gibt, mit dem eine Partei die andere fragen kann, welchen Schlüssel sie verwendet, kann der Mann in der Mitte nur dann unentdeckt bleiben, wenn er auf die gleiche Weise reagieren kann, wie es die legitime Partei getan hätte. Während die Frage häufig mit einer digitalen Signatur beantwortet wird, um den Identitätswechsel zu erschweren, kann die Frage auch über Sprachkommunikation gestellt / beantwortet werden. Wenn eine Sprachanwendung den Teilnehmern den aktuellen Verschlüsselungsschlüssel anzeigt und ein Teilnehmer willkürlich einen Bereich und einen beliebten Filmstar (z. B. Marilyn Monroe) auswählt und den anderen auffordert, die fünfzehnten bis fünfundzwanzigsten Ziffern in seiner besten Marilyn Monroe-Stimme zu lesen, a Ein echter Teilnehmer, der die Zahlen vor sich hat, könnte dies schnell und flüssig tun, und ohne einen MITM-Angriff würden die Ziffern mit denen der ersten Partei übereinstimmen. Ein Angreifer in der Mitte hätte kein Problem damit, die Frage zu erkennen, und könnte - mit der Zeit - eine Sprachdatei des legitimen Kommunikanten fälschen, der eine schlechte Nachahmung von Marilyn Monroe macht und die entsprechenden Ziffern sagt, würde dies aber tun Es fällt mir schwer, das so schnell wie das echte zu tun.

Kurz gesagt, DH allein kann gegen MITM-Angriffe robust sein, wenn jeder Teilnehmer etwas weiß, was der andere Teilnehmer mit einer Nummer effizienter als ein Angreifer tun kann. Andere Protokolle werden jedoch im Allgemeinen in Verbindung mit DH verwendet, da es nützlich ist, den Authentifizierungsprozess zu automatisieren, und die meisten Authentifizierungsformen, die nicht auf Verschlüsselung beruhen (z. B. Sprache, Phrasierung usw.), eine menschliche Validierung erfordern. Darüber hinaus ist es häufig erforderlich, dass Entitäten die Kommunikation von Fremden erbitten. Wenn Sie mit einem Vertreter der Acme Bank sprechen möchten, könnte ein Betrüger in der Mitte ein falsches "Acme Bank" -Büro einrichten und meinen Anruf entgegennehmen und jemanden in einem falschen Wohnzimmer dazu bringen, alles, was ich sage, an den Real weiterzuleiten Acme Bank, und niemand wäre klüger. Wenn ich keine Ahnung hätte, wie gut oder schlecht ein echter Mitarbeiter der Acme Bank Marilyn Monroe nachahmen könnte, hätte ich keine Möglichkeit zu wissen, dass die Nachahmung eines Betrügers nicht dieselbe ist.

DH ist im Allgemeinen nicht resistent gegen Man in the Middle-Angriffe.

Wenn Alice und Bob (A<-> B) ein gemeinsames Geheimnis einrichten können. Dann kann Frank ein gemeinsames Geheimnis mit Alice einrichten (A<-> F). Gleichzeitig kann Frank ein zweites (anderes) gemeinsames Geheimnis mit Bob einrichten (F<-> B). Frank kann dann A-> F-Nachrichten entschlüsseln und erneut verschlüsseln und an Bob F-> B & senden.

* Sie müssen also sicherstellen, dass die Nachricht tatsächlich stammt (von signiert wurde) ) Alice. Entweder mit einem zuvor gemeinsam genutzten Geheimnis (über einen anderen Kanal bereitgestellt) oder mithilfe einer Zertifizierungsstelle (für die Proxy-Vertrauensstellung). Oder eine andere Methode.

Wenn Sie einer Zertifizierungsstelle nur ein wenig vertrauen, kann Alice ein gemeinsames DH-Geheimnis mit Bob einrichten und die Nachricht mit dem Zertifikat der Zertifizierungsstelle signieren. Bob überprüft, ob die Nachrichten von der Zertifizierungsstelle signiert wurden. Frank kann die Nachrichten nicht fälschen, da sie nicht das erforderliche Zertifikat haben.

Jetzt haben Alice und Bob ein gemeinsames Geheimnis. Frank konnte sich nicht in die Mitte täuschen. Die Zertifizierungsstelle war jedoch nicht an der Erstellung des gemeinsamen Geheimnisses beteiligt (sie signierte nur die auf dem Weg gesendeten Teile). Daher kann die Zertifizierungsstelle auch nicht als schlechter Schauspieler auftreten. Auch wenn Frank ihnen mit einem 5-Dollar-Schraubenschlüssel droht.

* Etwas simpel, aber das ist die allgemeine Idee.

Ich muss einen Punkt in Tom Leeks Antwort präzisieren: "In SSH wird ein Diffie-Hellman-Schlüsselaustausch verwendet, aber der öffentliche Teil des Servers (sein g ^{b sup> mod p) ist signiert vom Server. "}

Tatsächlich ist der gesamte DH-Schlüsselaustausch signiert. Es reicht nicht aus, nur g ^{b sup> mod p zu signieren: Man könnte den SSH-Server fälschen, indem man einfach eine Verbindung zu ihm herstellt und das [SSH-TRANS] -Paket später wiedergibt. Dies beweist keine Kenntnis der Daten der aktuellen Sitzung. g a sup> mod p, die SSH-ID-Zeichenfolgen und die Protokollaushandlung werden weggelassen.}

Die Authentifizierung erfolgt, nachdem die beiden Parteien SSH-ID-Zeichenfolgen und Protokollaushandlungsnachrichten ausgetauscht haben und der Client sendet eine Diffie-Hellman-Schlüsselaustauschnachricht, die g ^{a sup> mod p enthält.}

Der Server berechnet g ^{b sup> mod p und hasht alle wichtigen Informationen: H = Hash (Kontext || sig_pub || g a sup> mod p || g b sup> mod p || g ab sup> mod p) mit context = SSH ID-Zeichenfolgen || Protokollverhandlungsnachrichten.}

Dann wird der Handshake-Hash signiert: sig = Signatur (sig_priv, H) und an den Client zurückgesendet (sig_pub, g ^{b sup> mod p, sig).}

Auf diese Weise kann niemand etwas fälschen, außer wenn er den Signaturalgorithmus gebrochen hat.

Hier versagen die sprachlichen Beschreibungsfähigkeiten der englischen Sprache. Diffie Helman ist resistent gegen Mitm, wenn ein Out-of-Band-Drittanbieter bei der Verteilung von Schlüsseln und / oder der Überprüfung der Identität helfen kann. In der Literatur finden Sie meistens ein verbundenes Vertrauensnetz, das die Identität des Empfängers oder in den meisten Fällen die Person, die dem Schlüssel oder Zertifikat zugeordnet ist, umgibt.