Privacy-Handbuch: E-Mails verschlüsseln

Dieser Abschnitt ist noch im Entstehen und noch nicht offizieller Bestandteil des Buchs. Gib den Autoren Zeit, den Inhalt anzupassen!

Weltweit wird der unverschlüsselte E-Mail-Verkehr systematisch gescannt. Führend ist die NSA mit Echelon, das auch zur Industriespionage sowie zum Abhören von NGOs verwendet wird, und Abhörschnittstellen bei allen großen amerikanischen ISPs. Frankreich betreibt ein ähnliches System unter dem Namen French ECHELON. Das russische Pendant zur NSA ist der SSSI (früher FAPSI). Der schwedische Geheimdienst FRA und das Schweizer Onyx Projekt nutzen Supercomputer zur Verarbeitung der beim Schnorcheln anfallenden Datenmengen. Für Syrien, Iran, Saudi Arabien und Ägypten wurden entsprechende Aktivitäten nachgewiesen, und die Great Firewall von China hat ebenfalls über die nötigen Fähigkeiten.

In Deutschland wird der E-Mail-Verkehr im Rahmen der Strategischen Fernmeldeaufklärung von den Geheimdiensten gescannt. Eine von der G-10-Kommission genehmigte Stichwortliste mit 16.400 Begriffen (Stand 2010) wird für die automatisierte Vorauswahl verwendet, um nach Waffenhandel und Terroristen zu suchen. 37 Mio. E-Mails meldeten die Scanner im Jahr 2010 als verdächtig, die näher analysiert wurden.

Mit dem Verschlüsseln von E-Mails wird die Vertraulichkeit der Kommunikation gewährleistet. Eine Nachricht kann nur vom Empfänger geöffnet und gelesen werden.

Asymmetrischen Verschlüsselung

• Jeder Anwender generiert ein Schlüsselpaar, bestehend aus einem geheimen und einem öffentlichen Schlüssel. Während der geheime Schlüssel sorgfältig geschützt nur dem Anwender zur Verfügung stehen sollte, ist der öffentliche Schlüssel an alle Kommunikationpartner zu verteilen.
• Wenn der Anwender Anton eine signierte E-Mail an die Anwenderin Beatrice senden will, erstellt er eine Signatur mit seinem geheimen Schlüssel. Die Anwenderin Beatrice kann mit dem öffentlichen Schlüssel von Anton die Nachricht verifizieren, da nur Anton Zugriff auf seinen geheimen Schlüssel haben sollte.
• Wenn Beatrice eine verschlüsselte Nachricht an Anton senden will, nutzt sie den öffentlichen Schlüssel von Anton, um die Nachricht zu chiffrieren. Nur Anton kann diese E-Mail mit seinem geheimen Schlüssel dechiffrieren und lesen.

Mit OpenPGP und S/MIME haben sich zwei Standards etabliert:

• OpenPGP: PGP (Pretty Good Privacy) und die kostenlose Alternative GnuPG (GNU Privacy Guard) stellen für die Verschlüsselung eine lang erprobte Software zur Verfügung. In der Regel können gängige E-Mail-Programme nicht out-of-the-box mit OpenPGP umgehen. Installation zusätzlicher Software ist nötig. Dafür ist es relativ einfach, die nötigen Schlüssel zu erzeugen. Für den Austausch der Schlüssel stellt das Internet eine ausgebaute Infrastruktur bereit.
• S/MIME: Das Secure MIME Protokoll (S/MIME) wurde 1998 entwickelt und ist heute in den meisten E-Mail-Clients integriert. Es werden Zertifikate nach dem Standard X.509 für die Verschlüsselung genutzt. Diese Zertifikate werden von einer Certification Authority (CA) ausgestellt und beglaubigt. Es ist nötig, gegenüber der CA die Identität des Nutzers mit Ausweisdokumenten nachzuweisen.

GnuPG und Thunderbird

Die folgende Anleitung erläutert den Einsatz von GnuPG in Kombination mit Thunderbird, dem E-Mail-Client der Mozilla Foundation. Alle Komponenten stehen für Linux, Mac OS und WINDOWS kostenfrei zur Verfügung:

Installation von GnuPG

GnuPG ist eine frei nutzbare Implementierung des OpenPGP-Standards zur Verschlüsselung und Signierung von Daten. Es wird vom GNU-Projekt ständig weiterentwickelt.

Linux:

alle Distributionen installieren GnuPG standardmäßig.

MacOS:

nutzen Sie die GPGTools .

Windows 1:

Das Projekt gpg4win stellt ein Paket für Windows bereit mit GnuPG v. 2.0 und dem GNU Privacy Assistant für die Schlüsselverwaltung.

Windows 2:

Ich kann auch das Paket GpgSX empfehlen, welches neben GunPG einige zusätzliche Dienstprogramme enthält (grafische Schlüsselverwalung, Erweiterung für den Explorer).

[htb]

[[Image:../screenshots/gpgsx1.png|image]] [abb:gpgsx]

Nach dem Herunterladen ist das Installationsprogramm zu starten und den Anweisungen zu folgen. Die Komponenten GnuPG und GpgSX sind zu installieren.

Installation der Enigmail-Erweiterung

Enigmail ist eine Erweiterung für Mozilla Thunderbird, welche eine Schnittstelle zu GnuPG bereitstellt und den Umgang mit Verschlüsselung im täglichen E-Mail Chaos vereinfacht. Am einfachsten installiert man Enigmail mit dem Add-on Manager von Thunderbird. Den Manager findet man unter Extras - Add-ons. Im Suchfeld gibt man Enigmail ein. Ein Klick auf den Button Installieren holt das Add-on.

[htb]

[[Image:../screenshots/enigmail_inst.png|image]] [abb:enigmailinst]

Nach Installation von Enigmail muss Thunderbird neu gestartet werden! Nach dem Neustart kann man den Konfigurations-Assistenten unter OpenPGP - OpenPGP-Assistent aufrufen. Dabei werden folgende Schritte durchlaufen:

1. Abfrage, ob gesendete E-Mails standardmäßig signiert und verschlüsselt werden sollen. Um unbedarfte Anwender nicht zu verwirren, kann man diese Funktion deaktivieren.

2. Abfrage, ob gesendete E-Mails standardmäßig verschlüsselt werden sollen. Da man meist nur OpenPGP-Schlüssel von wenigen Empfängern hat, kann man diese Option zunächst deaktivieren. Später, wenn sich die Verschlüsselung im Bekanntenkreis durchgesetzt hat, ist eine Aktivierung vielleicht sinnvoll.

3. Optimierung der Einstellungen für GnuPG. Die Vorgaben sind sinnvoll und sollten übernommen werden.

4. Generieren der Schlüsselpaare für alle vorhandenen Konten. Die Passphrase für den Zugriff auf den privaten Schlüssel sollte man sich vorher gut überlegen und merken! Es heißt Passphrase und nicht Passwort. Die Passphrase darf ruhig etwas länger sein und auch Leer- bzw. Sonderzeichen enthalten.
   

   Die Vorschläge des Assistenten sind erst einmal sinnvoll. Individuelle Anpassungen (z.B. 4096 Bit Schlüssellänge usw.) kann man nur beim Erstellen eines neuen Schlüssels in der Schlüsselverwaltung wählen.
   

   Kryptografischen Funktionen können nicht unbegrenzt den Fortschritten der Kryptoanalyse widerstehen. Es ist sinnvoll, die Nutzungszeit des Schlüssels mit einem Haltbarkeitsdatum zu versehen. Eine Nutzung länger als 5 Jahre sollte man nur in begründeten Ausnahmen in Erwägung ziehen. Bei der Schlüsselerstellung sollte ein Verfallsdatum angegeben werden.
   

   Mit jedem Schlüsselpaar kann auch ein Zertifikat für den Rückruf erstellt und sicher gespeichert werden. Mit diesem Zertifikat kann man einen Schlüssel für ungültig erklären, wenn der private Schlüssel kompromittiert wurde oder die passphrase in Vergessenheit gerät.
   Dieser vierte Schritt kann übersprungen werden, wenn man bereits gültige OpenPGP-Schlüssel hat.

5. FERTIG

Sollte Enigmail das Programm gpg nicht finden, weil man lieber die Version 2 gpg2 von GnuPG nutzen möchte oder weil man es unter WINDOWS in einem selten verwendeten Verzeichnis liegt, wählt man den Menüpunkt OpenPGP / Einstellungen und gibt im Dialogfenster den Pfad zum GPG-Programm ein.

Schlüsselverwaltung

Die Schlüsselverwaltung findet man in Thunderbird unter dem Menüpunkt OpenPGP - Schüssel verwalten. Ist die Liste noch leer, wählt man zuerst den Menüpunkt Erzeugen - Neues Schlüsselpaar. Diesen Schritt übernimmt jedoch auch der Assistent zur Einrichtung von Enigmail.

[htb]

[[Image:../screenshots/enigmail_schl.png|image]] [abb:enigmail_schl]

Exportieren des eigenen öffentlichen Schlüssels

Um verschlüsselt zu kommunizieren, muss den Kommunikationspartnern der eigene öffentliche Schlüssel zur Verfügung gestellt werden. Der einfachste Weg nutzt die Schlüsselserver im Internet. In der Schlüsselverwaltung findet man den Menüpunkt Schlüssel-Server / Schlüssel hochladen. Der öffentliche Schlüssel wird auf den Schlüsselserver exportiert und steht dort allen Partnern zur Verfügung. Die verschiedenen Server synchronisieren ihren Datenbestand.

Alternativ könnte man den öffentlichen Schlüssel als E-Mail-Anhang versenden oder als Datei auf einem Webserver ablegen. Den Menüpunkt für den Export in eine Datei findet man unter Datei - Schlüssel exportieren in der Schlüsselverwaltung. Um den Schlüssel als Anhang an eine Mail anzuhängen, aktivieren Sie die Option OpenPGP - Meinen öffentlichen Schlüssel anhängen beim Schreiben einer Mail wie im Bild [abb:enigmailaddkey] zu sehen.

[htb]

[[Image:../screenshots/enigmail_add_key.png|image]] [abb:enigmailaddkey]

Import der Schlüssel der Partner

Um an einen Kommunikationspartner verschlüsselte E-Mails zu senden oder die Signatur erhaltener Nachrichten zu prüfen, benötigt man den öffentlichen Schlüssel des Partners.

• Am einfachsten läßt sich dieser importieren, wenn man eine signierte E-Mail erhalten hat. Ein Klick auf den blauen Stift rechts oben im Header der E-Mail reicht aus, um den öffentlichen Schlüssel von einem Schlüsselserver zu importieren.

• Zum Importieren des Schlüssel eines Partners aus einer Datei, die man als Anhang oder als Datei zum Herunterladen erhalten hat, wählt man den Menüpunkt Datei / Importieren in der Schlüselverwaltung.

• Wenn der Schlüssel als Text angeboten wird, sieht es etwa so aus:

   -----BEGIN PGP PUBLIC KEY BLOCK-----
   Version: SKS 1.1.1
   
   mQENBEt5GIIBCACOnOeTtfBIUbdcOmw5DlLuxkQB4uQ/8HbSUaH96s1z
   HqFA/31GB70podyEKqc41T2TDdWWITfdy1dpxeGwopBK/wljPAuNAgJQ
   ....
   fU7xEW/RQT76n0RfTXnbj2m/DRPmoivcXW5G/zJM6QUjl++vO7OB+3xb
   SnDCMQtaWHM57eLcmnsMAK3qHOYlVrNUTSvEgatjUqLU
   =fP9T
   -----END PGP PUBLIC KEY BLOCK-----

  Man kann die Zeilen von BEGIN ...bis... END mit der Maus markieren und in die Zwischen­ablage kopieren. In der Schlüssel­verwaltung von Enigmail importiert man den Schlüssel wie im Bild [abb:enigmailimp] dargestellt mit Bearbeiten - Aus Zwischenablage importieren.

  [htb]

  [[Image:../screenshots/enigmail-clip.png|image]] [abb:enigmailimp]

• Auch ohne eine signierte E-Mail erhalten zu haben, kann man die Schlüsselserver nach dem zu einer E-Mail Adresse gehörenden Schlüssel durchsuchen. Die Funktion findet man unter dem Menüpunkt Schlüssel-Server / Schlüssel suchen. Man gibt in der sich öffnenden Dialogfenster die E-Mail-Adresse des Empfängers ein und bestätigt mit Ok.
  

  Wurden zur Suchanfrage passende Schlüssel gefunden, werden diese in einer Liste angezeigt. Wählen Sie aus dieser Liste den zu importierenden Schlüssel und bestätigen Sie mit OK. Wenn mehrere passende Schlüssel für eine E-Mail Adresse gefunden wurden, ist in der Regel der neueste Schlüssel die richtige Wahl.

  [htb]

  [[Image:../screenshots/enigmail_suche2.png|image]] [abb:enigmailsuche]

Signieren und Verschlüsseln erstellter E-Mails

Wurde in den Kontoeinstellungen in der Sektion OpenPGP die Option Nachrichten standardmäßig verschlüsseln aktiviert, sind beim Schreiben einer E-Mail keine weiteren Hinweise zu beachten. Anderenfalls ist für jede E-Mail explizit festzulegen, dass sie verschlüsselt werden soll.

Das Fenster für das Erstellen einer neuen E-Mail (Bild [abb:thunder_email_neu]) zeigt nach der Installation des Enigmail-PlugIns einen neuen Button OpenPGP. Klickt man auf diesen Button, öffnet sich der im Bild [abb:thunder_email_neu] gezeigte Dialog, der es ermöglicht, die Krypto-Eigenschaften für diese E-Mail festzulegen.

Sollte die E-Mail Anhänge enthalten, ist die Option PGP / MIME zu aktivieren, um die Anhänge standardkonform zu verschlüsselt.

Achtung: Die Betreffzeile wird nicht (!) mit verschlüsselt. Sicher wird man die Kontonummer nicht in der Betreffzeile schreiben, aber auch ein ausführlicher Betreff ermöglicht zusammen mit der Adresse oder den Adressen der Empfänger einige Aussagen über die Kommunikation.

Wenn man als Betreff beispielsweise schreibt:

Treffen der Aktivisten-Gruppe ... am 13.01.09

und diese Mail per CC an alle Mitglieder der Gruppe versendet, sind 90% der relevanten Informationen bekannt, und man kann sich die Verschlüsselung der Mail sparen.

Alternativ ist es auch möglich, lediglich für bestimmte Empfänger festzulegen, dass alle E-Mails signiert oder verschlüsselt werden sollen. Für die Festlegung dieser Regeln ist der entsprechende Dialog über OpenPGP / Empfängerregeln in Thunderbird zu öffnen.

[htb]

[[Image:../screenshots/gpg_senden.png|image]] [abb:thunder_email_neu]

Adele - der freundliche OpenPGP E-Mail-Roboter

Adele ist der freundliche OpenPGP E-Mail-Roboter der G-N-U GmbH. Man kann mit dem Robot seine ersten verschlüsselten Mails austauschen und ein wenig üben ohne Freunde mit Anfänger­probleme zu belästigen.

1: Den eigenen Schlüssel an Adele senden:

Als erstes schickt man den eigenen öffentlichen Schlüssel per E-Mail an adele@gnupp.de. Den Schlüssel hängt man als Anhang an die Mail an, indem man die Option OpenPGP - Meinen öffentlichen Schlüssel anhängen vor dem Versenden der Mail aktiviert (Bild [abb:enigmailaddkey])

2. Verschlüsselte Antwort von Adele:

Als Antwort erhält man nach einigen Minuten eine verschlüsselte E-Mail von Adele. Die E-Mail wird nach Abfrage der Passphrase entschlüsselt und enthält den Schlüssel von Adele:

 Hallo,
 
 hier ist die verschlüsselte Antwort auf Ihre E-Mail.
 
 Ihr öffentlicher Schlüssel wurde von mir empfangen.
 
 Anbei der öffentliche Schlüssel von adele@gnupp.de,
 dem freundlichen E-Mail-Roboter.
 
 Viele Grüße,
 adele@gnupp.de
 
 -----BEGIN PGP PUBLIC KEY BLOCK-----
 Version: GnuPG v1.4.9 (GNU/Linux)
 
 mQGiBDyFlIkRBACfVHJxv47r6rux7TwT4jHM7z/2VfyCrmcRegQEsbdLfqu3mEmK
 RouuaDQukNINWk2V2ErOWzFnJqdzpapeuPJiOWp0uIEvU3FRPhYlytw9dFfwAHv4
 MJ7639tAx9PfXBmZOd1PAoE451+VLhIGlLQiFGFppJ57SZ1EQ71/+/nkSwCg8Mge
 ....
 EQIABgUCPIWUlQASCRDlczRpkqs/9wdlR1BHAAEBv20AoJJGeeZjMCSbXtmNSwfW
 QsLOd0+4AKCdXwt552yi9dBfXPo8pB1KDnhtbQ==
 =ERT8
 -----END PGP PUBLIC KEY BLOCK-----

3. Schlüssel von Adele importieren:

Man kann die Zeilen von BEGIN PGP PUBLIC KEY BLOCK bis einschließlich END PGP PUBLIC KEY BLOCK mit der Maus markieren, in die Zwischenablage kopieren und in der Schlüsselverwaltung über Bearbeiten - Aus Zwischenablage importieren einfügen.

Alternativ holt man sich Adeles Schlüssel mit der ID 0x92AB3FF7 von einem Keyserver.

4. Adele verschlüsselte E-Mails schreiben

Jetzt kann man Adele verschlüsselte E-Mails schicken. Als Antwort erhält man umgehend eine gleichfalls verschlüsselte E-Mail mit dem gesendeten Text als Zitat.

 Hallo,
 
 hier ist die verschlüsselte Antwort auf Ihre E-Mail.
 
 Ich schicke Ihnen Ihre Botschaft im Wortlaut zurück, damit Sie
 sehen, dass ich sie erfolgreich entschlüsseln konnte.
 
 > Hello Adele,
 >
 > hope you are feeling well.

Verschlüsselung in Webformularen

Auch bei der Nutzung eines Webmail Accounts oder Webforms für die Versendung anonymer E-Mails muss man auf Verschlüsselung nicht verzichten.

Einige grafische Tools für die Schlüsselverwaltung wie z.B. GPA (GNU Privacy Assistent) oder KGPG enthalten einen Editor. Man kann den Text in diesem Editor schreiben, mit einem Klick auf den entsprechenden Button signieren oder verschlüsseln und das Ergebnis über die Zwischenablage in die Textbox der Website einfügen. Entschlüsseln funktioniert umgekehrter.

Enthält das bevorzugte Tool für die Schlüsselverwaltung keinen Texteditor, kann man folgende Alternativen nutzen, die auch für unterwegs (auf dem USB-Stick) geeignet sind:

1. Das kleine Tool gpg4usb bietet einen Editor mit den Buttons für das Ver- und Entschlüsseln des Textes, Dateiverschlüsselung sowie eine kleine Schlüsselverwaltung (Signieren und Prüfen der Signatur steht noch auf der ToDo Liste). Das ZIP-Archiv enthält Versionen für Windows und Linux. Es kann einfach auf dem USB-Stick genutzt werden.
2. Die Applikation Portable PGP ist eine Java-Anwendung (plattformunabhängig), die ebenfalls Texte und Dateien ver- und entschlüsseln kann. Eine einfach Schlüsselverwaltung ist ebenfalls enthalten. Zusätzlich zu Portable PGP benötigt man eine Java Laufzeitumgebung. Eine portable Version der Sun-JRE gibt es bei portableapps.com.

GnuPG SmartCard nutzen

Die Sicherheit asymmetrischer Verschlüsselung hängt in hohem Maße von der sicheren Aufbewahrung des privaten Keys ab. Nutzt man GnuPG auf mehreren Rechnen, insbesondere wenn andere Nutzer Administrator- bzw. Root-Privilegien auf diesen Rechnern haben, könnte der private Key in falsche Hände gelangen.

Böswillige Buben könnten mit einem Trojaner versuchen, den privaten Key zu kopieren und das Passwort mit Tools wie Elcomsoft Distributed Password Recovery ermitteln. Die unbedachte Entsorgung einer Festplatte oder eines Computers ist ein weiteres Risiko, wenn der private Key nicht zuverlässig gelöscht wurde.

SmartCards: ermöglichen eine sichere Nutzung von GnuPG unter diesen Bedingungen. Der private Key ist ausschließlich auf der SmartCard gespeichert, er verläßt diese sichere Umgebung nicht. Sämtliche kryptografischen Operationen werden auf der Card ausgeführt. CardReader (USB) und GnuPG-SmartCards gibt es bei kernelconcepts.de .

CryptoStick: Da das Handling mit CardReader und SmartCard unter Umständen etwas umständlich sein kann, wurde ein USB-Stick entwickelt, der CardReader plus eine SmartCard in einem kleinen Gehäuse enthält und voll kompatibel mit der Version 2.0 der OpenPGP SmartCard ist. Weitere Informationen gibt es auf der Webseite des Projektes .

[htb]

[[Image:../screenshots/cryptostick2.jpeg|image]] [abb:cryptostick]

Hardware-Treiber installieren

Vor der Nutzung der SmartCard ist der Hardware-Treiber für den CardReader zu installieren.

• WINDOWS: Die Lieferung des CardReaders von kernelconcepts.de enthält eine CD mit den nötigen Treiber für WINDOWS. Das zum Gerät passende ZIP-Archiv ist zu entpacken und setup.exe als Administrator zu starten.
  

  Für den CryptoStick gibt es den PC Twin USB PC/SC Treiber .

• Linux: Da Linux out-of-the-box viel mehr Hardware unterstützt als Windows, sind die nötigen Treiber in den Repositories enthalten. Unter Debian/Ubuntu installiert man alles Nötige für die Nutzung der SmartCard mit folgendem Kommando:

    # aptitude install pcscd libpcsclite1 libccid

  Die Pakete openct und opensc sollten entfernt werden, da diese zu Beeinträchtigungen führen können.

  # aptitude purge openct opensc

Außerdem benötigen die aktuelle OpenPGP-SmartCard und der Crypto-Stick GnuPG mindestens in der Version 1.4.9+ oder die 2.0.12+. Unter WINDOWS funktioniert erst die Version 1.4.10. Aktualisieren sie ihre GnuPG Version, wenn nötig.

Wer “gpg2” nutzen möchte, sollte beachten, dass der “gpg-agent” unbedingt nötig ist. In der Datei $HOME/.gnupg/gpg.conf ist am Ende einfach ein use-agent einzufügen. Dann meldet man sich vom Desktop ab und wieder an.

Nachdem die Software installiert wurde, sollte man prüfen, ob alles funktioniert. SmartCard anschließen und auf der Konsole bzw. DOS-Box eingeben:

  > gpg --card-status
  Application ID ...: D27600xxxxxxxxxxxxxxx
  Version ..........: 2.0
  Manufacturer .....: unknown
  .... 

SmartCards und CryptoStick mit Enigmail nutzen

Enigmail ist seit der Version 1.0.1 voll kompatibel mit der SmartCard und dem CryptoSick. Das Add-on bietet eine grafische Oberfläche, um die SmartCard zu verwalten. Diese Funktionen öffnet man über den Menüpunkt OpenPGP - Smartcard verwalten.

[htb]

[[Image:../screenshots/smartcard1.png|image]] [abb:smartcard1]

1. Als Erstes kann man die Card personalisieren und den Namen usw. editieren, eine URL für den Public Key angeben... (Edit Card Data).

2. Im zweiten Schritt sollte der PIN und der Admin-PIN geändert werden. Der PIN ist eine 6-stellige Zahlenkombination (Default: 123456), welche den User-Zugriff auf die Card sichert. Der Admin-PIN ist eine 8-stellige Zahlenkombination (Default: 12345678) für die Verwaltungsoperationen.
   

   Wurde der PIN 3x falsch eingegeben, wird die Card gesperrt und kann mit dem Admin-PIN wieder entsperrt werden (Unblock PIN). Wird der Admin-PIN 3x falsch eingegeben, ist die SmartCard zerstört!.
   

   Die Festlegung auf 6- bzw. 8-stellige Zahlenkombinationen legt es nahe, ein Datum aus dem persönlichen Leben als PINs zu nutzen. Das reduziert die Vergesslichkeit. Es sollte jedoch kein einfach zu erratenes Datum wie der Geburtstag des Töchterchens sein.

   [htb]

   [[Image:../screenshots/smartcard3.png|image]] [abb:smartcard3]

3. Als letzten Schritt vor der Nutzung der SmartCard im täglichen Krypto-Chaos sind die Keys auf der SmartCard zu generieren. Der entsprechende Dialog bietet die Auswahl eines Mail-Account an, für den die SmartCard genutzt werden soll. Für diesen Account darf kein(!) OpenPGP-Key vorhanden sein. Anderenfalls bricht der Vorgang mit einer wenig verständlichen Fehlermeldung ab.
   

   Es sollte unbedingt bei der Erzeugung des Schlüssels ein Backup der Card-Keys angelegt und mit einem Passwort gesichert werden. Später ist kein Zugriff auf diese Schlüssel mehr möglich. Bei Beschädigung der SmartCard kann der gesicherte Card-Key in eine neue SmartCard importiert werden. Das Backup wird im GnuPG-Verzeichnis abgelegt und ist auf einem sicheren Datenträger zu speichern!
   

   Wurden die Schlüssel erfolgreich generiert, findet man in der Schlüsselverwaltung ein neues Paar. Der Public Key dieses Schlüsselpaares kann wie üblich exportiert und den Partnern zur Verfügung gestellt werden. Der Private Key dieses Paares definiert lediglich, dass die kryptografischen Operationen auf einer SmartCard auszuführen sind. Er ist ohne die passende Card unbrauchbar.

Funktionen für Genießer

Die Nutzung von gpg auf der Kommandozeile bietet etwas mehr Möglichkeiten, als bisher im Enigmail-GUI implementiert sind. Natürlich stehen auch die mit dem GUI durchführbaren Funktionen auf der Kommandozeile zur Verfügung.

Einen Überblick über alle SmartCard-Funktionen gibt die Hilfe. Als erstes muss man den Admin Mode aktivieren, dann hat man vollen Zugriff auf alle Funktionen:

   > gpg --card-edit
   Befehl> admin
   Befehl> help

Neue Schlüssel generiert man auf der SmartCard mit:

   > gpg --card-edit
   Befehl> admin
   Befehl> generate

Hat man mehrmals den PIN falsch eingegeben kann man einen neuen (alten) PIN (rück-)setzen, wenn man den Admin-PIN kennt:

   > gpg --card-edit
   Befehl> admin
   Befehl> passwd

Möglicherweise hat man bereits eine OpenPGP Schlüssel mit vielen Signaturen. Den möchte man nicht wegwerfen und im Web of Trust noch einmal von vorn beginnen. Als Ausweg bietet es sich an, einen vorhandenen, starken Schlüssel mit der SmartCard zusätzlich zu schützen. Der Zugriff auf den geheimen Schlüssel ist dann nur mit der SmartCard möglich. Es ist dem vorhanden Schlüssel mit der ID key-id ein Subkey der SmartCard hinzuzufügen. Das geht nur auf der Kommandozeile:

   > gpg --edit-key key-id
   command> addcardkey

Dabei wird ein evtl. auf der SmartCard vorhandener Key zerstört!

SSL-Verschlüsselung für Keyserver aktivieren

Seit Anfang Oktober 2012 bietet der Keyserverpool sks-keyservers.net einen Sub-Pool mit SSL-Verschlüsselung für das Abrufen und Senden von OpenPGP-Schlüsseln . Die SSL-Verschlüsselung verhindert, dass ein Lauscher beobachtet, welche OpenPGP-Schlüssel man sucht und herunter lädt.

Um diesen sicheren Sub-Pool zu nutzen, sind folgende Schritte nötig:

1. Man benötigt eine Version von GnuPG, die das hkps:// Protokoll unterstützt. Man kann gnupg2 nutzen oder das Paket gnupg-curl installieren. Für Windows bietet gpg4win ein Paket mit gnupg2, unter Linux installiert man eines der genannten Pakete mit dem bevorzugten Paketmanager.

2. Das CA-Root Zertifikat des Keyserverpool sks-keyservers.netCA.pem ist herunter zu laden und auf dem eigenen Rechner zu speichern.

3. In der Konfiguration von Enigmail sind die Experten Optionen zu aktivieren und folgende Werte einzutragen:

   1. Bei der Nutzung von gnupg2 ist der Pfad zu diesem Programm auszuwählen.

   2. Auf dem Reiter Schlüssel-Server ist der HKPS-Pool als einziger Schlüssel-Server einzutragen:

      hkps://hkps.pool.sks-keyservers.net
         

   3. Auf dem Reiter Erweitert sind als Zusätzliche Parameter für GnuPG die nötigen Keyserver-Optionen einzutrage:

      --keyserver-options ca-cert-file=<Path to>/sks-keyservers.netCA.pem
         

Web des Vertrauens

Im Prinzip kann jeder Anwender einen Schlüssel mit beliebigen E-Mail-Adressen generieren. Um Vertrauen zu schaffen, gibt es das Web of Trust.

Hat Beatrice die Echtheit des Schlüssels von Anton überprüft, kann sie diesen mit ihrem geheimen Schlüssel signieren und auf die Schlüsselserver re-exportieren. Conrad, der den Schlüssel von Beatrice bereits überprüft hat, kann damit aufgrund der Signatur auch dem Schlüssel von Anton vertrauen. Es bildet sich ein weltweites Netz von Vertrauensbeziehungen. Die Grafik [abb:weboftrust] zeigt eine mögliche Variante für den Schlüssel von Anton (A).

[htb]

[[Image:../grafiken/web_of_trust.png|image]] [abb:weboftrust]

OpenPGP-Schlüssel signieren

Die Echtheit eines Schlüssels kann anhand des Fingerabdrucks geprüft werden. Zu jedem Schlüssel existiert ein eindeutiger Fingerabdruck. Dieser lässt sich in den Eigenschaften des Schlüssels anzeigen. In der Schlüsselverwaltung ist der zu prüfende Schlüssel auszuwählen und über den Menüpunkt Anzeigen - Eigenschaften den im Bild [abb:enigmail_schl_eigensch] dargestellten Dialog zu öffnen.

Der angezeigte Fingerabdruck des Schlüssels kann mit dem Wert verglichen werden, den man vom Eigentümer des Schlüssels erhalten hat. Sind beide identisch, kann das Vertrauen des öffentlichen Schlüssels auf ein hohes Niveau gesetzt werden. Den Dialog findet man in der Schlüsselverwaltung unter Bearbeiten - Vertrauenswürdigkeit.

[htb]

[[Image:../screenshots/schluessel_eigensch.png|image]] [abb:enigmail_schl_eigensch]

Hat man sich von der Echtheit des Schlüssels überzeugt, kann man ihn in Absprache mit dem Schlüsseleigentümer auch signieren und den signierten Schlüssel auf einen Keyserver exportieren. Wenn viele Nutzer die Ergbnisse ihrer Überprüfung online verfügbar machen, entsteht das Web-of-Trust und es wird schwer, gefälschte Schlüssel in Umlauf zu bringen.

Certification Authorities

Diese Infrastruktur kann auch von vertrauenswürdigen Institutionen (Certification Authorities, CAs) genutzt werden. Die Nutzer wenden sich an die CA und lassen gegen Vorlage von Ausweisdokumenten den eigenen OpenPGP-Key signieren. Alle Partner benötigen lediglich den öffentlichen Schlüssel der CA, um die Echtheit der Schlüssel zu überprüfen.

Beispiele für Certification Authorities sind:

• CAcert.org signiert auch OpenPGP-Schlüssel
• Krypto-Kampagne der Zeitschrift c’t
• PCA des Deutschen Forschungsnetzes (DFN-PCA)

Keysigning-Party

Wenn sich mehrere OpenPGP-Nutzer treffen um sich gegenseitig die Echtheit ihrer Schlüssel zu bestätigen, nennt man es eine Keysigning-Party. Dabei kommt es nicht darauf an, dass die Beteiligten sich persönlich kennen. Die Echtheit des Schlüssels können auch Unbekannte gegen Vorlage von Ausweisdokumenten und Fingerprint des Key bestätigen.

Eine Keysigning-Party läuft üblicherweise folgendermaßen ab:

1. Der Organisator lädt zu einer Party ein und bittet um Anmeldungen.
2. Wer an der Party teilnehmen möchte, sendet seinen öffentlichen OpenPGP-Schlüssel zusammen mit Namen und dem "Fingerabdruck" an den Organisator.
3. In Vorbereitung der Party erstellt der Organisator einen Schlüsselbund ("key ring") für alle Beteiligte und eine Liste mit Namen, Key-IDs und Fingerprints von allen Teilnehmern.
4. Der "key ring" und die Liste werden an alle Teilnehmer verteilt. Die Teilnehmer können auf der Party die Identität gegenseitig durch Vorlage von Ausweisdokumenten prüfen.
5. Wieder zuhause, können die Schlüssel im Party-Schlüsselbund signiert und an die Inhaber per E-Mail versendet werden. In der Regel erfolgt dieser Schritt nicht beim Treffen.

Wer häufiger an Keysigning-Partys teilnimmt, kann unter Linux das Dienstprogramm caff für den letzten Schritt nutzen. Das Prpgramm ist im Paket signing-party für nahezu alle Linux-Ditributionen verfügbar und kann mit dem Paket-Manager der Wahl installiert werden.

Nach der Installation ist die Datei $HOME/.caffrc als Textdatei anzulegen und die Werte für den eigenen Namen, E-Mail Adresse, OpenPGP-ID sowie die Parameter zur Versendung von E-Mails sind zu konfigurieren:

$CONFIG{'owner'} = 'Michi Müller';
$CONFIG{'email'} = 'm@m.de';
$CONFIG{'keyid'} = [ qw{01234567890ABCDE} ];

$CONFIG{'mailer-send'} =  [ 'smtp', Server => 'mail.server', Auth => ['user','pass'] ];

Ein kleines Kommando im Terminal signiert alle Schlüssel des Party-Keyring, verpackt sie in E-Mails, die mit dem Schlüssel der Empfänger verschlüsselt werden, und sendet die E-Mails an die Inhaber der OpenPGP-Schlüssel:

 > caff --key-file party-keyring.asc

Schlüssel zurückrufen

Soll ein Schlüsselpaar nicht mehr verwendet werden (beispielsweise weil der geheime Schlüssel kompromittiert wurde oder die Passphrase in Vergessenheit gefallen ist), kann der öffentliche Schlüssel für ungültig erklärt werden.

Öffnen Sie die Schlüsselverwaltung, wählen Sie den Schlüssel, der für ungültig erklärt werden soll. Rufen Sie den Menüpunkt Bearbeiten / zurückrufen auf. Nach einer Sicherheitsfrage und Eingabe der Passphrase wird der Schlüssel auf den Schlüsselservern im Internet für ungültig erklärt. Auch wenn der geheime Schlüssel nicht mehr vorliegt oder die Passphrase in Vergessenheit geraten ist, kann der öffentliche Schlüssel für ungültig erklärt werden, indem das unter Punkt 4 erstellte Rückrufzertifikat importiert wird.

S/MIME mit Thunderbird

S/MIME nutzt Zertifikate nach dem Standard X.509 für die Verschlüsselung und Signatur von E-Mails. Eine Certification Authority (CA) bestätigt mit einer Signatur die Echtheit und die Identität des Besitzers eines ausgegebenen Zertifikates. Für diese Signatur wird das Root Certificate der CA genutzt. Die Root Certificates etablierter CAs sind in nahezu allen Browsern und E-Mail Clients enthalten. Wer diesen Zertifikaten vertraut, vertraut auch ohne weitere Nachfrage den damit signierten persönlichen Zertifikaten anderer Nutzer.

Kostenfreie Certification Authorities

In der Regel kostet dieser Dienst bei einer etablierten CA 30 bis 100 Euro pro Jahr. CAcert.org bietet eine kostenfreie Alternative für die Ausstellung und Signatur von X.509-Zertifikaten. CAcert.org ist ein Web of Trust von Nutzern, welche sich gegenseitig bei einem persönlichen Treffen die Identität bestätigen. Einfache Nutzer werden durch Zusicherer ("assurer") verifiziert, die ehrenamtlich für CAcert.org arbeiten.

Für jede Bestätigung durch einen Zusicherer erhält der Nutzer bis zu 35 Punkte. Sobald man 50 Punkte angesammelt hat, also nach mindestens zwei unabhängigen Bestätigungen, kann man sich auf der Website ein Class-3-Zertifikat mit dem eigenen Namen generieren. Mit einem Punktestand von 100 Punkten kann man den Status eines Zusicherers beantragen.

Auch ohne Bestätigungen durch Zusicherer kann man ein Zertifikat zu erzeugen. Dieses Class-1-Zertifikat enthält nur die E-Mail-Adresse des Besitzers und keinen verifizierten Namen.

Der Weg zur Erstellung eines S/MIME-Zertifikates:

• Wer häufig CAcert.org nutzt, sollte das Root-Zertifikat dieser CA in den Browser importieren. Man erspart sich damit lästige Nachfragen beim Besuch der Website. Die Root-Zertifikate von CAcert.org ist standardmäßig nicht in den häufig genutzten Browsern enthalten. CAcert.org bietet sie auf der Webseite zum Herunterladen.
• Es ist notwendig, die Root-Zertifikate von CAcert.org in den E-Mail-Client als vertrauenswürdige CA zu importieren. Nur so kann die Gültigkeit des eigenen Zertifikats überprüft werden.
• Die Anmeldung folgt dem üblichen Schema. Nach Eingabe der Kontaktdaten erhält man eine E-Mail zu Verifizierung und kann sich im Anschluss auf der Website ammelden, um die persönlichen Angaben zu vervollständigen.
• Zur Bestätigung der Identität kann man auf der Website einen Zusicherer in der Nähe suchen und um ein persönliches Treffen bitten. Zum Treffen ist ein Ausdruck des WOT-Formulars mitzubringen.
• Hat man 50 Punkte durch Bestätigungen von mehreren Zusicherern erreicht, kann man auf der Webseite ein Zertifikat erstellen. Das Zertifikat und den privaten Schlüssel findet man nach dem Vorgang in der Zertifikatsverwaltung des Browsers unter Eigene Zertifikate! Es gibt keine Möglichkeit zum Herunterladen o.ä.
• Das Zertifikat wird aus der Zertifikatsverwaltung des Browsers als *.P12-Datei exportiert und im E-Mail-Client wieder importiert.

Erzeugen eines Zertifikates

Die verschiedenen Certification Authoroties (CAs) bieten eine Web-Oberfläche, um nach der Überprüfung der Identität ein signiertes Zertifikat zu erstellen. In der Regel stehen zwei Wege zur Auswahl:

1. Der Anbieter (CA) führt den gesamten Vorgang aus: die Generierung des privaten Schlüssels inklusive Sicherung mit einem Kennwort ("passphrase"), die Generierung des Certification Request (CSR), die Signierung des CSR und die Erstellung der Zertifikatsdatei mit privatem und öffentlichem Schlüssel.
   

   CAcert.org hat eine Lösung entwickelt, den privaten Schlüssel im Browser des Nutzers zu generieren und nur den CSR (public Key) zur Signatur auf den eigenen Server zu laden. Viele CAs generieren aber beide Schlüssel auf dem eigene Server und haben damit Zugriff auf den privaten Schlüssel.

2. Der Anwender generiert den privaten Schlüssel und den CSR selbst, lädt nur den CSR auf den Server des Anbieters, der CSR wird dort signiert und als Zertifikat wieder zum Herunterladen bereitgestellt.

Da die Sicherheit asymmetrischer Verschlüsselung davon abhängt, dass nur der Anwender Zugriff auf den privaten Schlüssel hat, sollte man sich die Mühe machen und den zweiten Weg gehen. Anderenfalls ist es möglich, dass der private Schlüssel bereits vor der ersten Verwendung kompromittiert wird. Man sollte den Certification Authorithies nicht blind vertrauen.

Die OpenSSL-Bibliothek bietet alles Notwendige. Die Dienstprogramme sind unter Linux installiert. Ein grafisches Interface ist TinyCA (http://tinyca.sm-zone.net).

Schrittweise Anleitung für die Kommandozeile

1. Generieren eines passwortgeschützten privaten Schlüssels in der Datei mein.key:

   > openssl genrsa -out mein.key -des3 2048

2. Generieren eines Certification Request (CSR) in der Datei mein.csr, die folgenden Daten werden dabei abgefragt:

   > openssl req -new -key mein.key -out mein.csr
   Enter pass phrase for mein.key:
   ....
   Country Name (2 letter code) [AU]: DE
   State or Province Name (full name) []: Berlin
   Locality Name (eg, city) []: Berlin
   Organization Name (eg, company) []: privat
   Organizational Unit Name (eg, section) []:
   Common Name (eg, YOUR name) []: Max Musterman
   Email Address []: max@musterman.de

3. en CSR übergibt man der CA. Die Datei enthält nur den öffentlichen Schlüssel. Die CA signiert diesen CSR, und man erhält ein signiertes Zertifikat als Datei mein.crt via E-Mail oder als URL zum Herunterladen.

4. Diese Datei kann man an alle Kommunikationspartner verteilen.

5. Für den Import im eigenen E-Mail-Client fügt man privaten Schlüssel und signiertes Zertifikat zu einer PKCS12-Datei mein.p12 zusammen.

   > openssl pkcs12 -export -in mein.crt -inkey mein.key -out mein.p12

   Diese passwortgeschützte Datei kann in allen E-Mail-Clients importiert werden und sollte sicher verwahrt werden.

S/MIME-Krypto-Funktionen aktivieren

Liegt eine Datei mit signiertem Zertifikat und geheimem Schlüssel vor, können die S/MIME-Funktionen für ein E-Mail Konto aktiviert werden. Es ist der Dialog mit den Konto-Einstellungen zu öffnen und in die Sektion S/MIME-Sicherheit zu wechseln (Bild [abb:thunder_smime_konto]).

[htb]

[[Image:../screenshots/thunderbird_smime_konto.png|image]] [abb:thunder_smime_konto]

Zuerst ist das persönliche Zertifikat zu importieren. Ein Klick auf den Button Zertifikate öffnet den Manager für eigene Zertifikate (Bild [abb:thunder_smime_zert]). Hier ist der Button Importieren zu wählen und das gespeicherte persönliche Zertifikat mit öffentlichem und geheimem Schlüssel zu importieren.

[htb]

[[Image:../screenshots/thunderbird_einst_zert_3.png|image]] [abb:thunder_smime_zert]

Es folgt eine Abfrage des Passwortes, mit dem der Zugriff auf den geheimen Schlüssel geschützt werden soll und evtl. die Frage nach dem Passwort, mit welchem die Datei verschlüsselt wurde. Der Zertifikatsmanager ist im Anschluss mit einem Klick auf den Button Ok zu schließen und in den Konto-Einstellungen das frisch importierte Zertifikat für das Signieren und Entschlüsseln auszuwählen.

Sollen alle ausgehenden Nachrichten standardmäßig signiert werden, kann die entsprechende Option aktiviert werden.

Thunderbird bietet die Möglichkeit, das Online Certifate Status Protocol (OCSP) für die Validierung von Zertifikaten zu nutzen. Standardmäßig ist die Nutzung dieser Funktion sinnvoll deaktiviert. Da nur validierte Zertifikate für die Verschlüsselung und Signaturprüfung genutzt werden können, muss man das Root Zertifikat der ausstellenden CA von der Website herunterladen und importieren. Dies kann vereinfacht werden, wenn man im Dialog Einstellungen in der Sektion Datenschutz auf dem Reiter Sicherheit den Button OCSP... wählt und die Option OCSP verwenden aktiviert. Damit hat man jedoch keine Möglichkeit zu entscheiden, ob man der CA wirklich vertraut.

Zertifikate der Partner und der CA importieren

Im Gegensatz zu OpenPGP, das im Internet eine ausgereifte Infrastruktur zur Verteilung öffentlicher Schlüssel bereitstellt, muss der Inhaber eines S/MIME-Zertifikates selbst die Verteilung übernehmen. Am einfachsten ist es, dem Partner eine signierte E-Mail zu senden. Alle E-Mail-Clients mit S/MIME-Unterstützung können aus der Signatur das Zertifikat importieren und tun dies in der Regel ohne Nachfrage.

Bevor der Empfänger einer signierten E-Mail die Signatur prüfen und verschlüsselt antworten kann, muss er das Zertifikat verifizieren. Viele Root-Zertifikate sind bereits in gängigen E-Mail Clients enthalten. Einige muss der Nutzer jedoch erst selbst importieren. Diese Root-Zertifikate stehen auf den Websites der Ausstellers zum Herunterladen bereit. Wurde die Gültigkeit verifiziert, kann der Empfänger im Anschluß verschlüsselt antworten.

Es ist auch möglich, eine Datei nur mit dem öffentlichen Schlüssel des Zertifikates auf den Rechner des Partners zu transferieren. Dort ist die Datei in Thunderbird zu importieren.

Für den Import eines Zertifikates in Thunderbird ist der Dialog Einstellungen zu öffnen. In der Sektion Datenschutz auf dem Reiter Sicherheit ist der Button Zertifikate zu wählen (Bild [abb:thunder_smime_zert2]), um die Verwaltung zu öffnen.

[htb]

[[Image:../screenshots/thunderbird_einst_zert.png|image]] [abb:thunder_smime_zert2]

Im Zertifikatsmanager ist auf dem Reiter Zertifikate anderer Personen der Button Importieren zu finden, welcher eine Dateiauswahl öffnet, um das erhaltene Zertifikat aus einer lokal gespeicherten Datei zu importieren.

Die Root-Zertifikate weiterer Certification Authorities (CAs) können auf dem Reiter Zertifizierungsstellen importiert werden.

Nachrichten verschlüsseln und signieren

Wenn das persönliche Zertifikat bestehend aus öffentlichem und geheimem Schlüssel importiert wurde, ist es möglich, signierte E-Mails zu versenden. Wurden Zertifikate mit den öffentlichen Schlüsseln der Kommunikationspartner importiert, kann die Nachricht auch verschlüsselt werden.

[htb]

[[Image:../screenshots/thunderbird_smime_email.png|image]] [abb:thunder_smime]

Für die Wahl der Optionen steht im Editor einer neuen Nachricht der Button S/MIME zur Verfügung. Klickt man auf den kleinen schwarzen Pfeil unmittelbar neben dem Button S/MIME, öffnet sich das im Bild [abb:thunder_smime] dargestellte Menü zum Festlegen der Kryptographie-Optionen für die aktuelle Nachricht.

Eine Möglichkeit, für bestimmte Empfänger die Einstellungen für Verschlüsselung dauerhaft festzulegen, bietet Thunderbird in der Standard-Konfiguration nicht. Man muß bei jeder neu verfassten E-Mail daran denken, sie wenn möglich zu verschlüsseln! Das ist sehr fehleranfällig.

Eine Lösung bietet das Plug-In Virtual Identity. Es kann bei jeder versendeten E-Mail die gewählten Einstellungen für die Verschlüsselung speichern. Damit lernt Thunderbird, welche Verschlüsselungseinstellungen für welche Empfänger gelten. Die Einstellungen werden bei jeder neuen E-Mail an den Empfänger als Default aktiviert.

Nach der Installation des Plug-Ins muss man unter dem Menüpunkt “Extras - Virtual Identity - Einstellungen” die Speicherung der Einstellungen für die Verschlüsselung aktivieren. (Bild [abb:vertual_id1])

[htb]

[[Image:../screenshots/virtual-id1.png|image]] [abb:vertual_id1]

Unter dem Menüpunkt “Extras - Virtual Identity - Datenspeicher” findet man die gesammelten Daten und kann sie auch editieren.

Ist S/MIME-Verschlüsselung unsicher?

Nach unserer Einschätzung ist die S/MIME-Verschlüsselung wesentlich schwächer als OpenPGP. Die Ursachen liegen nicht in einer Schwäche der verwendeten Algorithmen, sondern in der Generierung und Speicherung der privaten Schlüssel außerhalb der Hoheit des Anwenders.

Die Sicherheit asymmetrischer Kryptografie hängt entscheidend von der Vertrauenswürdikeit der privaten Schlüssel ab. Während der öffentliche Schlüssel möglichst breit zu verteilen ist, muss die Verfügungsgewalt für den privaten Schlüssel ausschließlich und vollständig(!) in der Hand des Anwenders liegen. Nur so kann gewährleistet werden, dass kein unbefugter Dritter die vertrauliche Kommunikation entschlüsseln kann.

Um die Nutzung der S/MIME-Verschlüsselung für unbedarfte Anwender zu erleichtern, wird die Erzeugung und Aufbewahrung der privaten Schlüssel häufig durch organisatorische Schwächen kompromittiert.

Erzeugen der privaten Schlüssel

Alle Anbieter von Zertifizierungen für X.509 Zertifikate bieten eine webbasierte Bedienoberfläche für die Erzeugung und Signatur der Zertifikate. In der Regel werden nach erfolgricher Überprüfung der Identität des Antragstellers zwei Varianten für die Generierung eines gültigen Zertifikates angeboten:

1. Man kann nach in einer selbst gewählten sicheren Umgebung den privaten Schlüssel und ein Certification Request (CSR) erzeugen. Der CSR enthält nur den öffentlich Schlüssel. Dieser wird im Webinterface hochgeladen, und man erhält via E-Mail oder Link zum Herunterladen das signierte Zertifikat.
2. Man die gesamte Generierung des privaten und öffentlichen Schlüssels der CA überlassen und muss darauf vertrauen, dass dieser keine Kopie des privaten Schlüssels speichert.

Aus Bequemlichkeit nutzt die Mehrheit der Anwender den zweiten Weg und geht damit das Risiko ein, dass die Schlüssel bereits vor der Verwendung kompromittiert werden könnte.

In einem Forschungspapier kommen die Sicherheitsforscher C. Soghoian und S. Stamm zu dem Schluss, das die US-Regierung von kooperierenden Certification Authorities die privaten Schlüssel von X509-Zertifikaten erhalten könnte und die US-Behörden somit die Daten problemlos entschlüsseln können. Eine ähnliche Zusammenarbeit gibt es unserer Meinung nach auch zwischen Startcom-SSL und dem isrealischen Geheimdienst.

Der Deutsche Bundestag

Der Deutsche Bundestag bietet allen Abgeordneten die Möglichkeit, S/MIME für die Verschlüsselung von E-Mails zu verwenden.

Die Abgeordneten sind anscheinend nicht über diese Möglichkeit informiert. Bei der technischen Umsetzung gilt das Prinzip Security by obscurity, wie ein Testbericht zeigt (http://www.heise.de//tp/r4/artikel/27/27182/1.html).

Um die Abgeordneten maximal von der “komplizierten” Technik des Entschlüsseln der E-Mail zu entlasten, erfolgt die Entschlüsselung auf einem zentralen Server des Bundestages. Auf diesem zentralen Server liegen auch die privaten Schlüssel und die Zertifikate der Abgeordneten.

Damit ist gesichert, dass auch die Sekretäre keine Probleme haben, wenn der Absender einer E-Mail diese verschlüsselt und damit sicherstellen wollte, dass nur der Abgordnete selbst sie lesen kann.

Hier wird eine Vertraulichkeit der Kommunikation vorgegaukelt. Gefährlich wird dieser Placebo, wenn ein Bürger auf die Sicherheit vertraut und sich gegenüber seinem Abgeordneten freimütiger äußert, als er es unverschlüsselt täte.

Web.de (Free-) Mail-Konto

Beim Anlegen eines Mail-Kontos bei Web.de wird automatisch ein S/MIME-Zertifikat für den Nutzer generiert. Der öffentliche und der private Schlüssel liegen auf dem Server des Anbieters. Der Schlüssel ist nicht durch ein Passwort geschützt.

Dieses Feature wird von Web.de wie folgt beworben:

“Versehen Sie Ihre E-Mail mit einer digitalen Unterschrift, kann diese auf dem Weg zum Empfänger nicht verändert werden. Die digitale Verschlüsselung sorgt dafür, dass die E-Mail auf dem Weg zum Empfänger nicht gelesen werden kann.”

Außerdem fordert die Website dazu auf, das Zertifikat im eigenen E-Mail Client zu importieren und für die Verschlüsselung zu nutzen.

Diese Variante von S/MIME ist ein Placebo, den man ignorieren sollte.

Die Werbebotschaft entspricht nicht der Wahrheit. Gemäß geltendem Recht ist die E-Mail beim Empfänger angekommen, wenn der Empfänger Gelegenheit hatte, sie zur Kenntnis zu nehmen. Vorher kann sie jedoch auf dem Server von Web.de entschlüsselt werden (auch von staatlichen Stellen).

Projekt De-Mail

Auch das geplante Portale De-Mail für die rechtsverbindliche und sichere deutsche Alternative zur E-Mail soll X.509 Zertifikate für die Gewährleistung der vertraulichen Kommunikation nutzen. Die Anforderungen sehen eine Entschlüsselung der vertraulichen E-Mails durch Betreiber des Dienstes ausdrücklich vor. Als Grund wird die Notwendigkeit des Virescans genannt.

Außerdem wirbt das Projekt damit, den Nutzern einen “Datentresor” für vertrauliche digitale Dokumente zur Verfügung zu stellen. Das Konzept kann jedoch nur als Placebo bezeichnet werden. Sowohl die verschlüsselten Dokumente als auch die Schlüssel für den Zugriff auf die Dokumente sollen beim Anbieter des Dienstes liegen. Die Entschlüsselung der vertraulichen Daten durch Mitarbeiter ist ebenfalls ausdrücklich vorgesehen.

Das Projekt De-Mail wird in Zusammenarbeit mit dem ePA einen Key-Escrow (Hinterlegung der Schlüssel bei den Behörden) für unbedarfte Anwender vorrantreiben. Den Anwendern wird eine Sicherheit vorgegaukelt, die durch Behörden einfach kompromittiert werden kann.

Schlußfolgerung

Im Gegensatz zu OpenPGP kann man bei S/MIME nicht sicher davon ausgehen, dass der Gegenüber seinen privaten Schlüssel selbst generiert hat und dass der Schlüssel ausschließlich ihm zur Verfügung steht. Es besteht damit die Gefahr, dass die Vertraulichkeit der Kommunikation nicht umfassend gewährleistet ist.

In extremen Fällen ist die angebotene Verschlüsselung nur ein Placebo.

Staatliche Projekte wie der ePA zusammen mit dem Projekt De-Mail weichen die Sicherheit der S/MIME Verschlüsselung weiter auf.

Eine Bemerkung zum Abschluß

“Mache ich mich verdächtig, wenn ich meine E-Mails verschlüssel?”

Eine Frage, die häufig gestellt wird, wenn es um verschlüsselte E-Mails geht. Bisher gab es darauf folgende Antwort:

“Man sieht es einer E-Mail nicht an, ob sie verschlüsselt ist oder nicht. Wer befürchtet, dass jemand die Mail beschnüffelt und feststellen könnte, dass sie verschlüsselt ist, hat einen Grund mehr, kryptografische Verfahren zu nutzen!”

Aktuelle Ereignisse zeigen, dass diese Frage nicht mehr so einfach beantwortet werden kann. Dem promovierten Soziologen Andrej H. wurde vorgeworfen, Mitglied einer terroristischen Vereinigung nach §129a StGB zu sein. Der Haftbefehl gegen ihn wurde unter anderem mit konspirativem Verhalten begründet, da er seine E-Mails verschlüsselte.

Am 21.Mai 2008 wurden in Österreich die Wohnungen von Aktivisten der Tierrechtsszene durchsucht und 10 Personen festgenommen. Der Haftbefehl wurde mit Verdunklungsgefahr begründet, da die Betroffenen z.B. über verschlüsselte E-Mails kommunizierten.

Am 18.10.07 hat der Bundesgerichtshof (BGH) in seinem Urteil Az.: StB 34/07 den Haftbefehl gegen Andrej H. aufgehoben und eindeutig festgestellt, dass die Verschlüsselung von E-Mails als Tatverdacht NICHT ausreichend ist, entscheidend sei der Inhalt:

“Ohne eine Entschlüsselung der in den Nachrichten verwendeten Tarnbegriffe und ohne Kenntnis dessen, was bei den - teilweise observierten und auch abgehörten - Treffen zwischen dem Beschuldigten und L. besprochen wurde, wird hierdurch eine mitgliedschaftliche Einbindung des Beschuldigten in die ’militante gruppe’ jedoch nicht hinreichend belegt.”

Außerdem geben die Richter des 3. Strafsenat des BGH zu bedenken, dass Andrej H. “ersichtlich um seine Überwachung durch die Ermittlungsbehörden wusste”. Schon allein deshalb konnte er “ganz allgemein Anlass sehen”, seine Aktivitäten zu verheimlichen. Woher Andrej H. von der Überwachung wusste, steht bei http://annalist.noblogs.org.

Trotz dieses Urteils des BGH bleibt für uns ein bitterer Nachgeschmack über die Arbeit unser Ermittler und einiger Richter. Zumindest die Ermittlungsrichter sind der Argumentation der Staatsanwaltschaft gefolgt und haben dem Haftbefehl erst einmal zugestimmt.