PFS - Perfect Forward Secrecy

ELektronik-KOmpendium.de
Online

Preis auf Anfrage
Vergleichen Sie diesen Kurs mit ähnlichen Kursen
Mehr ansehen

Wichtige informationen

  • Kurs
  • Online
Beschreibung

PFS - Perfect Forward Secrecy Forward Secrecy und Backward Secrecy sind Verfahren, die verhindern sollen, dass durch Bekanntwerden eines geheimen Sitzungsschlüssels die zukünftige und auch vergangene Kommunikation entschlüsselt werden kann.
Die Idee dahinter ist, dass wenn der Angreifer tatsächlich mal an einen geheimen Sitzungsschlüssel gelangen kann, dass er damit nur einen kleinen Teil der Kommunikation einsehen kann. Verfahren mit Backward und Forward Secrecy sorgen dafür, dass die geheimen Sitzungsschlüssel keinen Bezug zueinander haben.

Wichtige informationen

Was lernen Sie in diesem Kurs?

Kommunikation
Verschlüsselung

Themenkreis

Unterschied zwischen Backward und Forward Secrecy

Sofern ein Angreifer in die Lage kommt, einen Sitzungsschlüssel herauszubekommen, verhindert Backward Secrecy, dass er die vorher aufgezeichnete Kommunikation nachträglich entschlüsseln kann. Backward Secrecy ist gegeben, wenn ein Angreifer aus einem Sitzungsschlüssel nicht die vorhergehenden Sitzungsschlüssel ableiten kann.
Sofern ein Angreifer in die Lage kommt, einen Sitzungsschlüssel herauszubekommen, verhindert Forward Secrecy, dass er nicht auf die Folgeschlüssel schließen kann, um so die nachfolgende Kommunikation entschlüsseln zu können. Forward Secrecy ist gegeben, wenn ein Angreifer aus einem Sitzungsschlüssel nicht die nachfolgenden Sitzungsschlüssel ableiten kann.

Unterschied zwischen Forward Secrecy und Perfect Forward Secrecy

Neben Forward Secrecy gibt es auch noch Perfect Forward Secrecy. Oftmals wird zwischen beiden Konzepten "nicht" unterschieden. Dabei unterscheiden sich beide Verfahrensweisen in Bezug auf ihre Sicherheit erheblich voneinander.
Forward Secrecy verwendet immer die gleichen Parameter während einer Kommunikation. Zum Beispiel den Sitzungsschlüssel. Der wird erst dann neu berechnet, wenn die Kommunikation beendet und neu aufgebaut wird. Je nach Verfahren und Implementierung auch nicht immer.
Perfect Forward Secrecy verändert regelmäßig die Parameter während einer Kommunikation. Ein Sitzungsschlüssel wird also nur temporär verwendet und immer wieder neu erstellt. Dabei muss man berücksichtigen, dass die Erzeugung temporärer Parameter Rechenleistung kostet und deshalb Perfect Forward Secrecy bei Server-Betreibern nicht so beliebt und deshalb nicht so häufig aktiviert ist.

Hintergrund: "Heute sammmeln, morgen knacken"

Warum ist Backward und Forward Secrecy so wichtig? Seit Mitte 2013 ist bekannt, dass die NSA (US-Geheimdienst) Massenüberwachung betreibt. Dabei ist vorgesehen, alles an Daten zu sammeln, auch wenn sie verschlüsselt ist. Dabei geht die NSA nach dem Prinzip vor: "heute sammeln, morgen knacken". Die NSA spekuliert darauf, die Daten zu einem späteren Zeitpunkt schnell und einfach entschlüsseln zu können. Beispielsweise dann, wenn genug Rechenleistung zur Verfügung steht oder neue Erkenntnisse dazu führen, dass sich die Verschlüsselung leichter brechen lässt. Die Wahrscheinlichkeit, dass das tatsächlich irgendwann gelingt ist hoch. Denn der Sitzungsschlüssel wird bei den üblicherweise verwendeten asymmetrischen Verschlüsselungsverfahren während der Kommunikation ausgetauscht. Er kann also aufgezeichnet und zu einem späteren Zeitpunkt geknackt werden

  • Überwachung durch Geheimdienste
Problem: Übertragung des geheimen Schlüssels

Das Problem bei jedem Verschlüsselungsverfahren ist, dass der geheime Sitzungsschlüssel zwischen den Kommunikationspartnern ausgetauscht werden muss. Üblicherweise muss er dazu verschlüsselt übertragen werden. Wenn jetzt ein Angreifer die Kommunikation aufzeichnet und irgendwann an den privaten Schlüssel des Servers gelangt, dann kann der Angreifer auch den geheimen Sitzungsschlüssel herausbekommen und somit auch die gesamte Kommunikation entschlüsseln.
Das ist zum Beispiel dann möglich, wenn bei TLS der Client beim Beenden einer Verbindung den Schlüssel nicht verwirft, sondern speichert (Session Ticket). Das macht man, damit beim erneuten Verbindungsaufbau der Krypto-Handshake aus Performance-Gründen entfallen kann. Unter Umständen kann der Angreifer dieses Session Ticket auslesen.

Lösung: Diffie-Hellman-Verfahren und Perfect Forward Secrecy (PFS)

Diffie-Hellman ist ein Schlüsselaustauschverfahren, bei dem der Sitzungsschlüssel nicht übertragen wird. Und Perfect Forward Secrecy verhindert, dass ein Angreifer, der einen Sitzungsschlüssel doch herausbekommt, daraus einen anderen ableiten kann.

Der erste und wichtigste Schritt ist, dass der geheime Sitzungsschlüssel nirgendwo dauerhaft gespeichert oder wie bei der asymmetrischen Verschlüsselung übertragen wird. Dazu muss ein Verfahren zum Einsatz kommen, bei dem sich beide Kommunikationspartner auf einen Schlüssel einigen bzw. austauschen, ohne ihn zu übertragen. Diffie-Hellman ist ein solches Schlüsselaustauschverfahren, beim dem der Schlüssel nicht übertragen wird.
Bei Diffie-Hellman wird bei beiden Kommunikationspartnern das Schlüsselmaterial erzeugt und jeweils nur ein Teil davon übertragen. Auf diese Weise kommt der Angreifer oder Abhörer nicht an den tatsächlichen Schlüssel heran, sondern nur an Teile davon, aus denen der Schlüssel mathematisch berechnet wird.

Dabei bleibt ein Problem weiterhin bestehen. Die Sitzungsschlüssel werden aus dem gleichen Masterschlüssel-Material (Code, Zufallszahl, usw.) generiert und stehen somit in Bezug zueinander, weshalb sie voneinander abgeleitet werden können. Wird einer der Sitzungsschlüssel geknackt, kann man auf den Folgeschlüssel schließen. Perfect Forward Secrecy (PFS) löst dieses Problem.

Die Sitzungsschlüssel sind immer nur eine bestimmte Zeit lang gültig. Verfällt ein Sitzungsschlüssel, stößt PFS einen neuen Diffie-Hellman-Prozess an, bei dem völlig neues Schlüsselmaterial (Code, Zufallszahl, usw.) generiert wird. Und somit haben die einzelnen Sitzungsschlüssel keinen Bezug mehr zueinander. Wichtig ist, dass ein wirklich zufälliger Schlüssel generiert wird und die Sitzungsschlüssel nach der Kommunikation auf beiden Seiten gelöscht werden.

  • Diffie-Hellman-Merkle-Schlüsselaustausch
Diffie-Hellman und PFS in der Praxis

Die Verfahren Diffie-Hellman und PFS sind schon lange bekannt und teilweise im Einsatz. So erfordert zum Beispiel SSHv2, das es schon seit 1998 gibt, einen Schlüsselaustausch mit Diffie-Hellman und Perfect Forward Secrecy. Auch bei IPsec kommt oft PFS zum Einsatz.
Und auch SSL/TLS bietet mehrere Schlüsselaustauschverfahren an, die auf Diffie-Hellman und PFS beruhen.

Es gibt allerdings ein grundsätzliches Problem, weshalb Systemadministratoren Diffie-Hellman und PFS nicht so gerne einsetzen. Der Grund, die erforderlichen Berechnungen kosten Zeit und verlangsamen den SSL-Handshake. Je nach Verfahren dauert der Schlüsselaustausch zwischen 15 Prozent (ECDHE) und 300 Prozent (DHE) länger. Das heißt, ein Server wird bei einem solchen Schlüsselaustausch mehrfach zusätzlich belastet. Das geht zu Lasten der verfügbaren Rechenleistung und kostet natürlich Geld, wenn in entsprechend leistungsfähige Hardware investiert werden muss.

Neuere Verfahren basieren auf elliptischen Kurven. Die würden die Beeinträchtigungen der Geschwindigkeit beseitigen. Die setzen allerdings TLS Version 1.1 voraus, was nur mit neueren Webbrowsern und auf dem aktuellen Stand befindlichen Webservern funktioniert.

Wie sicher ist Diffie-Hellman in Kombination mit PFS?

Um an die Daten und Informationen in einer verschlüsselten Kommunikation zu kommen benötigt der Angreifer den geheimen Sitzungsschlüssel. Damit kann er die verschlüsselte Kommunikation entschlüsseln. Wenn Diffie-Hellman in Kombination mit PFS verwendet wird, dann gibt es nur zwei Möglichkeiten, wie ein Angreifer an den geheimen Sitzungsschlüssel gelangen kann.

Der eine Weg wäre per Man-in-the-Middle-Angriff die Kommunikation zu manipulieren und beiden Teilnehmern einen eigenen Sitzungsschlüssel aufzuzwingen. Das wäre nur dann möglich, wenn die Teilnehmer die mit der Identität verbundenen Zertifikate gegenseitig unzureichend prüfen würden oder die Validierungsstelle für das Zertifikat manipuliert wäre.
Alternativ könnte sich der Angreifer per Trojaner Zugriff auf den Rechner einer der beiden Teilnehmer verschaffen, um den Sitzungsschlüssel während der Dauer der Kommunikation aus dem Arbeitsspeicher abzugreifen.
Beide Fälle sind mit erheblichem Aufwand verbunden, für die der Angreifer umfangreiche Ressourcen und Zugriffsmöglichkeiten benötigt. Die Massenüberwachung einer verschlüsselten Kommunikation von Milliarden von Menschen ist damit (zur Zeit) nicht möglich.

Der Schlüsselaustausch mit Diffie-Hellman und PFS gilt als äußerst sicher und stellt aktuell das Maß der Dinge dar. Der Vorteil ist, dass der Anwender nur dafür sorgen muss, dass verschlüsselte Verbindungen mit beiden Verfahren aufgebaut werden.

Wie kann ein Nutzer erkennen, ob Diffie-Hellman und Perfect Forward Secrecy verwendet wird?

Ob die aktuelle Verbindung wirksam mit Diffie-Hellman und Perfect Forward Secrecy verschlüsselt ist, ist für den Anwender auf den ersten Blick nicht zu erkennen. Neben dem Bewusstsein, dass eine wirksame Verschlüsselung notwendig ist, ist auch eine gewisse Fachkenntnis über Verschlüsselung und die Bedienung der jeweiligen Software erforderlich. Von einem normalen Internet-Nutzer ist das nicht zu verlangen.

Neben Aufklärungsarbeit ist auch die jeweilige Software, zum Beispiel der Browser oder E-Mail-Client, stark verbesserungswürdig. Hier besteht das Problem, dass die Clients in der Regel keine Auskunft darüber geben, welche Verschlüsselungsverfahren zum Einsatz kommen. Und auch im Vorfeld einer Kommunikation ist es nicht möglich zu prüfen, welche Verschlüsselung zum Einsatz kommt.

In der Regel bleibt dem Nutzer nur übrig auf Kommandozeilen-Tools zurückzugreifen, was nicht jedermanns Sache ist.

  • Verschlüsselung prüfen
  • Analyse von SSL/TLS-Verbindungen
Übersicht: SSL / TLS
  • SSL - Secure Socket Layer
  • TLS - Transport Layer Security
  • Schwachstellen von SSL/TLS
  • HTTPS / HTTP Secure
  • HSTS - HTTP Strict Transport Security
  • OCSP - Online Certificate Status Protocol
  • CA-Pinning / Certification Authority Authorization
  • DANE - DNS-based Authentication of Named Entities
Weitere verwandte Themen:
  • Grundlagen der Netzwerk-Sicherheit
  • Verschlüsselung
  • SSH - Secure Shell
  • Diffie-Hellman-Merkle-Schlüsselaustausch

Vergleichen Sie diesen Kurs mit ähnlichen Kursen
Mehr ansehen