Dies ist die archivierte Version des Blogs vom 05.01.2017. Aktuelle Beiträge findest du unter thomas-leister.de
 

Die Telekom hat zusammen mit dem Fraunhofer-Institut für Sichere Informationstechnologie (SIT) die Initiative „Volksverschlüsselung“ gestartet. Ziel ist es, die End-to-End E-Mail Verschlüsselung in Deutschland zum Standard zu machen und den Bürgern benutzerfreundliche, einfache Software dafür zur Verfügung zu stellen. Ein guter Freund hat mich gestern auf die Initiative aufmerksam gemacht, also habe ich mir das mal angesehen. Was zuerst einen vielversprechenden Eindruck gemacht hat, hat mich allerdings schnell enttäuscht, denn bereits jetzt halte ich das Projekt für ungeeignet, um die E-Mail Kommunikation ernsthaft abzusichern. Dafür gibt es natürlich auch einen Grund – und der heißt X.509.

Die Initiative will Public-Key-Infrastruktur (PKI) auf Basis des X.509-Standards zur Beglaubigung ihrer Zertifikate nutzen. Wem X.509 etwas sagt, der kennt sehr wahrscheinlich auch die große Schwäche des Standards: Zentrale Beglaubigungsstellen – auch „Certificate Authorities“, CAs, genannt. Ich will im Folgenden erklären, was X.509 bedeutet und wieso ich es für ungeeignet halte. Wer die Probleme kennt, für den wird hier nichts neues zu lesen sein … ;)

X.509 steht im Gegensatz zum sog. Web-of-Trust-Modell. Während es im Web-of-Trust keine zentralen Instanzen gibt, die bestimmen, wem vertraut werden kann und wem nicht, setzt X.509 genau auf diese Instanzen: Die Certificate Authorities. Eine CA beglaubigt Sicherheitszertifikate, d.h. sie überprüft, ob der Ersteller eines Zertifikats tatsächlich die Person ist, für die das Zertifikat gilt. Jeder Benutzer, der wiederum der CA vertraut, soll nun sichergehen können, dass alle von dieser CA signierten Zertifikate echt sind und jeweils den ihnen zugeordneten Personen gehören. Indem man als Anwender einer CA vertraut, gibt man die Überprüfung der Identität seines Kommunikationspartners also aus der Hand und überträgt diese Aufgabe einem dritten – der CA. Das kann sehr praktisch sein: Man erspart sich die Arbeit, selbst zu kontrollieren, ob ein Sicherheitszertifikat tatsächlich der Person gehört, der es gehören sollte. Diese Aufgabe übernimmt nun die CA. Es genügt, sich auf die einwandfreie Arbeit der CA zu verlassen und ihr zu vertrauen.

Genau hier liegt auch schon Schwachstelle #1: Wer garantiert, dass die Certificate Authoritity verlässlich und richtig nachprüft, ob ein Zertifikat tatsächlich einer bestimmten Person gehört? Wer garantiert, dass die CA vor Manipulationen sicher ist? Wer stellt sicher, dass die CA ihre Macht nicht missbraucht und falsche Zertifikate unterschreibt? Wie überprüft man die Arbeit der CA? Eine CA ist eine ultimative Vertrauensinstanz. Mit ihr steht und fällt die Sicherheit aller Anwender, die sich auf die korrekte Arbeit dieser CA verlassen. Wir haben hier also einen Single Point of Failure, den es in der Informationstechnologie eigentlich immer zu vermeiden gilt.

X.509-Schwachstelle #2 hat direkt damit zu tun: In der Praxis gibt es nicht nur eine einzige, große CA, die Zertifikate beglaubigen kann, sondern hunderte. Da es nicht praktikabel ist, jedes Zertifikat von allen CAs beglaubigen zu lassen, sodass ein Anwender nur seiner Lieblings-CA vertrauen muss, wird der Anwender sämtlichen CAs trauen, die es gibt. Irgendeine dieser CAs wird das jeweilige Sicherheitszertifikat schon beglaubigt haben. Und hier liegt das Problem: Jede dieser CAs hat uneingeschränkte Macht. Jede einzelne CA kann (absichtlich oder unabsichtlich) Zertifikate beglaubigen, die sie nicht beglaubigen dürfte. Es genügt, wenn ein Zertifikat nur von einer einzigen CA unterschrieben ist, und das Zertifikat wird von der Verschlüsselungssoftware als bestätigt angesehen. Die Sicherheit fast aller X.509-Anwender steht und fällt also nicht nur mit der Sicherheit einer einzigen CA, sondern mit der Sicherheit aller verfügbarer, allgemein anerkannten CAs. Manipulationen an einer CA reichen aus, um die Sicherheit aller Anwender zu gefährden.

Um kurz zwei Beispiele zu nennen: Sicherheitsschwachstelle #1 kann beispielsweise dazu eingesetzt werden, die Kommunikation von Bürgern zu entschlüsseln, die sich in Sicherheit wähnen. Der Staat hat die Möglichkeit, gefälschte Zertifikate zu erstellen, diese den zu überwachenden Bürgern unterzuschieben, und diese gefälschten Zertifikate von einer CA beglaubigen zu lassen. Die Zertifikate werden von der Verschlüsselungssoftware als bestätigt angesehen, der Nutzer bemerkt von all dem nichts, und der staatliche Geheimdienst kann problemlos mitlesen.

Schwachstelle #2 ist noch ein Stück problematischer: Nicht nur eine landeseigene CA kann gefälschte Zertifikate wie echte aussehen lassen, sondern auch jede andere CA, die allgemein anerkannt ist. Es ist also noch nicht einmal nötig, dass der deutsche Staat mitlesen will – es reicht aus, wenn irgendein anderer Staat das will. Sollte ein ausländischer Geheimdienst an meiner Kommunikation interessiert sein, wird es ihm möglich sein, mir gefälschte Zertifikate unterzuschieben, die von einer ihm untergebenen CA siginiert wurden. Mein Kommunikationspartner wird diesen gefälschten Zertifikaten automatisch trauen, denn er vertraut standardmäßig allen anerkannten CAs. Um es noch einmal kurz auf den Punkt zu bringen: Eine chinesische CA kann für meinen E-Mail Account problemlos Zertifikate fälschen.

Ihr merkt vielleicht schon – X.509 ist das perfekte Vertrauensmodell für Staaten und Institutionen, um verschlüsselte Kommunikation unbemerkt mitzulesen. Es gibt hunderte „Points of failures“ an denen eine Menge schief gehen kann. Selbst wenn man allen Staaten und Betreibern von CAs vertrauen könnte, wäre immer noch fraglich, ob alle Certificate Authorities tatsächlich sicher vor Kriminellen sind. Leider ist es ausgerechnet X.509, welches z.B. auch für die verschlüsselte Übertragung von Websites genutzt wird. Doch für den Einsatz im Webbrowser gibt es inzwischen Technik, die Manipulationen aufzudecken oder zu verhindern versucht: HPKP und DANE mit DNSSEC. Um eine X.509-basierte Vertrauensstruktur für E-Mail zumindest ansatzweise vernünftig nutzen zu können, müsste man diese Technik auch für E-Mail etablieren. Ohne diese zusätzliche Absicherung ist vor allem gegenüber anderen Staaten keine E-Mail Sicherheit gewonnen.

Lieber wäre mir jedoch ein völlig anderes Trust-Modell: Das Web-of-Trust, also ein Vertrauensnetzwerk bestehend aus gleichberechtigten Teilnehmern, wie es bei OpenPGP der Fall ist. Hier gibt es keine CAs, keine zentralen Instanzen, die Vertrauen definieren. Jedes Sicherheitszertifikat ist zu Beginn nicht vertrauenswürdig. Andere Nutzer können jedoch (z.B. durch persönlichen Kontakt) ermitteln, ob ein Zertifikat zu einem bestimmten Benutzer gehört. Ist das der Fall, so wird das Zertifikat nicht von einer CA signiert, sondern von einem anderen Nutzer. Die Nutzer beglaubigen ihre Zertifikate also gegenseitig. Je mehr Unterschriften ein Zertifikat bekommen hat, desto vertrauenswürdiger ist es. Ein Zertifikat, das ein guter Freund signiert hat, ist auch für mich vertrauenswürdig – schließlich traue ich einem guten Freund zu, dass er keine gefälschten Zertifikate signiert. Die Vertrauenskette ist also an persönliche Kontakte und persönliches Vertrauen in reale Personen geknüpft. Ich halte das für das wesentlich zuverlässigere Vertrauensmodell – auch wenn es etwas komplexer ist. Oder um das Bild in den Bereich der Netzwerktopologien zu übertragen: Ein Mesh-Netzwerk ist wesentlich zuverlässiger als ein Stern-Netzwerk.

Leider haben sich Telekom und das Fraunhofer SIT für die Umsetzung ihrer Volksverschlüsselung auf Basis von X.509 entschieden. Das mag vor allem begründet sein, dass X.509 weit verbreitet und sehr einfach zu benutzen ist. Nutzer sollen sich keine Gedanken um Vertrauen machen und brauchen möglichst einfache Software, die sie nicht überfordert. OpenPGP mit dem Web-of-Trust-Modell soll von der Initiative zwar zu einem späteren Zeitpunkt auch berücksichtigt werden, allerdings ist dazu nicht mehr nachzulesen. Wann und wie OpenPGP für die Volksverschlüsselung genutzt werden soll, wird nicht bekanntgegeben. Schade eigentlich. Das Ziel der Initiative ist lobenswert, doch wie so oft kann die Umsetzung nicht überzeugen. Statt die Digitale Welt zu dezentralisieren und dem Nutzer die Vertrauensfreiheit zu überlassen, setzt man auf Technik, die für ihre Anfälligkeit und ihre schwerwiegenden Schwachstellen schon lange bekannt ist. Vom Fraunhofer-Institut hatte ich etwas mehr Weitblick erwartet.

 

 

Anmerkung am 29.02.2016: Das X.509-Modell (und damit S/MIME) ist nicht per se schlecht. Innerhalb eines Unternehmens ist die Technik beispielsweise wunderbar geeignet, um E-Mail Kommunikation abzusichern. Die Nachteile fallen weg, denn alle Beteiligten würden dann nur der Unternehmens-eigenen Certificate Authority vertrauen. Sobald aber mehrere Benutzergruppen (Unternehmen) via S/MIME füreinander verschlüsseln, verschlechtert sich die Situation.


Post published on 28. Februar 2016 | Last updated on 22. August 2016
Tags:               

Diesen Blog unterstützen

Wenn Dir der Beitrag gefallen hat, freue ich mich über einen kleinen Obolus :-) Bitcoin QR Code

PayPal-Seite: https://www.paypal.me/ThomasLeister
Meine Bitcoin-Adresse: 15z8 QkNi dHsx q9WW d8nx W9XU hsdf Qe5B 4s

Siehe auch: Unterstützung

Informationen zum Autor

Thomas Leister

Geb. 1995, Kurzhaar-Metaller, Geek und Blogger. Nutzt seit Anfang 2013 ausschließlich Linux auf Desktop und Servern. Student der Automobilinformatik an der Hochschule für angewandte Wissenschaften in Landshut.

6 thoughts on “Warum die Volksverschlüsselung mit X.509 nicht die Lösung ist

  • Niklas Buschmann

    Wirklich guter Artikel.

    Ich denke allerdings aus praktischen Gründen nicht, dass ein WoT die beste Lösung ist, weil dabei jeder manuell ein Netz aus Vertrauen aufbauen muss, was durchaus machbar, aber aufwendig ist.

    Ich denke, wenn man gute Verschlüsselung implementiert hat (möglichst weiter unten im OSI-Modell, also nicht für jede Anwendung eine eigene Implementierung), ist die beste Möglichkeit zum Schlüsselaustausch ein System wie Namecoin, damit kann man dann zu einer gegebener (Domain/Mailadresse/sonstigem String) nachweislich den richtigen Schlüssel finden.

    tl;dr CJDNS + Namecoin wäre mein favorisierter Ansatz.

  • Eines der besten Blogposts die ich in den letzten Jahren gelesen habe. Vielen Dank!

  • Ich denke nicht das der Ansatz WoT/GPG in naher Zukunft umsetzbar ist, da es dafür einfach keine einfach bedienbare Software gibt. Und das Frauenhofer Institut hat nun halt etwas ausgewählt, das etabliert, auch mit bekannten Schwächen, und schon implementiert ist => auch von Nicht-Technisch-Affinen-Leuten bedien- und nutzbar.

  • Ich nutze beides, sowohl GPG als auch S/MIME. Beim WoT ist leider auch nicht alles Gold was glänzt. Um wirklich sicher zu sein dass der Schlüssel auch tatsächlich der Person gehört mit der man kommunizieren will, muss man schon selbst sehr genau prüfen. Es gibt Chaos auf den Schlüsselservern und jeder kann für jede E-Mailadresse einen Schlüssel erzeugen. Wenn ich aber jeden persönlich überprüfen muss, dann ist der Vorteil einer asymmetrischen Verschlüsselung fast schon aufgehoben.

    Abgesehen vom Vertrauen ist aber die Sicherheit der Verschlüsselung nicht bedroht, weil auch bei S/MIME der private Schlüssel immer in Deiner Hand bleibt (wenn es richtig gemacht wird). Von der Benutzung ist S/MIME aber sehr viel einfacher.

    Ideal wäre eine Kombination aus beiden Welten, also WoT + CAs und die Handhabung wie S/MIME.

  • Wenn ich noch was ergänzend „klugscheissen“ darf, die Situation im Moment ist so, dass 99,9% aller Mails weder verschlüsselt noch signiert versenden werden. Es ist also alles besser als die jetzige Situation.

    Und was die CA’s angeht, man kann denen auch das Vertrauen für die E-Mailsignatur entziehen oder sie ganz rauswerfen (chinesische CA’s z.B.).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.