Christian Seiler: Get oder Post

Beitrag lesen

Hallo Martin,

ich glaube, so langsam vestehe ich das Prinzip zumindest ansatzweise, auch wenn mir einiges noch wie schwarze Magie vorkommt. Allein aus den Daten, die beim Diffie-Hellman-Handshake ausgetauscht werden, kann man also noch nicht die nachher übertragenen Daten entschlüsseln. Das muss ich mir wohl in einer ruhigen Stunde nochmal durch den Kopf gehen lassen, denn es kommt mir intuitiv irgendwie paradox vor.

Zur Veranschaulichung von DH gibt's übrigens folgendes Experiment: Alice und Bob suchen sich beide eine geheime Farbe aus, die sie niemandem weitergeben. Zum Beispiel wählt Bob blau und Alice rot. Alice sucht sich dann eine dritte Farbe aus (hier z.B. gelb) und schickt Bob die Farbe (die kann jeder sehen, die dritte Farbe ist also öffentlich). Bob mischt dann die Farbe zu seiner eigenen Farbe (blau + gelb = grün) und schickt Alice das Ergebnis. Alice mischt ihrerseits wiederum die öffentliche Farbe gelb mit ihrer Farbe rot (= orange) und gibt die Farbe dann Bob. Beide mischen dann ihre geheime Farbe zur Farbe, die sie vom Gegenüber erhalten haben. Alice mischt rot + grün = braun und Bob mischt orange + blau = braun. Beide haben dann eine gemeinsame Farbe braun, die jedoch nie zwischen beiden geschickt wurde.

Natürlich hat das mit den Farben einen großen Haken: Wenn man sich die Farben ansieht, kann man mit etwas Ahnung von Farbenlehre ableiten, welche Farbe die geheime Farbe gewesen sein muss; wenn die öffentliche Farbe gelb ist und Bob grün zurückschickt, dann ist es für einen Menschen nicht schwierig, daraus abzuleiten, dass Bob blau gehabt haben muss. Allerdings ist zumindest das physikalische Trennen der Farbe grün in gelb und blau bestenfalls sehr, sehr schwierig. Und genau da funktioniert die Analogie wieder: Es ist mathematisch so schwierig, aus den übermittelten Informationen das Geheimnis einer Partei zu erhalten, dass man es besser gleich bleiben lässt.

Bildlich gesprochen:
[...]

Soweit kann ich folgen. Schön gezeichnet übrigens.  ;-)

Wie können nun Zertifikate helfen, Man-in-the-Middel zu vermeiden? Ganz einfach: Es werden nicht nur die DH-Informationen übertragen, die DH-Informationen werden zusätzlich noch mit dem eigenen privaten Schlüssel signiert.

Halt: Was heißt "signiert"? Eine Verschlüsselung kann es ja in dieser Phase des Handshakes noch nicht sein. Und gebe ich damit nicht gerade wieder den privaten Schlüssel preis, der die Geschichte bis hierher "sicher" gemacht hat?

Ok, signieren kann bei bestimmten Algorithmen sehr kompliziert werden, deswegen nehme ich hier einfach mal RSA an und erkläre den mal genauer. RSA ist ein asymmetrischer Verschlüsselungsalgorithmus. Für einen symmetrischen Verschlüsselungsalgorithmus kann man sich in der Regel einen beliebigen Schlüssel heraussuchen (bzw. aus Zufallsdaten erzeugen) und den dann mit dem Verfahren nutzen, das Verfahren legt der Form des Schlüssels in den meisten Fällen keine besonderen Beschränkungen auf, als AES-Schlüssel kann man z.B. alles mögliche nehmen, was 128 bit lang ist. Bei einem asymmetrischen Verschlüsselungsalgorithmus ändern sich gleich zwei Dinge:

  1. Die Wahl des Schlüssels ist nicht mehr so einfach möglich, d.h. man kann nicht irgend etwas beliebiges als Schlüssel nutzen. Deswegen verwenden asymmetrische Verfahren auch riesige Schlüssellängen von 1024, 2048 oder gar 4096 bit während symmetrische Verfahren bei viel geringeren Schlüseellängen (256 bit) als genauso sicher gelten. Wobei es neuerdings asymmetrische Verfahren auf anderen mathematischen Überlegungen beruhend gibt, die auch mit geringeren Schlüssellängen auskommen sollen, allerdings sind die Verfahren noch sehr neu und es wurden in meinen Augen noch nicht genügend Versuche unternommen, sie zu knacken, weswegen ich da noch etwas warten würde, das einzusetzen. Das ganze nennt sich "Elliptic Curve Cryptopgrahy (ECC)".

  2. Wenn man sich einen Schlüssel erzeugt, erzeugt man nicht nur *einen* Schlüssel, sondern ein Schlüsselpaar. Das heißt, man besitzt dann zwei Schlüssel. Die Schlüssel haben die Eigenschaft, dass es mathematisch viel zu aufwändig ist, aus dem einen Schlüssel den anderen herzuleiten und umgekehrt [1]. Einen von beiden nimmst Du dann als öffentlichen Schlüssel, den kann ruhig jeder kennen, den anderen nimmst Du als privaten Schlüssel und den _darf_ niemand außer Dir kennen.

Wie funktioniert nun RSA? Ganz einfach: Wenn Du etwas mit einem Schlüssel verschlüsselst, kannst Du es nur mit dem anderen entschlüsseln. Mal aufgezeichnet:

+-----------+               +-----------+               +-----------+
| Nachricht |  Schlüssel 1  |   Mit S1  |  Schlüssel 2  | Nachricht |
| im Klar-  |-------------->|  verschl. |-------------->| im Klar-  |
|   text    |               | Nachricht |               |   text    |
+-----------+               +-----------+               +-----------+
      |                           |
      | Schlüssel 2               | Schlüssel 1
      |                           |
      v                           v
+-----------+                +----------+
|   Mit S2  |  Schlüssel 2   | Zeichen- |
|  verschl. |--------------->|  salat   |
| Nachricht |                |          |
+-----------+                +----------+
      |
      | Schlüssel 1
      |
      v
+-----------+
| Nachricht |
| im Klar-  |
|   text    |
+-----------+

Mit RSA kann man nun zwei Dinge bewerkstellign:

* Verschlüsselung
 * Digitale Signaturen

Zum Teil mit der Verschlüsselung: Stell Dir vor, ich habe mir ein RSA-Schlüsselpaar erzeugt und habe den öffentlichen Schlüssel veröffentlicht. Du willst mir nun eine verschlüselte Botschaft schicken, die nur ich lesen kann. Was machst Du? Du verschlüsselst die Botschaft mit meinem öffentlichen Schlüssel. Danach kann nur noch jemand, der meinen privaten Schlüssel besitzt (im Idealfall nur ich) die Nachricht wieder entschlüsseln. Der öffentliche Schlüssel, den jeder Angreifer auch kennen kann, ist für die Entschlüsseung nutzlos.

Dann digitale Signaturen: Stell Dir vor, ich will Dir eine Nachricht schicken, die zwar durchaus unverschlüsselt über die Leitung gehen darf, von der Du aber wissen können musst, dass sie wirklich von mir ist. Was mache ich? Ich hashe die Nachricht (mit SHA1 z.B.) und verschlüssele das Ergebnis des Hashes mit meinem privaten (!) Schlüssel. Das schicke ich dann zusammen mit der Nachricht selbst an Dich. Du kannst dann meinen öffentlichen (!) Schlüssel (den Du kennst) nutzen, um den Hash wieder zu entschlüsseln; dann bildest Du selbst wieder den Hash der Nachricht, vergleichst und schon weißt Du, ob die Nachricht authentisch ist, oder nicht.

[Wenn Dich die Mathematik zur RSA näher interessiert: Es gibt im Internet eine ganze Menge Seiten, die sich mehr oder weniger intensiv mit dem Thema auseinandersetzen.]

Was hier an der ganzen Sache besonders wichtig ist, ist dass Du den korrekten öffentlichen Schlüssel von mir besitzt. Der darf zwar allen bekannt sein, muss aber korrekt (!) sein. Stell Dir vor, ein Angreifer jubelt Dir einen öffentlichen Schlüssel unter, zu dem der Angreifer den privaten Schlüssel hat und behauptet, der öffentliche Schlüssel wäre meiner, obwohl das nicht stimmt. Wenn Du dann eine Nachricht mit diesem Schlüssel verschlüsselst, braucht der Angreifer die Nachricht nur abfangen, dann kann er sie selbst entschlüsseln und - damit ich keinen Verdacht hege - sie selbst mit meinem richtigen öffentlichen Schlüssel verschlüsseln und mir weiterschicken. Genauso kann er eine unterschriebene Nachricht, die von mir kommt, abfangen, den Hash entfernen, die Nachricht modifizieren, selbst mit seinem eigenen privaten Schlüssel den neuen Hash signieren und Dir das Ergebnis dann schicken - Du würdest denken, die Nachricht wäre authentisch. Aus diesem Grund gibt es bei SSL/TLS sogenannte Certification Authorities (CAs), die sich darum kümmern, öffentliche Schlüssel zu beglaubigen. Alle Browser haben einen Satz von öffentlichen Schlüsseln einiger CAs vorinstalliert, von denen die Browserhersteller denken, dass die User ihnen vertrauen können. Mit diesen öffentlichen Schlüsseln der CAs können die Browser dann die Unterschriften unter den öffentlichen Schlüsseln der Server verifizieren und so überprüfen, ob ein Serverschlüssel authentisch ist, oder nicht.

Wenn der Client nun eine Nachricht vom Server erhält, die zum einen die notwendigen DH-Informationen des Servers, zum anderen jedoch auch eine digitale Signatur mit dem privaten Schlüssel des Servers, kann sie mit Hilfe des öffentlichen Schlüssels des Servers überprüfen, ob die digitale Signatur wirklich authentisch ist, d.h. wirklich vom Sever kommt.

Na gut - aber bei unserem "Woman-in-the-middle"-Szenario würde sich Eve doch Alice gegenüber als Bob ausgeben, also auch sein Zertifikat weiterreichen, ohne sich um dessen Inhalt kümmern zu müssen.

Das Zertifikat weiterzureichen ist wie gesagt kein Problem, aber Du hast ja drei Dinge die übertragen werden: Zertifikat, DH-Parameter und Signatur zu den DH-Parametern. Wenn Du das Zertifikat weiterreichst, MUSS die Signatur der DH-Parameter dann sowohl zu den DH-Parametern als auch zum Zertifikat passen, d.h. wenn Du eins austauscht (Du willst die DH-Parameter austauschen, so dass Du mit dem Client einen eigenen Key aushandeln kannst und dann mit dem Server nochmal einen Key und dann den "Mittler" in der Kommunikation spielen kannst), dann musst Du auch die Signatur anpassen - das Problem ist, dass Du keine Signatur erzeugen kannst, die zum Zertifikat passt, d.h. Dir bleibt nichts anderes übrig, als auch das Zertifikat auszutauschen, was dann aber dazu führt, dass der Client das auch merkt.

Eine zweite Möglichkeit wäre das von Dir angesprochene: Er könnte das Zertifikat vom Server durchreichen. Problem ist hierbei nur, dass der Angreifer dann dem Client ja seine eigenen DH-Parameter zukommen lassen müsste, um sich einklinken zu können. Nur kann der Angreifer die natürlich nicht mit dem privaten Schlüssel des Servers signieren, weil er diesen nicht besitzt.

Ja, aber das ist doch wurscht - der Client kennt ja den *privaten* Schlüssel des Servers auch nicht, also kann er doch gar nicht feststellen, ob der "echt" ist.

Doch, mit dem öffentlichen Schlüssel der Servers. Das ist ja gerade das Tolle an asymmetrischen Verfahren: mit dem öffentlichen Schlüssel kann man feststellen, ob jemand im Besitz des zugehörigen privaten Schlüssels ist, ohne überhaupt den zugehörigen privaten Schlüssel zu kennen.

Viele Grüße,
Christian

[1] Allerdings ist es bei RSA der Fall, dass man aus einem der beiden erzeugten Schlüssel leichter (aber immer noch sehr aufwendig) den anderen herleiten kann, als umgekehrt, deswegen nimmt man den günstigeren als öffentlichen Schlüssel, damit man es den Angreifern möglichst erschwert.

--
"I have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone." - Bjarne Stroustrup