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

Linux Mint 17.2 im Test: Desktops ohne Schnickschack, aber mit Langzeitunterstützung
Linux Mint 17.2 im Test
Desktops ohne Schnickschack, aber mit Langzeitunterstützung
  1. Fedora 22 im Test Das Ende der Experimentierphase
  2. Linux Mint Cinnamon 2.6 verringert CPU-Last deutlich
  3. Linux-Distributionen im Test Rosa Desktop Fresh kooperiert mit aktueller Hardware

Airbus E-Fan 2.0: Elektromobilität geht auch in der Luft
Airbus E-Fan 2.0
Elektromobilität geht auch in der Luft
  1. Oneweb Airbus baut gigantische Internet-Satelliten-Konstellation
  2. Raumfahrt Airbus entwickelt wiederverwendbares Raketentriebwerk
  3. Airbus Flugzeugtragflächen sollen mit Piezoelementen Strom erzeugen

Microsoft: Preise, Systemanforderungen und Limitierungen für Windows 10
Microsoft
Preise, Systemanforderungen und Limitierungen für Windows 10
  1. Windows 10 Zweite Preview innerhalb von zwei Tagen
  2. Microsoft Neue Preview von Windows 10 ändert einiges
  3. Microsoft Windows 10 Home kostet 135 Euro

  1. Worldwide Telescope: Microsoft legt virtuellen Weltraum offen
    Worldwide Telescope
    Microsoft legt virtuellen Weltraum offen

    Mit der komplexen .Net-Anwendung Worldwide Telescope können Nutzer den Weltraum auf Grundlage von Teleskop- und Satellitenaufnahmen erkunden. Microsoft legt den Quellcode der Anwendung nun offen, wovon insbesondere Forschungs- und Bildungseinrichtungen profitieren sollen.

  2. BND-Selektorenaffäre: Die Hasen vom Bundeskanzleramt
    BND-Selektorenaffäre
    Die Hasen vom Bundeskanzleramt

    In der Affäre um unzulässige NSA-Selektoren wälzt die Regierung alle Verantwortung auf den Bundesnachrichtendienst ab. Das ist ebenso perfide wie unzulässig für eine Aufsicht, die vor allem ermöglichen und nicht kontrollieren will.

  3. Kommando zurück: Google setzt Preis des Nexus 6 wieder herauf
    Kommando zurück
    Google setzt Preis des Nexus 6 wieder herauf

    Zu früh gefreut: Gestern hat Google den Preis des Nexus 6 noch auf 420 Euro gesenkt - heute kostet das Smartphone wieder 490 Euro.


  1. 14:16

  2. 14:11

  3. 13:37

  4. 12:00

  5. 11:46

  6. 11:26

  7. 11:13

  8. 11:13