E-Mail Verschlüsselung []

Diese Seite ist nicht editierbar. Sie können den Quelltext sehen, jedoch nicht verändern. Kontaktieren Sie den Administrator, wenn Sie glauben, dass hier ein Fehler vorliegt.
====== E-Mail Verschlüsselung ======
Diese Untersuchung zum Thema E-Mail Verschlüsselung fand im August 2013 statt und spiegelt den Stand der Erkenntnisse zu diesem Zeitpunkt wieder. Die fortlaufende Berichterstattung zur NSA-Affäre hat **PGP** inzwischen stärker in den Vordergrund gerückt.
===== Verschlüsselungssysteme =====

Derzeit werden zwei unterschiedliche Systeme für die Verschlüsselung von E-Mails angewendet, dabei handelt es sich um **S/MIME** und **PGP** (bzw. GPG – dazu später mehr). Diese sind nicht kompatibel, verwenden unterschiedliche Datenformate und verfolgen unterschiedliche Lösungsansätze. Beiden gemein ist die Verwendung von asymmetrischen Schlüsseln (Schlüsselpaaren) zur Ver- bzw. Entschlüsselung von Informationen.

Der wesentliche Unterschied zwischen den Systemen besteht im Umgang mit den öffentlichen Schlüsseln. Grundsätzlich können öffentliche Schlüssel beliebig weitergegeben werden da deren Inhalt nicht geheim ist. Der Angriffspunkt besteht allerdings darin, dass die Identität des Schlüsselinhabers gefälscht werden kann und dadurch Zugang zu der vertraulichen Information entsteht. Die Lösung ist eine so genannte **PKI** (Public Key Infrastructure)

S/MIME bedient sich bei der Bestätigung der Identität so genannter Certification Authoritys (CA), die wie ein Notar in der realen Welt die Echtheit der Schlüssel bestätigen und in einer hierarchischen Organisation (Chain of Trust) untereinander vernetzt sind. Das Schlüsselpaar wird erstellt und der öffentliche Teil beim CA hinterlegt, der seinerseits die Vertrauenswürdigkeit (in Klassen 1 bis 3) und die Gültigkeitsdauer definiert und den Schlüssel als Zertifikat signiert.

PGP geht grundsätzlich davon aus, dass die Schlüssel individuell erzeugt und verwaltet werden. Standardmäßig heißt das, das jeder seinen öffentlichen Schlüssel an die Personen verteilt, mit denen er verschlüsselte Informationen austauschen möchte. Die Prüfung der Identität erfolgt dann im direkten Kontakt beispielsweise per Telefon durch Vergleich eines elektronischen Fngerabdrucks (Hash-Wert des Schlüssels). Anschließend setzt der Empfänger den Grad des Vertrauens und signiert den öffentlichen Schlüssel mit seinem privaten Schlüssel.
 
Inzwischen gibt es natürlich auch für die öffentlichen PGP-Schlüssel Schlüsselserver, wo man seinen Schlüssel hinterlegen kann und damit zur allgemeinen Verfügung stellt. Die Echtheit dieser Schlüssel auf einem Schlüsselserver wird nur anhand existierender Signaturen von Dritten bestätigt. Inwieweit man dem traut, muss jeder selber entscheiden und im Zweifel wieder per Fingerabdruck selber prüfen (Web of Trust).
 
==== S/MIME (Secure / Multipurpose Internet Mail Extensions) ====
S/MIME basiert direkt auf den Standard-Spezifikationen der E-Mail-Inhalte. Es wird daher von vielen E-Mail-Clients „out of the box“ unterstützt. Ebenfalls ist die Verfügbarkeit über Systemgrenzen hinweg weitgehend gegeben.

Nachteil ist die bürokratische Verwaltung der Zertifikate. So müssen diese alle Jahre wieder neu beantragt werden und alte Zertifikate ordentlich aufgehoben werden, da sonst alte Mails nicht mehr gelesen werden können. Die meisten CA bieten inzwischen nur noch kostenpflichtige Zertifikate, was ebenfalls von einem Ausprobieren der Verschlüsselung abhält. 

Ausnahmen sind z. B. [[https://www.secorio.com/|secorio]], wo ein Klasse 1 Zertifikat von Comodo mit einem Jahr Gültigkeit für private Zwecke kostenlos angeboten wird. Das Zertifikat kann auch direkt bei [[https://www.comodo.com/home/email-security/security-software.php|Comodo]] bestellt werden.

Ein Test verlief erfolgreich, prinzipiell kann damit ein Einstieg in das Thema erfolgen. \\
Das Zertifikat eines Web.de – Mailkontos konnte ebenfalls erfolgreich getestet werden. Hier muss nur das Stammzertifikat von Web.de zusätzlich in die Clients importiert werden, da dieser Provider in den Standards der Browser und MailClients unbekannt ist.

==== PGP (Pretty Good Privacy) ====
PGP wurde vor längerer Zeit als offene Alternative zum eher kommerziellen S/MIME Umfeld entwickelt. Inzwischen ist PGP ebenfalls eine komerzielle Softwarelösung und die Open Source Gemeinde hat den GNU Privacy Guard, kurz GnuPG oder GPG etabliert. PGP und GPG sind voll kompatibel, im privaten Umfeld ist daher heute meist GPG im Einsatz.

Vorteil von GPG ist der private Ansatz, Verschlüsselung kann eingesetzt werden ohne dass die Schlüssel irgendwo öffentlich hinterlegt sein müssen. Man braucht keine Adressen bekannt zu geben und kann sicher sein, dass niemand außer den Kommunikationspartnern etwas von den Schlüsseln weiß.

Ein weiterer Vorteil ist, dass für ein Schlüsselpaar beliebig viele eMail – Adressen zugelassen werden können. Aliasnamen und sonstige Mail-Kontos können so mit dem gleichen Schlüsselpaar abgesichert werden. Der Schlüssel ist sozusagen persönlich und nicht auf ein Konto bezogen.  

Nachteil ist, dass GPG außer auf Linux-Maschinen immer nachträglich installiert werden muss und manchmal schlecht bis gar nicht unterstützt wird. Ein weiterer Nachteil ist, dass mit PGP/MIME zwar inzwischen auch ein vollständiges Mail-Inhalts-Konzept existiert, dieses leider aber von großen Hersteller ignoriert oder auch boykottiert wird. Das führt dazu, das beim Einsatz von GPG  sicherheitshalber auf HTML-Mail verzichtet und Anlagen einzeln separat verschlüsselt werden. 

So wirkt GPG im Einsatz nicht mehr ganz zeitgemäß, obwohl beispielsweise die Mails zwischen zwei Nutzern mit Thunderbird/Enigmail genauso elegant verschlüsselt werden können wie mit S/MIME.

===== Einsatz von Verschlüsselung im heterogenen Umfeld =====
Um eine Entscheidung für das eine oder das andere Verschlüsselungssystem zu treffen, ist wesentlich wie einfach sich die Verschlüsselung in die jeweilige E-Mail Umgebung integrieren lässt, die Schlüssel-Verwaltung funktioniert und der Dienst genutzt werden kann. 

==== Web-Dienste ====
Die Web-Dienste der Mail-Provider lassen das Thema Verschlüsselung fast ausnahmslos außen vor. Einzige Ausnahme ist [[http://web.de|Web.de]], die selber eine CA sind und allen Nutzern automatisch ein S/MIME Zertifikat ausstellen.

Das Ganze ist aber beinahe verschämt in der Web-Oberfläche versteckt und lädt nicht unbedingt zur Nutzung ein. Alle Anderen Anbieter bieten keine Möglichkeit zur Verschlüsselung in den Web-Oberflächen.

Letztlich ist das auch verständlich, denn die Software läuft auf den Web-Servern der Provider und damit sind die E-Mails zumindestens teilweise ungeschützt unterwegs. Nach strenger Auslegung der Sicherheit darf die Ver- bzw. Entschlüsselung nur auf dem Client erfolgen.

PGP ist als Web-Dienst bei den Providern unbekannt. Ein spannendes Konzept entwickelt Mailvelope http://www.mailvelope.com/. Hier wird PGP als Client-AddOn für Chrome und Firefox angeboten, das sich dann nahtlos in die Mail-Software von Gmail, GMX oder Yahoo integriert. So kann es gehen, aber das Projekt ist wirklich noch in einer sehr frühen Entwicklungsphase und der t-online-Client wird nirgends erwähnt.

**Fazit:** Verschlüsselung mit dem Web-Client kann man momentan vergessen, auch wenn Web.de eine löbliche Ausnahme darstellt.

==== Linux ====
Alle aktuellen Linux-Distributionen enthalten GPG standardmäßig. Hintergrund dafür ist, das die Verteilung von Linux-Software durch GPG – Zertifikate abgesichert wird. Dadurch ist aber noch nicht gewährleistet, dass im eMail-Client ebenfalls GPG – Verschlüsselung zur Verfügung steht. Für den beliebten Client Thunderbird gibt es das AddOn enigmail, das alle wesentlichen Funktionen von GPG in Thunderbird integriert. Andere Mail-Clients wie z. B. Kmail unterstützen GPG „out of the box“. 

S/MIME wird in Thunderbird „out of the box“ unterstützt. Für den ersten Test in Ubuntu-Linux waren daher alle Software-Vorausetzungen sofort erfüllt, bzw. konnten mit enigmail aus dem Softwarecenter nachgeladen werden.

**Fazit:** Alle Voraussetzungen für eine schnelle Einführung der Verschlüsselung sind in LINUX erfüllt.

==== Windows ====
In Windows ist das Bild etwas heterogener. Von Haus aus enthält das Betriebssystem bis heute keine Kryptografie – Lösung. Die mitgelieferten eMail-Clients sind eher einfach bis unbrauchbar, je nachdem welche Windows-Version man als Grundlage nimmt. 

Platzhirsch bei den eMail-Clients unter Windows ist Outlook. Outlook wird mit MS-Office mitgeliefert und dient vornehmlich zur Anbindung an Microsofts Exchange-Servern in Unternehmen. Outlook kann aber auch mit Mail-Konten bei Providern zusammenarbeiten und besitzt eine Funktion zur Verwaltung und Nutzung von S/MIME – Zertifikaten. PGP ist standardmäßig unbekannt. Die Verwaltung von öffentlichen Schlüsseln der Partner zur Verschlüsselung ist über Outlook - Kontakte geregelt und unnötig umständlich. Eine [[http://office.microsoft.com/de-de/outlook-help/hinzufugen-oder-importieren-eines-zertifikats-zu-den-oder-in-den-kontakten-HA010099276.aspx#BM1|Beschreibung von Microsoft]] hilft etwas, in einem Firmennetzwerk können die öffentlichen Schlüssel auch im Globalen Adressbuch hinterlegt werden, was die Bedienung etwas vereinfacht.

Modzillas Thunderbird gibt es genau wie Firefox natürlich auch in einer Windows – Version. Dort gilt das Gleiche wie unter Linux. S/MIME sofort und auch erfolgreich getestet, GPG nur via enigmail – sofern GPG überhaupt auf dem Windows Rechner existiert.

Durch das Bundesamt für Sicherheit in der Informationstechnik (BSI) wurde ein Projekt gefördert, dass GPG unter Windows bereitstellt. Die Software heißt Gpg4win http://www.gpg4win.de und soll sogar Komponenten zur Einbindung in Outlook enthalten. Ich habe das noch nicht weiter getestet, denn ich nutze kein Outlook. Die neueste Version von Outlook, auf die Zugriff habe ist aus Office XP aus dem Jahr 2001 und das möchte ich dann doch nicht mehr verwenden. 

Einen kommerziellen Anbieter von PGP für Outlook habe ich auch gefunden. Der will allerdings € 95,-- für die Software haben, was ich eine Frechheit finde, denn der zentrale Baustein GPG ist nun einmal kostenlos.

**Fazit:** Die Einbindung der Verschlüsselung in Windows mit Thunderbird als Client ist kein Problem, Outlook oder andere Mail-Clients müssen bei Bedarf noch getestet werden und benötigen ggf. zusätzliche Softwarekomponenten. PGP ist auf alle Fälle mit Bastelei verbunden, denn es ist ein Fremdkörper auf Windows – Systemen, auch wenn das BSI löblicherweise ein kostenloses Framework finanziert hat.

==== Android ====
Für Android gibt es eine App, die S/MIME zur Verfügung stellt. Diese arbeitet mit der App Gmail zusammen.
http://www.djigzo.com/android.html

Djigzo ist dabei eigenständig und enthält nur den S/MIME – Verwaltungsteil sowie einen Erstellungs- und Sendeclient. Eine verschlüsselte Mail wird in der Gmail App ohne Text aber mit einer .p7m  -Anlage dargestellt.

Beim Öffnen der Anlage startet Djigzo und zeigt den verschlüsselten Inhalt. Eine unterschriebene Mail enthält eine .p7s – Anlage. Wird diese geöffnet,  wird der öffentliche Schlüssel nach Djigzo importiert. 

Für PGP ist K9 als Mail – Client erforderlich. Eine parallele Installation zur Gmail App ist möglich, aber die Systeme konkurrieren, so werden z. B. bei einem Mail-Eingang 2 Meldungen angezeigt. Die Deinstallation von Gmail App wird empfohlen, habe ich im Moment keinen Nerv dafür. 

**Fazit:** Keine ganz tolle Lösung, möglicherweise wäre K9 auch für S/MIME eine Alternative, aber es funktioniert und schaufelt mir nicht den Speicher voll. 

==== IOS ====
S/MIME wird ab iOS 5 „out of the box“ unterstützt. Eine Anleitung befindet sich hier: \\
http://www.iphone-ticker.de/email-verschlusselung-im-video-erklart-smime-im-ios-5-23204/

In dem Chat am Ende dieser Anleitung sind einige Hinweise, die Einschränkungen in der Implementierung aufzeigen. Es kann nur genau ein privates Zertifikat verwaltet werden, mehrere Mail-Accounts können nicht mit S/MIME unterstützt werden. \\
Ist S/MIME aktiviert, wird eine Mail immer unterschrieben und verschlüsselt, sofern der öffentliche Schlüssel des Empfängers bekannt ist. Aussetzen geht nur über die Mail-Einstellungen. Es besteht kein Zugriff auf die root-Zertifikate. Ein User-Zertifikat von Web.de kann nicht verwendet werden, da man keine root-Zertifikate von Web.de importieren kann.  Inwieweit StartCom als root-Zertifikat vorhanden ist muss noch geprüft werden. Das TC Trustcenter aus dem Video gibt es nicht mehr.

Ansonsten braucht es noch eine Methode, wie die .p12 – Datei auf das iPad transportiert wird. Vermutlich via iTunes, oder? Das Versenden per mail im Video ist jedenfalls keine wirklich gute Idee. Der private Schlüssel ist zwar mit einem Passwort geschützt, sollte die private Umgebung aber nie verlassen. Und USB-Sticks kann man am iPad nicht verwenden. 

PGP ist in iOS völlig unbekannt, ich habe keine App gefunden, mit der pgp o. gpg auf dem iPad bereitgestellt werden kann.

**Fazit:** S/MIME wird unterstützt, sofern man mit den Einschränkungen zurecht kommt. 

==== OS(X) ====

S/MIME wird in Apple Mail "out of the box" unterstützt. Die Zertifikate werden in der Schlüsselverwaltung abgelegt. Dort muss auch das Private Zertifikat als .p12-Datei importiert werden. Anschließend geht Alles "fast" wie von selber. 

Probleme gab es mit unbekannter CA von Web.de. Lag aber vermutlich an einem Fehler bei Web.de.

Ein weiteres Problem war, dass auch Ablauf eines Zertifikats noch verschlüsselte E-Mails versendet werden konnten. Fehler in Apple Mail. Ein neues Zertifikat mit atiueller Gültigkeit wird nicht sofort an die E-Mail Adresse gebunden, sonder muss in der Schlüsselverwaltung per Rechtsklick mit "neue Zertifikatseinstellung" der E-Mail Adresse zugewiesen werden.
===== Gesamtfazit =====
S/MIME ist zwar durch die Beantragung der Schlüssel am Start etwas aufwändiger, und verlangt alle Jahre wieder einen Eingriff durch die beschränkte Gültigkeit der Schlüssel. Durch die bessere und breitere Unterstützung in den Betriebssystemen und Applikationen wird das aber ausgeglichen. Aus meiner Sicht sollten wir S/MIME anwenden, meine Erfahrungen mit StartCom als CA sind auch in Ordnung. Bleibt zu hoffen, dass ein kostenloses Zertifikat auch künftig zu erhalten ist.

Der folgende Beitrag zeigt, wie eine eigene CA eingerichtet werden kann. Damit ist S/MIME von den Notaren unabhängig und funktioniert reibungslos. Lediglich der Umstieg auf ein neues Zertifikat nach Ablauf der Gültigkeit ist immer etwas knifflig.
===== Einrichtung einer eigenen CA =====

Für SSL - Verschlüsselungen und private E-Mail Verschlüsselung kann die Einrichtung eines eigenen CA eine sinnvolle Lösung sein. Windows Server bringen die Möglichkeit einer CA mit, Vorteil ist die automatische Verteilung des CA-Zertifikats, hierzu eine [[http://www.msxfaq.de/signcrypt/setupca.htm|Checkliste]], die allerdings auch gute Argumente bei einer Linux-based CA enthält. Vollständig ist die CA allerdings nur im Enterprise Server!

Wie ein CA prinzipiell eingerichtet wird ist in [[http://wiki.ubuntuusers.de/CA|ubuntuusers/CA]] beschrieben. 
Umfassender und mit Einbeziehung des Themas "Radius" ist http://root.bbs-duew.de/ca/OpenSSL-Windows-Zertifikat-Erstellung.htm . Das ist die [[https://thomas-leister.de/internet/eigene-openssl-certificate-authority-ca-erstellen-und-zertifikate-signieren/|Step-by-step Anleitung]]. Und dann gibt es noch das [[http://www.absolute-cool.de/dokus/ssl/openssl/|OpenSSL Handbuch]], das aber eher zur Verwirrung denn Hilfe beiträgt.

Darüber hinaus habe ich folgende Erfahrungen gemacht. Der Ramdomizer brachte eine Fehlermeldung, was daran lag, dass die Datei ''$HOME/.rnd'' root gehörte. 

Folgende Änderungen in ''/usr/lib/ssl/misc/CA.pl'' machen Sinn:
    * $DAYS="-days 730";     # 2 year
      * $CADAYS="-days 3650";  # 10 years

Folgende Änderungen in ''/etc/ssl/openssl.cnf'' machen Sinn:
  * default_days = 730
  * default_bits = 2048

**Offen:** Die Zertfikate werden mit SHA-1 generiert. Der Schalter ''-sha256'' sollte noch ergänzt werden. Dann allerdings müssen die Zertifikate noch einmal getestet werden. Zumindestens apache ist von Haus aus nicht unbedingt auf SHA-2 eingestellt.

Die Anleitung hat zur Verschlüsselung für eine Web-Seite funktioniert. Die nächste Frage ist die S/MIME Verschlüsselung in E-Mail. 

Das Zertifikat für eine S/MIME Verschlüsselung wird mit ''/usr/lib/ssl/misc/CA.pl -newreq'' erzeugt und anschließend mit ''/usr/lib/ssl/misc/CA.pl -sign'' signiert. Wichtig ist dabei, dass die E-Mail Adresse 100% stimmen muss. 

Als letzten Schritt wird dann das folgende Kommando abgesetzt.

<code>
$ openssl pkcs12 -export -in newcert.pem -inkey newkey.pem -out user_email.pfx
</code>

Damit entsteht aus dem neuen Zertifikat des CA ein E-Mail Zertifikat ''user_email.pfx''. Manche E-Mail Clients kommen mit der Endung .pfx micht zurecht. Die resulitierde Datei kann auch in *.p12 unbenannt werden. 

Dieser Schlüssel funktioniert auch in Outlook. Eine .pfx-Datei kann sofort in den Zertifikatsspeicher importiert werden und steht dann im Trust-Center/E-Mail von Outlook2013 zur Verfügung. Wichtig ist es auch, das CA-Cert zu importieren, da sonst keine funktionsfähige Trust-Kette existiert. Wenn alles geklappt hat, sind in E-Mail verfassen / Optionen die Buttons für "Verschlüsseln" und "Unterschreiben" aktiv.

Problematisch ist Outlook hinsichtlich Verschlüsselung. Zu Verschlüsseln muss die E-Mail Adresse als Kontakt existieren UND das öffentliche Zertifikat des Partners dem Kontakt zugeordnet sein. Der Empfang einer unterschriebenen E-Mail wie bei Thunderbird reicht also nicht, um den Zertifikatsspeicher zu erweitern. 

Die Ergebnisse zu den CA-Untersuchungen sind auch in {{smime-prinzipien.docx}} zusammengefasst.

Ich packe das Verzeichnis demoCA in einen tarball und verschlüssele es mit dem Kommando

<code>
$ # Verschlüsseln
$ gpg --force-mdc -c tarball.tgz
$ # Entschlüsseln und auspacken
$ gpg -d tarball.tgz.gpg | tar -xvfz -
</code>