Verschlüsseln ist wichtig. Fand ich schon immer und habe es doch nie wirklich gemacht. Bis auf einen kleinen Zeitraum während der Ausbildung, in der ich alle E-Mails an einen privaten Gesprächspartner verschlüsselt habe. Eher aus Spaß und nicht aufgrund wichtiger Informationen. Um die Verschlüsselung wollte ich mich also schon lange wieder kümmern. In Zeiten von PRISM & Co. ist das Thema noch wichtiger geworden. Einfach schon aus Prinzip finde ich. Aber natürlich auch, um für Dritte verschlüsselt erreichbar zu sein, was ich ab heute bin.
Warum verschlüsseln?
Hauptsächlich besteht mein Bedarf an Verschlüsselung bei der Kommunikation über E-Mails. Dateien werde ich zwar vermutlich auch verschlüsseln, aber in einem kleineren Umfang. Aber gerade bei E-Mails, die Postkarten der digitalen Kommunikation, ist eine Verschlüsselung von Informationen wichtig. Grundsätzlich gibt es die Möglichkeit, mit S/MIME oder OpenPGP zu verschlüsseln. Ich habe mich für letzteres entschieden, obwohl mit S/MIME ein Standard bereitsteht, der nativ von Outlook unterstützt wird. Allerdings habe ich solche Entscheidungen noch nie gerne auf Basis einer vorhandenen Lösung ausgesucht, insbesondere, wenn ich eh überlege diese auszutauschen. Der zweite Grund war, dass bei S/MIME ein Zertifikat notwendig ist, dass bei einem Zertifikatshersteller ausgestellt wird. Das ist zwar nicht mehr so kostspielig wie noch vor einigen Jahren, trotzdem möchte ich — aufgrund der aktuellen Ereignisse — nicht von einem Zertifikat oder einem Zertifikatshersteller abhängig sein. Mein öffentlicher PGP-Schlüssel ist zwar erst einmal nicht zertifiziert, dass werde ich aber vermutlich auf der nächsten CeBIT auf dem c’t-Stand nachholen.
Outlook Plug-In OutlookPrivacyPlugin
Aktuell setze ich Outlook 2013 ein. Das könnte sich in naher Zukunft zwar auch ändern, im Moment bleibe ich aber noch dabei. Also ist eine einfache Integration von PGP in Outlook notwendig. Vorzugsweise über ein Plug-In, dass die notwendigen Schritte der Ver- und Entschlüsselung automatisch erledigt. Im besten Fall sogar transparent, also ohne noch mal manuell eine Aktion ausführen zu müssen. Sowohl über Twitter als auch Google wurde ich auf einige Plug-Ins aufmerksam gemacht. Obwohl ich gerne Software kaufe, wenn sie mir einen Mehrwert biete, finde ich circa 100 Euro für ein Plug-In, dass die eigentliche Arbeit an die PGP.exe delegiert, schon recht happig.
Daher habe ich mich letztendlich für die Open Source Variante OutlookPrivacyPlugin entschieden, die im Moment als BETA 34 vorliegt und Outlook 2010 und 2013 unterstützt. Die Installation verlief problemlos über ClickOnce. Lediglich die aktuelle Version des .NET Frameworks musste noch installiert werden. Das Plug-In ist, wenn zuvor Gpg4win installiert wurde, sofort einsatzbereit und bietet einige Einstellmöglichkeiten.
Auf der einen Seite können neue E-Mails automatisch signiert und/oder verschlüsselt werden (Abbildung 2). Sehr praktisch, da pro neuer E-Mail keine weiteren, manuellen Schritte notwendig sind. Beide Optionen habe ich allerdings zunächst nicht aktiviert. Die Signierung werde ich wohl bald nutzen. Die automatische Verschlüsselung nicht. Ich denke, damit würde ich ansonsten circa 98% meiner Kommunikationspartner ausschließen :). Leider! Aber Sinn und Zweck einer Verschlüsselung ist das natürlich auch nicht.
Des Weiteren besteht auch die Möglichkeit, geöffnete E-Mails automatisch zu verifizieren und zu entschlüsseln, falls entsprechende Informationen vorhanden sind beziehungsweise die E-Mail überhaupt verschlüsselt ist. Nach einem kurzen Test bleiben diese beiden Optionen auf jeden Fall aktiviert. Wird eine verschlüsselte E-Mail geöffnet, ist automatisch der Originaltext sichtbar. Es ist kein weiterer Schritt notwendig. Jetzt fehlt nur noch irgendwo ein Hinweis, dass diese E-Mail zuvor verschlüsselt war. Wirklich essentiell ist die Information nicht. Im Moment hätte ich sie nur gerne. Rein aus Interesse.
Abbildung 4 zeigt die möglichen Aktionen für eine neue E-Mail, die am rechten Rand der Ribbonbar zu finden sind. Sehr simpel. Mehr braucht es aber auch nicht. Einfach Sign und/oder Encrypt anklicken und die Nachricht verschicken. Das Plug-In erledigt den Rest, bevor die E-Mail wirklich gesendet wird. Den PGP-Schlüssel habe ich zuvor über Kleopatra erzeugt. Mit dem Tool können Zertifikate verwaltet werden und kann optional bei Gpg4win mit installiert werden. Eine Schönheit ist die Anwendung sicherlich nicht. Ein häufiges Problem bei Open Source Anwendungen. Aber die Zeit, die ich für das Mangement von Zertifikaten aufwenden muss, wird sich hoffentlich in Grenzen halten. Hin und wieder einen öffentlichen Schlüssel importieren ist schnell erledigt. Wer den E-Mail-Client Thunderbird einsetzt, sollte mal einen Blick auf enigmail werfen. Das scheint eine gute Erweiterung zu sein, die einen Blick wert ist.
Mittlerweile habe ich dazu auch einen weiteren Blogpost geschrieben, um enigmail ausführlich vorzustellen und zu besprechen.
Fazit
Das Plug-In erfüllt genau meine Anforderungen. Klein, performant, Open Source und nach der Installation transparent für den Anwender. Wie viele E-Mails ich in Zukunft tatsächlich verschlüsseln werde, hängt stark von meinen Empfängern ab. Unterstützen diese auch PGP, werde ich sicherlich häufiger darauf zurückgreifen. Einfach aus dem Grund, weil es einfach ist und der zusätzliche Aufwand gegen Null geht. Mein öffentlicher Schlüssel kann über mein Blog heruntergeladen werden. Im Impressum ist die entsprechende asc-Datei verlinkt. So ist der Aufwand gering, an meinen öffentlichen Schlüssel zu gelangen.
„Die automatische Verschlüsselung nicht. Ich denke, damit würde ich ansonsten circa 98% meiner Kommunikationspartner ausschließen“
sicher?
Ich hätte jetzt vermutet dass dies nur verschlüsselt wenn man den Öffentlichen Schlüssel des Gegenübers besitzt.
Hallo Skeptiker,
danke für die Info. Leider funktioniert das nicht ganz so. Ich habe einen zweiten Beitrag mit den Infos verfasst, der auch diese Frage beantwortet.
»Die Signierung werde ich wohl bald nutzen. Die automatische Verschlüsselung nicht. Ich denke, damit würde ich ansonsten circa 98% meiner Kommunikationspartner ausschließen :). Leider! Aber Sinn und Zweck einer Verschlüsselung ist das natürlich auch nicht.«
Also das kann eigentlich nicht stimmen, auch wenn ich das Outlook Plug In nicht nutze, läuft das ja dem hybriden Verschlüsselungsverfahren von PGP voll entgegen. Du brauchst ja einen öffentlichen Schlüssel des Kommunikationspartners um überhaupt für ihn verschlüsseln zu können. Und da ist völlig egal welches Plug In man nutzt. Und auch welche Service App eingesetzt wird. Ob nun GPG4Win oder GPG Tools.
Also das solltest Du noch mal prüfen. Du kannst also gar niemanden ausschließen, denn GPG 4 Win verschlüsselt dann einfach nicht im Hintergrund, weil es gar nicht verschlüsseln kann. Eine Signatur ist hingegen immer möglich, denn die Nachricht läuft im Klartext, lediglich die Signatur wird errechnet und kann vom Gegenüber evtl. nicht ausgelesen werden.
Also, wenn das doch auf seltsame und wunderhafte Weise, wie eine Quantenverschränkung , doch klappt und ich es einfach nicht verstehen kann, weil mein Intellekt nicht ausreicht, bzw. das nicht in mein menschliches Verständnis passt, meld‘ Dich noch mal! 😉
Man benötigt für S/MIME zwar ein Zertifikat einer CA, aber diese muss nicht akkreditiert sein. Es ist somit möglich – beispielsweise mittels XCA – eine eigene CA zu erstellen und sich die Zertifikate auszustellen. Wenn Du willst, kann ich dir gerne ein von mir verwendetes Template zusenden.
XCA ist kostenlos.
Selber ein Zertifikat erstellen ist natürlich immer möglich. Ist das dann aber nicht genau das Gegenteil einer CA? Dir hat ja niemand das „Vertrauen“ durch das Zertifikat ausgestellt.
Trotzdem bin ich an dem Template interessiert, da ich in Zukunft mehr über die Zertifikate schreiben möchte. Im Impressum findest du eine E-Mail Adresse. Freue mich über eine Nachricht :).
X.509 klappt oft nicht, weil selbst erstellte Zertifikate manchmal selbst dann nicht akzeptiert werden, wenn man das Root-Zertifikat auch importiert. Man muss auch nicht eine eigene CA aufbauen, sondern kann bei CACert mitmachen. Aber selbst damit scheint es manchmal Probleme zu geben. Kleinweich sind anscheinend nur Zertifikate angenehm, die mit Gebühren verbunden sind.
hallo,
ich habe in Gpg4win einen Schlüssel angelegt und erst später noch eine 2te email-Adresse eingefügt was ja laut der Anleitung funktionieren sollte. Wenn ich egal ob über den Testaccount Adele oder einen Kollegen eine verschlüsselte email auf diese 2te eMail-Adresse erhalte kann ich diese nicht entschlüsselt. Ich erhalte die Fehlermeldung “ error, unable to locate decryption key“. In Gpg4Win kommt unbekannter Empfänger. Auf der anderen eMail funktioniert es einwandfrei. Wie bekomme ich den Fehler beseitigt ? Wollte nicht unbedingt noch ein Zertifikat erstellen. Muss ich vielleicht in meinem privaten Schlüssel diese mit einfügen ???
Hallo,
vielen Dank für den Kommentar.
Die genutzten E-Mail Adressen müssen auf jeden Fall im privaten Schlüssel vorhanden sein, damit diese durch den Schlüssel identifiziert werden.
Falls Sie die zweite Adresse noch nicht zum privaten Schlüssel hinzugefügt haben, testen Sie das bitte einmal. Unter Kleopatra sollte das, unter den Eigenschaften eines Schlüssels, durch das Hinzufügen einer weiteren Benutzer-ID gehen.
Viele Grüße,
Fabian
Hallo,
habe das alte Zertifikat jetzt doch noch gefunden und belasse jetzt erstmal die beiden für die jeweilige eMail. Ich werde es aber nochmal versuchen die 2te eMail zu integrieren. Muss ich dann den privaten Schlüssel exportieren und wieder importieren damit dies auch dauerhaft bleibt oder einfach nur 2te email einfügen ?? Das habe ich schon mal gemacht hat ja wie beschrieben nicht funktioniert
Ich habe noch ein anderes Problem. Wenn ich das OutlookPrivacyPlugin installiere erhalte ich beim Neustart meines Win 8.1. Laptop die Fehlermeldung „Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt“. Kennt jemand diesen Fehler und wie den beheben kann ?
Hallo,
vielen Dank für den Kommentar.
Es sollte ausreichen, die zweite E-Mail einfach als weitere Benutzer-ID hinzuzufügen. Ich mache das immer über Kleopatra. Das Outlook-Plugin nutzt auch, wenn ich mich recht erinnere, die gleichen Zertifikate wie Kleopatra. Wenn es allerdings einen eigenen Zertifikatsspeicher hat, was ich mir nicht vorstellen kann, dann müsste dort das Zertifikat noch mal importiert werden.
Das Problem hatte ich bisher nicht, allerdings nutze ich auch schon eine Zeit lang kein Outlook mehr. Ich werde mich aber mal auf die Suche nach einer Lösung machen.
Viele Grüße,
Fabian
Da GpgOL beim Laden mein Outlook blockiert, habe ich jetzt mal das Outlook Privacy Plugin installiert. Die Integration ist unter Outlook 2010 ähnlich gut wie bei GpgOL unter Outlook 2003 / 2007. Verwundert bin ich allerding über die Tatsache, dass das Kennwort (Passphrase) nur einmalig abgefragt wird. Sicher ist das jetzt nicht.
Aber es gibt auch noch ein ernsthaftes Problem: Während das Verschlüsseln tadellos funktioniert, benutzt das Outlook Privacy Plugin beim Signieren plötzlich einen mir unbekannten Schlüssel. Leider kann ich bisher nicht ermitteln, woher der kommt und wie man das Problem fixt. Ich benutze übrigens die Beta 49. Beim Öffnen der Email wird folgendes angezeigt: ** Invalid signature from „“ with KeyId E99C134E. Wobei mir diese KeyID völlig unbekannt ist.
Verunsichert bin ich auch über den Reiter „Settings“ des Plugins. Dort wird von „Encryption: AES-128“ und „Digest: SHA-1“ gesprochen. Wurde hier vielleicht etwas implementiert, was parallel zu Gpg4Win arbeitet?
Gruß René