Perfect Forward Secrecy

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Perfect Forward Secrecy (PFS), auf deutsch etwa perfekte vorwärts gerichtete Geheimhaltung, ist in der Kryptographie eine Eigenschaft bestimmter Schlüsselaustauschprotokolle mit dem Ziel, einen gemeinsamen Sitzungsschlüssel so zwischen den Kommunikationspartnern zu vereinbaren, dass dieser von einem Dritten auch dann nicht rekonstruiert werden kann, wenn einer der beiden Langzeitschlüssel später einmal kompromittiert werden sollte.

Dadurch kann eine aufgezeichnete, verschlüsselte Kommunikation auch bei Kenntnis des Langzeitschlüssels nicht nachträglich entschlüsselt werden.[1] Gelegentlich wird diese Eigenschaft auch unter dem Schlagwort Folgenlosigkeit behandelt, da ein späteres Aufdecken des Langzeitschlüssels folgenlos für die Sicherheit aller früheren Sitzungen bleibt. Diese Eigenschaft betont auch die alternative englische Bezeichnung break-backward protection.

Prinzipiell kann jeder Schlüssel aufgedeckt werden – entweder durch aufwändige Analyseverfahren, durch Ausspähung, Diebstahl, Bestechung, Erpressung, Nachlässigkeit des Eigentümers oder durch eine Brute-Force-Methode. Aus diesem Grund werden Sitzungsschlüssel verwendet, die in kurzen Abständen immer wieder neu ausgehandelt werden. Ein Angreifer, dem ein derartiger Sitzungsschlüssel bekannt wird, kann deshalb nur den Teil der Kommunikation entschlüsseln, der mit diesem Sitzungsschlüssel verschlüsselt worden war.

Allerdings sind sämtliche Sitzungsschlüssel der Gefahr ausgesetzt, dass derjenige Langzeitschlüssel kompromittiert wird, der für die gesicherte Übertragung der Sitzungsschlüssel verwendet wird. Durch die Kenntnis dieses Langzeitschlüssels könnte ein möglicher Angreifer sämtlichen Datenverkehr entschlüsseln, insbesondere auch die Übertragung der Sitzungsschlüssel und somit Zugriff auf den gesamten früheren Datenverkehr erhalten.

Dies wird durch Perfect Forward Secrecy unterbunden. Ein möglicher Angreifer kann trotz Kenntnis des Langzeitschlüssels keinerlei Rückschlüsse auf die ausgehandelten Sitzungsschlüssel ziehen. Bei TLS wird dies dadurch erreicht, dass der Langzeitschlüssel zu einem Signaturverfahren gehört und nur benutzt wird, um Kurzzeitschlüssel zu signieren. Mit diesen wird jeweils durch einen Diffie-Hellman-Schlüsselaustausch ein Sitzungsschlüssel ausgehandelt. Wird ein Server kompromittiert, erfährt der Angreifer nur den langfristigen Signaturschlüssel und die Sitzungsschlüssel gerade aktiver Verbindungen. Die Sitzungsschlüssel zurückliegender Verbindungen sind bereits gelöscht und lassen sich nicht mehr rekonstruieren.

Bei den heutigen Standardverfahren, bei denen zusammen mit symmetrischen Sitzungsschlüsseln (session key) auch asymmetrische Master-Keys eingesetzt werden, müssen auch die sehr viel langlebigeren Hauptschlüssel (master keys) eines Kommunikationskanals PFS-fähig sein. Die Kenntnis eines oder beider privater Schlüssel der Kommunikationsendpunkte darf Angreifern das Aufdecken der Sitzungsschlüssel nicht erleichtern.

Ein Nachteil von Perfect Forward Secrecy ist der deutlich höhere Aufwand zur Generierung von Sitzungsschlüsseln und die dadurch geringere Verarbeitungsgeschwindigkeit. Aus diesem Grunde kann es bei manchen Verschlüsselungsverfahren (z. B. IPsec) deaktiviert werden.

Im April 2019 empfahl das deutsche Bundesamt für Sicherheit in der Informationstechnik in seinen Sicherheitsanforderungen für den Einsatz von TLS bei der Übertragung von Daten die Version TLS 1.2 oder TLS 1.3 in Kombination mit Perfect Forward Secrecy zu nutzen.[2]

Von den großen internationalen IT-Unternehmen war Google das Erste, das den Standard unterstützte. Mittlerweile wenden auch Facebook, YouTube und andere dieses Verfahren an.[3][4] Microsoft verwendet den PFS-Standard seit Mitte 2014 für die HTTPS-geschützte Kommunikation zwischen Clients und den Servern von Outlook.com, Microsoft OneDrive und Office 365.[5] Auch die Wikimedia Foundation unterstützt seit Juli 2014 für alle durch sie gehosteten Wikis den Standard.[6] Apple hat auf seiner Entwicklerkonferenz (WWDC) 2016 angegeben, ab 2017 nur noch Apps im Apple Appstore zuzulassen, welche die Kommunikation über TLS 1.2 in Verbindung mit PFS in App Transport Security unterstützen.[7][8]

Im Januar 2015 waren ca. 37,8 Prozent aller Webseiten, die eine TLS-Verschlüsselung nutzten, dazu konfiguriert, Cipher Suites zu verwenden, die Perfect Forward Secrecy unterstützten.[9] Ein Jahr später, im Januar 2016, waren es schon ca. 46,6 Prozent insgesamt.[10] Im Juli 2023 unterstützen 99,6 % der Webseiten, die TLS-Verschlüsselung nutzen, auch Perfect Forward Secrecy.[11]

  • Naganand Doraswamy, Dan Harkins: IPSec. The New Security Standard for the Internet, Intranets, and Virtual Private Networks. 2. Auflage. Prentice Hall PTR, Upper Saddle River NJ 2003, ISBN 0-13-046189-X (englisch).

Normen und Standards

[Bearbeiten | Quelltext bearbeiten]
  • D. Harkins, D. Carrel: RFC 2409 – The Internet Key Exchange (IKE). November 1998 (englisch).
  • H. Orman: RFC 2412 – The OAKLEY Key Determination Protocol. November 1998 (englisch).
  • M. Euchner: RFC 4650 – HMAC-Authenticated Diffie-Hellman for Multimedia Internet KEYing (MIKEY). September 2006 (englisch).

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone: Handbook of Applied Cryptography. CRC Press, 1996, Definition 12.16, S. 496 (englisch, uwaterloo.ca [PDF]).
  2. BSI – Transport Layer Security (TLS). (PDF) Abgerufen am 10. Juni 2021.
  3. Die bessere Verschlüsselung, Artikel von Christiane Schulzki-Haddouti in Zeit online vom 3. September 2013
  4. Informationen zu den E-Mailprodukten (Memento vom 28. Dezember 2014 im Internet Archive) (Karteikarte „Sicherheit“) freenet.de
  5. Advancing our encryption and transparency (Memento vom 2. Juli 2014 im Webarchiv archive.today), Artikel von Matt Thomlinson in Microsoft TechNet vom 1. Juli 2014
  6. Tech/News/2014/27, Wikimedia
  7. What's New in Security – WWDC 2016 – Videos – Apple Developer. In: developer.apple.com. Abgerufen am 27. Juni 2016.
  8. Preventing Insecure Network Connections. In: Apple Developer Documentation. Abgerufen am 12. Juni 2021.
  9. Trustworthy Internet Movement - SSL Pulse. 23. Januar 2015, archiviert vom Original (nicht mehr online verfügbar) am 23. Januar 2015; abgerufen am 5. Juli 2023.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.trustworthyinternet.org
  10. Trustworthy Internet Movement - SSL Pulse. 30. Januar 2016, archiviert vom Original (nicht mehr online verfügbar) am 30. Januar 2016; abgerufen am 5. Juli 2023.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.trustworthyinternet.org
  11. Qualys SSL Labs - SSL Pulse. Abgerufen am 5. Juli 2023.