Zukunftsfähigkeit von PGP und S/MIME

Sicherheit
21

Wenn Du bei jeder Meldung von Signal, der Kontakt hat geänderte Schlüssel (Erläuterung von Signal: hat sehr wahrscheinlich ein neues Telefon) diese erneut auf einem unabhängigem Kanal prüfst, dann und nur dann ist Signal m.E. sicherer als PGP mit vertrauenswürdigen (geprüften) Schlüsseln. Und wer macht das schon konsequent?
Wenn Du weder bei PGP noch Signal den Schlüssel prüfst sind die natürlich beide unsicher.
Ansonsten würde mich Deine Liste der Bereiche/Kriterien interessieren. Insbesondere würde ich ein zentrales System dezentralen Systemen regelmäßig als unterlegen einstufen. Und ja, ich kenne Marlinspikes Grund „Innovation“ für zentrale Systeme.

SMTP-DANE erlaubt eine Authentifizierung der Emailserver die nur von aktiven Angreifern überwunden werden kann, die entweder Deinen DNS-Anbieter oder Deine CA kompromittieren können. Und das ohne Mitwirkung der Benutzer, die mit Schlüsselmanagement regelmäßig überfordert sind.

Threema hab ich nicht im Einsatz und daher nicht angesehen. Auch ich richte mich letztendlich danach, wo die Leute sind, mit denen ich kommunizieren will.

22

Dass so etwas wie PGP überhaupt auf eine Stufe mit Signal gestellt wird verstehe ich nicht. Das Signal-Protokoll ist wohl eines der renommiertesten Protokolle für verschlüsselte Kommunikation. PGP und E-Mails mit PGP werden dagegen von renommierten Forschern im Bereich Kryptographie schon seit vielen Jahren kritisiert:

2 „Gefällt mir“
23

Ich verstehe es hier nicht so, dass Signal mit PGP auf eine Stufe gestellt wird und werden kann, da Mail und Messenger doch recht unterschiedlich sind und vom Prinzip ihre Vor- und Nachteile haben.
Offenes vs geschlossenes System.
Der größte Vorteil der Mail ist die universelle Anwendbarkeit. Der größte Vorteil eines geschlossenen Systems, ist die Umsetzung der Verschlüsselung. Aufgrund des bei beiden nötigen Schlüsselmanagements sieht man, das PGP bei Mail bei Beibehaltung der Offenheit in der Praxis schlecht funktioniert mit leichten Vorteil bei S/MIME, aber immerhin hat sich heutzutage ein verschlüsselter Transport durchgesetzt.
Bei geschlossenen Systemen kann das Schlüsselmanagement besser gehändelt werden, nicht nur bei Mail (z.B Proton oder Tuta), sondern auch bei Messenger wie Threema und Signal.
Einer der größten Probleme ist allerdings, die Sicherheit zu wissen, ob mein Kommunikationspartner auch wirklich der ist mit dem ich zu sprechen meine. Bei Signal müsste ich jedesmal über einen anderen sicheren Kanal mich rückversichern, ob bei einer geänderten Sicherheitsnummer mein Gesprächspartner immer noch derselbe ist. Bei Mail mit SMTP-DANE kann ich davon ausgehen und meine Mail wurde verschlüsselt transportiert (und mit zusätzlich PGP, S/MIME sogar verschlüsselt).

1 „Gefällt mir“
24

Wird mit SMTP-DANE nicht nur der SMTP-Server zu der Domain eines Kommunikationspartners authentisiert? Eine Aussage über die Identität des Kommunikationspartners lässt SMTP-DANE doch IMHO selbst gar nicht zu.

Für diesen Schritt muss doch weiterhin auf S/MIME Zertifikate oder PGP-Schlüsselvergleiche zurückgreifen und damit hat hier wieder dieselbe Herausforderung an den Benutzer wie auch bei Signal.

Habe ich hier einen Denkfehler?

Oder geht Ihr bei der Argumentation Pro SMTP-DANE vs. PGP davon aus, dass bei den Mail-Serverbetreibern einfach keine Identitätsübernahme möglich ist?

25

PGP hat einige Fehler die man korrigieren könnte, allerdings nur wenn man sowohl Benutzern beibringt, mit Schlüsseln umzugehen, als auch ein benutzbares, vertrauenswürdiges, skalierendes Schlüsselmanagement realisiert.

Richtig ist bei PGP (und S/MIME) immerhin, dass der Schlüssel (aka Authentifizierung) an eine Person oder Organisation und nicht an eine Kombination von Geräten wie bei WhatsApp oder Signal gebunden ist - das ist einfach konzeptioneller Murks. Und kann man nicht korrigieren ohne genau die gleichen Probleme wie bei PGP zu lösen (oder gleich X.509 Zertifikate wie bei S/MIME verwenden).

Mal und Messenger unterscheiden sich m.E. in drei Punkten:
a) Messenger organisieren das UI nach Kontakten/Gruppen/Räumen statt nach Threads (wie auch immer organisiert)
b) die meisten Messenger sind geschlossene Systeme (Ausnahme Matrix), wie wenn ich bei Email nur Nachrichten zum gleichen Anbieter schicken könnte.
c) Messenger löschen Nachrichten nach der Übermittlung, Email nicht (war früher aber üblich).
Die Probleme mit Identifikation/Authentifizierung/Schlüsselmanagement sind m.E. absolut identisch, nur dass die Messenger das Problem ungeeignet lösen um es benutzbar zu bekommen.

richtig, aber von Wegwerf-Email-Anbietern abgesehen authentifiziert jeder Emailbetreiber seine Nutzer. Damit kannst Du davon ausgehen, dass eine DKIM-signierte Email in aller Regel aus dem entsprechenden Postfach stammt und bei SMTP-DANE auch immer beim richtigen Empfänger landet (Ausnahme potenter Angreifer auf DNSSEC oder CA).

Nachtrag:

klar, Dumme finden sich immer wieder. Beispiel auch in meinem Artikel in DuD 11/2024 (gute Bibliotheken haben die). Wer das Konto übernehmen kann, kann aber auch bei allen üblichen Schlüsselservern für PGP neue Schlüssel hinterlegen und damit zumindest Chaos stiften.

26

Vielen Dank für eure aktive Teilnahme an diesem Thread!

Ich habe für mich entschieden, dass PGP und S/MIME in ihrer aktuellen Form sowie angesichts der Bestrebungen von Unternehmen, Behörden und Regierungen keine zukunftsfähige Lösung darstellen. E2EE wird aus den von euch mehrfach genannten Gründen kein massentaugliches Produkt bleiben.

Eine zentrale Anlaufstelle, bei der man kostenlos ein Zertifikat erhält, verifiziert wird und bei der alle Aktualisierungen zentral verwaltet werden, wäre ein sinnvoller Ansatz. Diese Datensätze könnten von E-Mail-Anbietern automatisch abgefragt werden, sobald die Mailadresse des Empfängers im Mailclient eingegeben wird. Eine Organisation bei der mehrere wichtige Akteure sich ähnlich wie Let’s Encrypt zusammenschließen, wäre hier ein ideales Modell.

Leider halte ich es für unwahrscheinlich, dass so etwas realisiert wird – einfach, weil das Thema für die entscheidenden Akteure keinen hohen Stellenwert hat.

1 „Gefällt mir“
27

Solche Dinge wären etwas für die EU.

28

Sollte es der Vollständigkeit halber nicht besser GAFAX heißen? Schließlich gehört Elon auch zum Club of Transhumanism.

29

Gibt es eigentlich nennenswerte Unterschiede zwischen PGP und S/MIME bezüglich des praktischen Einsatzes?
Also konkret ist es so, dass für meinen beruflichen Email-Account ein S/MIME-Zertifikat beantragen (erst jetzt entdeckt), aber ich hatte schon vor ein paar Monaten ein PGP-Zertifikat in TB erstellt. Bringt es mir etwas jetzt auf S/MIME umzusteigen? Meint ihr es ist vielleicht einfacher dann die anderen Nutzer zu S/MIME zu motivieren? Ich habe nämlich leider beruflich noch keine einzige verschlüsselte Email schreiben können…

30

Ich zitiere mich mal selbst, weil es hier wirklich gut erklärt ist:

31

warum umsteigen? Du kannst doch beides machen. (Nicht in einer Mail :sunglasses:)

32

Im beruflichen Kontext wird zumeist S/MIME genutzt. Im akademischen und privaten Umfeld eher PGP. Mit geeigneten E-Mail-Clients kann man aber beide Verfahren nebeneinander benutzen.

Die Frage ist somit vor allem, was unterstützen Deine Kommunikationspartner? Leider lautet die Antwort zumeist - weder S/MIME noch PGP.

Wenn Du jedoch Kommunikationspartner hast die E-Mail-Verschlüsselung unterstützen, nutze einfach das Verfahren wo Ihr gemeinsam einen Mehrwert erreichen könnt.

1 „Gefällt mir“
33

@nudel Achso, das geht? Das wäre natürlich eine Option.
Weiß jemand wie ich das in Thunderbird handhabe? Also die PGP-Verwaltung klappt ja schon und für die S/MIME-Einrichtung gibt es einen Leitfaden, aber wie wähle ich dann für die Emails ein Verfahren aus?

34

Für mich ist es überhaupt einer der Schwachpunkte von PGP, dass es überhaupt keine Infrastruktur für die Überprüfung von PGP-Schlüsseln gibt und dass die Anforderungen dafür, dass ein Schlüssel als vertrauenswürdig gilt, zu hoch sind.

Seit einiger Zeit hat jeder Bürger in Deutschland die Möglichkeit, seinen PGP-Schlüssel mit Hilfe der Ausweisapp signieren zu lassen. Ich habe das mal gemacht - es hat aber keine Konsequenzen, meine PGP-Signatur wird überall als nicht vertrauenswürdig angezeigt. Der Umstand, dass mein Schlüssel erst signiert wurde, nachdem ich mich mit dem e-Perso authentifiziert habe, sollte für ein hinreichendes Vertrauensniveau sorgen, dass ein von der Fa. Governikus signierter Schlüssel als vertrauenswürdig (und zwar nicht in gelb, sondern in grün) dargestellt wird.

Alle TLS-Implementierungen kommen mit einer Liste von vertrauenswürdigen CAs, deren Signaturen immer vertraut wird. Das fehlt bei PGP völlig. Statt dessen gehen PGP-Entwickler von der völlig unrealistischen Annahme aus, dass es dem Anwender zuzumuten ist, einen öffentlichen Schlüssel nicht über das Internet, sondern auf einem Datenträger persönlich entgegennimmt und dann selbst signiert. Dieser völlig überzogene Ansatz bei der Überprüfung von Signaturen sorgt dafür, dass PGP in seiner gegenwärtigen Form keine Chance hat.

35

S/MIME nutzt das Vertrauensmodell der stellvertretenden CAs, die Prüfungen von Schlüsseln durchführen und die Mailprogramme der Kommunikationspartner Deinem Key aufgrund der Signatur der CA im Zertifikat automatisch vertraut wird.

PGP hat ein anderes Konzept, bei dem die Kommunikationspartner standardmäßig ihre Schlüssel gegenseitig durch Prüfung des Fingerprints des Schlüssels verifizieren und diese von Ihnen durchgeführte Prüfung dann das Vertrauen in ihrem Schlüsselbund verzeichnen.

Aus diesem Grund hat die Signatur durch Governikus keine direkte Auswirkung auf die Vertrauenswürdigkeit Deines Schlüssels bei Deinen Kommunikationspartnern. Für das PGP Deines Kommunikationspartners ist die Signatur von Governikus erst einmal nichts anderes als die Signatur einer beliebigen, anderen Person und weder mehr noch weniger vertrauenswürdig.

Dein Kommunikationspartner kann aber die Signatur von Governikus dazu nutzen, für sich selber zu entscheiden, dass er Deinem Schlüssel auch ohne Fingerprint-Vergleich das Vertrauen in seinem Schlüsselbund ausspricht. Es ist aber weiterhin ein manueller Vorgang.

Welches Verfahren jetzt der bessere Ansatz ist hängt von Deinem Blickwinkel ab. Die Nutzung von CAs lagern die Prüfaufwände in die Hand von Firmen / Organisationen aus. Die eigenständige Prüfung ist aufwendiger für die Nutzer, aber dafür vertrauenswürdiger, da man selbst die Prüfung vorgenommen hat.

36

Ein Verfahren, das ausschließlich auf manuelle Prüfung setzt, ist, von wenigen Sonderfällen abgesehen, nicht praktikabel und weitgehend nutzlos. Oder soll ich, wenn ich im Rahmen der Überprüfung einer ISO-Datei mal eben schnell ins Flugzeug steigen und mir von demjenigen in Übersee, der die sha256sum.txt signiert hat, den öffentlichen Schlüssel auf einem Datenträger persönlich aushändigen lassen? Das ist doch schlicht und ergreifend Blödsinn.

37

Das Konzept von PGP ist nun einmal ohne Vertrauensauslagerung an CAs entwickelt worden.

Du kannst persönlich für Dich ja entscheiden, ab wann Du einem Schlüssel vertraust. Ob Du dafür den Download des Schlüssels von einer https-gesicherten Webseite, durch telefonischen Schlüsselvergleich oder auch einfach nur basierend auf „Trust on first use“ sein.

Was praktikabel ist bestimmt jeder selbst. Als Schlüsseleigner hast Du darauf aber keinen Einfluss.

38

Nein, auch die Kommunikationspartner. Ich weigere mich, PGP einzusetzen - manuell Schlüssel abgleichen ist Unsinn, die Keyserver auch mangels Authentifizierung. S/MIME würde ich ggfs. einsetzen, aber es gibt eben keine kostenlosen Zertifikate wie bei PGP. Ergo ist beides im privaten Bereich tot, und im Organisationsbereich ebenso, weil dort MUSS ich die Schlüssel sowieso hinterlegen.

39

Unsinn ist es nicht, es ist eben nur sehr aufwendig.

Auch das Verständnis darüber was die Rolle der Keyserver in PGP angeht ist IMHO häufig falsch.

Es ging bei diesen nicht primär darum, bisher unbekannte Schlüssel zu E-Mail-Adressen zu suchen (was aufgrund der fehlenden Authentisierung beim Einstellen der Schlüssel blödsinn ist), sondern um die Verteilung der Web-of-Trust-Signaturen und vor allem den Schlüssel-Widerruf bei Kompromitierung bzw. das Außerdienst stellen eines Schlüssels.

Wenn man überhaupt mir PGP arbeiten will, funktioniert dieses aus meiner Sicht nur sinnvoll durch

(-) Mitsenden des öffentlichen Schlüssels zu jeder E-Mail und ggf. ergänzende Bereitstellung im DNS oder auf einer Webseite.

(-) Empfang des Schlüssels anderer und Entscheidung ob man diesen in seinen Schlüsselbund übernimmt und auf welchem Weg man dem Schlüssel sein Vertrauen ausspricht.

Wenn man den Schlüssel ohne Prüfung und eigene Signatur übernimmt, dann sollte der eigene E-Mail-Client einen auf die fehlende Schlüsselprüfung bei jeder neuen E-Mail hinweisen. Der Einsatz eines solchen Schlüssels erhöht also nicht zwingend die Vertraulichkeit E-Mail, aber verringert diese eben auch nicht. Maximal kann bei Verwendung eines falschen Schlüssel der Empfänger die E-Mail nicht einsehen.

Wenn man hingegen den Fingerprint verglichen hat und dann den Schlüssel in seinem Schlüsselbund signiert hat, dann ist das Verfahren gleichwertig oder sogar höher als der Einsatz von S/MIME mit einer von einer Zertifizierungsinstanz geprüften Schlüssel.

(Am Besten durch Fingerprintvergleich zum Beispiel bei einem persönlichen Treffen, am Telefon. Aber auch die Einschätzung anhand bestehender anderer Signaturen wie z. B. von Governikus kann für einen persönlich sinnvoll sein.)

(-) Regelmäßige Aktualisierung der Schlüssel aus den Keyservern um Widerrufe mitzubekommen.

Aber PGP und S/MIME sind trotzdem effektiv für den Masseneinsatz gescheitert, da die Aufwände für die Anwender zum Schlüsselverwaltung, Synchronisation über mehrere Geräte, Auswahl oder ggf. Erweiterung der PGP-Unterstützung der E-Mail-Clients einfach zu hoch sind.

Auch können weder PGP noch S/MIME eine Ende-zu-Ende-Verschlüsselung für den Absender garantieren, da die Frage ob die E-Mail erst beim E-Mail-Client des Empfängers oder auf einem vorgelagerten Gateway entschlüsselt wird, für den Absender nicht erkennbar ist. Firmen nutzen eben häufig Gateway-Lösungen, bei denen dann die E-Mails zu den internen Mailservern unterschlüsselt zugestellt werden, um Stellvertretungsregelungen zu ermöglichen oder auch E-Mails auf Malware und/oder Spam zu untersuchen.

1 „Gefällt mir“
40

Genau das, was Du als Blödsinn bezeichnest, macht m.W. Thunderbird und gpg ohne Rückfrage.

Schlüssel über den gleichen (unsicheren) Kanal zu schicken verbessert die Sicherheit nicht.