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?

    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


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

Anzeige
Stellenmarkt
  1. DLR Deutsches Zentrum für Luft- und Raumfahrt e.V., Oberpfaffenhofen bei München
  2. Robert Bosch GmbH, Leonberg
  3. IFS Deutschland GmbH & Co. KG, Erlangen
  4. über Robert Half Technology, Bielefeld


Anzeige
Blu-ray-Angebote
  1. 21,99€ (Vorbesteller-Preisgarantie)
  2. 5,49€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Elementary OS Loki im Test: Hübsch und einfach kann auch kompliziert sein
Elementary OS Loki im Test
Hübsch und einfach kann auch kompliziert sein
  1. Linux-Distribution Ubuntu diskutiert Ende der 32-Bit-Unterstützung
  2. Dells XPS 13 mit Ubuntu im Test Endlich ein Top-Notebook mit Linux!
  3. Aquaris M10 Ubuntu Edition im Test Ubuntu versaut noch jedes Tablet

Wolkenkratzer: Wer will schon 2.900 Stufen steigen?
Wolkenkratzer
Wer will schon 2.900 Stufen steigen?
  1. Hafen Die Schauerleute von heute sind riesig und automatisch
  2. Bahn Siemens verbessert Internet im Zug mit Funklochfenstern
  3. Fraunhofer-Institut Rekord mit Multi-Gigabit-Funk über 37 Kilometer

Festplatten mit Flash-Cache: Das Konzept der SSHD ist gescheitert
Festplatten mit Flash-Cache
Das Konzept der SSHD ist gescheitert
  1. Ironwolf, Skyhawk und Barracuda Drei neue 10-TByte-Modelle von Seagate
  2. 3PAR-Systeme HPE kündigt 7,68- und 15,36-TByte-SSDs an
  3. NVM Express und U.2 Supermicro gibt SATA- und SAS-SSDs bald auf

  1. Polaris-Grafikkarten: AMD stellt Radeon RX 470 und RX 460 vor
    Polaris-Grafikkarten
    AMD stellt Radeon RX 470 und RX 460 vor

    Die Polaris-Familie wird vervollständigt: Die Radeon RX 470 und Radeon RX 460 sind Gaming-Grafikkarten, das kleinere Modell erscheint unter gleichem Namen auch für Spiele-Notebooks. Interessant finden wir die Taktraten, welche eine Einschätzung schwierig machen.

  2. Windows 10 Anniversary Update: Cortana wird zur alleinigen Suchfunktion
    Windows 10 Anniversary Update
    Cortana wird zur alleinigen Suchfunktion

    Mit dem Anniversary Update für Windows 10 wird die bisher optionale Suche durch Cortana ersetzt. Wer die Assistentin dann noch loswerden will, kann das zwar auf Umwegen - dann gibt es aber keine Suchfunktion mehr, zumindest nicht ohne weitere Software.

  3. Quartalsbericht: Amazon schwimmt im Geld
    Quartalsbericht
    Amazon schwimmt im Geld

    Amazon kann das fünfte Mal in Folge einen Rekordgewinn vorlegen. Die Zeiten, in denen der weltgrößte Internethändler meist einen knappen Gewinn machte oder ein Minus erwirtschaftete, scheinen vorbei zu sein.


  1. 06:00

  2. 23:26

  3. 22:58

  4. 22:43

  5. 18:45

  6. 17:23

  7. 15:58

  8. 15:42