Zukunftssicher verschlüsseln mit Perfect Forward Secrecy

Der Schlüsselaustausch via Diffie-Hellman - hier mit DHE-RSA - ergibt Perfect Forward Secrecy.
Erstveröffentlicht: 
25.07.2013

Wie durch die Enthüllungen von Edward Snowden bekannt wurde, sammelt die NSA in großem Stil verschlüsselte Daten auf Vorrat, um sie später zu entschlüsseln und analysieren. Das gelingt zum Beispiel dann, wenn der Geheimdienst den geheimen Schlüssel einer überwachten Web-Seite in die Finger bekommt. Allerdings gibt es ein Rezept gegen diese nachträgliche Entschlüsselung -- und einige Web-Seiten nutzen es sogar schon.

 

Jürgen Schmidt

 

Um zu verstehen, was genau es mit der sogenannten Perfect Forward Secrecy oder einfach Forward Secrecy auf sich hat und wie das funktioniert, muss man zunächst ungefähr verstehen, wie SSL-Verschlüsselung normalerweise arbeitet. Der Kernpunkt ist, dass eigentlich zwei Verschlüsselungsverfahren zum Einsatz kommen: zunächst eine asymmetrische Verschlüsselung mit einem Schlüsselpaar aus geheimem und öffentlichem Schlüssel und danach eine symmetrische Verschlüsselung mit einem geheimen Sitzungsschlüssel. Der Hauptgrund dafür ist, dass die asymmetrische Verschlüsselung zu langsam ist, um den kompletten Datenstrom darüber abzuwickeln.

 

Beim Aufruf einer Web-Seite wie https://meine-mail.de erfolgt typischerweise ein Schlüsselaustausch über das asymmetrische Verschlüsselungsverfahren RSA. Dabei läuft grob vereinfacht folgende Kommunikation zwischen dem Server der Bank und dem Browser ab:

  1. Browser kontaktiert https://meine-mail.de
  2. Server präsentiert einen öffentlichen Schlüssel, dem eine vertrauenswürdige Zertifizierungsstelle attestiert hat, dass er tatsächlich der Firma meine-mail gehört
  3. Browser überprüft die Unterschrift der Zertifizierungsstelle und ist danach überzeugt, dass er tatsächlich mit meine-mail.de spricht. Er verschlüsselt seine Nachrichten jetzt mit dem soeben erhaltenen öffentlichen Schlüssel.
  4. Server kann die Nachrichten mit dem zugehörigen geheimen Schlüssel entschlüsseln.
  5. Browser schlägt supergeheim123 als geheimen Sitzungsschlüssel vor
  6. Server bestätigt supergeheim123 als geheimen Sitzungsschlüssel

Ab jetzt beginnt eine ganz normale http-Sitzung, die mit einer symmetrischen Verschlüsselung wie AES und dem Sitzungsschlüssel supergeheim123 gesichert ist. Das Problem dabei ist folgendes: Wenn jemand wie die NSA diese komplette Kommunikation einschließlich des Verbindungsaufbaus aufgezeichnet hat und später irgendwann in den Besitz des geheimen Schlüssels des Servers meine-mail.de kommt, kann sie daraus den Sitzungsschlüssel supergeheim123 extrahieren. Mit dem kann sie dann wiederum die komplette Kommunikation aus dem gespeicherten Cipher-Daten extrahieren.

 

Und hier setzt die Perfect Forward Secrecy (PFS) an, die genau das verhindern soll – dass nämlich eine in der Vergangenheit geführte, bereits abgeschlossene aber verschlüsselt aufgezeichnete Kommunikation durch nachträgliches Bekanntwerden des geheimen Schlüssels kompromittiert wird. Das klingt zwar unmöglich, lässt sich aber mit Hilfe eines cleveren Schlüsselaustauschverfahrens namens Diffie-Hellman tatsächlich realisieren. Interessierte können die Mathematik dahinter bei Wikipedia nachlesen; der Knackpunkt dabei ist, dass sich die beiden Kommunikationspartner durch den Austausch mehrerer Nachrichten auf einen gemeinsamen, temporären Sitzungsschlüssel einigen können, der dabei jedoch nie "über die Leitung" geht – also nicht übertragen wird. Nach dem Ende der Sitzung zerstören die beiden Kommunikationspartner ihre Kopie dieses Schlüssels, der damit nicht mehr existiert, auch nicht in irgendwelchen verschlüsselten Aufzeichnungen.

 

Ein passiver Lauscher kann also die Sitzungsdaten im Nachhinein trotz Kenntnis des geheimen, asymmetrischen Schlüssels nicht entschlüsseln. Nur als aktiver Man-in-the-Middle, der die Kommunikation aktiv manipuliert und etwa beiden Endpunkten seinen eigenen Sitzungsschlüssel aufzwingt, kann er nach wie vor mitlauschen. Aber zumindest abgeschlossene Sitzungen sind damit perdu

 

In der Praxis

 

Nun bietet die SSL/TLS-Spezifikation zwar mehrere Schlüsselaustauschverfahren an, die auf Diffie-Hellman beruhen und somit PFS bieten (DHE_* und die Äquivalente auf elliptischen Kurven ECDHE_*) und sowohl Server als auch aktuelle Browser beherrschen die ebenfalls. Das abschließende E steht dabei jeweils für "ephemeral", also flüchtige, vergängliche Schlüssel.

 

Doch die Diifie-Hellman-Verfahren haben einen deutlichen Nachteil: Aufgrund der notwendigen zusätzlichen Kommunikation dauern sie deutlich länger als ihre Pendants etwa aus der RSA-Familie. Bei den performanteren EC-Varianten muss ein Server-Betreiber mit etwa 15-30 Prozent Overhead rechnen, beim herkömmlichen Diffie-Hellman sogar noch deutlich mehr.

 

Das ist ein guter Grund für die meisten Betreiber, auf diese vorbeugende Sicherheit zu verzichten: Microsoft, Apple. Twitter, Facebook, Yahoo, AOL, gemäß einer aktuellen Netcraft-Untersuchung unterstützt keiner dieser großen US-Anbieter von Kommunikationsdiensten Forward Secrecy. Es gibt allerdings mit eine große Ausnahme: Google hat seine Server bereits 2011 auf Schlüsselaustausch mit PFS umgestellt. Bei den deutschen Webmail-Providern sieht die Situation etwas besser aus: GMX und Web.de bieten PFS, 1und1 und T-Online können es zwar prinzipiell, müssten aber vom Browser aktiv dazu gezwungen werden.

 

Apropos Browser: Aktuelle Versionen von Firefox, Chrome, und Opera haben keine Probleme mit PFS; sie bevorzugen es im Zweifelsfall sogar. Internet Explorer und Safari lassen sich zur Not vom Server zu einer PFS-Schlüsselvereinbarung überreden. Wer seinen Internet-Diensten selber auf den Zahn fühlen will, kann deren Verschlüsselungsoptionen bei den SSL Labs überprüfen. Die Ergebnisse zeigen auch gleich, welche Verschlüsselungsverfahren ein Verbindungsaufbau in verschiedenen Browsern ergibt und ob dieser dann Forward Secrecy ergibt.

 

Server-Betreiber, die jetzt gerne ihre Server auf Forward Secrecy umstellen wollen, sollten ECDHE und DHE in der Liste der präferierten Cipher-Suiten an die Spitze der präferierten Cipher-Suiten setzen. Konkret empfiehlt etwa Ivan Ristic von den SSL-Labs die folgenden Suiten zu bevorzugen:

  • TLS_ECDHE_RSA_WITH_RC4_128_SHA
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
  • TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA

Die Zukunft

 

Selbst wenn die NSA einzelne, verschlüsselte Verbindungen nach wie vor gezielt mit aktiven Man-in-the-Middle-Angriffen belauschen kann, dürfte ihr und auch anderen Schnüfflern der Einsatz von Forward Secrecy ein Dorn im Auge sein. Macht es doch die verdachtsunabhängige Vorratsspeicherung verschlüsselter Daten auf absehbare Zeit erstmal nutzlos. Denn bis sie die eingesetzten symmetrischen Verschlüsselungsverfahren ohne Schlüssel knacken können, dürfte noch einige Zeit ins Land gehen – erst Recht, wenn das in großem Stil passieren soll.

 

Und Anwendern gibt diese Funktion endlich ein hartes Kriterium an die Hand, welcher Dienstanbieter seinen Versprechen in Bezug auf Privatsphäre auch Taten folgen lässt – auch auf die Gefahr hin, Geheimdienste und Strafverfolger zu verärgern. Natürlich macht es wenig Sinn, jetzt alle US-Konzerne außer Google in Bausch und Bogen zu verdammen; schließlich wussten viele Admins bis vor kurzem nicht einmal, was Perfect Forward Secrecy ist. Doch Server-Betreiber, die jetzt nicht anfangen, ihre Server umzustellen, sollten sich in nächster Zeit auf bohrende Fragen ihrer Kunden gefasst machen. (ju)