© olegdudko, 123RF

Nicht nur aus Datenschutzgründen ergibt es Sinn, im Unternehmen einen eigenen Keyserver zu betreiben. Er versammelt und prüft die öffentlichen Schlüssel sämtlicher Kunden und Mitarbeiter und beendet so die nervige und zeitintensive Suche nach den passenden Keys.

Jeder weiß, dass unverschlüsselte E-Mails vom Sicherheitsniveau noch unterhalb einer Postkarte liegen. Trotzdem installiert kaum ein Unternehmen PGP. Als erste Begründung ist zu hören, das Verfahren sei zu kompliziert, als zweite, die Nutzung gestalte sich zu unhandlich. Sind beide Hemmschwellen ausgeräumt, heißt es: “Aber was ist, wenn der Mitarbeiter geht? Dann ist der Private Key futsch.” Spätestens hier kippt das Projekt PGP-Einführung. Doch das lässt sich lösen, wie der Artikel zeigt.

Die Erfinder von E-Mail waren froh, dass sie es schafften, eine Nachricht erfolgreich zu verschicken. Die Grundpfeiler der IT-Sicherheit – Vertraulichkeit, Integrität und Authentizität – blieben dabei erst einmal Nebensache. Doch der Prototyp büxte aus den Laboren aus; der Rest ist eine Erfolgsgeschichte.

Seit den 1970er Jahren gilt aber auch: E-Mail ist unsicher. Eine Verschlüsselung wäre angezeigt, doch praktisch niemand nutzt sie. Zu umständlich, zu schwierig, zu komplex, dem Laien nicht zu vermitteln, so lauten die beliebtesten Gegenargumente. Überhaupt: “Was passiert, wenn der Empfänger das nicht hat?”

Keines der Argumente hält genauem Hinsehen stand: Komplex sind zwar die Mathematik dahinter und auch die Kunst der hybriden Verschlüsselung. Allerdings muss der normale Anwender beide nicht durchschauen, um seine E-Mails zu verschlüsseln – wer weiß schon im Detail, wie der Motor seines Autos arbeitet?

Der Empfänger hat kein PGP? Na dann bekommt er halt eine unverschlüsselte E-Mail. Wichtiger wäre, dass unternehmensweit alle Mitarbeiter auf alle bekannten öffentlichen Schlüssel zugreifen dürfen, damit nicht aus Versehen E-Mails unverschlüsselt auf die Reise gehen.

Wie sich das lösen lässt, beschreibt der erste Teil dieses Artikels. Der zweite kümmert sich um ein valides Argument, das der Autor in der Praxis aber nur einmal zu hören bekam: Was passiert, wenn der Mitarbeiter geht? Hat das Unternehmen dann noch Zugriff auf seine E-Mails?

Wofür der Aufwand?

Doch warum überhaupt verschlüsseln, seit den 70ern geht es doch auch so? Laut DSGVO müssen Unternehmen mit personenbezogenen Daten sorgsam umgehen. Taucht dort Verschlüsselung nur als Empfehlung auf, gilt das Verschlüsseln in anderen Bereichen als Pflicht, etwa bei Finanz- und Passbehörden.

Manche Unternehmen und Behörden reden sich bei E-Mail dann auf SSL/TLS zwischen den E-Mail-Servern raus, so etwa “E-Mail made in Germany” [1]. Wer diesen Unsinn Datenschützern und Admins erzählt, darf froh sein, wenn die einzige Reaktion ein Facepalm ist. Die E-Mail lagert auf allen Zwischenstationen unverschlüsselt – also kein ausreichender Sicherheitsgewinn.

DSGVO-geschulte Seitenbetreiber legen dann los mit: “Wir holen uns eine Einwilligung.” Doch auch die ist untauglich, denn sie setzt Freiwilligkeit voraus. Die dürfte kaum gegeben sein, wenn unverschlüsselte E-Mails die einzige Kontaktoption darstellen. Auf Fax und Brief muss sich der Anwender nicht verweisen lassen, das Landesamt für Datenschutzaufsicht Bayern fordert insoweit eine mediengleiche, sichere Alternative. Da bleibt eigentlich nur die Verschlüsselung.

Noch stärker betroffen, wenn auch häufig ignorant, sind Berufsgeheimnisträger wie Rechtsanwälte, Ärzte oder Steuerberater. Dennoch kommunizieren sie oft per E-Mail, gern über US-Server in der Office-365-Cloud. Auch hier gilt: Der Mandant muss verschlüsseln dürfen, es ist seine Wahl. Die in der Branche dann mit Vorliebe vorgeschlagene Datev-Lösung, ein rudimentärer Webmailer, über den der Mandant seine E-Mails abrufen soll, ist technisch untauglich (siehe Kasten “Datev – das Grauen kehrt zurück”).

Nicht zuletzt gibt es in manchen Industriezweigen einen hohen Geheimhaltungsbedarf, weit über den Datenschutz hinaus. Kaum ein Betrieb, der Forschung und Entwicklung betreibt, möchte seine Wettbewerber früher als nötig über seine Pläne informieren.

PGP oder S/MIME

Für die Kommunikation nach außen ist Verschlüsselung unabdingbar. Jetzt streiten Experten, ob PGP oder S/MIME besser sei. Aus Sicht des Autors spricht für PGP, dass sich jeder Nutzer jederzeit einen Key generieren kann, mithin auch eine pseudonyme Kommunikation gelingt. S/MIME verlangt nach einem Zertifikat; dabei ist Pseudonymität nicht vorgesehen, obgleich manchmal möglich. Efail [2] wurde in PGP ebenfalls behoben, für S/MIME gilt das nicht. PGP kann unter anderem E-Mails verschlüsseln, aber auch mehr. S/MIME ist konzeptionell für E-Mails gemacht. Daher erscheint PGP als flexibler und sinnvoller.

Keys im Griff

In jedem Fall brauchen alle Nutzer im Unternehmen Zugriff auf die Schlüssel aller Kommunikationspartner. Dazu dient ein Keyserver. Für PGP gibt es jede Menge öffentlicher Server, etwa die SKS-Keyserver oder auch Keys.openpgp.org.

Die lassen sich jedoch von Unternehmen kaum rechtskonform nutzen: Die DSGVO verlangt von Firmen, dass sie mit einem Dritten, der personenbezogene Daten im Auftrag verarbeitet, einen Auftragsverarbeitungsvertrag schließen. Stehen dessen Server außerhalb der EU und außerhalb von als sicher anerkannten Drittstaaten (zu denen die USA nicht gehören), müssen aufwändigere Verträge her.

Für öffentliche Keyserver stellt das schon ein unüberwindbares Hindernis dar. Hinzu kommt die Pflicht zur Löschung, Auskunft und Korrektur: Das SKS-Keyserver-Konzept erlaubt es wegen des Web of Trust nicht, Keys zu entfernen.

Qual der Wahl

Die Lösung: Ein interner Keyserver, der keine Daten mit externen Servern austauscht, um das Datenschutzproblem zu umgehen. Das überschaubare Angebot an Lösungen zeigt Openpgp.org [3]. Für Unternehmen eignen sich Hockeypuck [4] und Mailvelope [5].

Das in Go geschriebene Hockeypuck kann seine Keys in einer PostgreSQL- oder MongoDB-Datenbank ablegen, doch die letzte Release stammt von 2015. Mailvelope dagegen ist recht aktuell, im August 2019 kam Version 4 heraus. Es nutzt Node.js und die No-SQL-Datenbank MongoDB. Ersteres stellt einen kleinen Vorteil gegenüber Go dar – Javascript ist verbreiteter. Letzteres erscheint auch nicht als Hindernis: Der Keyserver sollte eh auf eigener, zu diesem Zweck installierter Hardware beziehungsweise einer VM laufen.

01 ln -sf /usr/local/bin/python2.7 /usr/local/bin/python
02 ln -sf /usr/local/bin/python2.7-2to3 /usr/local/bin/2to3
03 ln -sf /usr/local/bin/python2.7-config /usr/local/bin/python-config
04 ln -sf /usr/local/bin/pydoc2.7  /usr/local/bin/pydoc
05 rcctl enable mongod
06 rcctl set mongod flags --config /etc/mongodb.conf
07 rcctl start mongod

Der Autor strebt an, ein kompaktes System mit hoher Sicherheit ab Werk zu verwenden. Die VM sollte mit 1 GByte RAM und 4 GByte Plattenplatz auskommen, sich schnell installieren lassen und wenig Aufwand bereiten. Die Wahl fiel auf das oft übersehene OpenBSD als Basissystem. Dank Node.js lässt sich Mailvelope analog auf allen anderen Systemen installieren. Die Dokumentation ist das größte Manko von Mailvelope, unerfahrene Admis dürften mit der Anleitung verzweifeln.

Paketbote

Zunächst müssen Node.js und MongoDB auf das System. Das erledigt in der Regel der systemeigene Paketmanager, bei OpenBSD lautet der Befehl »pkg_add node mongodb«. Node.js braucht auf OpenBSD etwas Nacharbeit. Einerseits sollte der Installateur die Manpages in der »/etc/man.conf« mit eintragen, was folgende zusätzliche Zeile erledigt:

manpath /usr/local/lib/node_modules/npm/man

Andererseits sollte er die gewünschte Python-Version verlinken (Listing 1, Zeilen 1 bis 4). Soll auch die Datenbank MongoDB beim Systemstart automatisch hochlaufen, erledigt das die Befehlsfolge aus den Zeilen 5 bis 7. Damit Mailvelope in MongoDB seine Keys auch speichern kann, legt Listing 2 alles Nötige an.

01 use keyserver
02 db.createUser({ user:"Mongo-DB-Nutzer", pwd:"Passwort", roles:[{ role:"readWrite", db:"keyserver" }] }

TLS muss sein

Experten streiten gern darüber, ob öffentliche Schlüssel der Natur nach nur verschlüsselt übertragen werden sollten. Zumindest die GPG-Tools auf dem Mac verweigern die Zusammenarbeit mit Keyservern, wenn die kein SSL anbieten. Also heißt es, entweder ein firmenweites Zertifikat zu verwenden oder sich rasch ein selbst signiertes Zertifikat zu erzeugen. Das erledigt OpenSSL (Listing 3).

01 cd /etc/ssl
02 mkdir certs
03 openssl genrsa -out private/Privater_Schlüssel.key 4096
04 openssl req -new -key private/Privater_Schlüssel.key -out certs/Private_Zertifikatsanforderung.csr
05 openssl x509 -req -in certs/Private_Zertifikatsanforderung.csr -signkey private/Privater_Schlüssel.key -out certs/Sicheres_Zertifikat.pem

Die Datei »Sicheres_Zertifikat.pem« sollte als sicher eingestuftes Zertifikat auf dem eigenen Rechner landen. Zugleich sollte der Admin den Hostnamen des Keyservers (etwa »keyserver.Eigene_Domain.org«) im internen DNS oder in der eigenen »/etc/hosts« eintragen.

Postbote

Mailvelope bietet an, hochgeladene Keys zu verifizieren. Dazu erhalten alle für einen Key eingetragenen E-Mail-Adressen automatisch eine Nachricht mit einem Link. Um diese E-Mails zu verschicken, braucht Mailvelope einen lokalen E-Mail-Server. Kompakt, schlank und schnell aufgesetzt ist OpenSMTPD [6]. Wahrscheinlich existiert ein Unternehmens-Mailserver, dorthin sollen die E-Mails zur weiteren Zustellung gehen. Das erledigt die Konfigurationsdatei »/etc/mail/smtpd.conf« aus Listing 4.

01 [...]
02 table aliases file:/etc/mail/aliases
03 # To accept external mail, replace with: listen on all
04 listen on 127.0.0.1 inet4 port 25 hostname keyserver.Eigene_Domain.org
05 action "local" mbox alias <aliases>
06 action "relay" relay host smtp+tls://Unternehmens-Server:25 tls no-verify helo keyserver.Eigene_Domain.org
07 match for local action "local"
08 match for any action "relay"

Wer sich, wie der Autor, gern genau dann vertippt, wenn das unmöglich scheint, prüft einfach über »smtpd -n«, ob die Konfiguration tatsächlich fehlerfrei ist. Bei positivem Ergebnis startet der Admin über »rcctl restart smtpd« im nächsten Schritt den SMTP-Dienst neu.

Verknotet

Jetzt kommt endlich Mailvelope selbst an die Reihe: Zunächst lädt der Administrator sich die aktuelle Entwicklerversion des Keyservers auf die Festplatte (Listing 5, Zeile 1), entpackt sie dort in ein Verzeichnis (Zeile 3) und richtet sie dann ein (Zeile 4). Der Node.js-Paketmanager Npm installiert dabei die nötigen Bibliotheken mit.

01 git clone https://github.com/mailvelope/mailvelope.git
02 [...]
03 unzip keyserver-master.zip
04 npm install keyserver

Die spärliche Doku schlägt vor, mit »npm test« die Installation zu prüfen. Wer das tut, wird mit Fehlermeldungen überhäuft. Besser ist es, zunächst die »config/default.js« anzupassen. Das Ergebnis zeigt Listing 6, Tabelle 1 erläutert die nicht selbsterklärenden Optionen.

Kein HTTPS?

Mailvelope schlägt vor, einen HTTPS- oder HTTP-Proxy vor den eingebauten Webserver zu stellen. Das erscheint nicht nur unlogisch, sondern gerade im unternehmensinternen Einsatz eher überflüssig. Wenn die GPG-Tools zum Beispiel nur über SSL mit dem Server kommunizieren möchten, sollte die Verschlüsselung nicht am Proxy enden.

01 'use strict';
02
03 var fs= require('fs');
04 module.exports = {
05   log: {
06     level: 'silly',
07     console: {
08       colorize: true,
09     }
10   },
11
12   papertrail: {
13     host: process.env.PAPERTRAIL_HOST,
14     port: process.env.PAPERTRAIL_PORT
15   },
16   server: {
17     port: 80,
18     port_https: 443,
19     httpsUpgrade: true,
20     httpsKeyPin: 'base64_encoded_sha256',
21     httpsKeyPinBackup: 'base64_encoded_sha256',
22     rejectUnauthorized: false,
23     key: fs.readFileSync('/etc/ssl/private/Privater_Schlüssel.key'),
24     cert: fs.readFileSync('/etc/ssl/certs/Sicheres_Zertifikat.pem')
25   },
26   mongo: {
27     uri: '127.0.0.1/keyserver',
28     user: 'Mongo-DB-Nutzer',
29     pass: 'Passwort'
30   },
31   email: {
32     autoverify: true,
33     host: '127.0.0.1',
34     port: '25',
35     tls: 'no',
36     starttls: 'no',
37     pgp: true,
38     sender: {
39       name: 'Keyserver',
40       email: 'keyserver@keyserver.Eigene_Domain.org',
41     },
42     origin: {
43       protocol: 'https',
44       host: 'keyserver.Eigene_Domain.org'
45     },
46   },
47
48   publicKey: {
49     purgeTimeInDays: process.env.PUBLIC_KEY_PURGE_TIME || 30
50   }
51
52 };

Mailvelope beherrscht standardmäßig nur HTTP. Dabei lässt sich ein HTTPS-Server dank des KOA-Frameworks mit zwei minimalen Änderungen in der Datei »/src/index.js« erzeugen; die neue Version zeigt Listing 7. Die »config/default.js« aus Listing 6 berücksichtigt die passenden Erweiterungen schon.

01 'use strict';
02
03 const log = require('winston');
04 const config = require('config');
05 const init = require('./app');
06 const http = require('http');
07 const https = require('https');
08 (async () => {
09   try {
10     const app = await init();
11     http.createServer(app.callback()).listen(config.server.port,
12       () => {
13         log.info('app', `Listening on http://localhost:${config.server.port}`)
14       }
15     );
16     https.createServer({key: config.server.key, cert: config.server.cert},app.callback()).listen(config.server.port_https,
17       () => {
18         log.info('app', `Listening on https://localhost:${config.server.port_https}`)
19      }
20     );
21   } catch (err) {
22     log.error('app', 'Initialization failed!', err);
23   }
24 })();

Jetzt läuft der Test mit »npm test« erfolgreich durch, »npm start« lässt dann den Keyserver durchstarten. Unter »https://keyserver.Eigene_Domain.org« sollte jetzt das Webfrontend erscheinen.

Das sieht so aus, wie jenes unter http://keys.mailvelope.com. Das ist unerfreulich, aber leicht zu ändern: Alles, was die Oberfläche ausmacht, steht als HTML in »/src/view/«. So lässt sich der lästige, weil nicht automatisch aktualisierte Verweis auf »hkps://keys.mailvelope.com« aus der unteren rechten Ecke ersetzen.

Einrichten

GPG unter Unix hält seine benutzereigenen Konfigurationsdateien üblicherweise in »~/.gnupg/« vor. Dort findet sich auch die Datei »dirmngr.conf«, die der Admin um den neuen internen Server ergänzt (Listing 8). Um Nutzer anzulegen, bietet es sich an, diese Datei als Template in »/etc/skel/« vorzuhalten.

01 keyserver hkps://keyserver.Eigene_Domain.org
02 hkp-cacert /etc/ssl/certs/Sicheres_Zertifikat.pem

Als Ergebnis der Schritte sollte der Admin über die Kommandozeile jetzt einen vorher hochgeladenen Key finden können (Listing 9, erste Zeile). In die jeweiligen GPG-Schlüsselverwaltungen wie GPG Keychain oder Kleopatra trägt er die Server bei Bedarf auch ein.

01 gpg -vvv --keyserver hkps://keyserver.Eigene_Domain.org --receive-keys 'Fingerprint_des_Keys'
02 gpg -vvv --keyserver hkps://keyserver.Eigene_Domain.org --send-keys 'Fingerprint_des_Keys'

Lädt der Anwender dann über den Befehl aus der zweiten Zeile (oder ganz bequem per Webfrontend) einen weiteren Schlüssel auf den Server, erzeugt Mailvelope eine automatische Kontrollmail (Abbildung 1). Erst wenn der Besitzer des Schlüssels den Link anklickt, gilt der öffentliche Schlüssel als bestätigt.

Abbildung 1: Mailvelope verschlüsselt seine Authentifizierungsmails auf Wunsch mit dem eigenen Public Key.

Steht der Wert »pgp« in der Datei »config/default.js« auf »true« (Listing 6), verschlüsselt Mailvelope die E-Mail gleich mit dem öffentlichen Key des Empfängers. So prüft die Software nicht nur, ob der E-Mail-Empfänger existiert, sondern auch, ob er den passenden privaten Schlüssel besitzt.

Verwendet ein Unternehmen hingegen einen Keyserver ohne Zugriffsmöglichkeit von außen, lässt sich keine auf E-Mails basierte Prüfung für Kundenschlüssel umsetzen. Hier ergibt es Sinn, die Prüfung komplett zu unterlassen. Da Mailvelope aber nur geprüfte öffentliche Schlüssel ausliefert, wäre der Keyserver so unbrauchbar.

Listing 10 zeigt einen Vorschlag für die Lösung: Es ersetzt die Zeile 103 der »service/public-key.js«. Die neue Konfigurationsdirektive »autoverify« aktiviert das dort vorgeschlagene Feature. Über ein wenig Javascript-Code und mit Hilfe regulärer Ausdrücke ließen sich dann auch einige Domainnamen in der Datei ergänzen und nur dafür E-Mails zur Verifizierung durchlassen.

01 if (config.email.autoverify) {
02   // User-IDs automatisch prüfen
03   for (let userId of key.userIds) {
04     userId.verified = true;
05     userId.publicKeyArmored = null;
06   }
07   key.publicKeyArmored = publicKeyArmored;
08 } else {
09   // E-Mails senden, um User-IDs zu prüfen
10   await this._sendVerifyEmail(key, origin, ctx);
11 }

SMTP über TLS?

Wer in der »smtpd.conf« in Listing 4 die fehlenden PKI-Direktiven entdeckt und entsetzt in der »config/default.js« den Eintrag »starttls« vermisst: Weil Mailvelope alle ausgehenden E-Mails über den lokalen Mailserver per PGP-verschlüsselt, eine Authentifizierung fehlt und die Kommunikation nur lokal verläuft (über »localhost« oder »127.0.0.1«), ist SSL überflüssig.

Zwar ließe sich das selbst signierte Zertifikat anlegen und schnell in die »smptd.conf« einbinden, doch wäre zum Akzeptieren solcher Zertifikate eine Code-Änderung an Mailvelope nötig: Die Software mault bei selbst signierten Zertifikaten.

Reisende nicht aufhalten

Mit dem Keyserver kann es nun losgehen: Kommunikation intern und extern ist perfekt verschlüsselt. Doch was passiert, wenn ein Mitarbeiter das Unternehmen verlässt, krank wird oder gar Urlaub macht? Wie realisiert man im Rahmen einer – hoffentlich DSGVO- und Fernmeldegeheimnis-tauglichen – Vertreterregelung den Zugriff auf die E-Mails?

Einen Gruppen-Key sieht PGP zwar nicht vor. Unter den folgenden drei Prämissen findet sich aber auch für dieses Problem ein Ausweg:

• Der PGP-Einsatz zielt vorrangig auf eine sichere Ende-zu-Ende-Verschlüsselung für die externe Kommunikation ab und nur eingeschränkt auf eine Authentifizierung des Absenders. Es genügt, dass sich das Unternehmen authentifiziert.
• Es gibt einen definierten Prozess, um Schlüssel beim Ausscheiden von Mitarbeitern zurückzurufen.
• Innerhalb einer Abteilung sind gegenseitige Vertretungen vorgesehen.

Treffen alle drei Punkte zu, wäre es denkbar, eine E-Mail-Adresse für die Abteilung zu generieren (Abbildung 2), zum Beispiel »vertrieb@example.org«, deren Schlüssel die E-Mail-Adressen der Mitarbeiter der Abteilung (Abbildung 3) als weitere IDs auflistet (Abbildung 4). Einzelne Mitarbeiter erhalten dann keine verschlüsselten E-Mails mehr.

Abbildung 2: Einen neuen Key für die Vertriebsabteilung erzeugen.

Die Nachteile der Lösung: Den Private Key teilen sich alle Mitarbeiter der Vertriebsabteilung. Daher setzt Abbildung  2 die Gültigkeitsdauer für den Schlüssel recht kurz an. Zudem eignet sich der Key damit nur noch eingeschränkt zum Signieren: Die Signatur bestätigt nicht mehr den Versand durch eine Person, sondern allenfalls durch ein Mitglied der Abteilung. Zudem dürfen so alle Mitarbeiter der Abteilung Nachrichten entschlüsseln. Doch das ist erwünschtes Verhalten.

Fazit

Aus Sicht des Autors stellt das geschilderte Szenario einen tragbaren Kompromiss zwischen ungeschützter Kommunikation und unternehmensinternen Risiken dar. Für vertrauliche Kommunikation im Unternehmen, etwa mit dem Betriebsrat oder -arzt, lassen sich zusätzlich individuelle Schlüssel konfigurieren.

Abbildung 3: Barbara Beispiel als weitere ID dem Key hinzufügen.

Abbildung 4: Ist die Vertriebsabteilung komplett, sind deren Mitglieder über verschlüsselte E-Mails an »vertrieb@example.com« erreichbar.

Dank des internen Keyservers greifen alle Mitarbeiter auf die Public Keys von Kunden und Kollegen zu. Da Mailvelope die Keys per Default nicht verteilt und deren Löschen ermöglicht, darf die Lösung – anders als bei öffentlichen Keyservern – als datenschutzfreundlich gelten. Der Implementationsaufwand erscheint, lässt man die schlechte Dokumentation von Mailvelope beiseite, ebenfalls tragbar. Am Ende stünde ein wichtiger Fortschritt bei E-Mails: Eine echte Ende-zu-Ende-Verschlüsselung zwischen den Kommunikationspartnern.