Original-URL des Artikels: https://www.golem.de/news/pretty-easy-privacy-pep-ausprobiert-einfache-e-mail-verschluesselung-kann-so-kompliziert-sein-1905-141553.html    Veröffentlicht: 29.05.2019 07:25    Kurz-URL: https://glm.io/141553

Pretty Easy Privacy (Pep) ausprobiert

Einfache E-Mail-Verschlüsselung kann so kompliziert sein

Seit den 90ern lassen sich E-Mails mit GPG verschlüsseln, doch nur wenige nutzen das System täglich. Zu kompliziert sagen Kritiker. Pep tritt an, die E-Mail-Verschlüsselung radikal zu vereinfachen - und macht alles noch komplizierter.

Glenn Greenwald wäre fast die Snowden-Story entgangen, weil ihm die Einrichtung von PGP/GPG zu aufwendig war. GPG, so die oft vorgebrachten Vorwürfe, sei kompliziert, keineswegs nutzerfreundlich und nicht mehr zeitgemäß. Die naheliegende Lösung: PGP in einfach und unkompliziert. Genau mit diesem Ziel tritt Pep (Pretty Easy Privacy) an und will die E-Mail-Verschlüsselung radikal vereinfachen.

Ich habe sie ausprobiert und festgestellt: Statt ihrem Ziel gerecht zu werden, macht die Open-Source-Verschlüsselungs-Software alles komplizierter, fordert von GPG-Nutzern nicht weniger, sondern mehr Know-how und untergräbt die teils hart erarbeitete Sicherheit.

Ich benutze GPG seit meiner Schulzeit und das täglich. Ich habe Freunde und Bekannte überredet, GPG zu benutzen, Workshops gehalten und Menschen die Nutzung von GPG nähergebracht. Jedes Update, das ich installiere, wird mit Hilfe einer Signatur durch GPG geprüft. Kurz: Ich bin ein Freund von GPG. Von Pep bin ich allerdings kein Freund geworden.

Einfaches Chaos

Als ich vor einigen Monaten das erste Mal eine verschlüsselte Mail von einem Freund bekam, in deren Betreff schlicht "p≡p" stand, schwante mir bereits Böses. Der Freund hatte seinen Computer platt gemacht, dabei Thunderbird und Enigmail neu installiert und seine GPG-Schlüssel händisch über Enigmail wieder eingespielt. Da war es allerdings bereits zu spät: Enigmail lief im Junior-Modus und übernahm mit Pep die Kontrolle. Für die eingerichteten E-Mail-Konten wurden völlig automatisiert und ohne jegliche Nachfrage GPG-Schlüssel generiert - ohne Passwort, ohne Ablaufdatum, ohne alles. Nach dem Import des ursprünglichen und selbstgenerierten Schlüssels verwendete Enigmail einfach weiter den Pep-Schlüssel - und brachte den genannten Freund pretty easy zur Verzweiflung.

Pep untergräbt die Sicherheit

Ein ähnliches Problem hatte auch ein Verein, dessen Vereinsmailadresse von mehreren Personen mit dem gleichen Schlüssel verwaltet wird. Auch hier begannen die Thunderbird/Enigmail-Installationen einzelner Nutzer, selbst Pep-Schlüssel für die Vereinsmailadresse zu generieren und zu verwenden. Die Pep-Schlüssel wurden an jede versendete E-Mail angehängt, woraufhin einige Empfänger begannen, ihre Antworten an den Verein mit ebenjenen Pep-Schlüsseln zu verschlüsseln. Die so verschlüsselten Mails konnte im besten Fall nur eine Person lesen. Im ungünstigen Falle einer weiteren Neuinstallation kam gar kein Vereinsmitglied mehr an die Inhalte heran. Die geteilte Verschlüsselung der Mailadresse war dahin.

Dass Enigmail nach der Neuinstallation im Junior-Modus lief und damit automatisiert in ihren Sicherheitseinstellungen herumpfuscht, teilte die Software den Vereinsmitgliedern nicht mit. Sie mussten erst einmal herausfinden, was eigentlich los war. Auch das Deaktivieren von Pep gestaltete sich zumindest unter Ubuntu alles andere als einfach.

In den Enigmail-Einstellungen lässt sich der Junior-Modus und damit Pep zwar deaktivieren, unter Ubuntu werden den Nutzern jedoch die Design-Einstellungen zum Verhängnis. Die einzelnen Einstellungsreiter sind schlich nicht als solche zu erkennen. Erst wenn der Reiter "Kompatibilität" entdeckt wurde und die Auswahl von "Automatisch entscheiden, ob der Junior-Modus verwendet werden soll" zu der Einstellung "Nutzung von S/MIME und Enigmail" gewechselt wurde, kann GPG wieder wie gewohnt genutzt werden. Warum Nutzer dafür erst in den Optionen suchen müssen, bleibt unklar. Vielen Thunderbird/Enigmail-Nutzern war zudem überhaupt nicht klar, was die einzelnen, verschwurbelt formulierten Optionen bedeuten. Eine Hilfestellung oder Erklärung sucht man vergebens.

Doch damit nicht genug: Pep übernimmt auch das komplette Schlüsselmanagement. In einem Test konnte ich Pep beliebige Schlüssel unterjubeln.

Trollen mit Pep

Um für die Nutzer die E-Mail-Verschlüsselung besonders einfach zu gestalten, übernimmt Pep die komplette Schlüsselverwaltung. Jeder gesendeten E-Mail wird der generierte Pep-Schlüssel automatisch angehängt. Nutzt auch der Empfänger die Software, antwortet dessen Pep automatisch mit seinem Schlüssel. Allerdings werden nicht nur diese automatisch ausgetauschten Schlüssel angenommen, sondern jeder Schlüssel im Anhang einer E-Mail.

Ich generiere GPG-Schlüssel für verschiedene E-Mail-Adressen mit unterschiedlichen Domainendungen und sende sie als E-Mail-Anhang an eine Thunderbird-Installation mit Enigmail im Junior-Modus. Dort öffne ich die E-Mails und sehe - nichts. Thunderbird zeigt mir ungewöhnlicherweise nicht einmal an, dass die E-Mails einen Anhang enthalten. Die Schlüssel werden förmlich vor dem Nutzer versteckt, tauchen aber anschließend - vollautomatisch - in der Schlüsselverwaltung von Enigmail und im Schlüsselspeicher von GPG auf. Selbst ein Schlüssel für das Empfängerkonto, für das Pep bereits Schlüssel erstellt hat, wird ungefragt angenommen.

Wurde bereits verschlüsselt mit einer E-Mail-Adresse kommuniziert und ein Schlüsselaustausch durchgeführt, speichert Pep zwar meine untergejubelten Schlüssel, verwendet sie jedoch nicht. Bei allen E-Mail-Adressen, bei denen das nicht der Fall ist, werden die untergejubelten Schlüssel verwendet. Sei es, weil noch kein Schlüsselaustausch stattgefunden hat oder weil die betreffende E-Mail-Adresse keine Verschlüsselung mit GPG unterstützt. Diesen Mailadressen sendet der Nutzer automatisch unlesbare - weil mit meinen Schlüsseln verschlüsselte - E-Mails.

Zu einem Sicherheitsproblem dürfte es hier zwar nur im Einzelfall kommen, allerdings eignet sich Pep wunderbar, um Leute zu trollen.

Dieser Automatismus kann jedoch an einer anderen Stelle zu Sicherheitsproblemen führen: GPG wird nicht nur zum Verschlüsseln von E-Mails eingesetzt, sondern auch zum Signieren von Software. Beispielsweise lässt sich mittels der Signaturen vor der Installation einer Nextcloud oder des Tor-Browsers überprüfen, ob die Software auf dem Weg mit einem Trojaner infiziert wurde. Über Pep könnten Nutzern gefälschte Schlüssel von Nextcloud, dem Tor-Projekt oder anderen Softwareprojekten untergeschoben werden. Wird die heruntergeladene Software auf dem Weg verändert und mit den gefälschten Schlüsseln signiert, könnten sich die Nutzer Schadsoftware einfangen - auch wenn sie die Software überprüft haben.

Nutzer wollen gefragt werden

Der Schlüsselaustausch ist immer ein kritischer Punkt von Public-Key-Kryptografie, an dem beispielsweise Man-in-the-Middle-Attacken (MitM) ansetzen können. Mit diesen werden die Schlüssel von beiden Kommunikationspartnern abgefangen und ausgetauscht. Dieses zentrale Problem löst Pep nicht, sondern automatisiert es.

Letztlich nimmt Pep Nutzern vor allem jede Menge Kontrolle aus der Hand und stellt kaum Fragen. Möchtest du Pep verwenden? Möchtest du diesen Schlüssel importieren? Diese Fragen sollte Pep den Nutzern stellen, statt den gesamten Verschlüsselungsprozess vor ihnen zu verstecken.

Am Ende erreicht Pep nicht einmal sein originäres Ziel. Die verschiedenen Betriebs-Modi und Automatismen vereinfachen das Leben des Nutzers nicht. Im Gegenteil, es verwirrt sie, untergräbt ihre Entscheidungen und damit ihre Sicherheit. In meinem Umfeld hat Pep bisher vor allem eins geschafft: Zu nerven und zu verunsichern. Die Freude war meist dann am größten, wenn die Option zum Deaktivieren von Pep gefunden wurde. Eine absichtlich mit Pep verschlüsselte E-Mail habe ich noch nicht erhalten.  (mtr)


Verwandte Artikel:
E-Mail-Verschlüsselung: Sicherheitslücke in Pep/Enigmail geschlossen   
(16.10.2018, https://glm.io/137143 )
GPG/OpenPGP: BSI zertifiziert GPG für den Dienstgebrauch   
(07.05.2019, https://glm.io/141097 )
Chat over IMAP: Gut gemeint ist leider nicht gut gemacht   
(06.05.2019, https://glm.io/141009 )
TCPcrypt: IETF veröffentlicht zwei RFCs zur TCP-Verschlüsselung   
(29.05.2019, https://glm.io/141583 )
Dateisystem: ZFS on Linux unterstützt native Verschlüsselung   
(27.05.2019, https://glm.io/141539 )

© 1997–2019 Golem.de, https://www.golem.de/