E-Mail-Verschlüsselung und Signatur in der IT-Forensik

1. Motivation und Kontext zur IT-Forensik

Dieser Wiki-Eintrag beschreibt die Möglichkeiten der Ende-zu-Ende-Absicherung von E-Mail-Inhalten. Dies kann insbesondere bei der Kommunikation über das Internet mit externen Dritten erforderlich werden, wenn der direkte persönliche Kontakt nicht möglich, nur mit entsprechend hohem Aufwand verbunden ist oder zu einem unakzeptablen Zeitverzug führen würde. Bei der Behandlung von Sicherheitsvorfällen sowie der Durchführung von forensischen Untersuchungen sind in Abhängigkeit des konkreten Untersuchungsgegenstandes beispielsweise Kontaktaufnahmen zu lokalen Sicherheitsspezialisten oder Ermittlungsbehörden erforderlich, um den Austausch von Informationen sicherzustellen (vgl. A. Geschonnek 2014. Computer-Forensik Computerstraftaten erkennen, ermitteln aufklären. 6., aktualisierte und erweiterte Auflage. dpunkt.verlag GmbH Heidelberg. S. 46 f.). Technisch, organisatorisch und finanziell aufwendig zu implementierenden Infrastrukturen für gesicherte Übertragungswege über das Internet, zum Beispiel von virtuellen privaten Netzwerken (VPN) oder im Rahmen von IPsec-Tunnel, wie sie in der Regel bei verteilten Unternehmensstandorten zum Einsatz kommen, stehen für diese Anwendungsfälle meist nicht zur Verfügung. Auch die alleinige Verwendung von Transportverschlüsselung zum Beispiel gemäß des Protokolls Transport Layer Security (TLS) bei den verschiedenen E-Mail-Protokollen (IMAP, POP3, SMTP und so weiter) bietet hier keinen ausreichenden und allumfassenden Schutz der Kommunikationsinhalte vom Sender bis zum Empfänger.

Innerhalb der organisatorischen Vorbereitung müssen diese E-Mail-Kommunikationswege auf einen sicheren Informationsaustausch geprüft werden und erforderlichenfalls vorbereitet werden.

2. PGP/OpenPGP Message Format

Eine einfach und schnell zu implementierende Lösung einer Ende-zu-Ende abgesicherten E-Mail-Kommunikation stellt PGP dar. PGP und OpenPGP werden häufig als Synonym genannt. Bei genauerer Betrachtung steht OpenPGP als ein Begriff für Sicherheitssoftware die PGP verwendet. PGP ist eine Sammlung von Softwaresystemen, welche von Philip R. Zimmermann entwickelt wurde und auf OpenPGP basiert. Dabei steht PGP als Abkürzung für Pretty Good Privacy. In diesem Zusammenhang ebenfalls zu nennen ist GnuPG (GPG). PG steht für Privacy Guard. GnuPG ist eine OpenPGP Implementierung (#https://gnupg.org). OpenPGP bietet Datenintegritäts- und Vertraulichkeitsdienste für Nachrichten und Datendateien durch: • digitale Signaturen • Verschlüsselung • Kompression • Radix-64-Konvertierung (Base64 kodierte Daten mit CRC-24 Prüfsumme) PGP und OpenPGP sind in den folgenden Request for Comments (RFC) der Internet Engineering Task Force (IETF) spezifiziert: • RFC1991 PGP Message Exchange Formats August 1996 (PGP Version 2.x), obsolet mit RFC4880 • RFC2440 OpenPGP Message Format November 1998 (PGP Version 5.x als PGP 3), obsolet mit RFC4880 • RFC4880 OpenPGP Message Format November 2007 (PGP Version 5.x als PGP 3) • RFC5581 The Camellia Cipher in OpenPGP Juni 2009, Aktualisierung RFC4880 • RCF6637 Elliptic Curve Cryptography (ECC) in OpenPGP Juni 2012, Erweiterung zu RFC4880 • RFC2015 MIME Security with Pretty Good Privacy (PGP) Oktober 1996 • RFC3156 MIME Security with OpenPGP August 2001, Aktualisierung RFC2015 Gemäß der letzten beiden aufgelisteten RFC ist es also möglich, PGP zur Absicherung von Multipurpose Internet Mail Extensions (MIME) einzusetzen. MIME definiert insbesondere ein Datenformat für E-Mails, welche über das Internet Message Format (IMF, vgl. RFC5322) also die Syntax von Textnachrichten hinausgeht. Dazu gehören somit auch alle Nicht-Text-Daten in E-Mail-Nachrichten wie Bilder, Audio oder andere Arten von strukturierten Daten. Um die Authentizität der öffentlichen Schlüssel sicherstellen nutzt PGP keine hierarchischen Zertifikatsketten, sondern ursprünglich einen Web-of-Trust Ansatz. Jedes Mitglied kann einen öffentlichen Schlüssel signieren und damit ein Zertifikat erstellen, wenn er glaubt, dass ein öffentlicher Schlüssel tatsächlich zu der Person gehört. Je mehr Zertifikate mit einem Schlüssel verbunden sind desto höher ist die Sicherheit, dass dieser Schlüssel tatsächlich dem angegebenen Eigentümer gehört. Die öffentlichen PGP-Schlüssel wurden in einem international synchronisierten Ring von Key-Servern (Synchronizing OpenPGP Key Server – SKS) zum Abruf bereitgehalten. Jeder Inhaber eines deutschen Personalausweises mit Online-Ausweisfunktion kann sich in Verbindung mit einem Near Field Communication (NFC)-fähigen Endgerät (zum Beispiel ein entsprechendes Smartphone) über die AusweisApp2 des Bundes (https://www.ausweisapp.bund.de/ausweisapp2/) von einem vom Bundesamt für die Sicherheit in der Informationstechnik (BSI) beauftragten Unternehmen (Governikus GmbH & Co. KG) den eigenen öffentlichen PGP Schlüssel beglaubigen lassen (https://pgp.governikus.de/pgp/). Mit dem Projekt EasyGPG reagierte das BSI auf verstärkte Angriffe gegen diese Key-Server. (https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Freie-Software/E-Mail-Verschluesselung/EasyGPG/easygpg.html). Insbesondere im Jahr 2019 tauchten auf den SKS vermehrt gefälschte Schlüssel auf, da prinzipiell jeder Schlüssel auf die Server hochladen konnte und somit zu einer Identität sowohl gefälschte als auch echte Schlüssel vorhanden waren. Eine Löschung von Schlüsseln auf den Servern war durch den PGP Web-of-Trust Ansatz grundsätzlich nicht vorgesehen. Somit war nicht sichergestellt, ob ein vom Server importierter Schlüssel einer Identität echt ist oder nicht, wenn der Fingerprint eines Schlüssels nicht mit der entsprechenden Identität abgeglichen wurde beziehungsweise werden konnte. Die mit EasyGPG vorgesehenen Erweiterungen Web Key Directory (WKD) und Web Key Service (WKS) sollen diese Sicherheitslücke schließen. Eine Veröffentlichung erfolgte durch die Network Working Group der IETF mit dem derzeit in der Version 12 vom 16.05.2021 vorliegenden Internet Draft Dokument: • OpenPGP Web Key Directory draft-koch-openpgp-webkey-service-12 (https://datatracker.ietf.org/doc/html/draft-koch-openpgp-webkey-service-12)

Für WKD und WKS wird lediglich benötigt:

• ein Webserver wie nginx oder Apache, der eine persönliche Domain oder die des eigenen Unternehmens ausliefert • ein gültiges X.509 Zertifikat für TLS beispielsweise mittels Automatic Certificate Management Environment (ACME, vgl. RFC8555 März 2019) von Let’s Encrypt (https://letsencrypt.org/) der Internet Security Research Group (ISRG) ACME beruht darauf, dass der Identitätsnachweis über die Authentifizierung des Domainnamen erfolgt, das heißt dass anhand von bestimmten Herausforderungen (challenge) die Inhaberschaft einer Domain nachgewiesen wird (response). Domainvalidierte Zertifikate, bieten den Vorteil, dass sie unverzüglich ausgestellt werden. ACME in Verbindung mit DNS Security Extensions (DNSSEC, vgl. RFC4033) sowie DNS over TLS (DoT, vgl. RFC7858) oder DNS Queries over HTTPS (DoH, vgl. RFC8484) sollen die Schwachpunkte bei der Validierung im Domain Name System (DNS) beseitigen (vgl. RFC8555 S.79ff 10.2. Integrity of Authorizations und S.86 11.2. DNS Security). Einige Anbieter von öffentlichen DNS-Diensten und Nameserver (NS) unterstützen bereits DNSSEC. Im Gegensatz muss bei erweitert validierten Zertifikaten in der Regel die Identität des Zertifikatsinhabers aufwendig mittels Face-to-Face also von Angesicht zu Angesicht überprüft werden und bieten dafür ein Höchstmaß an Fälschungssicherheit. Nutzbar ist PGP in Verbindung mit WKD und WKS durch die weit verbreiteten E-Mail-Clients Mozilla Thunderbird und KMail sowie über eine Programmerweiterung (GpgOL) für Microsoft Outlook, welche mittels Gpg4win installiert wird. Die Entwicklung von Gpg4win wurde durch das BSI beauftragt (https://www.gpg4win.de/). Für Webmailer steht die Browser-Erweiterung Mailvelope zu Verfügung, dessen Entwicklung ebenfalls durch das BSI initiiert wurde. (https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Freie-Software/E-Mail-Verschluesselung/Mailvelope/mailvelope_node.html) Alternativen zu WKD und WKS bieten die Lösungen: • RFC7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP, August 2016 • sowie der Key-Server https://keys.openpgp.org/ Dieser Key-Server erfordert im Gegensatz zu den SKS persönliche Daten als Identitätsinformationen des Besitzers zum OpenPGP-Schlüssel, welche ausschließlich mit dessen Zustimmung veröffentlicht werden (https://keys.openpgp.org/about). Das Netzwerkprotokoll DANE basiert auf DNSSEC bei der Namensauflösung. Eine weitere Möglichkeit der Ende-zu-Ende-Absicherung von E-Mail-Inhalten bietet S/MIME, welches aber zu PGP nicht kompatibel ist. 3. S/MIME S/MIME steht für Secure/Multipurpose Internet Mail Extensions und bietet die Möglichkeit MIME-Daten sicher zu senden und zu empfangen. Verwendet werden: • Digitale Signaturen für Authentifizierung, Nachrichtenintegrität und Nichtabstreitbarkeit sowie Herkunftsnachweis • Verschlüsselung für Datenvertraulichkeit • Kompression zur Reduktion der Datengröße Die bestimmenden RFC der IETF für S/MIME sind: • RFC2311 S/MIME Version 2 Message Specification März 1998, kein Internet Standard und historisch • RFC2633 S/MIME Version 3 Message Specification Juni 1999, obsolet mit RFC3851 • RFC3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification Juli 2004, obsolet mit RFC5751 • RFC5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification Januar 2010, obsolet mit RFC5751 • RFC8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification April 2019 sowie zur Verwendung von X.509 Zertifikaten bei S/MIME: • RFC2632 S/MIME 3.0 Certificate Handling Juni 1999, obsolet mit RFC3850 • RFC3850 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling Juli 2004, obsolet mit RFC5750 • RFC5750 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Certificate HandlingJanuar 2010, obsolet mit RFC8550 • RFC8550 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Certificate Handling April 2019 Eines der wesentlichen Unterschiede zu PGP ist somit, dass S/MIME für den Betrieb X.509 basierte Zertifikate nach RFC5280 erfordert und damit auf eine strikt hierarchisches Architekturmodell von vertrauenswürdigen Zertifizierungsstellen (Certificate Authority – CA) setzt. Die Sicherheit basiert also wie bei WKD/WKS von EasyPKP des BSI auf den Vertrauensfaktor in die CA. Validierungsstufen bei der Verifizierung der Identität für ein S/MIME Zertifikat sind nicht genormt und vom jeweiligen Zertifikatsanbieter abhängig. Bei hohen Validierungsstufen müssen in der Regel Identitäten anhand gültiger offizieller Dokumente (wie Personalausweis oder Reisepass) vor Ort beim Zertifikatsanbieter nachgewiesen werden. Automatisierte Verfahren wie ACME sind noch nicht nutzbar beziehungsweise verfügbar. Allerdings wurden mit RFC8832 Extensions to Automatic Certificate Management Environment for End-User S/MIME Certificates der IETF vom April 2021 erste grundlegende Spezifizierungen festgeschrieben. Eines der wesentlichen Vorteile von S/MIME ist, dass nahezu jede E-Mail-Client Anwendung S/MIME ohne zusätzlich zu installierende Programmerweiterung unterstützt. 4. Anti-Forensik Entgegen dem Nutzen bei der eigenen Verwendung von PGP und S/MIME können so geschützte Inhalte den forensischen Untersuchungsprozess selbst auch erschweren. Mögliche Angreifer und Täter können im Rahmen von Anti-Forensik-Maßnahmen die genannten Techniken zum Beispiel der Verschlüsselung mittels PGP oder S/MIME zum Verbergen von Kommunikationsinhalten ebenfalls nutzen. Die beschriebenen Verfahren mit PGP und S/MIME verschlüsseln lediglich den Inhalt der E-Mail. Metadaten wie Absender, Empfänger und Betreff werden nicht verschlüsselt.