Nach dem in den Medien fast täglich eine neue Schlagzeile rund um die NSA Affäre auftaucht, habe ich beschlossen mich näher mit dem Thema „Vertrauliche Kommunikation“ zu befassen.
Dieser Artikel fasst meine Überlegungen zusammen und grenzt das Thema ein. Dabei gehe ich kurz auf meine Motivation ein, nenne gängige Verfahren zur vertraulichen Kommunikation und kommentiere diese. Dabei führe ich einige Links zu Quellen auf, die weiterführende Informationen zu den einzelnen Verfahren und Programmen bieten. Ich plane in folgenden Artikeln detaillierte Beschreibungen zu einzelnen Lösungen zu geben. Bei diesem Artikel handelt es sich damit sozusagen, um den Grundlagenartikel zum Thema.
Mein Ziel ist es eine Lösung zu finden, mit der eine möglichst sichere (denn 100%-ige Sicherheit gibt es nicht) und vertrauliche Kommunikation über das Internet machbar ist.
Vertrauliche Kommunikation
Vertraulich ist eine Nachricht dann, wenn nur der Absender und der oder die Empfänger von ihrem Inhalt Kenntnis haben. Überbringern bzw. Übermittlern dieser Nachricht ist ihr Inhalt entgegen nicht bekannt.
Dies ist z.B. beim klassischen Brief der Fall. Der Absender schreibt ihn, packt ihn in einen Umschlag, verschließt diesen und übergibt ihn der Post zur Zustellung. Die Post bzw. der Postbote, als Überbringer des Briefs, kann den Brief nicht lesen, ohne den Umschlag zu öffnen. Nur der Empfänger kann die enthaltene Nachricht nach Erhalt lesen. Erhält der Empfänger jedoch einen geöffneten Umschlag, so weiß er, dass die Authentizität und Integrität nicht mehr gewährleistet sind.
Im Gegensatz dazu gleicht eine E-Mail eher eine Postkarte. Jeder, der sie in die Hand bekommt, bzw. jeder Server der die E-Mail weiterreicht, kann den Inhalt im Klartext lesen, kopieren und ggf. verändern.
Möchte ich nun in bestimmten Fällen vermeiden, dass meine Nachricht für unbekannte Dritte lesbar ist, muss ich mir Maßnahmen überlegen, wie ich die Vertraulichkeit sicherstellen kann.
Bekannte Probleme
Vertraulicher Kommunikation im Internet stehen vor allem drei bekannte Probleme entgegen.
- Die Verfahren sind für den Anwender meist extrem unkomfortabel in der Anwendung.
- Die Verfahren sind so komplex, dass technisch wenig versierte Anwender sie nicht verstehen bzw. nachvollziehen können.
- Ob die Verfahren wirklich ein hohes Maß an Sicherheit bieten lässt sich meist nur schwer einschätzen.
Alle drei Punkte sorgen dafür, dass auf eine digitale Signatur bzw. Verschlüsselung meist verzichtet wird.
Ich will es dennoch versuchen und schaue mir dazu die folgenden Lösungen an.
Mögliche Lösungen
Auf den ersten Blick bieten sich fünf Möglichkeiten, um das gesteckte Ziel zu erreichen:
- DE-Mail,
- E-Postbrief,
- E-Mail „Made in Germany“,
- Einsatz von GnuPG oder
- S/MIME
Rufen wir uns nochmal kurz das Ziel in Erinnerung. Ich möchte, dass die Kommunikation zwischen dem Sender und dem Empfänger der Nachricht vertraulich bleibt. Dabei möchte ich so nah wie möglich an die Vertraulichkeit des klassischen Briefs herankommen.
Dabei bin ich mir bewusst, dass es Geheimdiensten unter Umständen trotzdem möglich ist an den Inhalt meiner Nachricht zu gelangen. Dieses Problem stellt sich jedoch auch beim klassischen Brief. Wie gesagt, 100%-ige Sicherheit gibt es nicht. Aber ich möchte versuchen es ihnen so schwer wie möglich zu machen. Wenn es mir dabei jedoch gelingt alle anderen Freunde von Big Data auszusperren, ist dies schon als Sieg zu werten.
Kommen wir zu den oben genannten Lösungen im Einzelnen.
DE-Mail und E-Postbrief
Meine Kritik an diesen beiden Produkten habe ich bereits in meinem Artikel „DE-Mail und E-Postbrief – Zwei echte Rohrkrepierer“ geäußert.
Beide Produkte bieten aktuell keine Ende-zu-Ende-Verschlüsselung. Während der Übertragung wird die Nachricht auf den Servern der Anbieter entschlüsselt, verarbeitet, wieder verschlüsselt und weitergeleitet. Nach Angaben der Anbieter wird die Nachricht entschlüsselt, um sie auf enthaltene Schadsoftware zu überprüfen. Der kritische Punkt ist jedoch, dass sie überhaupt entschlüsselt wird. Damit ist der Inhalt der Nachricht nicht mehr vertraulich. Aus diesem Grund kommen beide Produkte für mich nicht in Frage. Weder für den privaten Gebrauch, noch für die Kommunikation mit Ärzten, Versicherungen oder Behörden.
E-Mail „Made in Germany“
Die E-Mail „Made in Germany“ hat das gleiche Problem wie die DE-Mail und der E-Postbrief.
Zitat:
Entgegen zunächst anders lautender Angaben wird bei „E-Mail made in Germany“ genau wie bei De-Mail die Mail auf den Servern der beteiligten Unternehmen mit einem Virenscanner auf Virenfreiheit geprüft. Wer dies nicht wünscht, muss den Inhalt der Mail und etwaige Attachments verschlüsseln.
Die einzige „Neuerung“ im Vergleich zur bisherigen E-Mail Kommunikation besteht darin, dass die E-Mails beim Transport von Server zu Server nun endlich verschlüsselt übertragen werden und nicht an jedem Router, den sie passieren, mitgelesen oder verändert werden können. Dies ist jedoch keine echte Innovation, da die Technik zur Transportverschlüsselung bereits seit Ende der 90’er Jahre vorhanden ist.
Offen bleibt lediglich die Frage, ob man deutschen Providern mehr Vertrauen entgegen bringen kann, als anderen, oder eben nicht. Da ich auch mit Personen außerhalb Deutschlands oder Europas kommuniziere geht der Nutzen dieser Lösung für mich gegen Null.
GnuPG und S/MIME
GnuPG und S/MIME sind zwei verbreitete Möglichkeiten um Daten digital zu signieren und verschlüsseln zu können.
GnuPG wurde in RFC4880 definiert. Die Spezifikationen zu S/MIME finden sich in RFC1847, RFC2633, RFC3851 und RFC5751.
Zuerst die schlechte Nachricht. Beide Verfahren sind nicht kompatibel zueinander. Daher stellt sich als erstes die Frage, auf welches Verfahren man setzen sollte. Im Internet bin ich auf den Artikel „S/MIME vs. OpenPGP: Eine Entscheidungshilfe“ gestoßen. Dieser Artikel war mir bei der Entscheidungsfindung sehr hilfreich. Meine Entscheidung gegen S/MIME fiel unter anderem wegen des folgenden Zitats:
X.509 verwendet ein streng hierarchisches System zur Zertifizierung von öffentlichen Schlüsseln. Eine Certificate Authority (CA) steht an der Spitze der Zertifizierungs-Hierarchie und signiert entweder direkt oder über Sub-CAs die Schlüssel aller Teilnehmer innerhalb der Public Key Infrastruktur (PKI). Die einzelnen Benutzer sind im Besitz ihres eigenen Schlüssels und des öffentlichen CA-Schlüssels und können dadurch die Gültigkeit unbekannter Zertifikate überprüfen.
Dadurch ergibt sich ein Sicherheitsrisiko, welches bei Wikipedia wie folgt beschrieben wird:
Für die Nutzung von S/MIME-Zertifikaten zur Verschlüsselung und Signierung wird aufgrund des Public-Key-Verschlüsselungsverfahrens ein Schlüsselpaar aus öffentlichem und privatem Schlüssel benötigt. Im Gegensatz zum Zertifikat können und sollten diese Schlüssel lokal beim Anwender erzeugt und mit den Zertifikaten verbunden werden. Oft werden die Schlüssel aber gleich von der Zertifizierungsstelle zusammen mit dem Zertifikat generiert und an den Anwender übermittelt. Dadurch ist der Zertifizierungsstelle der private Schlüssel bekannt, was unbedingt im Rahmen der Sicherheit vermieden werden sollte, da der Schlüssel in falsche Hände gelangen kann. Es gibt aber auch Verfahren, bei denen die Schlüssel durch den Webbrowser des Anwenders erzeugt werden. Dabei verlässt der private Schlüssel den PC des Benutzers nicht.
Nach den Enthüllungen rund um die NSA Affäre stehe ich zentralen Zertifizierungsstellen skeptisch gegenüber. Die meisten dieser Zertifizierungsstellen haben ihren Sitz in den USA und es liegt der Verdacht nahe, dass die Geheimdienste durch Hintertüren oder eingebaute Schwachstellen, die mittels dieser Zertifikate geschützte Kommunikation mitlesen können. Auf gut Deutsch: Mein Vertrauen in diese Zertifizierungsstellen wurde schwer in Mitleidenschaft gezogen.
Aus diesem Grund, und aufgrund der Tatsache, dass ich privat vorwiegend auf die Betriebssysteme Linux und Android setze, fiel meine Entscheidung auf GnuPG, welches für alle gängigen Betriebssysteme frei verfügbar ist.
Fazit: Bisher haben wir nur ein paar Überlegungen zu vertraulicher Kommunikation und möglichen Lösungen getroffen. Ihr seht wie lang dieser Artikel geworden ist. Dabei haben wir noch nicht ein Programm installiert, keine Nachricht signiert und auch noch keine Nachricht verschlüsselt.
In einem der nächsten Artikel werde ich mich daran wagen, mit Hilfe von GnuPG ein Schlüsselpaar zu erzeugen und eine erste verschlüsselte Nachricht zu versenden.
