SMIME zur internen Verschlüsselung?

Das Internet ist unsicher und SMIME und PGP sind effektive Möglichkeiten die Kommunikation durch Verschlüsselung und Signierung zu schützen. Aber kann ich damit auch intern zwischen Postfächern den Schutz verbessern, damit z.B. Administratoren nicht mitlesen?

Anforderung

Die Anforderung lautete, dass nicht nur Mails mit Partnern besser geschützt werden sondern auch intern eine Absicherung möglich sein soll.
Bei Lotus Notes hatte schon jeder Anwender entsprechendes Schlüsselmaterial in seiner Notes-ID und den passenden PublicKey im Adressbuch (Names.nsf).

Eine ähnliche Funktion gibt es schon viele Jahre mit Outlook, Exchange und Active Directory. Schon immer gibt es im AD ein Feld "userCertificate", welches vom Anwender sogar selbst gefüllt werden kann. Anwender können mit Outlook ein SMIME-Zertifikat anfordern, den privaten Schlüssel auf dem lokalen PC abspeichern und das Zertifikate mit dem von einer CA signierten Publickey im Active Directory veröffentlichen. (Siehe auch Benutzerzertifikate im AD) Alle anderen Benutzer können dieses Zertifikat über das Adressbuch finden, lesen und direkt Mails signieren. Klingt nach einer heilen Welt. Nur warum nutzen diese Funktion nur ganz wenige Firmen?

Einschränkungen

Um ihre verschlüsselten Mails zu lesen, benötigen Sie ihren privaten Schlüssel, der aus Sicherheitsgründen nicht "exportierbar" sein sollte. Wie lösen Sie dann die folgenden Fälle?

  • Sie bekommen einen neuen Computer.
    Wie bekommen sie ihren privaten Schlüssel vom alten Computer auf den neuen Computer, wenn er eigentlich nicht exportierbar ist?. Es gibt hier die Funktion Clientzertifikat Roaming, die aber konfiguriert werden muss.
  • Benutzer vergisst sein Kennwort
    Der private Key ist im "Keystore" gespeichert, der mit dem Kennwort des Anwenders verschlüsselt ist. Wenn der Anwender sein Kennwort ändert, aktualisiert Windows auch die Verschlüsselung des "Credential Store". Wenn Sie als Administrator ein neues Kennwort setzen, dann hat der Benutzer keinen Zugriff mehr auf seine Schlüssel und gespeicherten Kennworte.
  • Mails per Browser aus der Ferne
    OWA unterstützt auch SMIME aber natürlich benötigen Sie auf dem Client irgendwie den privaten Schlüssel. Das kann eine Smartcard oder ein USB-Key sein, aber beides sollten Sie nie in einen "unbekannten" Computer stecken. Der Zugriff ist also stark eingeschränkt
  • Mails auf dem Smartphone, z.B. ActiveSync
    Wenn Sie ihr Zertifikat auf dem Smartphone hinterlegen und eine passende App nutzen, dann können Sie zumindest ihre empfangenen verschlüsselten Mails lesen und signiert senden.
  • Ein Stellvertreter soll ihre Mail lesen
    Das geht natürlich nur, wenn entweder der Stellvertreter ebenfalls ihren privaten Key hat. Dann kann er aber auch mit ihrem Namen signieren. Wollen Sie das?
  • Eingehende Mails sollen automatisch (Regeln, Power Automate etc.) verarbeitet werden
    Das kann nur noch anhand des Empfänger, Absenders oder Betreff erfolgen, denn bei einer verschlüsselten Mail sind der Body und Anlagen nicht ohne privaten Schlüssel lesbar.
  • OOF-Meldungen sind unsigniert
    Durch die Nutzung von SMIME auf dem Client kann der Server natürlich nicht signieren. Wenn ihre Kommunikationspartner nur signierte/verschlüsselte Mails erwarten, dann sind sie vielleicht von einer unsignierten Urlaubsmail irritiert.
  • New statt "Renew"
    Zertifikate gelten immer nur eine bestimmte Zeit, z.B. 1 Jahr. Danach müssen Sie erneuert werden. Es ist wichtig, dass Sie das bestehende Zertifikat verlängern, so dass der private und öffentliche Schlüssel gleich bleiben. Ansonsten müssen sie von Jahr zu Jahr mehr Zertifikate mitschleifen. Das neue Zertifikat mit neuen Schlüsseln kann nämlich keine alten Mails entschlüsseln.
  • Wie regeln Sie Compliance/Archiv/Backup/Spamfilter/Antivirus-Anforderungen?
    Ohne Vorkehrungen ist der Besitzer mit dem privaten Schlüssel die einzige Instanz, die eine verschlüsselte Mails decodieren und damit lesen kann. Sicher könne sie auch verschlüsselte Mails "sichern" aber ohne den privaten Key gibt es keinen Zugriff.
  • Disclaimer
    Aber auch beim Versand gibt es Hürden wie z:B. die Anforderung an jede Mail einen "Legal Disclaimer" mit Pflichtangaben im geschäftlichen Verkehr zu addieren. Das geht nicht reibungslos, wenn die Mail vom Anwender schon mit dem öffentlichen Schlüssel des Empfängers verschlüsselt und mit dem eigenen Key signiert ist.

Aus meiner Sicht sind das alles viel zu viele Punkte, die den Einsatz von SMIME/PGP im internen Netzwerk erschweren und ohne entsprechenden Vorkehrungen eigentlich verbieten. Zudem lösen SMIME/PGP nicht das Problem, dass ein legitimer Empfänger die Mail entschlüsseln und seinerseits unverschlüsselt und verändert mit nicht berechtigten Personen teilen kann. SMIME/PGP sind also kein "Rights Managment". Solche Funktionen sind dann eher in AIP/RMS zu finden.

Option: SMIME verhindern

Hier müssen wir unterscheiden, ob wir die SMIME unterstützen oder verbieten wollen. Im Grund kann nämlich jeder Mitarbeiter sich bei einer der öffentlichen PKIs auf private Kosten ein SMIME-Zertifikat kaufen und nutzen. Dies können Sie am effektivsten mit einer Transportregel auf Exchange Ebene oder auf einem vorgelagerten Spamfilter unterbinden. Genauso soll sie auch eingehende Mail auf SMIME prüfen und signierte Mails entweder blockieren oder zumindest die Signatur samt Absenderzertifikat entfernen. Ansonsten könnte ihr Mitarbeiter sogar "verschlüsselt antworten".

Wer sicherstellen muss, dass er immer die komplette Kontrolle über die Nutzung von Email im Unternehmen hat, sollte überwachen, ob und wer SMIME/PGP nutzt und über eine interne Hausordnung die Verwendung beschreiben und per Konfiguration erzwingen.

Wenn sie aber SMIME intern aktiv nutzen wollen, dann bleibt noch die Frage, welche PKI die Zertifikate ausstellt.

Option: SMIME mit externer PKI

Der "einfachstes" Weg ist sicher, das Sie für jeden Anwender ein SMIME-Zertifikat als Firma kaufen und dem Anwender bereitstellen. Wenn der Anwender das Zertifikat nicht selbst auf seinem Computer "rechnet", dann haben Sie als IT-Abteilung auch den privaten Schlüssel und können damit auch nach dem Ausscheiden des Mitarbeiters, Verlust des Endgeräts etc. relativ einfach wieder die Funktion erreichen.

Die Mitarbeiter können damit auch intern verschlüsseln und signieren. Beachten Sie aber unbedingt die Einschränkungen an Anfang dieser Seite. Denn sie werden sicher nicht jedem automatischen Prozess den Zugriff auf alle privaten Schlüssel geben, nur damit sie z.B. serverseitige Regeln umsetzen können. Zudem müssen Sie alle Produkte auch auf ihre Eignung prüfen. Exchange Transport Regeln können nicht mit SMIME umgehen und ob ihre Disclaimer-Lösung und Archiv-Lösung dies kann, steht wieder auf seinem anderen Blatt.

Zuletzt ist es natürlich auch eine Kostenfrage. Aktuell gibt es z.B. mit Let's Encrypt einen kostenfreien Dienst für Server-Zertifikate (HTTPS) für den Einsatz einer Transportverschlüsselung per TLS. Damit könnten Sie auch die SMTP-Server ausstatten. Aber es gibt keinen kostenfreien Dienst, der SMIME-Zertifikate bereitstellt.

Option: SMIME mit eigener PKI

Sie können das intern durchaus mit einer eigenen PKI umsetzen, weil Sie hier dann auch alle Kontrolle über Key Recovery etc. haben und es zumindest nur ihre Arbeitszeit und Rechenleistung kostet, aber keine Zahlungen an eine CA je Mailadresse erforderlich sind. Technisch ist es relativ einfach:

  • Private PKI
    Ich bevorzuge hier eine zweistufige PKI mit einer RootCA (offline), die verschiedene IssuingCAs signiert und auf allen Firmengeräten als "Trusted Root" addiert wird. (Aber bitte nicht bei Partnern, wie ich auf Partner-StammCA beschrieben habe.
    Die IssuingCA für SMIME hat ein "KeyRecoverAgent"-Setup, so dass man bei Verlust eines Zertifikats das Schlüsselmaterial wieder herstellen kann. Natürlich muss Sie als "Key Vault" auch für einen sicheren Betrieb konfiguriert werden.
  • AutoEnrollment
    Wenn die IssuingCA sogar AD-Mitglied ist können die Anwender sogar selbst ein Zertifikat anfordern. Ich würde das aber nur tun, wenn die Anwender entsprechend geschult sind.

Allerdings sollten Sie genau überlegen, wie sie die externe Kommunikation im Griff behalten, denn das führt immer wieder zu Nachfragen, die letztlich ihre Zeit kosten. Ohne entsprechendes Gateway würde ich jegliche signierte oder verschlüsselte Kommunikation mit dem Internet unterbinden, da dort ihre Signaturen nicht "vertrauenswürdig" sind und entsprechende Warnungen bei den Kommunikationspartnern generieren.

Dennoch gibt es Firmen, die genau dies tun und sogar ihre Partner bitten der Partner-StammCA zu vertrauen.

Aus meiner Sicht ist dies für keinen der beiden Kommunikationspartner ein erwünschter Weg.

Dies wird sich auch nicht so schnell ändern, selbst wenn irgendwann die RootCAs vielleicht obsolet werden, wenn Zertifikate per DNSSEC im DNS veröffentlicht werden.

Option: SMIME mit Gateway

Sie wissen nun, dass die Nutzung von SMIME mit Zertifikaten einer privaten PKI im internen Nachrichtenaustausch durchaus nutzbar sein kann. Allerdings ist dies keine Lösung für eine externe Kommunikation. Der Einsatz öffentlicher Zertifikate ist aber ohne Key Recovery ein hohes Risiko und so bleibt nur noch eine Gateway-Verschlüsselung mit offiziellen Zertifikaten nach extern. Damit stellt sich die Frage, ob wir nicht beide Methoden kombinieren können, z.B. dass intern mit privaten Zertifikaten gearbeitet werden kann, die aber auf dem Weg nach Extern ersetzt werden. Die folgende Beschreibung könnte so eine Konstellation erklären. Ob sie aber sinnvoll ist und der Aufwand sich lohnt, lasse ich aktuell noch unbeantwortet: Zuerst einmal die verschiedenen Komponenten.

  • Links ist der rote externe Anwender einer anderen Firma
    Er kann SMIME nutzen, weil der Anwender Ext1" ein SMIME-Zertifikat (1) einer öffentlichen PKI und den dazu passenden privaten Schlüssel (PRIV1) hat. Der signierte öffentliche Schlüssel hat auch schon schon das Gateway (3) der Firma durch eine frühere Mail bekommen
    Der externe Anwender hat auch schon das (blaue) Zertifikat (2) des Firmenbenutzers von einer andere öffentlichen PKI durch das Gateway erhalten.
  • Gateway
    Das Gateway hat die Aufgabe, alle eingehende SMIME-Mails zu entschlüsseln und zu prüfen und ausgehende Mails möglich gemäß der Richtlinien zu signieren und zu verschlüsseln. Dazu kann es sich die erforderlichen Zertifikaten von einer internen oder externen PKI holen oder öffentliche aus dem Mailflow extrahieren. Entsprechend hat es das Zertifikat des externen Benutzers (3) und ein Zertifikate mit privatem Schlüssel (4) für den eigenen Anwender.
    Damit der interne Anwender aber nicht am Gateway vorbei SMIME nutzt ,entfernt das Gateway bei eingehenden Mails das Signaturzertifikat des externen Absenders und erstellt ein privates Zertifikat für die externe Adresse (5), die aber nur intern zum Einsatz kommt. Zudem hat das Gateway natürlich auch das Zertifikate der internen PKI für den Benutzer1.
  • Firmenbenutzer mit internen Zertifikate
    Wir wollen intern mit privaten Zertifikaten und SMIME arbeiten. Daher hat der Anwender natürlich über das Adressbuch oder früheren Emails ein Zertifikat für den externen Anwender (7), welches aber natürlich von der eigenen internen PKI ist. Zudem hat der Clients ein SMIME-Zertifikat (8) mit privatem Key der privaten PKI zur Nutzung von SMIME.

Mit diesem sind nun alle SMIME-Kommunikationswege möglich.

  • Intern zu Intern
    Wenn zwei interne Anwender miteinander eine Mail signiert und/oder verschlüsselt austauschen wollen, dann können Sie dies mittels dem Zertifikat (8) pro Benutzer einfach tun. Niemand kann hier Einsicht nehmen. Ein Exchange Administrator kann über die Nachrichtenverfolgung nur die Kommunikationspartner, Zeitpunkt, Größe und Betreff einsehen. Als PKI-Administrator können Sie natürlich beim Ausstellen der Zertifikate ein "Backup" des Schlüssels verlangen, um weitergehende Funktionen bereitstellen zu können.
  • Intern nach Extern
    Der Anwender kann jederzeit eine Mail mit seinem Zertifikat (8) digital signieren. Das angeblich öffentliche Zertifikat des externen Empfängers kann er per LDAP o.ä. vom Gateway abrufen, welches notfalls schnell ein Zertifikat (5) ausstellt. Die so verschlüsselte Mail kommt auf dem Weg ins Internet zwangsläufig am SMIME-Gateway vorbei, welches die Mail dank Zertifikat 5 die Mail entschlüsseln und die Signatur prüfen kann. Das Gateway entfernt dann aber beides und signierte und verschlüsselt die Mail neu. Diesmal aber mit den öffentlichen Zertifikaten 3 und 4.
    Der externe Empfänger merkt gar nicht, dass die Mails intern mit anderen Zertifikaten verarbeitet wurde.
  • Extern nach Intern
    Auch in die Gegenrichtung funktioniert dies, wenn der externe Absender mit seinem Zertifikat (1) signiert und mit dem öffentlichen Zertifikat (2) für den Firmenbenutzer verschlüsselt. Das SMIME-Gateway hat ja den dazu passenden privaten Schlüssel und kann die Mail entschlüssel, um Malware zu suchen als auch die Signatur prüfen, ehe das Gateway dann die Mail mit den internen Zertifikaten des Anwenders verschlüsselt und ggfls. ein internes Zertifikat für den externen Absender zur Signatur anlegt.

Über so eine Konfiguration erhalten Sie natürlich keine vollwertige Ende-zu-Ende-Verschlüsselung aber die Mail selbst ist auf allen Transportwegen mittels SMIME gegen Mitlesen oder Veränderungen geschützt. Der interne Anwender hat sogar noch den Vorteil, dass er auch am Icon und Status der Mails sieht, wenn diese aus dem Internet "signiert" angekommen ist und ein lokaler Angreifer mit Zugriff auf eine PST/OST-Datei, kann mit den Mails solange nichts anfangen, wie er auch nicht an die kryptographischen Schlüssel kommt.

Einschätzung

Ich habe diese Seite absichtlich nur als "Konzept" geschrieben und kein HowTo mit einem Produkt geschrieben. Nur weil etwas technisch möglich sei könnte, bedeutet dies nicht, dass es entsprechende Produkte gibt oder die Umsetzung wirklich eine Lösung für ein Kundenproblem sein könnte.

Mir graut es immer noch vor SMIME-Verschlüsselten Mails in Postfächern von Mitarbeitern, denen dann der dazu passenden privaten Key fehlt und Sie nicht mehr lesen können.

Ich bin aber gespannt, welche besonderen SMIME/PGP-Anforderungen Sie in ihrer Umgebung erfüllen müssen. Sprechen Sie mich gerne dazu an. Kontakt

Weitere Links