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?

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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

    Benutzer wird von Ihnen ignoriert. Anzeigen

  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.

    Benutzer wird von Ihnen ignoriert. Anzeigen

Neues Thema Ansicht wechseln


Entschuldigung, nur registrierte Benutzer dürfen in diesem Forum schreiben. Klicken Sie hier um sich einzuloggen


Anzeige

Haben wir etwas übersehen?

E-Mail an news@golem.de


Qubes OS angeschaut: Abschottung bringt mehr Sicherheit
Qubes OS angeschaut
Abschottung bringt mehr Sicherheit

Schenker XMG P505 im Test: Flaches Gaming-Notebook mit überraschender GTX 970M
Schenker XMG P505 im Test
Flaches Gaming-Notebook mit überraschender GTX 970M
  1. Getac S400-S3 Das Ruggedized-Notebook mit SSD-Heizung
  2. Geforce GTX 980M und 970M Maxwell verdoppelt Spielgeschwindigkeit von Notebooks
  3. Toughbook CF-LX3 Panasonics leichtes Notebook mit der Lizenz zum Runterfallen

Legale Streaming-Anbieter im Test: Netflix allein macht auch nicht glücklich
Legale Streaming-Anbieter im Test
Netflix allein macht auch nicht glücklich
  1. Netflix-Statistik Die Schweiz streamt am schnellsten
  2. Deutsche Telekom Entertain ab dem 14. Oktober mit Netflix
  3. HTML5-Videostreaming Netflix bietet volle Linux-Unterstützung

  1. Software Development Kit: Linux-Support und geringere Latenz für Oculus Rift
    Software Development Kit
    Linux-Support und geringere Latenz für Oculus Rift

    Oculus VR hat das SDK 0.4.3 veröffentlicht, welches das Dev Kit 2 eingeschränkt unter Linux unterstützt. Das Multithreading soll besser arbeiten, Unity Free wurde integriert und die Latenz verringert.

  2. Big Brother Awards: Österreich prämiert die EU Kommission und Facebook
    Big Brother Awards
    Österreich prämiert die EU Kommission und Facebook

    In Österreich wurden die Gewinner der Big Brother Awards bekanntgegeben: Nelli Kroes und Siim Kallas von der EU Kommission erhalten ihn für Ecall in Autos, Facebook für seine psychologischen Experimente mit Nutzern.

  3. iFixit: Touch-ID-Sensor im iPad mini 3 mit Klebstoff befestigt
    iFixit
    Touch-ID-Sensor im iPad mini 3 mit Klebstoff befestigt

    Die Bastler von iFixit haben das iPad Mini 3 von Apple auseinander genommen. Die Befestigung des neuen Fingerabdrucksensor ist ungewöhnlich und dürfte beim Reparieren Schwierigkeiten verursachen.


  1. 23:28

  2. 21:30

  3. 20:43

  4. 19:59

  5. 15:19

  6. 13:47

  7. 13:08

  8. 12:11