Zu den Themen, mit denen man sich als Rechtsanwalt oder als jemand, der gerade im Begriff ist, einer zu werden, auseinander setzen sollte, gehört Verschlüsselung. Ausgerechnet unter Mac OS X hatte ich jedoch einige Hürden zu überwinden. Welche das waren und wie ich sie umschiffen konnte, beschreibt dieser Artikel.

So wie man Mandatengespräche nicht unbedingt in einem überfüllten Zug führt und seine Schriftsatzentwürfe auch nicht unbedingt per Postkarte an seine Mandanten sendet, sollte man auch entsprechende Vorkehrungen treffen, um die Vertraulichkeit des Verhältnisses zwischen Mandant und Anwalt auch im Internet zu wahren.

Folgerichtig postulieren berufsständische Vereinigungen der Rechtsanwalt schon länger, dass Rechtsanwälte ihren Mandanten verschlüsselte Kommunikation ermöglichen sollen (vgl. Eichler in DAV/FORUM junge Anwaltschaft[Hrsg.]: DAV-Ratgeber für junge Rechtsanwältinnen und Rechtsanwälte, 12. Auflage, Berlin 2008, S. 394f. m.w.N.).

Leider hat sich diese eigentlich ziemlich triviale Erkenntnis bis heute nicht durchsetzen können. Namentlich E-Mail-Verschlüsselung ist noch immer eher die Ausnahme, als die Regel. Dabei ist eigentlich alle Software, die man für eine gute E-Mail-Verschlüsselung benötigt, kostenlos im Netz verfügbar.

Wie aber kann ich die Verschlüsselung nun einsetzen? Freilich führen, wie so oft in der IT-Welt, mehr als nur ein Weg zum Ziel. Welcher Weg der kürzeste ist, hängt aber ab von verschiedenen Rahmenbedingungen ab, wie dem verwendeten Betriebssystem und der verwendeten E-Mail-Software. In meinem Fall verwende ich ein zum Zeitpunkt der Erstellung dieses Blog-Eintrags aktuelles Mac OS X „Snow Leopard“ als Betriebssystem und Mozilla Thunderbird als Mailclient.

Die Theorie ist ganz einfach: Man muss das Add-on „Enigmail“ installieren, man muss GnuPG installieren, dann kann man auch schon loslegen. Gesagt, getan.

Als alter UNIXer habe ich über GnuPG zunächst über die MacPorts installiert, während ich die für Mac OS X vorgesehene Thunderbird-Ausgabe von Mozilla bezog. Über den Add-on-Installationsmechanismus installierte ich dann Enigmail. Dann noch mit Enigmail ein Schlüsselpaar erzeugt, und schon schien der verschlüsselten Kommunikation nichts mehr im Wege zu stehen.

Leider jedoch mögen sich Enigmail und das MacPorts-GnuPG nicht. Ich konnte beide nicht zur Zusammenarbeit bewegen, Enigmail meldete, sobald es Zugriff auf den geheimen Schlüssel benötige, was beispielsweise beim Signieren einer E-Mail oder beim Erzeugen eines Widerrufzertifikats der Fall ist, stets einen Fehler in der Interprozesskomunikation.

Ich habe daher das MacPorts-GnuPG wieder deinstalliert und sodann das GnuPG von MacGPG installiert. Sodann einmal ab- und wieder angemeldet, um sicherzustellen, dass der für die Verwaltung der geheimen Schlüssel zuständige GPG-Agent läuft, und schon schien mir alles endlich einsatzbereit zu sein. Tatsächlich: Versucht Enigmail nun, auf den geheimen Schlüssel zuzugreifen, meldet sich der GPG-Agent zu Wort und fragt mich nach meiner Passphrase. Sehr schön, das soll er auch. Aber: Er behauptet, dass meine Passhphrase ungültig sei, ich also eine Falsche eingegeben habe. Na, gut, kann ja mal passieren. Versuchen wir es halt noch einmal. Doch siehe da: Das Ergebnis bleibt dasselbe. Nach einigen erfolglosen Versuchen komme ich zu dem Schluss, dass ich meine Passphrase wohl vergessen zu haben scheine, aber was soll’s, ich hatte den Schlüssel eh noch mit niemandem ausgetauscht, also lösche ich ihn einfach und generiere ein neues Paar. Doch auch diesmal: Der GPG-Agent bleibt stur.

Ich weiß nicht, was das Problem ist, es hängt aber vermutlich damit zusammen, dass beim Generieren des Schlüsselpaars die Passphrase von Enigmail abgefragt wird, und Enigmail wahrscheinlich irgendeine andere Art der Kodierung verwendet, als der GPG-Agent. Denn eine problemlose Verwendung von mit Enigmail erzeugten Schlüsselpaaren scheint nur mit solchen Passphrasen möglich zu sein, die absolut trivial sind, also einfache Wörter oder ähnliches. Leider ist dies aber aus Sicherheitssicht völlig inakzeptabel.

Mein Ziel erreichte ich dann schließlich auf diese Weise: Bei der MacGPG-Installation wird auch das Kommandozeilenprogramm „gpg“ installiert. Um dieses zu nutzen, öffnet man das Dienstprogramm „Terminal“. Mit Mac OS X wird standardmäßig auch die Bourne-again shell (Bash) des GNU-Projekts installiert, ein ebenso unscheinbares wie mächtiges Werkzeug. Nachdem das Terminal gestartet wurde, bittet die Bash um Anweisungen, was sie tun soll. In unserem Falle soll sie uns von gpg ein Schlüsselpaar generieren lassen. Dazu tippt man ein:

gpg –gen-key

Am Ende eines jeden Befehls tippt man Enter, um der Bash mitzuteilen, dass man den Befehl fertig eingetippt hat und sie ihn jetzt doch bitte ausführen möge.

gpg fragt nun verschiedene Einstellungen für das zu erzeugende Schlüsselpaar ab. Mit der ersten Frage will es wissen, welche Algorithmen man verwenden möchte, mit der zweiten fragt es nach der Schlüssellänge. Im Zweifel bestätigt man einfach durch „Enter“ die Voreinstellungen, in der Hoffnung, dass die gpg-Entwickler schon gewusst haben werden, was sie tun. Danach will gpg wissen, ob der Schlüssel nach einem bestimmten Zeitraum verfallen soll, und ggf., nach welchem. Ich entscheide mich für einen Zeitraum von fünf Jahren und tippe daher

5y

Anschließend fragt gpg, ob das richtig sei, was man mit

j

bestätigt. Jetzt noch ein paar Fragen zur Identität beantworten, dann meldet sich der GPG-Agent zu Wort und fragt nach der Passphrase, vorsichtshalber gleich zweimal. Schließlich generiert gpg den Schlüssel und fordert den Benutzer auf, dabei irgendwelche Dinge zu tun, um die Qualität der Zufallszahlen zu verbessern.

Mit dem auf diese Weise generierten Schlüsselpaar steht der verschlüsselten Kommunikation nunmehr endlich nichts mehr im Wege. Viel Spaß dabei!