Perfect Forward Secrecy: Unterschied zwischen den Versionen

Aus Foxwiki
Keine Bearbeitungszusammenfassung
K Textersetzung - „Man-Pages“ durch „Man-Page“
 
(44 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
'''topic''' kurze Beschreibung
'''Perfect Forward Secrecy''' - Eigenschaft einer [[Kryptografie]], die Vertraulichkeit auch dann zu gewährleistet, wenn der Serverschlüssel kompromittiert wurde
== Beschreibung ==
== Installation ==
== Anwendungen ==
=== Fehlerbehebung ===
== Syntax ==
=== Optionen ===
=== Parameter ===
=== Umgebungsvariablen ===
=== Exit-Status ===
== Konfiguration ==
=== Dateien ===
== Sicherheit ==
== Dokumentation ==
=== RFC ===
=== Man-Pages ===
=== Info-Pages ===
== Siehe auch ==
== Links ==
=== Projekt-Homepage ===
=== Weblinks ===
=== Einzelnachweise ===
<references />
== Testfragen ==
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 1''
<div class="mw-collapsible-content">'''Antwort1'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 2''
<div class="mw-collapsible-content">'''Antwort2'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 3''
<div class="mw-collapsible-content">'''Antwort3'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 4''
<div class="mw-collapsible-content">'''Antwort4'''</div>
</div>
<div class="toccolours mw-collapsible mw-collapsed">
''Testfrage 5''
<div class="mw-collapsible-content">'''Antwort5'''</div>
</div>


[[Kategorie:Entwurf]]
=== Beschreibung ===
; ''Perfect Forward Secrecy'' (PFS) oder ''Forward Secrecy''
* ''perfekte vorwärts gerichtete Geheimhaltung''
* In der Kryptographie eine Eigenschaft bestimmter [[Schlüsselaustauschprotokoll]]e
* Eigenschaft einer Cipher Suite
* Vertraulichkeit gewährleistet, wenn Serverschlüssel kompromittiert wurde


= Wikipedia =
; Aufgezeichneter Datenverkehr
'''Perfect Forward Secrecy''' ('''PFS'''), auf {{deS}} etwa ''perfekte vorwärts gerichtete Geheimhaltung,'' ist in der Kryptographie eine Eigenschaft bestimmter [[Schlüsselaustauschprotokoll]]e 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.
* kann nicht entschlüsselt werden
* auch, falls ein Angreifer in den Besitz des Serverschlüssels gelangt ist


Dadurch kann eine aufgezeichnete, verschlüsselte Kommunikation auch bei Kenntnis des Langzeitschlüssels nicht nachträglich entschlüsselt werden.<ref name="HAC" /> 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''.
; Ziel
Gemeinsamen Sitzungsschlüssel so vereinbaren
* dass dieser von einem Dritten auch dann nicht rekonstruiert werden kann, wenn einer der beiden Langzeitschlüssel später einmal kompromittiert werden sollte


== Hintergrund ==
; Folgenlosigkeit und 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 ''[[Brute-Force-Methode|Brute-Force]]'', dem zufälligen Raten des Schlüssels. 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.
* aufgezeichnete, verschlüsselte Kommunikation auch bei Kenntnis des Langzeitschlüssels nicht nachträglich entschlüsselt werden
* 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''


Allerdings sind sämtliche Sitzungsschlüssel der Gefahr ausgesetzt, dass derjenige Langzeitschlüssel [[Technische Kompromittierung|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.
=== Hintergrund ===
; Prinzipiell kann jeder Schlüssel aufgedeckt werden
* Aufwendige Analyseverfahren
* Ausspähung
* Diebstahl
* Bestechung
* Erpressung
* Nachlässigkeit
* [[Brute-Force|Brute-Force]]


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 [[Transport Layer Security|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.
; Sitzungsschlüssel
* Deswegen 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.


== Praxis ==
; Langzeitschlüssel
Bei den heutigen Standardverfahren, bei denen zusammen mit symmetrischen Sitzungsschlüsseln ''({{lang|en|session key}})'' auch [[asymmetrisches Kryptosystem|asymmetrische Master-Keys]] eingesetzt werden, müssen auch die sehr viel langlebigeren Hauptschlüssel ''({{lang|en|master keys}})'' eines Kommunikationskanals PFS-fähig sein. Die Kenntnis eines oder beider [[geheimer Schlüssel|privater Schlüssel]] der Kommunikationsendpunkte darf Angreifern das Aufdecken der Sitzungsschlüssel nicht erleichtern.
* Allerdings sind sämtliche Sitzungsschlüssel der Gefahr ausgesetzt, dass derjenige Langzeitschlüssel [[Technische Kompromittierung|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.


Ein Nachteil von ''{{lang|en|Perfect Forward Secrecy}}'' ist der deutlich höhere Aufwand zur Generierung von Sitzungsschlüsseln und die dadurch geringere [[Rechenleistung|Verarbeitungsgeschwindigkeit]]. Aus diesem Grunde kann es bei manchen Verschlüsselungsverfahren (z.&nbsp;B. [[IPsec]]) deaktiviert werden.
; Perfect Forward Secrecy
Dies wird durch ''Perfect Forward Secrecy'' unterbunden
* Angreifer können trotz Kenntnis des Langzeitschlüssels keinerlei Rückschlüsse auf die ausgehandelten Sitzungsschlüssel ziehen
* Bei [[Transport Layer Security|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]] 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.


Im April 2019 empfahl das deutsche [[Bundesamt für Sicherheit in der Informationstechnik]] in seinen Sicherheitsanforderungen für den Einsatz von [[Transport Layer Security|TLS]] bei der Übertragung von Daten die Version TLS 1.2 oder TLS 1.3 in Kombination mit Perfect Forward Secrecy zu nutzen.<ref>{{Internetquelle |url=https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR02102/BSI-TR-02102-2.pdf |titel=BSI – Transport Layer Security (TLS) |abruf=2021-06-10}}</ref>
=== Praxis ===
; Standardverfahren
Bei den heutigen Standardverfahren, bei denen zusammen mit symmetrischen Sitzungsschlüsseln ''(session key)'' auch [[asymmetrisches Kryptosystem|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 [[geheimer Schlüssel|privater Schlüssel]] der Kommunikationsendpunkte darf Angreifern das Aufdecken der Sitzungsschlüssel nicht erleichtern.


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.<ref>[http://www.zeit.de/digital/datenschutz/2013-09/perfect-forward-secrecy ''Die bessere Verschlüsselung''], Artikel von Christiane Schulzki-Haddouti in [[Zeit online]] vom 3.&nbsp;September 2013</ref><ref>{{Toter Link| url=https://email.freenet.de/basic/Informationen | wayback=20141228174225 | text=Informationen zu den E-Mailprodukten}} (Karteikarte „Sicherheit“) freenet.de</ref> [[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]].<ref>''{{Webarchiv | url=http://blogs.technet.com/b/microsoft_on_the_issues/archive/2014/06/30/advancing-our-encryption-and-transparency-efforts.aspx | archive-is=20140702102923 | text=Advancing our encryption and transparency}}'', Artikel von Matt Thomlinson in [[Microsoft TechNet]] vom 1.&nbsp;Juli 2014</ref> Auch die [[Wikimedia]] Foundation unterstützt seit Juli 2014 für alle durch sie gehosteten Wikis den Standard.<ref>[https://meta.wikimedia.org/wiki/Tech/News/2014/27 Tech/News/2014/27], Wikimedia</ref> [[Apple]] hat auf seiner  [[Worldwide Developers Conference#WWDC 2016|Entwicklerkonferenz (WWDC) 2016]] angegeben, ab 2017 nur noch Apps im [[App Store (iOS)|Apple Appstore]] zuzulassen, welche die Kommunikation über [[Transport Layer Security|TLS 1.2]] in Verbindung mit PFS in {{lang|en|[https://forums.developer.apple.com/thread/6767 App Transport Security]}} unterstützen.<ref>{{Internetquelle|url=https://developer.apple.com/wwdc16/706|titel=What's New in Security – WWDC 2016 – Videos – Apple Developer|werk=developer.apple.com|zugriff=2016-06-27}}</ref><ref name="apple-Apple_De">{{Internetquelle|autor= |url=https://developer.apple.com/documentation/security/preventing_insecure_network_connections |titel=Preventing Insecure Network Connections |werk=Apple Developer Documentation |datum= |abruf=2021-06-12}}</ref>
; Nachteil
Ein Nachteil von ''Perfect Forward Secrecy'' ist der deutlich höhere Aufwand zur Generierung von Sitzungsschlüsseln und die dadurch geringere [[Rechenleistung|Verarbeitungsgeschwindigkeit]].
* Aus diesem Grunde kann es bei manchen Kryptografieverfahren (z.&nbsp;B.&nbsp;[[IPsec]]) deaktiviert werden.


{{Überarbeiten|2=Dieser Absatz |grund=Die Webarchives als Beleg funktionieren nicht mehr, andere Quellen vorhanden?}}
; Empfehlung
Nach Angabe des {{lang|en|[[Trustworthy Internet Movement]]}} vom Januar 2015 waren damals ca. 20,9 Prozent aller Webseiten, die eine TLS-Verschlüsselung nutzen, dazu konfiguriert, [[Cipher Suite]]s zu verwenden, die ''{{lang|en|Perfect Forward Secrecy}}'' mit modernen [[Webbrowser|Browsern]] unterstützten.<ref>{{cite web|url=https://www.trustworthyinternet.org/ssl-pulse/|title=SSL Pulse|accessdate=2015-01-10|date=2015-01-07|archiveurl=https://web.archive.org/web/20170515034337/https://www.trustworthyinternet.org/ssl-pulse/|archivedate=2017-05-15|archivebot=2019-05-06 20:05:42 InternetArchiveBot}}</ref> Ein Jahr später, im Januar 2016, waren es schon ca. 46,9 Prozent.<ref>{{cite web|url=https://www.trustworthyinternet.org/ssl-pulse/|title=SSL Pulse|accessdate=2016-01-31|date=2016-01-31|archiveurl=https://web.archive.org/web/20160130202732/https://www.trustworthyinternet.org/ssl-pulse/|archivedate=2016-01-30}}</ref>
Im April 2019 empfahl das deutsche [[Bundesamt für Sicherheit in der Informationstechnik]] in seinen Sicherheitsanforderungen für den Einsatz von [[Transport Layer Security|TLS]] bei der Übertragung von Daten die Version TLS 1.2 oder TLS 1.3 in Kombination mit Perfect Forward Secrecy zu nutzen.


== Literatur ==
; Unterstützung
* Naganand Doraswamy, Dan Harkins: ''[[IPSec]]. The New Security Standard for the Internet, Intranets, and Virtual Private Networks.'' 2nd Edition. Prentice Hall PTR, Upper Saddle River NJ 2003, ISBN 0-13-046189-X.
* 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.
* Nach Angabe des Trustworthy Internet Movement vom Januar 2015 waren damals ca. 20,9 Prozent aller Webseiten, die eine TLS-Kryptografie nutzen, dazu konfiguriert, [[Cipher Suite]]s zu verwenden, die ''Perfect Forward Secrecy'' mit modernen [[Webbrowser|Browsern]] unterstützten.


== Normen und Standards ==
=== Dokumentation ===
=== RFC ===
* RFC 2409, Beispiel bei ''The Internet Key Exchange (IKE)''
* RFC 2409, Beispiel bei ''The Internet Key Exchange (IKE)''
* RFC 2412, Beispiel bei IPsec
* RFC 2412, Beispiel bei IPsec
* RFC 4650
* RFC 4650


== Weblinks ==
=== Man-Page ===
* Netcraft: [http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html SSL: Intercepted today, decrypted tomorrow] (englisch)
=== Info-Pages ===
 
== Siehe auch ==
== Einzelnachweise ==
== Links ==
<references>
=== Projekt ===
<ref name="HAC">{{Literatur
=== Weblinks ===
| Autor=Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone
# Netcraft: [http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html SSL: Intercepted today, decrypted tomorrow]
| Titel=Handbook of Applied Cryptography
# [https://en.wikipedia.org/wiki/Forward_secrecy Vorwärtsgeheimnis] (Wikipedia)
| Verlag=CRC Press
# [https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection Pushing for Perfect Forward Secrecy, an Important Web Privacy Protection] (EFF)
| Jahr=1996
# [https://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html SSL: Heute abgefangen, morgen entschlüsselt] (Netcraft)
| Kapitel=Definition 12.16
| Seiten=496
| Online=http://cacr.uwaterloo.ca/hac/about/chap12.pdf
}}</ref>
</references>
 
[[Kategorie:Kryptologie]]
 


[[Kategorie:Verschlüsselung]]
[[Kategorie:Kryptografie/Algorithmus]]

Aktuelle Version vom 6. November 2024, 12:58 Uhr

Perfect Forward Secrecy - Eigenschaft einer Kryptografie, die Vertraulichkeit auch dann zu gewährleistet, wenn der Serverschlüssel kompromittiert wurde

Beschreibung

Perfect Forward Secrecy (PFS) oder Forward Secrecy
  • perfekte vorwärts gerichtete Geheimhaltung
  • In der Kryptographie eine Eigenschaft bestimmter Schlüsselaustauschprotokolle
  • Eigenschaft einer Cipher Suite
  • Vertraulichkeit gewährleistet, wenn Serverschlüssel kompromittiert wurde
Aufgezeichneter Datenverkehr
  • kann nicht entschlüsselt werden
  • auch, falls ein Angreifer in den Besitz des Serverschlüssels gelangt ist
Ziel

Gemeinsamen Sitzungsschlüssel so vereinbaren

  • dass dieser von einem Dritten auch dann nicht rekonstruiert werden kann, wenn einer der beiden Langzeitschlüssel später einmal kompromittiert werden sollte
Folgenlosigkeit und break-backward protection
  • aufgezeichnete, verschlüsselte Kommunikation auch bei Kenntnis des Langzeitschlüssels nicht nachträglich entschlüsselt werden
  • 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

Hintergrund

Prinzipiell kann jeder Schlüssel aufgedeckt werden
  • Aufwendige Analyseverfahren
  • Ausspähung
  • Diebstahl
  • Bestechung
  • Erpressung
  • Nachlässigkeit
  • Brute-Force
Sitzungsschlüssel
  • Deswegen 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.
Langzeitschlüssel
  • 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.
Perfect Forward Secrecy

Dies wird durch Perfect Forward Secrecy unterbunden

  • Angreifer können 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 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.

Praxis

Standardverfahren

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.
Nachteil

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 Kryptografieverfahren (z. B. IPsec) deaktiviert werden.
Empfehlung

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.

Unterstützung
  • 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.
  • Nach Angabe des Trustworthy Internet Movement vom Januar 2015 waren damals ca. 20,9 Prozent aller Webseiten, die eine TLS-Kryptografie nutzen, dazu konfiguriert, Cipher Suites zu verwenden, die Perfect Forward Secrecy mit modernen Browsern unterstützten.

Dokumentation

RFC

  • RFC 2409, Beispiel bei The Internet Key Exchange (IKE)
  • RFC 2412, Beispiel bei IPsec
  • RFC 4650

Man-Page

Info-Pages

Siehe auch

Links

Projekt

Weblinks

  1. Netcraft: SSL: Intercepted today, decrypted tomorrow
  2. Vorwärtsgeheimnis (Wikipedia)
  3. Pushing for Perfect Forward Secrecy, an Important Web Privacy Protection (EFF)
  4. SSL: Heute abgefangen, morgen entschlüsselt (Netcraft)