S/Mime oder PGP

Von der Seite Verschlüsseln und Signieren ist die Verschlüsselung mit symmetrischen und asymmetrischen Verfahren bekannt, aber trotzdem gibt es noch viele Feinheiten in der Art der Codierung. DES, 3DES, MD5, SHA1 und andere Begriffe fallen hier. Aber viel schlimmer ist, dass es zwei quasi Standards gibt:

  • S/MIME
    Ein RFC-Standard, mit der u.a. das Format der Mail und die verwendeten Verfahren zur Signatur und Verschlüsselung beschrieben wurde.
  • PGP - Pretty Good Privacy
    Der urahn aller Programme zur Signierung und Verschlüsselung von Mails

Auch wenn es zwei Verfahren gibt, so hat nach meiner Einschätzung S/MIME die Nase vorne. Zwar sind dazu Zertifikate erforderlich, aber jedes moderne Mailsystem kann ohne Installation weiterer Plug-ins damit arbeiten. Selbst PGP unterstützt ebenfalls SMIME.

Doch schauen wir uns die beiden Optionen genauer an:

S/MIME

SMTP ist sehr viel älter als S/MIME. S/MIME ist eine Erweiterung der MIME-Spezifikation um die Definition zur Verschlüsselung und Signierung. primär ist S/MIME also eine Formatbeschreibung, wie eine signierte oder verschlüsselte Mail auszusehen hat. Da eine Mail sei je her aus den Bestandteilen Envelope, Header und Body besteht (Siehe auch Envelope und Header und SMTP Grundlagen), muss eine entsprechende Erweiterung auch rückwärtskompatibel sein. Aber es ist schon einige Jahre her, dass eine Mail nur aus einem "Textbody" bestand und Anlagen in dem Text als UUNECODE-Block eingebettet waren.

MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="msxfaq"

This is a message with multiple parts in MIME format.
--msxfaq
Content-Type: text/plain

Dies ist der Textbody der Mail.

--msxfaq
Content-Type: text/html

<html>
<head></head>
<body><p>Dies ist der HTML-body der Mail.</p></body>
</html>

--msxfaq
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64

ABCABC  Hier koennte eine BASE64 codierte Anwendung angehaengt sein ABC
--msxfaq--

Eine signierte Mail sieht dann reicht einfach aus.

MIME-Version: 1.0
Content-Type: multipart/signed;
	protocol="application/x-pkcs7-signature";
	micalg=SHA1;
	boundary="----=_NextPart_000_0061_01CA8E2C.B0385EF0"

This is a multi-part message in MIME format.

------=_NextPart_000_0061_01CA8E2C.B0385EF0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Testbody


------=_NextPart_000_0061_01CA8E2C.B0385EF0
Content-Type: application/x-pkcs7-signature;
	name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename="smime.p7s"

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMgDCCA1ww
......
cyDdy4enMHykUHApaPkbKzqQPtO8ds1Fg0o1xeftv7pkyP1QkEOAGNUX7m1TDAqcA0fLErwe1hlJ
GFpC1MMR7Vi5fGwOKqMUzQAAAAAAAA==

------=_NextPart_000_0061_01CA8E2C.B0385EF0--

Sie sehen, dass es sich um eine TEXT-Mail handelt, die mit SHA1 signiert wurde. Die Signatur selbst ist BASE64 encodiert und habe ich zur Lesbarkeit verkürzt.

S/MIME ist einfach eine MIME Erweiterung, bei der die Mail selbst in einem Block eingefasst wird, welcher diesen Teil als "signiert" betrachtet. Ein weiterer Block enthält das Zertifikat usw. Ein entsprechender Client, der MIME und S/MIME versteht, kann direkt ohne Zusatzsoftware oder Drittprodukte diese Mails empfangen, die Signatur überprüfen, gegebenenfalls entschlüsseln und anzeigen. Dazu zählen unter anderem:

Die Liste der Programme die von Hause aus S/MIME unterstützen ist deutlich länger als der direkt PGP-Support (Cyrusoft Mulberry). Im Gegensatz zu PGP nutzt S/MIME immer "richtige" Zertifikaten.. Jeder Teilnehmer muss daher ein Zertifikat besitzen und installieren. Das Zertifikat ist nichts anderes als der öffentliche Schlüssel, welcher von einer CA (Certificate Authority) unterschrieben worden ist. Es ist allerdings nicht zwingend vorgeschrieben, dass Sie sich ein offizielles Zertifikat "kaufen" müssen. Auch hier könnten Sie sich selbst ein Zertifikat errechnen. Der Empfänger wird aber eine Warnung erhalten, bis her ihrem Zertifikat oder der ausstellenden CA vertraut.

S/MIME ist ein etablierter Standard, welcher die sichere Übertragung von Nachrichten über SMTP erlaubt. Normalerweise handelt es sich dabei um eine Client zu Client Verschlüsselung, d.h. die Programme der Anwender verschlüsseln die Daten und senden diese über die Mailsysteme. Exchange sieht wie jedes andere Mailprogramm nur die codierten Nachrichten, d.h. eine gültige Mail mit Absender und Empfänger aber dann nur noch Sonderzeichen. Allerdings gibt es auch Gateways, die das Verschlüsseln und Signieren dem Client abnehmen und z.B. an der Schnittstelle zwischen Internet und eigenem Mailserver arbeiten.

PGP

PGP ist ein Akronym für gleich drei Dinge:

  • Software
    PGP ist der Kurzbegriff für "Pretty good Privacy" und ist eines der ersten bekannten Programme, um Daten und Nachrichten sicher zu verschlüsseln. Der Autor Phil Zimmermann entwickelte damals das Programm auf Basis des RSA-Algorithmus. Die Anfänge der Programms waren komplett kommandozeilengesteuert und dienten dazu Dateien zu verschlüsseln. Die aktuelle Version integriert sich in die verschiedenen Mailprogramme und bietet auch eine virtuelle verschlüsselte Festplatte an. Nachrichten werden im Mailbody verschlüsselt oder z.B.: über die Zwischenablage umgewandelt.
    Mittlerweile integriert sich PGP in die verschiedensten Mailprogramme, zu denen auch Outlook und Outlook Express gehört. Der Exchange Server ist völlig unbelastet von PGP, da er nur Nachrichten überträgt ohne auf den Inhalt zu achten. Dass diese Nachrichten einen signierten oder verschlüsselten Mailbody haben, interessiert Exchange nicht. Wichtig ist darauf zu achten, dass die Nachrichten im Ordner "gesendete Objekte" auch von dem Absender nicht mehr zu lesen sind, wenn diese nur mit dem öffentlichen Schlüssel des Empfängers verschlüsselt wurden. Der einzige Schlüssel für den Zugriff ist der geheime Key des Empfängers.
  • Formatbeschreibung
    Lange vor S/MIME musste PGP auch ein Format beschreiben, wie signierte und verschlüsselte Mails über vorhandene Wege übertragen werden können. Ohne MIME wurde also die Mail allein im Body entsprechend gekennzeichnet. Dabei werden die Nachrichten mit einem Kopf versehen, anhand diesem PGP die Nachricht wieder erkennt. Teilweise sieht man das heute noch in Mails, hier ein Beispiel einer signierten Mail von win-sec-ssc:

    Sie sehen in der Mail am Anfang das "----BEGIN PGP SIGNED MESSAGE------" und die anderen Kennzeichnungen.
    Selbst Microsoft nutzt für die Signierung seiner Security Newsletter PGP, was ich so leider gar nicht verstehen kann. Nicht dass ich was gegen PGP hätte aber die Überprüfbarkeit wäre sicher deutlich breiter, wenn SMIME genutzt würde:
  • Schlüssel
    Als PGP populär wurde, gab es noch keine richtig Infrastruktur mit Zertifizierungsstellen etc. Es fehlten auch Spezifikationen und ein Stück weit wollten die Anwender einfach nur ihre Mails "sichern" ohne gleich Geld zu investieren. Das originale PGP arbeitete daher dezentral, d.h. es gab erst einmal keine zentral ausgestellten Zertifikate, sondern jeder Teilnehmer hat sich selbst ein Schlüsselpaar (Private und Public Key errechnet und selbst unterschrieben. Ein klassisches Selbstzertifikat.
    Die Schlüsselverwaltung basiert auf einer dezentralen Struktur, bei der Teilnehmer untereinander die öffentlichen Schlüssel der anderen Personen in einem Schlüsselbund sammeln. Dabei kann ein Teilnehmer seine gesammelten Schlüssel an andere Personen geben und wenn diese dem Absender vertrauen, kommen sie so auch an ausreichend zuverlässige Schlüssel anderer Personen. Es bildet sich ein Ring des Vertrauens ("Ring of Trust"). Einige Personen stellen ihren Schlüssel auch öffentlich z.B.: über eine Webseite oder einen Schlüsselserver bereit. Um hier eine Fälschung zu vermeiden, sind diese Schlüssel von einer bekannten Stelle signiert. Mittlerweile gibt es aber auch hier Keyserver.

Insofern war PGP in der Anfangszeit des Mailverkehr eine effektive und sichere Möglichkeit, Nachrichten ohne zentrale Stelle (CA) zu signieren und zu verschlüsseln. Dies wäre aber per S/MIME und Selbstzertifikaten heute natürlich genau so möglich.

Weitere Informationen hierzu erhalten Sie z.B. bei:

OpenPGP vs LibrePGP und Crypto Refresh

Die Definition von "PGP" liegt nicht in der Hand einer Person oder Firma, sondern ist eine kooperative Arbeit mehrerer Personen bei unterschiedlichen Firmen oder Privat. Wie so oft bei "Open Source" gehen die Meinungen auch einmal auseinander. Im schlimmsten Fall kommt es zu einem Bruch und einem "Fork", d.h. ein Projekt teil sich. Wir kennen das auch von vielen anderen Projekten.

ownCloud   vs. Nextcloud
OpenOffice vs. LibreOffice
OpenWrt    vs. LEDE
nagios     vs. icinga

Manche Projekte finden wieder zusammen während andere Projekt parallel sich weiter entwickeln und jeder seine Fan-Gemeinde pflegt. Problematisch wird es, wenn Inkompatibilitäten entstehen, weil eigene Erweiterungen von anderen Produkten nicht verstanden werden. Die PGP-Definitionen wurden als RFC veröffentlicht, aber die Entwicklung geht weiter:

Aber die Entwicklung bleibt nicht stehen, war gerade bei Verschlüsselung und Signierung natürlich wichtig ist, z.B. um alte Verfahren als obsolet zu kennzeichnen oder neue Verfahren zu ergänzen

Um 2023/2024 wurde ein "Crypto Refresh" angedacht, der insbesondere neuer Verfahren optional ergänzen sollte aber sehr schnell zu einer hitzigen Diskussion führte, wer das nun zu entscheiden hat. Zumal die verschiedenen Teams dies unterschiedliche implementiert hätten.

Ich bin nu nicht nahe genug an diesen Teams dran, um alle Feinheiten zu verstehen und zitiere daher nur einen Ausschnitt aus einer Diskussion, die die Problematik vermutlich gut auf den Punkt bringt.

Not to be pedantic but that's not how the history went.

First there was PGP (the product), then that was turned into a standard (RFC2440, "OpenPGP Message Format"), and GnuPG implemented that.

Then, some (backwards-compatible) changes to the OpenPGP standard were proposed, and every implementation implemented them. (These were specified in RFC4880.)

Then, some (backwards-compatible) changes to the OpenPGP standard were proposed, and many implementations implemented them. (They never ended up in an RFC, but are now dubbed "LibrePGP".)

Then, some more (again backwards-compatible) changes were proposed, and many implementations implemented them, but not GnuPG, for now. (This is the crypto refresh. It should become an RFC soon.) It's a shame GnuPG doesn't want to implement the crypto refresh at this time, but that shouldn't cause incompatibilities (if all implementations are conservative in what they generate).

Messages sent between GnuPG and other implementations can still use RFC4880 (the old OpenPGP standard), they just won't benefit from the improvements in the crypto refresh, unfortunately.
Quelle: https://news.ycombinator.com/item?id=38554393

Anscheinend haben verschiedene PGP-Libraries die Neuerungen schon implementiert aber die Maintainer von GnuPG waren mit den Änderungen nicht einverstanden und haben diese noch nicht umgesetzt. Ob das alles genauso ist, kann ich nicht bewerten. Vielleicht ist der Konflikt schon lange gelöst, wenn Sie diese Zeilen einige Monate später lesen.

Anhänge mit Kennwort schützen

Unabhängig von den beiden Verfahren gibt es eine einfache Lösung, schnell zumindest Anlagen zu sichern. Sie können z.B. mit Office mit Hilfe der integrierten Kennworte die Dokumente schützen. Allerdings ist der Schutz nicht sonderlich hoch und gerade bei älteren Versionen leicht zu knacken. Alternativ können die Dateien sehr effektiv mit einem Komprimierungstool gepackt und dabei auch direkt mit einem Kennwort versehen werden. Wird solch eine Datei als Anlage einer Mail versandt, ist der einfache Zugriff schon erschwert, sofern das Kennwort nicht gerade in der Email beschrieben wird. In der Mail selbst steht dann z.B. nur, dass die eigentliche Information in der mit Kennwort versehenen Anlage zu finden ist.

Beide Versionen sind symmetrische Verschlüsslungen, welche den Austausch des Kennworts zwischen den Anwendern erfordern und zudem ein Mehr an Arbeit beim Versenden bedeuten. Wie Sie dann aber das Kennwort übertragen (Telefonanruf etc.) bleibt ihr Geheimnis. Ebenso schützt dieses Verfahren nicht gegen die Fälschung von Absendern.

Digital Rights Management / Rights Management Server

Oft geht allein das sichere Übertragen von Nachrichten nicht weit genug. Es kann durchaus sein, dass damit zwar der Weg bis zum Empfänger gesichert ist, aber als Absender haben Sie keine Kontrolle darüber, wie der Empfänger mit der Information umgeht. Oft wird gefordert, dass überlassene Dokumente nicht nur sicher übertragen werden, sondern auch beim Empfänger weiteren Einschränkungen unterliegen z.B.: das dieser das Dokument nicht weiterleiten oder drucken kann. Solche Anforderungen gehen über S/MIME aber auch PGP hinaus. Und sind eine Aufgabe wie den Rights Management Server

Weitere Links