PFS - Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) oder auch nur Forward Secrecy ist ein Verfahren, dass verhindern soll, dass eine in der Vergangenheit geführt und aufgezeichnete verschlüsselte Kommunikation durch Bekanntwerden des geheimen Schlüssels nachträglich entschlüsselt werden kann. Sofern ein Angreifer sich in der Lage befindet einen Sitzungsschlüssels zu knacken, kann er dabei nicht automatisch auf den Folgeschlüssel schließen.

Bei PFS darf SSL/TLS den geheimen Schlüssel nur zum Authentifizieren des Webservers und der Schlüsselaustausch-Daten verwenden. Für den Austausch des symmetrischen Sitzungsschlüssels handeln die Kommunikationspartner jedes Mal ein neues, temporär gültiges Schlüsselpaar aus. Ist der Schlüsselaustausch abgeschlossen muss das temporäre Schlüsselpaar sofort gelöscht werden.

Angriffsszenario: "Heute sammmeln, morgen knacken"

Seit Mitte 2013 ist bekannt, dass die NSA (US-Geheimdienst) die verschlüsselte Kommunikation im Internet archiviert. Dabei geht die NSA nach dem Prinzip vor: "heute sammeln, morgen knacken". Die Daten werden jetzt gesammelt, mit dem Gedanken, zu einem späteren Zeitpunkt an die Inhalte zu kommen. Die NSA spekuliert darauf, die Daten zu einem späteren Zeitpunkt schnell und einfach entschlüsseln zu können. Die Wahrscheinlichkeit das 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 werden.

Das Problem: Übertragung des geheimen Schlüssels

Das Problem bei diesem häufig angewendeten Verfahren ist, dass der Sitzungsschlüssel übertragen wird. Der ist zwar verschlüsselt. Aber wenn ein Angreifer die Kommunikation aufzeichnet und irgendwann an den privaten Schlüssel des Servers gelangt, dann kann der Angreifer den Sitzungsschlüssel auslesen und somit auch die 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), damit beim erneuten Verbindungsaufbau der Krypto-Handshake entfallen kann. Unter Umständen kann der Angreifer dieses Session Ticket auslesen.

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

Der erste und wichtigste Schritt ist, dass der geheime Sitzungsschlüssel nirgendwo dauerhaft gespeichert oder wie bei der asymmetrischen Verschlüsselung der geheime Sitzungsschlüssel übertragen wird. Dazu muss ein Verfahren zum Einsatz kommen, bei dem sich beide Kommunikationspartner auf einen Schlüssel einigen, ohne ihn zu übertragen. Diffie-Hellman ist ein solches Schlüsselaustauschverfahren.
Zusätzlich muss man noch verhindern, dass wenn doch mal ein Sitzungsschlüssel bekannt wird, dass dann nicht automatisch auf alle weiteren Sitzungsschlüssel geschlossen werden kann. Hier ist Perfect Forward Secrecy das Mittel der Wahl.

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 Aufzeichner nicht an den tatsächlichen Schlüssel heran, sofern der Schlüssel nach der Kommunikation verworfen wird. Auch ein nachträgliches Bekanntwerden des geheimen, privaten Schlüssels ist kein Problem, weil kein Sitzungsschlüssel übertragen wird.

Aber ein Problem bleibt weiterhin. Die aufeinanderfolgenden 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 das Problem.

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. Auf diese Weise haben die einzelnen Sitzungsschlüssel keinen Bezug zueinander.

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 kennt, daraus einen anderen ableiten kann.

Diffie-Hellman und PFS in der Praxis

Diffie-Hellman und PFS sind schon lange bekannt und teilweise im Einsatz. So erfordert SSH V2, das es schon seit 1998 gibt, einen Schlüsselaustausch mit Diffie-Hellman und Perfect Forward Secrecy. Auch bei IPsec kommt PFS oft zum Einsatz.
Und auch SSL/TLS bietet mehrere Schlüsselaustauschverfahren an, die auf Diffie-Hellman und PFS beruhen. Allerdings kommen die eher selten zum Einsatz. 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. Hier muss man berücksichtigen, dass ein Server länger mit einer einzigen Anfrage ausgelastet wird, was natürlich dazu führt, dass ein Server mehr Rechenleistung braucht. Und das kostet natürlich Geld.

Als Anwender hat man nur selten die Möglichkeit einem Server die möglichst sichersten Verfahren zur Verschlüsselung zu diktieren. Im Zweifelsfall entscheidet immer der Server, welches Verschlüsselungsverfahren zum Einsatz kommt. Was wiederum der Betreiber festlegt. Der Client könnte dem Server zwar nur die wirklich sicheren Verschlüsselungsverfahren anbieten. Doch das würde bedeuten, dass zu manchem Server keine verschlüsselte Verbindung möglich ist, was dann auch nicht Sinn der Sache ist. In der Regel ist die Datensicherheit nicht so sehr in Gefahr, dass nicht eine weniger wirkungsvolle Verschlüsselung ebenso akzeptabel wäre. Hier muss man von Fall zu Fall entscheiden. Unternehmen haben dazu eine Security Policy.

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 die Kommunikation zu manipulieren und beiden Teilnehmern einen eigenen Sitzungsschlüssel aufzuzwingen. Das wäre nur dann möglich, wenn die Teilnehmer die Identität gegenseitig unzureichend prüfen würden oder die Validierungsstelle manipuliert wäre.
Alternativ könnte sich der Angreifer Zugriff auf den Arbeitsspeicher einer der beiden Teilnehmer verschaffen, um den Sitzungsschlüssel während der Dauer der Kommunikation abzugreifen.
Beide Fälle sind mit erheblichem Aufwand verbunden, für die der Angreifer umfangreiche Ressourcen und Zugriffsmöglichkeiten benötigt. Die routinemäßige Überwachung der 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 aktuelle 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.

Übersicht: SSL / TLS