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) Protocol. 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.
| normale Email | RFC 7672 und DKIM/ARC | Pretty Good Privacy (PGP) | S/MIME | |
|---|---|---|---|---|
| Relevante Standards (Auswahl) | RFC 5321: Simple Mail Transfer Protocol | 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), oder manuell (oft via Website, z.B. beim BfDI). | 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 | nur mit externem Schlüsselmanagement (RFC 7972 bzw. RFC 8162) das ich noch nirgends im Einsatz gesehen habe. | |
| Ist DNSSEC erforderlich? | nein | ja | ja für externes Schlüsselmanagement (RFC 7972 bzw. RFC 8162). | |
| 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 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. | |
Die im wesentlichen unbeantworteten Anfragen
| Erstellt | Geändert | Status | Behörde | Thema |
|---|
Veröffentlicht am 25.05.2022
© 2022 Joachim Lindenberg. Diese Seite spiegelt meine persönliche Meinung wieder. Sie stellt keine Rechtsberatung dar. Fragen Sie doch einen Anwalt der sich damit auskennt.