Abo
  1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Perfect Forward Secrecy…

Wirklich?

Anzeige
  1. Thema

Neues Thema Ansicht wechseln


  1. Wirklich?

    Autor: coelna 28.06.13 - 15:51

    "Normalerweise ist verschlüsselte Kommunikation nur sicher, solange die benutzten Schlüssel geheim bleiben. Anders ist das mit einer cleveren Technologie, die auf dem Diffie-Hellman-Verfahren basiert."

    Soll das heißen, wenn man DH zur >>Schlüsseleinigung<< nutzt, hat das einen Einfluss darauf, ob das Passwort nützlich ist, wenn es bekannt ist?

  2. Re: Wirklich?

    Autor: Regenbogenlilli 28.06.13 - 16:04

    Ich habe das anders verstanden. Durch DH wird bei jeder Kommunikation ein Schlüssel neu erzeugt. Dieser kann dann am Ende weg geschmissen werden und die Kommunikationsdaten, die evtl. von der NSA aufgezeichnet wurden, können nicht mehr entschlüsselt werden, da ja der Schlüssel weg ist. Sollte der Schlüssel aber nicht gelöscht werden, oder die NSA ist schon auf deinem Rechner, dann kann mit dem Schlüssel natürlich alles wieder entschlüsselt werden.

  3. Re: Wirklich?

    Autor: coelna 28.06.13 - 16:29

    Trotzdem bleibt es dabei.
    Schlüssel bekannt => Kommunikation bekannt. Vielleicht ist dann die zweite Kommunikation nicht betroffen. Im Grunde hat das aber garnichts mit DH zu tun.

  4. Re: Wirklich?

    Autor: robinx999 28.06.13 - 16:47

    soweit ich verstehe aber nur mit einer man in the middle atacke. Sonst sollte keiner an den Schlüssel kommen.
    Ist das nicht vereinfacht so wie hier dargestellt?
    https://www.youtube.com/watch?v=3QnD2c4Xovk

  5. Re: Wirklich?

    Autor: tangonuevo 28.06.13 - 16:48

    coelna schrieb:
    --------------------------------------------------------------------------------
    > Trotzdem bleibt es dabei.
    > Schlüssel bekannt => Kommunikation bekannt. Vielleicht ist dann die zweite
    > Kommunikation nicht betroffen. Im Grunde hat das aber garnichts mit DH zu
    > tun.

    Was wilst du uns damit sagen? DH verhindert die im Artikel beschriebene Möglichkeit, daß Geheimdienste einfach alles aufzeichnen in der Hoffnung durch späteren Einbruch an die Schlüssel zu kommen. Da kein real existierender Webbrowser oder Webserver (soweit nicht bereits gehackt) generierte Sessionschlüssel abspeichert (was ziemlich blödsinnig wäre), ist der genannte Angriff praktisch abgewehrt.

    PS: Wenns dir nur um die Semantik der von dir zitierten Aussage geht, da sind unterschiedliche Schlüssel gemeint. Die Kommunikation ist sicher, obwohl der *private Schlüssel* eines oder beider Kommunikationspartner bekannt sein kann.



    1 mal bearbeitet, zuletzt am 28.06.13 16:54 durch tangonuevo.

  6. Re: Wirklich?

    Autor: -.- 28.06.13 - 16:56

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > soweit ich verstehe aber nur mit einer man in the middle atacke. Sonst
    > sollte keiner an den Schlüssel kommen.

    Das Diffie-Hellman-Verfahren ist in der Tat anfällig gegen MITM-Angriffe; um diese zu vermeiden, müssen die DH-Schlüssel in irgendeiner Weise an den Besitzer gebunden werden, z.B. in Form eines Zertifikats einer Zertifizierungsstelle.

  7. Re: Wirklich?

    Autor: invalid 28.06.13 - 16:59

    tangonuevo schrieb:
    --------------------------------------------------------------------------------
    > Was wilst du uns damit sagen? DH verhindert die im Artikel beschriebene
    > Möglichkeit, daß Geheimdienste einfach alles aufzeichnen in der Hoffnung
    > durch späteren Einbruch an die Schlüssel zu kommen. Da kein real
    > existierender Webbrowser oder Webserver (soweit nicht bereits gehackt)
    > generierte Sessionschlüssel abspeichert (was ziemlich blödsinnig wäre), ist
    > der genannte Angriff praktisch abgewehrt.

    Ob der Sessionkey gespeichert wird oder nicht ist belanglos. Er wurde berechnet und er kann jederzeit wieder berechnet werden. Vorausgesetzt man besitzt alle dazu nötigen Daten also auch mindestens einen Privatekeys.

    Man kann nun auch die Privatekeys bzw. die Schlüsselpaare vor der Sitzung zufällig erzeugen und danach vernichten. Dann können sie nicht ausspioniert werden, womöglich aber aus den Publickeys berechnet werden. Weiterhin wird dann ein Man-In-the-Middle Angriff möglich weil man den eigenen Publickey nicht zuverlässig (geschützt gegen Veränderung) an die andere Partei transferieren kann.

  8. Re: Wirklich?

    Autor: tangonuevo 28.06.13 - 17:17

    invalid schrieb:
    --------------------------------------------------------------------------------
    > Man kann nun auch die Privatekeys bzw. die Schlüsselpaare vor der Sitzung
    > zufällig erzeugen und danach vernichten.

    Und nur dann schützt das Verfahren gegen die im Artikel beschriebene Attacke. Geh doch dann einfach mal davon aus, dass das Verfahren genau diese Methode benutzt.

    > Dann können sie nicht ausspioniert
    > werden, womöglich aber aus den Publickeys berechnet werden.

    Nur wenn das Public-Key Verfahren gebrochen ist. Ne bescheuerte Annahme, denn ohne anzunehmen, daß die grundlegenden Verschlüsselungsverfahren sicher sind, können wir Verschlüsselung gleich ganz lassen.

    > Weiterhin wird
    > dann ein Man-In-the-Middle Angriff möglich weil man den eigenen Publickey
    > nicht zuverlässig (geschützt gegen Veränderung) an die andere Partei
    > transferieren kann.

    Das ist aber ein viel aufwendigerer Angriff, während einfach mal alles speichern für die NSA viel einfacher ist. Zweitens könnte man das Aushandeln des DH innerhalb der normalen SSL Session ablaufen lassen, die ja Man-in-the-Middle (in der Theorie, leider nicht ganz in der Praxis) verhindert.

  9. Re: Wirklich?

    Autor: invalid 28.06.13 - 17:34

    tangonuevo schrieb:
    --------------------------------------------------------------------------------
    > invalid schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Man kann nun auch die Privatekeys bzw. die Schlüsselpaare vor der
    > Sitzung
    > > zufällig erzeugen und danach vernichten.
    >
    > Und nur dann schützt das Verfahren gegen die im Artikel beschriebene
    > Attacke. Geh doch dann einfach mal davon aus, dass das Verfahren genau
    > diese Methode benutzt.

    Es gibt mehrere denkbare Angriffe um den Private Key zu erhalten. Wenn man Angriffe nicht ernst nimmt dann kann man auch nicht zu sicheren Lösungen zu kommen.

    Angriff 1)
    Diebstahl, .. des Private Keys. Dieser wird relativ gut durch Diffie Hellman mit wechselnden Schlüsselpaaren (also eben nicht nur mit wechselnden Session Keys) unterbunden.

    Angriff 2)
    Berechnen des Privatekeys aus dem Publickey. Das geht nicht nur bei gebrochenen Verfahren sondern auch bei zu kurzen Schlüsseln. Für RSA kann mit Sicherheit 512 Bit als unsicher angesehen werden. Auch 768 Bit würde ich nicht als sicher gelten lassen. 1024 Bit ist bei einem Gegner wie die NSA sicher auch nicht angeraten. Die Aufwendungen sind zwar hoch und müssen individuell für jeden Schlüssel gelöst werden aber wer weiß. Der Primäre Angriffsvektor ist die Primfaktorzelegung, sollte auf diesem Gebiet jemand einen erheblichen Wissensvorsprung haben, dann gelten sämtliche bekannten Größen hier nicht mehr. Auch Wissen um die Verteilung von Primzahlen kann zu erheblich verbesserten Angriffen führen. Ggf. sind ja auch Formen von Tabellen (Rainbowtables) denkbar wenn man über genug Geld verfügt.

    Angriff 3)
    Schwache Schlüsselerzeugung. Sollten die Schlüsselpaare durch schwache Zufallszahlen vorhersagbar sein, dann könnten für ein Angreifer die Privatekeys erratbar sein. Solche schwache Schlüsselerzeugung kann auch vorsätzlich in Software eingeschleust werden. Es gab schon reichlich von solchen Fehlern auch in Open Source Software.

    ... to be extended ...
    Ein professioneller Angreifer (NSA) wird sicher noch mehr ausarbeiten als ich hier in wenigen Minuten.

  10. Re: Wirklich?

    Autor: *ubuntuuser 29.06.13 - 09:47

    Regenbogenlilli schrieb:
    --------------------------------------------------------------------------------
    > Ich habe das anders verstanden. Durch DH wird bei jeder Kommunikation ein
    > Schlüssel neu erzeugt. Dieser kann dann am Ende weg geschmissen werden und
    > die Kommunikationsdaten, die evtl. von der NSA aufgezeichnet wurden, können
    > nicht mehr entschlüsselt werden, da ja der Schlüssel weg ist. Sollte der
    > Schlüssel aber nicht gelöscht werden, oder die NSA ist schon auf deinem
    > Rechner, dann kann mit dem Schlüssel natürlich alles wieder entschlüsselt
    > werden.

    Das funktioniert ein bisschen anders:

    Der Schlüssel für die symetrische Verschlüsselung wird sowieso für jede Session neu (mit Hilfe von Zufallswerten) generiert. Nur müssen ja Client und Server den selben Schlüssel haben, und dafür gibt es zb. eben DH; oder der bei TLS meistens verwendete RSA-basierte Austausch.

    Grob gesagt generiert der Client, beim RSA-basierten Verfahren, den symetric Key und verschlüsselt diesen mit dem Public-key des Servers. Danach kann der Client den verschlüsselten Key zum Server senden, da nur noch mehr dieser mit seinem privaten Key in der Lage ist diesen zu entschlüsseln, was dieser auch macht. Ab diesem Zeitpunkt haben beide den selben symetric Key und können die Kommunikation verschlüsseln.
    Jeman der nun die Kommunikation aufzeichnet hat nun 2 dinge: Die verschlüsselte Kommunikation an sich, und den verschlüsselten Key dazu. Wenn dieser aber in Zukunft irgendwann an den private Key des Servers kommt (zb. durch einen Hackerangriff) kann dieser damit die verschlüsselten symetric Keys aller aufgezeichneten Sessions entschlüsseln und im Anschluss darauf auch die Kommunikation der Sessions selbst.

    Beim DH-Verfahren wird der symetric Key aber niemals über die Leitung übertragen, somit hilft es dem Anfreiger auch nicht wenn er in Zukunft an den private Key gelangt.

    Ich hoffe ich konnte das einigermaßen anschaulich erklären, wenn nicht einfach nochmal nachfragen.

    Mfg

  11. Re: Wirklich?

    Autor: tangonuevo 29.06.13 - 11:15

    invalid schrieb:
    --------------------------------------------------------------------------------
    > Es gibt mehrere denkbare Angriffe um den Private Key zu erhalten. Wenn man
    > Angriffe nicht ernst nimmt dann kann man auch nicht zu sicheren Lösungen zu
    > kommen.
    >
    > Angriff 1)
    > Diebstahl, .. des Private Keys. Dieser wird relativ gut durch Diffie
    > Hellman mit wechselnden Schlüsselpaaren (also eben nicht nur mit
    > wechselnden Session Keys) unterbunden.
    > ...

    Angriff n) Die NSA bedroht einen der Kommunikationspartner mit einem grossen Knüppel und haut ihn, bis er verrät, was er geschickt hat.

    Unbestreitbar gibt es auch nach korrekter Anwendung von DH weiter Möglichkeiten für Angreifer, an die Kommunikation zu kommen und wie man an n) sieht, ist es praktisch unmöglich eine Kommunikation *absolut* sicher zu machen. Die für die NSA momentan vermutlich einfachste Methode wäre aber verwehrt. Es wäre damit sicherer als vorher. Die Aussagen in deinem ersten Post sind immer noch falsch.

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Anzeige
Stellenmarkt
  1. Robert Bosch GmbH, Hildesheim
  2. Robert Bosch GmbH, Stuttgart-Feuerbach
  3. AOK - Die Gesundheitskasse für Niedersachsen, Hannover
  4. ETAS GmbH, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Top-Angebote
  1. mit Gutscheincode PCGAMES17 nur 82,99€ statt 89,99€
  2. 299,00€
  3. 47,99€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Xperia Touch im Test: Sonys coolem Android-Projektor fehlt das Killerfeature
Xperia Touch im Test
Sonys coolem Android-Projektor fehlt das Killerfeature
  1. Roboter Sony lässt Aibo als Alexa-Konkurrenten wieder auferstehen
  2. Sony Xperia XZ1 Compact im Test Alternativlos für Freunde kleiner Smartphones
  3. Sony Xperia XZ1 und XZ1 Compact sind erhältlich

Arktika 1 im Test: Monster-verseuchte Eiszeitschönheit
Arktika 1 im Test
Monster-verseuchte Eiszeitschönheit
  1. TPCast Oculus Rift erhält Funkmodul
  2. Oculus Go Alleine lauffähiges VR-Headset für 200 US-Dollar vorgestellt
  3. Virtual Reality Update bindet Steam-Rift in Oculus Home ein

ZFS ausprobiert: Ein Dateisystem fürs Rechenzentrum im privaten Einsatz
ZFS ausprobiert
Ein Dateisystem fürs Rechenzentrum im privaten Einsatz
  1. Librem 5 Purism zeigt Funktionsprototyp für freies Linux-Smartphone
  2. Pipewire Fedora bekommt neues Multimedia-Framework
  3. Linux-Desktops Gnome 3.26 räumt die Systemeinstellungen auf

  1. U-Bahn: Telefónica baut BTS-Hotels im Berliner Untergrund
    U-Bahn
    Telefónica baut BTS-Hotels im Berliner Untergrund

    Die Einzelheiten über den längst fälligen Mobilfunk-Ausbau in der Berliner U-Bahn werden erst langsam öffentlich. Dank moderner Technik brauchen die Betreiber weniger Betriebsräume.

  2. Kabelnetz: Statt auf Docsis 3.1 lieber gleich auf Glasfaser setzen
    Kabelnetz
    Statt auf Docsis 3.1 lieber gleich auf Glasfaser setzen

    Besonders kleinere Kabelnetzbetreiber sollten statt Docsis 3.1 das Koaxialkabel direkt durch Glasfaser ersetzen. Das alte Koaxkabel bleibe sonst immer ein Flaschenhals.

  3. Virtuelle Güter: Activision patentiert Förderung von Mikrotransaktionen
    Virtuelle Güter
    Activision patentiert Förderung von Mikrotransaktionen

    Der Umsatz mit Mikrotransaktionen lässt sich durch einfache Tricks noch steigern - und Activision hat dafür nun ein Patent. Bislang kommt das System aber nach Angaben der Firma noch nicht zum Einsatz.


  1. 19:09

  2. 17:40

  3. 17:02

  4. 16:35

  5. 15:53

  6. 15:00

  7. 14:31

  8. 14:16