Ende-zu-Ende-Verschlüsselung : Sichere Übertragung von Daten aus Webformularen

Werden über ein Webformular vertrauliche Informationen übermittelt, so stellt dies in der Regel keine wirksame Ende-zu-EndeVerschlüsselung dar. Unter anderem ist die Transportverschlüsselung zwischen Browser und Webanwendung nicht ausreichend, wenn die Vertraulichkeit der Webanwendung kompromittiert wurde: So kann der Betreiber oder ein eventueller Angreifer die sensiblen Informationen auf dem Webserver im Klartext lesen, bevor sie (ggf. sogar wiederum auf dem Transport gesichert) zum zuständigen Bearbeiter gelangen. Und selbst wenn die Vertraulichkeit gewahrt bleibt, ist der Kommunikationsprozess nur in einer Richtung abgesichert: Für vertrauliche Antworten oder Rückfragen müssten im Vorfeld Schlüsselinformationen ausgetauscht worden sein, was in der Praxis selten passiert.

Ziel einer durch das BSI finanzierten Entwicklung war es daher, nicht nur eine vertrauenswürdige Ende-zu-Ende-Absicherung bei der Datenübermittlung von OnlineFormularen zu gewährleisten, sondern auch den für einen Rückkanal notwendigen Schlüsselaustausch zu vereinfachen. Für eine breite Nutzung standen dabei die einfache Bedienbarkeit durch den Nutzer und ein angemessener Aufwand aufseiten des Formularempfängers im Vordergrund.

Aus Gründen der breiten Verfügbarkeit und hohen Überprüfbarkeit wurden die freie Browser-Erweiterung „Mailvelope“ [1] und die zugrunde liegende OpenPGP-Implementierung „OpenPGP.js“ als Basis für die Entwicklung genutzt, die eine sichere Übertragung von E-Mails auch beim Einsatz von WebmailDiensten ermöglicht: E-Mails werden im Browser durch die MailvelopeErweiterung OpenPGP verschlüsselt, sodass der Anbieter vom Inhalt der E-Mails auch bei der Eingabe keine Kenntnis nehmen kann.

Zukünftig kann die Software auch genutzt werden, vertrauliche Anfragen, zum Beispiel an Ärzte oder Banken, über Web-Formulare stellen zu können. Das Augenmerk der Entwicklung liegt neben der Sicherheit des Verfahrens in der möglichst einfachen Anwendung sowohl für den Nutzer als auch für die Seitenbetreiber, die ihren Nutzern eine derart abgesicherte Kontaktaufnahme ermöglichen wollen.

Neue Möglichkeiten

Die freie Software „Mailvelope“ bietet die Möglichkeit, E-MailEingaben von Webmail-Anbietern sicher zu erfassen und zu übermitteln. Dies geschieht, indem iFrames in die Websites des Anbieters eingebunden werden: Damit sind die Eingaben in diesem iFrame vor Zugriffen des Anbieters durch die Same-Origin-Policy (SOP) der Web-Browser geschützt. Der eingebettete Editor hat zusätzlich durch den Nutzer modifizierbare optische Kennzeichen, sodass es dem Anbieter nicht möglich ist, diese zu replizieren. Nach beendeter Eingabe wird der verschlüsselte Text an die Website übergeben, sodass die E-Mail dann verschlüsselt versendet werden kann.

Um Formulare auf ähnliche Weise bearbeiten zu können, muss zum einen der Editor um die Funktionalität generischer Formulare (Radio-Buttons, Auswahllisten und Ähnliches) erweitert werden. Zum anderen müssen sinnvolle Ein- und Ausgabeformate für Formulare konzeptioniert und realisiert werden, die sowohl möglichst kompatibel zu bestehenden Lösungen als auch sicher und leicht zu verwenden sind.

Als Lösung bot sich daher an, Formulare, wie sie mit dem freien Frontend-Framework „Bootstrap“ [2] erstellt und formatiert werden, zu unterstützen. Dies umfasst auch clientseitige Möglichkeiten zur Validierung, die unabsichtliche Fehleingaben vermeiden können. Das mit Bootstrap erstellte Formular wird mithilfe eines zur Verfügung gestellten Tools in ein spezielles HTML-Element eingefügt, das eine mit dem Schlüssel des Formularempfängers erstellte Signatur enthält. So ist sichergestellt, dass das Formular nicht durch den Betreiber der Website geändert werden kann – in Abbildung 1 wird ein solches Formular veranschaulicht.

Es können verschiedene Aktionen für die ausgefüllten Formulare gewählt werden, sodass die Daten nach der Entschlüsselung auf passende Weise weiterverarbeitet werden können. Hierzu gehören durch Menschen als auch durch Maschinen lesbare Formate. Die Ergebnisse der Entwicklung stehen zum einen auf der Plattform GitHub (lizenziert unter der GNU AGPL v3, www.gnu.org/licenses/agpl-3.0.de. html) im Quellcode [3] und zum anderen in dem Chrome- und FirefoxAdd-on Mailvelope ab Version 3 zur Verfügung.

Erweiterungen der verwendeten KryptografieBibliothek

Weiterhin wurde im Rahmen der Entwicklung in der Software „Mailvelope“ zugrunde liegenden Bibliothek „OpenPGP.js“ die Kompatibilität zum OpenPGP-Standard deutlich verbessert. So waren zum Beispiel Anpassungen der kryptografischen Funktionen, die auf elliptischen Kurven basieren (ECC), notwendig. Die Ergebnisse dieser Entwicklung sind ebenfalls auf der Plattform GitHub im Quellcode verfügbar [4].

Einbindungsmöglichkeit einer lokalen GnuPGInstallation

Um den Nutzern zu ermöglichen, auf eine lokal installierte Schlüsselverwaltung einer GnuPG-Installation zuzugreifen (und diese – z. B. beim Misstrauen gegenüber Kryptografie im Browser selbst – durch die quelloffene Standard- und Referenzimplementierung des OpenPGP-Standards „GnuPG“ übernehmen zu lassen), wurde die Schnittstelle zu OpenPGP.js abstrahiert: Damit lässt sich eine lokale GnuPG-Instanz mithilfe von „Native Messaging“ in die Erweiterung einbinden (ein relativ neues Verfahren, das Browser-Erweiterungen den Aufruf spezieller Programme auf dem Computer des Browser-Nutzers erlaubt, um auf die Funktionalität bereits installierter Programme zurückgreifen zu können). Der Nutzer hat dann die Auswahl, GnuPG statt OpenPGP.js zu verwenden. Für die Anbindungen wurden Änderungen an GnuPG nötig und ein weiteres Modul zur Kommunikation über JSON-Objekte zur freien Bibliothek GPGME [5] hinzugefügt.

Dies ermöglicht fortgeschrittenen Nutzern unter anderem auch, einen Sicherheitstoken wie eine Smartcard in Verbindung mit „Mailvelope“ zu verwenden und damit die Sicherheit weiter zu erhöhen. Zusätzlich sind die geheimen Schlüssel bei einer Kompromittierung des Browsers besser geschützt, sofern sie von GnuPG verwaltet werden. Das Sicherheitsniveau kann mit dieser Integration entsprechend erheblich gesteigert werden.

 Schlüsselaustauschverfahren

Eines der schwierigsten Probleme beim Einsatz von Kryptografie ist der Austausch von Schlüsseln. Im Falle von OpenPGP (bzw. asymmetrischer Kryptografie im Allgemeinen) ist es hierzu notwendig, den öffentlichen Schlüssel einer Person bekannt zu machen. Mithilfe des öffentlichen Schlüssels ist es dann möglich, Nachrichten an diese Person zu verschlüsseln, die nur mit dem geheimen Schlüssel entschlüsselt werden können.

Wichtig ist es, ein gewisses Vertrauen in die Korrektheit des Schlüssels zu etablieren: Kann ein Angreifer einem Kommunikationspartner einen falschen Schlüssel bereitstellen, ist die Vertraulichkeit aller Nachrichten kompromittiert. Die Etablierung eines automatischen Schlüsselaustauschverfahrens ist zwar für die Funktionalität der sicheren Übertragung von Daten nicht zwingend notwendig, erleichtert allerdings dem Anwender die Benutzung erheblich, was dem Ziel der breiten Verwendung zuträglich ist.

Zum Austausch von Schlüsseln gibt es verschiedene Modelle, die unterschiedliche Vor- und Nachteile bieten. Einige Beispiele sind (hier vereinfacht dargestellt):

• Manueller Schlüsselabgleich: Hier wird der Fingerabdruck eines Schlüssels (der z. B. über öffentliche Keyserver bezogen wird) manuell über einen anderen Kommunikationskanal mit dem Kommunikationspartner abgeglichen (z. B. persönlich oder per Telefon). Diese Methode etabliert ein sehr hohes Vertrauen in die Korrektheit des Schlüssels – allerdings ist das Abgleichen von langen Zeichenfolgen fehleranfällig und mühsam.
• DANE/OpenPGPKey: „Domain Name System-Based Authentication of Named Entities“ (DANE) bietet die Möglichkeit, das bereits bestehende Domain-Name-System (DNS) zu verwenden, um Schlüssel zu publizieren. So kann der E-MailAnbieter die Hoheit über seine Domäne (z. B. bsi.bund.de) verwenden, um für die Korrektheit des Schlüssels zu bürgen. Allerdings muss, um dieses Verfahren nutzen zu können, DNSSEC verwendet werden, um Manipulationen ausschließen zu können. Dieses Verfahren hat allerdings bislang noch eine geringe Verbreitung. Zusätzlich bestehen bei DANE/OpenPGPKey verschiedene Probleme in der Praxis – entsprechend eignet sich DANE nur bedingt für einen Schlüsselaustausch.
• „Trust On First Use“ (TOFU): Bei diesem Verfahren wird ein Schlüssel ohne vertrauensbildende Maßnahmen verwendet, um eine Nachricht zu verschlüsseln. Dies geschieht in der Hoffnung, dass – sollte der Schlüssel falsch sein – der Kommunikationspartner ein Problem zurückmeldet. Hierbei wird für die erste Vertrauensbildung insbesondere in Kauf genommen, dass die Vertraulichkeit der ersten Nachricht nicht verlässlich gegeben ist.
• Web-Key-Directory: Beim Web-Key-Directory (WKD) genannten Verfahren bestätigt der E-Mail-Anbieter ähnlich wie bei DANE/OpenPGPKey die Korrektheit des Schlüssels über eine zwischen Kunde und Anbieter bereits etablierte Vertrauensbeziehung. Im Gegensatz zu DANE wird beim WKD auf das weit verbreitete HTTPS statt DNSSEC gesetzt, um Schlüssel zu übertragen. Damit ist dieses Verfahren sowohl auf Anbieter- als auch auf Nutzerseite einfach umzusetzen und bietet zumindest eine eingeschränkte Vertrauensbildung.

Bei der Umsetzung wurde sich für eine Integration von WKD in Mailvelope entschieden – sofern der E-MailAnbieter WKD unterstützt, wird der öffentliche Schlüssel von Mailvelope-Nutzern im WKD des Anbieters veröffentlicht. Gleichzeitig wird das WKD bevorzugt verwendet, um unbekannte Schlüssel, unter Verwendung des Vertrauens in die TLS-Zertifizierungsinstanz des Webservers, von dem der Schlüssel bezogen wurde, mit einem Grundvertrauen auszustatten. Auf diesem Weg können zum Beispiel bisher unbekannte Empfangsadressen von Web-Formularen mit Vertrauen ausgestattet werden, sodass bereits ein erster Kontakt mit einem gewissen Anspruch an Vertraulichkeit gewährleistet ist, ohne dass ein Nutzer durch Vertrauensmanagement überfordert oder gehindert wird.

Abbildung 2 illustriert das Schlüsselaustauschverfahren mit WKD. Für den Fall, dass WKD nicht zur Verfügung steht (z. B. weil der Anbieter des Empfängers kein WKD unterstützt), kann eine manuelle Schlüsselverifikation wie oben beschrieben als Alternative eingesetzt werden. Hier kann der Nutzer dann auch eine Abwägung treffen und durch das Aussprechen von Vertrauen ohne manuelle Prüfung explizit auch „TOFU“ verwenden, sollte die Vertraulichkeit für diese Nachricht nur eine untergeordnete Rolle spielen.

IT-Sicherheits-Audit

Um das Vertrauen in die Entwicklungen zu stärken, wurde ein unabhängiger Dienstleister mit einem Audit der Sicherheitseigenschaften des Produkts betraut. Neben der Umsetzung der kryptografischen Verfahren waren speziell auch die Existenz von Routinen zur Nutzerüberwachung oder Kompromittierung privater Daten zentrales Ziel des Audits. Hierdurch wurde nicht nur ein hohes Maß an Qualität gewährleistet, sondern Probleme konnten direkt im Anschluss an die Entwicklung erkannt und vor der Freigabe gelöst werden.

Das Ergebnis des Audits ist ein Bericht, der nachvollziehbar Probleme und Gefahren identifiziert und die getroffenen Vorkehrungen zur Begegnung dieser darstellt – es ist geplant, den Bericht auf der Website des BSI zu veröffentlichen.

Literatur

[1] Mailvelope GmbH, Verschlüsselung mit OpenPGP, www.mailvelope.com

[2] Bootstrap, Projekthomepage, https://getbootstrap.com/

[3] Github, Mailvelope – Browser extension for OpenPGP encryption with Webmail, https://github.com/mailvelope/mailvelope/tree/d4e5f4656f-1254647c6ea6252faa268c7df12ec7

[4] Github, OpenPGP.js – OpenPGP implementation forJavaScript, https://github.com/openpgpjs/openpgpjs/tree/v3.1.0

[5] g10 Code GmbH, GnuPG Made Easy (GPGME), www.gnupg.org/software/gpgme/index.html