Verschlüsselung für die Massen
Das Ziel des am Mittwoch gestarteten Projekts „Volksverschlüsselung“, das in einer Zusammenarbeit zwischen dem Fraunhofer-Institut für Sichere Informationstechnologie (SIT) und der Deutschen Telekom entstand, ist die Ermöglichung der Ende-zu-Ende-Verschlüsselung von E-Mails, die so einfach ist, dass sie jeder benutzen kann – Volksverschlüsselung eben.
Dazu greift das Projekt auf den S/MIME-Standard in Verbindung mit X.509-Zertifikaten zurück, mit denen sich E-Mails verschlüsseln und signieren lassen. S/MIME gilt als kryptografisch sicher, sogar gegen NSA und Co., doch die Probleme der Volksverschlüsselung liegen anderswo. Trotzdem soll die Volksverschlüsselung eine Chance haben, sich zu beweisen.
Auf der Downloadseite des Projekts fällt zunächst auf, dass lediglich ein Betriebssystem zur Auswahl steht: OpenBSD…nein, Windows natürlich. Versionen für OS X, Linux, iOS und Android seien geplant. Außerdem wird zwar verkündet, dass der Quellcode des Clients offen einsehbar ist, der in der Windows-Anwendung enthaltene Link darauf leitet jedoch noch auf die Startseite um. Auf Nachfrage erklärte uns das Fraunhofer SIT, dass der Quellcode in Kürze veröffentlicht werden soll und man ihn noch zum besseren Verständnis aufbereiten will.
Ohne Authentifizierung keine Verschlüsselung
Die Installation der Software verläuft einfach, das Interface ist übersichtlich und intuitiv und beginnt direkt mit der Erstellung eines Zertifikats. Doch schon beim zweiten Schritt wird der Weg zur volksverschlüsselten E-Mail ausgebremst: Damit es weitergeht, muss man zunächst nachweisen, wer man ist. Ziel der Initiative ist es nicht nur, den Einsatz von Verschlüsselung zu vereinfachen, sondern auch die Identitäten der Kommunikationspartner zu bestätigen. Zur Authentifizierung stehen drei Optionen offen, die Authentifizierung mittels der Online-Ausweisfunktion des Personalausweises ist die Standardmethode. Daneben gibt es noch die Möglichkeit, sich über einen Festnetz-Account bei der Telekom zu authentifizieren – das klappt jedoch nur, wenn der Anschluss auf einen selbst registriert ist.
Möchte man, zum Beispiel wegen Sicherheitsbedenken gegenüber dem ePerso, keine der beiden Methoden nutzen oder ist einem dies gar nicht möglich, weil man weder (e)Perso-Besitzer noch Telekom-Kunde ist, bleibt einem noch die Vor-Ort-Registrierung auf Messen und anderen Veranstaltungen der Initiative übrig. Nach Angabe von Vorname, Name und E-Mailadresse und der Vorlage eines gültigen Ausweisdokuments erhält man einen Registrierungscode, der die Erstellung eines Verschlüsselungszertifikats erlaubt.
Es zeigt sich, dass es um die versprochene Benutzerfreundlichkeit schlecht bestellt ist, selbst wenn der Nutzer zur Erstellung des Zertifikats wenig technische Expertise benötigt. Und auch ein weiteres Problem entsteht durch den Authentifizierungszwang: Anonyme Kommunikation ist mit der „Volksverschlüsselung“ unmöglich. Dieser Zwang soll auch bei der ab der nächste Version verfügbaren Nutzung des OpenPGP-Standards bestehen bleiben.
Besonders problematisch: Die zentralisierte Infrastruktur
Ein weiteres Problem entsteht durch die Nutzung des X.509-Standards. Wie bereits erwähnt, stellt die Kryptographie dabei nicht den problematischen Punkt dar, sondern die zentralisierte Infrastruktur.
Die für die Verschlüsselung, das Signieren und Authentifizieren genutzen Zertifikate werden von einer zentralen Stelle vergeben, einer Certificate Authority (CA). Im Falle der Volksverschlüsselung heißt die Zertifizierungsstelle „Volksverschluesselung Root CA“. Der Nutzer muss dieser zentralen Stelle also vertrauen, die Authentizität der Zertifikate zu garantieren, um dadurch sicherzustellen, dass keine gefälschten Zertifikate im Umlauf sind.
Dieser Aufbau stellt ein extrem attraktives Angriffsziel für Angreifer und Geheimdienste dar, da nur ein System infiltriert werden muss, um Kontrolle über die Vergabe der Zertifikate zu erlangen; entweder durch eine technische Unterwanderung per Hacking oder indem die Zertifizierungsstelle hierzu rechtlich gezwungen wird. Dass das keine theroetische Bedrohung ist, zeigen der Hackerangriff auf die Zertifizierungsstelle DigiNotar und die Unterwanderung des belgischen Internetserviceproviders Belgacom.
Noble Idee mit falscher Umsetzung
Die Idee der Volksverschlüsselung ist lobenswert, das steht außer Frage. Verschlüsselung muss einfacher und alltäglich werden, damit die Überwachung der Massen erschwert wird und diejenigen, die schon seit langem verschlüsseln, weniger herausstechen und in der Masse untertauchen können. Die Umsetzung der Initiative ist hingegen zum Scheitern verurteilt. Ein nicht-anonymes, nicht-offenes System mit zentralisiertem Vertrauen ist genau das Gegenteil von dem, wie die Zukunft der verschlüsselten Kommunikation aussehen muss. Selbst in der Anwendbarkeit sind Alternativen wie GPG einfacher zu nutzen, wenn man an die komplizierte Authentifizierung der Volksverschlüsselung denkt. Bei GPG werden die Schlüssel außerdem nicht zentral authentifiziert, sondern von anderen Nutzern verifiziert und signiert. Das Vertrauen entsteht also durch mehrere Nutzer. Zudem bietet GPG den Vorteil einer anonymen Nutzbarkeit und der freien Verwendung und Erweiterung der Software.
Eine andere und möglicherweise aussichtsreichere Alternative ist die Entwicklung eines komplett neuen Protokolls zur Ablösung der E-Mail. Das Projekt DarkMail hat sich genau das zum Ziel gesetzt und will Mails automatisch Ende-zu-Ende verschlüsseln sowie gleichzeitig Meta-Daten reduzieren.
Statt Geld in die Entwicklung eines hübschen Interfaces für einen Standard mit bekannten Problemen zu stecken, wäre eine Unterstützung solcher Projekte wahrscheinlich wesentlich effizienter gewesen, um Verschlüsselung massentauglich zu machen.
Was soll denn überhaupt der Vorteil sein? S/MIME mit X.509-Zertifikaten mache ich seit 1998 mit Thunderbird auf AIX, MacOS und Windows. Mit binärkompatiblen Mailboxen. Outlook und Lotus Notes haben das ebenfalls integriert. Was soll der Schnickschnack also? Spionage?
Der Schnickschnack soll einfach bewirken, das die nun vermutlich vielen vielen verschlüsselten Email leichter zu sortieren und auszusortieren sind. Man muss ja vermuten, das hinter der Sache schlicht und einfach der Trick steckt, die Privaten Schlüssel gleich mal mit zu speichern und den Überwachern das leben noch einfacher zu machen, als es das bei NICHT-Verschlüsslung schon ist.
Allerdings bleibt abzuwarten, ob sich diese Initiative überhaupt durchsetzt, denn 95% der deutsche haben ja eh‘ „nix zu verbergen“ also werden sie auch nicht verschlüsseln, selbst wenn sie das nichts kosten würde.
Besser wäre es für die, die ihre totale Anonymität gern haben möchten, ihre Hauptkommunikation auf Threema & Co. zu verlagern und all ihre Kommunikationspartner entsprechend zu zwingen umzustellen, nur dann wird es möglich sein, das man unbemerkt und vorbei an der totalen Überwachung zu kommunizieren. Ein geeigneter Ersatz wäre es, denn man kann Dokumente, PDF’s, Bilder und was nicht noch alles damit versenden … derzeit leider nur mit den SmartPhone, aber vielleicht kriegen die Jungs es noch hin, das man dies synchron auf dem Desktop weiter führen kann. Apple zeigt ja schon, wie es geht (iMessage & Co.)
Die Schlüssel verlassen den PC des Nutzers laut Website nicht, das ist also so nicht richtig.
Threema ist closed source, ist also auch nicht die Lösung.
Dennoch: gab es denn irgendeine Verlautbarung, warum und mit welchem Nutzen zweitklassige Anbieter, die bisher auf dem Messaging-Markt noch nicht aufgefallen sind, einen Standard mit S/MIME und X.509-Zerttifikaten nachimplementieren, den Profis wie IBM mit Lotus Notes, Microsoft mit Outlook und Thunderbird seit nunmehr fast 20 Jahren in ihren Produkten fest integriert haben? Da müssen doch Staatsbetriebe Langeweile haben und Steuergelder verschwenden.
Dummheit am Rande: den härtesten Sicherheitsskandal habe ich dazu vom BSI gehört. Als die X.509-Zertifikate vermehrt aufkamen, merkte man, dass man zum Abfragen bei der CA, ob das Zertifikat noch gilt, mit LDAP nicht über eine demilitarisierte Zone kam, weil es für LDAP keine Gatesways oder Forwarder gab. Die Post führte, als sie noch im Trustcentergeschäft war, das Protokoll OCSP ein, dass man schön aus einem 10.x.x.xer Netz über einen HTTP-Proxy führen kann.
Die Deppen vom BSI aber, die den Firewall der Bundesverwaltung managten, schalteten auf dem Firewall NAT ein und routeten jeden dusseligen PC in einer Poststelle, die LDAP nutzen mussten/sollten, auf dem LDAP-Port ins gesamt Internet. Sicherheitsfachleute, die einem die Bunde aufmachen: völlig absurd. Seitdem ist das BSI für mich keine Behörde mehr, die Sicherheit produziert, sondern in Sicherheitsanalysen eine große Sicherheitsbedrohung darstellen. Ich muss jetzt nicht erwähnen, dass die Telekom bei LDAP blieb und nicht zu OCSP ging?
Böse Zungen würden jetzt sagen, dass Volksverschlüsselung lediglich ein klickibunti-Frontend für X.509 ist, mehr nicht.
Es wird von keinem Durchschnittsbürger erwartet die Protokolle im Detail zu verstehen. Aber manche erkennen, daß es so etwas wie „Volksverschlüsselung“ nicht geben wird. Man darf auch jedem Menschen zugestehen ein Dummkopf zu sein. Aber wenn sich die Leute, die sich so etwas wie „Volksverschlüsselung“ ausdenken, mit den Details auskennen, dann ist es eher wohl Volksverdummung. Siehe
https://dl.acm.org/citation.cfm?id=2673311
Ihr tut mich alle sehr leid. Eure ideologische Verblendung, Euer Hang zu Verschwörungstheorien sind schon krankhaft.
Die Volksverschlüsselung macht nicht den Fehler, noch eine weitere Methode zu den zig anderen hinzu zu fügen, die meinen mit proprietären undurchsichtigen Lösungen ein paar tausend Nutzer auf einer Insel zufrieden zu stellen. Nein, sie verwendet die Methode, die schon seit zig Jahren etabliert und international standardisiert, in den ausgereifeten Mail-Clients (Thunderbird, Outlook, Notes) bereits integriert ist: S/MIME.
Was die (einfachen) Benutzer bisher nicht geschafft haben, macht die Volksversclüsselung für sie im Hintergrund. Ein Zertifikat beantagen, bei dem die Identität an hand des Personalausweises geprüft wird oder bereits früher geprüft wurde (Telekom-Login), dieses an den richtigen Stellen im Zertifikatsmanager installieren, dem Aussteller das Vertrauen aussprechen und schließlich ein zentrales Verzeichnis verfügbar machen, in dem alle ausgestellten Zertifikate zu finden sind. Damit kann man künftig auch an Empfänger verschlüsseln, mit denen man noch gar keinen Kontakt hatte (wenn sie ihr Zertifikat dort veröffentlicht haben).
Ich finde, das ist ein richtig guter Schritt nach vorn – auch wenn bisher noch nicht alle Systemplattformen und alle Mail-Clients unterstützt werden. Und ob das Open-Source ist oder nicht, das können wir in ein paar Jahren noch klären. Fraunhofer hat mein Vertrauen!
Wie gesagt, nettes Frontend für einen wenig benutzten und problematischen Standard.
Der Vorteil an Open Source ist, dass man kein Vertrauen braucht, man kann nachweisen, dass die Software sicher ist.
„Der Vorteil an Open Source ist, dass man kein Vertrauen braucht, man kann nachweisen, dass die Software sicher ist.“
Bitte auf dem Teppich bleiben, der Satz klingt stark danach, als ob es mit OpenSource keine unsichere Software geben kann. Das ist Unsinn. Erstmal musst du bei OpenSource auch Vertrauen haben, ist ja nicht so als würdest du jede Zeile Code selbst überprüfen (was eh nicht geht, weder hätte ein Mensch alleine die Zeit dazu noch das Knowhow). Anstelle des Herstellers vertraust du der Community und hoffst, dass sich aus selbiger genug fachkundige Leute mit dem Code beschäftigen und Fehler veröffentlichen. Grade bei Volksverschlüsselung ist das meiner Meinung nach sehr fraglich. Die Community ist sehr klein (außerdem von Deutschland interessiert sich keiner dafür) und das Produkt selbst hat nicht grade einen Hype verursacht. Ein BugBounty Programm wäre hilfreich, aber ich bezweifel, dass das Fraunhofer eins macht, sobald/wenn sie den Code veröffentlichen.
Ich bin wirklicher großer Fan von OpenSource, aber in diesem Fall ist „es ist nicht OpenSource“ kein KO-Kriterium für mich.
Dann liest du da aber was rein. Im gleichen Sinne wie ein offener Quellcode die Möglichkeit bietet, Sicherheit nachzuweisen, bietet er logischerweise auch die Möglichkeit Sicherheitslücken zu finden und diese aufzuzeigen/zu beheben. Das geht bei einem geschlossenen Quellcode eben nicht (von unabhängiger Stelle).
Dann empfehle ich diesen Artikel, der nochmal erklärt, warum das eben doch ein KO-Kriterium ist:
https://netzpolitik.org/2016/volksverschluesselung-fuer-unfreie-buerger/
„Dann liest du da aber was rein.“
Mag sein. Ich habe aber mehr das Gefühl, du hast deine Behauptung einfach nicht zu Ende gedacht…
„Der Vorteil an Open Source ist,…, man kann nachweisen, dass die Software sicher ist.“
Könnte ich wirklich nachweisen, dass (OpenSource) Software sicher ist, warum sollte es dann unsichere Software geben? Macht keinen Sinn…
Der Satz stimmt nunmal einfach nicht. Unabhängig von OpenSource kannst du das nie nachweisen (bzw. nur in den seltesten Fällen). Man kann nachweisen, dass die Software Schwachstellen hat und dann versuchen sie sicherer zu machen (indem man die Schwachstellen behebt). Und nein, dass ist keine Haarspalterei, dass ist ein großer Unterschied! Softwareentwicklung Grundkurs, erste Stunde: Software ist niemals sicher, sie ist höchstens sicherer als vorher ;-)
Bei OpenSource haben mehr Menschen die Möglichkeit nach Schwachstellen zu suchen. Nicht mehr, nicht weniger. Hast du ja im zweiten Beitrag auch so geschrieben (da stimme ich dir zu). Aber dein erster Beitrag ist in der Hinsicht nunmal…nennen wir es von mir aus unglücklich formuliert…
„Dann empfehle ich diesen Artikel“
Hatte ich bereits gelesen, ändert nichts an meinem Beitrag oben. Warum auch…
Genau das wollte ich sagen und das ist der Vorteil von Open Source gegenüber Closed Source.
Nicht mehr und nicht weniger habe ich behauptet, zumindest wollte ich es nicht. Open Source ist kein magisches Schutzschild, das stimmt. Aber sie ist insofern Closed Source Software überlegen, dass es überhaupt die Möglichkeit gibt, dass Sicherheitslücken von unabhängiger Seite gefunden/berichtet/geschlossen werden können. Bei Closed Source Software hat man immer das Risiko, dass es unabsichtliche Sicherheitslücken oder bewusste Backdoors gibt, die niemand kennt, weil der Quellcode nicht offen ist.