Vergleich RFC 7672 vs. PGP / S/MIME
Weder das Bundesamt für Sicherheit in der Informationstechnik (BSI) noch der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit (BfDI) haben bisher ihre Gründe für die Verwendung von PGP oder S/MIME veröffentlicht. Also will ich meine eigenen Erkenntnisse etwas übersichtlicher und durchaus plakativer veröffentlichen. Zum Verständnis der Tabelle ist ganz wichtig, dass sowohl RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) als auch PGP oder S/MIME immer nur dann verwendet werden können, wenn beide Kommunikationspartner diese Standards verwenden. Es reicht nicht aus, dass eine Seite es kann.
Anders ist das bei DomainKeys Identified Mail (DKIM) oder Authenticated Received Chain (ARC). Bei DKIM reicht es, wenn der Sender DKIM kann, der Empfänger verwendet DKIM oft nur zur Bewertung ob es sich um Spam handeln könnte oder um Domain-based Message Authentication, Reporting and Conformance (DMARC) zu unterstützen. ARC ist nur auf Empfangsseite wichtig oder wenn eine Nachricht weitergeleitet wird (so zumindest die Sicht der Standards). Trotzdem werfe ich RFC 7672 und DKIM/ARC mal vereinfachend in einen Topf, weil nur so Gleichstand (Feature-Parity
) zu PGP oder S/MIME erreicht wird, weil bei diesen sowohl verschlüsselt als auch signiert werden kann.
PGP oder S/MIME kann auch in Kombination mit RFC 7672 oder DKIM/ARC verwendet werden. Insbesondere fordert das die Orientierungshilfe zur Emailverschlüsselung der Datenschutzkonferenz in Abschnitt 4.2.2 bei hohem Risiko. Das habe ich schon bei meiner ersten Veröffentlichung zu Email-Verschlüsselung als fragwürdig gekennzeichnet. Beides zu verwenden ergibt nur Sinn, wenn man seinem Anbieter nicht vertraut, aber dann kann man den auch wechseln statt alle Benutzer zu quälen. Und das mit Quälen ist wirklich ernst gemeint, SAP hat PGP eine Zeitlang eingesetzt (mit zentralem Schlüsselmanagement) und das hat nur wenige überzeugt, und glücklicherweise hat man das dann auch wieder gelassen.
Mir ist bewusst, dass andere wie Digitalcourage (Open)PGP empfehlen – siehe E-Mails verschlüsseln mit OpenPGP. Aber wir sollten stattdessen eher die Aufsichten, das sind die Bundesnetzagentur und der Bundesbeauftragte für den Datenschutz und die Informationsfreiheit, auffordern, die Einhaltung des Fernmeldegeheimnisses von Telekommunikationsdiensten einzufordern – und da macht RFC 7672 mehr Sinn als PGP oder S/MIME.
Aktualisierung 26.10.2023: Weitere Varianten zum Schlüsselmanagement bei PGP ergänzt und andere Kleinigkeiten aktualisiert.
| normale Email | RFC 7672 und DKIM/ARC | Pretty Good Privacy (PGP) | S/MIME | |
|---|---|---|---|---|
| Relevante Standards (Auswahl) | RFC 5321: Simple Mail Transfer Protocol, RFC 3207: SMTP Service Extension for Secure SMTP over Transport Layer Security | RFC 7672: SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) und dort referenzierte, RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, Authenticated Received Chain (ARC) Protocol | RFC 4880: OpenPGP Message Format | RFC 8551: Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification. |
| Konzept | Die Authentizität des sendenden Emailservers wird mit DKIM oder ARC, einer digitalen Signatur bestätigt. Die Authentizität des empfangenden Servers wird über Zertifikate und DANE sichergestellt. Für die Transportverschlüsselung wird ein zufälliger Schlüssel ausgehandelt. Alle Schlüssel oder Zertifikate sind dem Emailserver oder der Organisation zuzuordnen, nicht einzelnen Benutzern. | Die Authentizität des Senders wird durch digitale Signatur mit dem privaten Schlüssel des Senders sichergestellt. In der Regel wird das eigentliche Dokument mit AES und einem zufälligen Schlüssel verschlüsselt, und dieser zufällige Schlüssel wird mit dem öffentlichen Schlüssel des Empfängers verschlüsselt. Dadurch kann die Nachricht nur vom Empfänger entschlüsselt werden und mit Hilfe des öffentlichen Schlüssels des Senders kann die Signatur geprüft werden. Schlüssel oder Zertifikate können Benutzern oder Organisationen zugeordnet sein. | ||
| Schlüssel zum Verschlüsseln und Signieren | Verschlüsselung optional, jedes Zertifikat akzeptiert. DKIM/ARC optional aber häufig verwendet, Schlüssel für DKIM/ARC werden im DNS veröffentlicht (aber meist ohne DNSSEC). | Zertifikate werden mittels DANE identifiziert und Schlüssel für DKIM/ARC werden im DNSSEC veröffentlicht. | Web of Trust (nicht datenschutzkonform), RFC 7929 DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP (experimentell, kaum im Einsatz), keys.openpgp.org (ca. 400.000 Schlüssel), Mailvelope Key Server, OpenPGP Web Key Directory (Draft) (noch nicht verabschiedeter Entwurf), oder manuell (oft via Website, z.B. beim BfDI). Siehe unten zu Sicherheitsaspekte beim Schlüsselmanagement für PGP. | intern mit Verzeichnisdienst (Active Directory), extern mit RFC 8162: Using Secure DNS to Associate Certificates with Domain Names for S/MIME (experimentell, kaum im Einsatz), oder manuell. |
| Sowohl bei PGP als auch S/MIME wird gerne auch Vertrauen bei der ersten Nachricht hergestellt (trust on first use). Wird dabei der Absender nicht überprüft kann aber auch ein falscher Schlüssel/Zertifikat als vertrauenswürdig eingestuft werden. | ||||
| Sind Schlüssel/Zertifikate organisationsübergreifend automatisiert beschaffbar und überprüfbar? | -- | ja | Thunderbird unterstützt keys.openpgp.org und OpenPGP Web Key Directory (Draft), aber anscheinend nicht vollautomatisch. Sollte PGP irgendwann populärer werden, dann ist zu befürchten, dass Spammer irgendwann diese Dienste nutzen und verschlüsselte Spam verschicken, die nur bei Nutzung eines Gateways (s.u.) im Spamfilter erkannt werden kann. | nur mit externem Schlüsselmanagement (RFC 8162) das ich noch nirgends im Einsatz gesehen habe. |
| Ist DNSSEC erforderlich? | nein | ja | Ausdrücklich für externes Schlüsselmanagement (RFC 7929 bzw. RFC 8162). Auch bei den anderen Ansätzen ist DNSSEC erforderlich damit ein Angreifer nicht die Schlüsselbeschaffung angreifen kann. | |
| Schlüsselwiderruf — Was passiert bei Ablauf/Widerruf eines Zertifikats/Schlüssel? | Neue Schlüssel für RFC 7672 oder DKIM/ARC werden über DNS(SEC) veröffentlicht. Bei DKIM/ARC werden die Prüfergebnisse zusammen mit der Nachricht (meist im Header) gespeichert, so dass der Ablauf/Widerruf keinen Einfluss auf gespeicherte Nachrichten hat. | Widerruf nicht möglich (es gibt keine Sperrlisten). Ablaufdatum wird meist nicht verwendet (mir ist keine Behörde bekannt, die eines verwendet, und nach meinem Verständnis verstößt das gegen CON.1.A4 im BSI Grundschutz). | Theoretisch möglich. In der Praxis selten unterstützt. Insbesondere bei Vertrauen-bei-der-ersten-Nachricht werden abgelaufene Zertifikate gerne verwirrend angezeigt. | |
| Was wird auf dem Transportweg verschlüsselt? | Im schlechtesten Fall gar nichts. | Es werden sowohl die Metadaten als auch der Inhalt einer Nachricht verschlüsselt. Die einzigen unverschlüsselten Informationen sind Namen und Fähigkeiten der beteiligten Emailserver. | Nur der Nachrichteninhalt wird verschlüsselt, nicht die Metadaten – insbesondere nicht Sender, Empfänger, und manchmal auch der Betreff. | |
| Wird das Fernmeldegeheimnis – TTDSG §3 (1) – eingehalten? | Nein | Ja | Nein | |
| Die nächsten Fragen hängen bei PGP bzw. S/MIME weniger vom Verfahren selbst als von der Verwendung eines Gateways. Wird ein Gateway verwendet, dann findet die PGP oder S/MIME Verschlüsselung nur für die externe Kommunikation statt, intern liegen die Emails dann meist unverschlüsselt vor oder werden anders verschlüsselt als mit PGP oder S/MIME. Dass ein Gateway verwendet wird, kann man von außen oft daran erkennen, dass eine Organisation nur einen einzigen PGP-Schlüssel hat und nicht für jeden Benutzer einen eigenen. Es gibt aber auch Gateways, die für jeden Mitarbeiter ein anderes Schlüsselpaar verwenden können. Für Gateways gilt dann im folgenden das gleiche wie bei einem normalen Emailanbieter mit oder ohne RFC 7672, also gelten die Aussagen links. Ohne Gateway, oder auch wenn der Anbieter mit PGP-Verschlüsselung wirbt, werden die Emails meist so gespeichert wie sie übertragen werden, dann gilt rechts. | ||||
| Normale Email, RFC 7672, oder PGP bzw. S/MIME über Gateway | PGP bzw. S/MIME auch bei der Speicherung | |||
| Wird verschlüsselt gespeichert? | Hängt vom Betreiber ab: zwischen nichts und alles jede Möglichkeit. Es gibt Anbieter, die eine Verschlüsselung der Ablage zusichern oder eingehende Mails ggfs. auch PGP-Verschlüsseln (und dann gelten die Nachteile rechts), etc.. | Ja, PGP bzw. S/MIME, evtl. zusätzliche Datenträgerverschlüsselung. Da hier die ursprüngliche Verschlüsselung/Signatur manchmal über Jahrzehnte beibehalten wird, muss diese besonders sicher sein. Möglicherweise deswegen pusht das BSI Quantenkryptographie lange bevor Quantencomputer praktikabel sind. Nur leider hilft das nicht sicherzustellen, dass Fehler der Vergangenheit korrigiert werden können. | ||
| Funktioniert eine Volltextsuche auf Mails? Wichtig um eine Auskunft nach Artikel 15 DSGVO erteilen zu können. | Wenn IMAP verwendet wird, meist ja. | funktioniert auf dem Server nur auf den unverschlüsselten Metadaten wie der Emailadresse oder dem Betreff, nicht auf dem Volltext. Wenn also nicht mit, sondern über eine Person geschrieben wird, oder eine Mail weitergeleitet wird, dann findet die Suche das nicht. Und ich habe bewusst "auf dem Server" geschrieben. Weil z.B. Proton Mail einen Suchindex in der WebApp aufbauen kann – aber das zwingt Sie auch, diese oder einen anderen speziellen Emailclient zu verwenden und aller Wahrscheinlichkeit funktioniert das dann auch nur wenn sie die zu suchende Mail auch schonmal auf diesem Computer in diesem Browser geöffnet haben. In meinen Augen keine überzeugende Lösung. Stellen Sie sich vor, sie installieren den Computer neu oder kaufen ein neues Smartphone und müssen dann alle Mails erst auf dem Client haben bevor sie suchen können. | ||
| mit Schlüsselmanagement (typisch für institutionelle Verwender) | ohne Schlüsselmanagement (typisch für kleine oder private Verwender) | |||
| Muss man als Benutzer verstehen wie Verschlüsselung funktioniert? | Nein, aber man sollte sich nach einem Anbieter umsehen, der RFC 7672 (und DKIM/ARC) verspricht. Mehr Informationen auf Emailsicherheit – der Test. Bitte nicht vergessen: beide Seiten müssen RFC 7672 unterstützen. Einige wenige Anbieter zeigen die Verwendung von RFC 7672 beim Kommunikationspartner auch direkt an, oft ohne deutlich von nur schwächerer Verschlüsselung zu unterscheiden. | Nein, aber auch kein nennenswerter Sicherheitsgewinn gegenüber RFC 7672 denn alle Schlüssel sind zentral hinterlegt. Man tauscht oder teilt im Zweifelsfall nur das Vertrauen in den Email-Administrator gegen/mit das in den Schlüssel-Administrator. Realisieren Sie lieber ein vier-Augen-Prinzip, Protokollierung, und bezahlen Sie vernünftig. | Ja, aber leider zeigen alle wissenschaftlichen Untersuchungen, dass der normale Benutzer damit überfordert ist. Von anderen Benutzbarkeitsproblemen abgesehen ist das in meinen Augen größte Problem dabei die Gefahr des Verlusts des privaten Schlüssels. Dann sind alle alten und viele neue Emails nicht mehr lesbar. Die neuen auch, weil es schwierig bis unmöglich ist, den alten öffentlichen Schlüssel zu widerrufen oder zu ersetzen. Suchen Sie nach Johnny (still) can't encrypt. Und die meisten Firmen die sagen, er kann doch, schicken Sie mindestens eine Spalte weiter nach links. | |
Sicherheitsaspekte beim Schlüsselmanagement für PGP
Dieser Abschnitt wurde am 08.11.2023 ergänzt. Die Überlegungen dazu waren ein Nebenprodukt meines Videos: Sichere Kommunikation bei Email.
Das Bundesamt für Sicherheit in der Informationstechnik (BSI) bewirbt mit E-Mail Verschlüsselung: Schlüsseltausch einfach gemacht – EasyGPG OpenPGP Web Key Directory. Leider legt es dabei wenig Wert auf Sicherheit:
- OpenPGP Web Key Directory hat eine nicht ausdrücklich genannte Abhängigkeit zu DNSSEC über den TXT-Record (Abschnitt 3.1 des Drafts, s.a. GnuPG: Web Key Directory (WKD) einrichten) und durch den zweistufigen Mechanismus openpgpkey.example.org vs. example.org. Immerhin verwenden einige Schlüsselserver DNSSEC. Unklar ist jedoch, ob das auch bei den Clients der Fall ist.
- Auf "WKD as a Service" steht, ein CNAME reiche. Dass der Server an den delegiert wird ein passendes Zertifikat haben muss, steht nicht da. Tatsächlich zeigt "gpg -v --auto-key-locate clear,wkd,nodefault --locate-key noreply@lindenberg.one" bei einem CNAME die Meldung "gpg: (further info: bad cert for 'openpgpkey.lindenberg.one': Hostname does not match the certificate)" ohne jedoch abzubrechen. Unklar ist, ob Programme wie Thunderbird dann abbrechen oder Schlüssel akzeptieren.
- Aussagen zu Caching oder Key-Validierung fehlen bei OpenPGP Web Key Directory, das Löschen eines Schlüssels ist nicht vorgesehen, man muss ihn wohl durch einen zurückgerufenen ersetzen. DSGVO-konform ist das nicht. Das BSI schreibt, der Schlüssel wird lokal im "Schlüsselbund" des Absenders gespeichert und kann zukünftig ohne Abfrage beim E-Mail Anbieter benutzt werden – im Widerspruch zu Basisanforderungen in CON.1.A4 des Grundschutz Kompendium (Edition 2023).
- Bei keys.openpgp.org, Mailvelope Key Server und OpenPGP Web Key Directory (Draft) findet die Validierung bzw. der Schlüsseltausch per Email statt – kann also nur so sicher sein, wie die zugrundeliegende SMTP-Kommunikation. SMTP-DANE oder DKIM wird leider nicht gefordert. Ein Angreifer, dem es gelingt, die Emailkommunikation zu übernehmen, kann eigene Schlüssel veröffentlichen und damit erreichen, dass Signaturen des angegriffenen Benutzers ungültig sind und der angegriffene Benutzer eingehende Mails nicht mehr lesen kann.
- Einige Anbieter erzeugen das Schlüsselpaar und kennen damit auch den privaten Schlüssel – was Missbrauch durch den Anbieter ermöglicht. Darüberhinaus kann der Betreiber des Schlüsselservers (meist der Betreiber der Emaildomäne) einen Schlüssel ändern – das würde auffallen – oder als The Additional Decryption Subkey hinzufügen und dann mitlesen – ggfs. im Rahmen staatlich veranlasster Telekommunikationsüberwachung.
- Alle Systeme machen die öffentlichen Schlüssel automatisiert abrufbar, was die Benutzerfreundlichkeit stark verbessert, aber auch Spammern ermöglicht, verschlüsselte Spam zu senden, die dann nicht vom Spamfilter erkannt werden kann.
Natürlich kann ich mich in Details irren, aber meine Email an Werner Koch zu einem Teil dieser Probleme blieb bisher unbeantwortet. Ich habe eine Schwachstellenmeldung beim BSI eingereicht. Wirklich beheben kann man die Zertifikatsprüfung, die unglückliche Suchlogik, und das Caching. Dass man dem Anbieter ausgeliefert ist, ist konzeptionell bedingt und gehört im entsprechenden Standard dargestellt. Einen Schlüsselserver muss man unter eigener Kontrolle betreiben, sonst ist man dem Betreiber ausgeliefert, und wenn man nicht auch Email selbst betreiben will, sollte man den Schlüssel auf anderem Weg auf den Schlüsselserver bringen.
Phil Zimmermann, der Erfinder von PGP, schrieb: PGP empowers people to take their privacy into their own hands. There's a growing social need for it. That's why I wrote it. Dafür reicht es leider nicht, PGP zu verwenden, man muss seinen Schlüsselserver selbst betreiben oder bei manueller Verwaltung bleiben. Aber dann wird PGP wohl weiter ein Nischendasein führen.
Die im wesentlichen unbeantworteten Anfragen
| Erstellt | Geändert | Status | Behörde | Thema |
|---|---|---|---|---|
| 24.09.2021 | 13.02.2023 | Teilweise erfolgreich | Konferenz der unabhängigen Datenschutzbehörden des Bundes und der Länder | Orientierungshilfe Emailverschlüsselung – Sichere Email beim BSI? |
| https://blog.lindenberg.one/AufsichtOhneOrientierung | ||||
| 07.02.2022 | 24.05.2022 | Eingeschlafen | Bundesamt für Sicherheit in der Informationstechnik | PGP/S/MIME vs RFC 7672 und DKIM? |
| Das BSI hat anscheinend keine (Er-)Kenntnisse, wie leider an so vielen anderen Stellen auch. Allen die hier vorbeilesen oder folgen daher zum Lesen empfohlen, vom speziellen (PGP) zum allgemeineren:https://blog.lindenberg.one/VergleichRfc7672PgpSmimehttps://blog.lindenberg.one/AufsichtOhneOrientierunghttps://blog.lindenberg.one/BundesamtUnsicherheitund natürlich freue ich mich auch über Feedback und Diskussionen. | ||||
| 13.11.2023 | 23.11.2023 | Teilweise erfolgreich | Bundesamt für Sicherheit in der Informationstechnik | Threatmodell für (Easy)GPG |
| Man hat kein Threat-Modell, aber kann es "on-the-fly" herleiten. Stimmt, so ging es mir beim Lesen der entsprechenden Dokumente auch, ich musste dauernd den Kopf schütteln. Aber in Konsequenz heißt das auch, das Verfahren ist benutzerfreundlicher aber nicht wirklich sicherer als normale Email mit RFC76272/SMTP-DANE. Sicherer als WKD und Co ist übrigens RFC 7929, aber dafür braucht es sowohl DNSSEC als auch eine Domäne die sowohl Email als auch RFC 7929 umsetzt – die großen Anbieter tun das jedenfalls nicht.Nachbessern scheint man auch nicht für erforderlich zu halten, denn es liegt ganz bestimmt nicht daran, dass ich irgendeine Guideline nicht erfüllt habe. Das ist nur die formale Ausrede. Ketzerisch darf ich vermuten, dass man als nachgeordnete Behörde des BMIs die Möglichkeiten des Staates mitzulesen nicht einschränken will.Mehr auf https://blog.lindenberg.one/VergleichRfc7672PgpSmime und für Einsteiger auf https://blog.lindenberg.one/EmailVideo. | ||||
Veröffentlicht am 25.05.2022, zuletzt geändert am 08.11.2023.
© 2022,2023 Joachim Lindenberg. Diese Seite spiegelt meine persönliche Meinung wieder. Sie stellt keine Rechtsberatung dar. Fragen Sie doch einen Anwalt der sich damit auskennt.