Please note, that the Knowledge Base isn't translated to english completely at the moment. You will still find some german texts - we are translating permanently the outstanding parts! Thank you for understanding!

Standards of E-Mail Security

		INFO & KNOWLEGDE

Nachrichtensysteme für elektronische Nachrichten beinhalteten bei ihrer Konzeptionierung keine Mechanismen um Sicherheitsziele abzudecken. Da weder X.400 noch Internet-Mail (RFC 821, 822) diese integriert haben sind diese mit späteren Erweiterungen abgedeckt worden. Um Authentizität, Integrität und Vertraulichkeit, sprich Verschlüsselung, Signatur und bestätigte Identität, in E-Mails zu integrieren gibt es einige Möglichkeiten.

Privacy Enhanced Mail

Privacy Enhancement for for Internet Electronic Mail oder Privacy Enhanced Mail (PEM) ist mit seinen Anfängen um die Mitte der 80er Jahre, der älteste entsprechende Standard und ein Pionierstandard der sich mit Verschlüsselung beschäftigt.

Neben einem ungebräuchlichen symmetrischen Schlüsselmanagement wurde schon die Verwendung von hybrider Verschlüsselung und die Verwendung eines hierarchischen Vertrauensmodells mit X.509v1 Zertifikaten bestimmt.

Da PEM älter als MIME ist, müssen die E-Mailclients die PEM eigene Syntax für die Aufteilung einer Nachricht beherrschen. Zusätzlich werden Daten mit PEM vor dem Verschlüsseln in ein 7-Bit-ASCII - Format gebracht (kanonisiert) was bei Sonderzeichen problematisch ist.

MOSS und MSP

MIME Object Security Services (MOSS) ist ein Versuch die Mängel von PEM zu beheben und verwendet MIME zur Formatierung einer Nachricht, nachdem aber weder Zertifikatsformate noch Algorithmen spezifiziert werden ist MOSS mehr ein Rahmenwerk als ein Standard.

Das Message Security Protocol (MSP) ist ein OSI-Standard und vor allem für die Verwendung mit X.400 Nachrichten, soll aber unabhängig davon sein. Spielt aber keine größere Rolle.

MailTrusT

Die MailTrusT-Spezifikation der Telesec basiert soweit als möglich auf etablierten und verbreiteten Standards. Ist anfangs zu PEM, X.509v1 und PKCS#11 („Cryptoki“), auf denen die Version 1.1 basiert, gesetzt worden, werden für die Version 2 aus 1999 insbesondere auch die PKIX-Spezifikationen und die Signatur-Interoperabilitätspezifikation des BSI zum deutschen Signaturgesetz berücksichtigt. Auf der Basis dieser Standards werden Profile definiert, die die Standards interoperabel machen.

Die Schnittstelle zwischen verschiedenen Teilnehmer-Komponenten, die auf der Basis von PEM definiert sind, ist in Version 2 im Wesentlichen unverändert geblieben. Zum schrittweisen Übergang zu MailTrusT-Nachrichten auf der Basis von S/MIME wurde ein MailTrusT-Profil für S/MIME spezifiziert.

Pretty Good Privacy

Phil Zimmermanns PGP ist streng genommen ein Dateiverschlüsselungsprogramm, war aber von Anfang an auch zum Verschlüsseln von E-Mails gedacht. War PGP anfangs eher kein Standard sondern eine Anwendung ist mittlerweile mit OpenPGP (RFC 2440) ein Standard vorhanden, der die Basis von Implementierungen wie GnuPG oder PGP bildet. Ältere Versionen von PGP sind nicht zu OpenPGP vollständig konform.

Ein wesentlicher Unterschied zwischen PGP und anderen etablierten Standards ist das Schlüsselmanagement, PGP verwendet als Vertrauensmodell das Web of Trust, schließt aber eine Hierarchie nicht aus, es existieren demnach auch PGP-Zertifizierungsstellen . Ebenso bringen Keyserver PGP etwas in Richtung Zentralität. Als Zertifikatsformat werden eigene PGP-Zertifikate verwendet. Manche kommerzielle Produkte können X.509-Schlüsselmaterial in PGP-Schlüsselmaterial migrieren.

E-Mails mit Attachments werden mit PGP/MIME als ganzes verschlüsselt, aber nicht alle Lösungen beherrschen PGP/MIME. Bei PGP-Inline wird jeder Teil einzeln verschlüsselt sodass ein Empfänger Body und Attachment einzeln entschlüsseln muss.

Secure MIME

Die SMIME Arbeitsgruppe in der IETF arbeitet am S/Mime-Standard welcher mit Mime-Mails umfangreiche Sicherheitsfeatures erlaubt.

S/Mime verwendet X.509v3 Zertifikate und verwendet die auf PKCS #7 aufbauende Cryptographic Message Syntax. Signaturen können dabei auf 2 unterschiedliche Arten erstellt und übertragen werde, als Klartext-Signatur oder als opake Signatur.

Die Klartext-Signatur besteht aus zwei Mime-Parts wobei der Erste den signierten Inhalt enthält und der Zweite ausschließlich die Signatur, mit dem Vorteil, dass E-Mailclients, die nicht S/Mime fähig den Inhalt darstellen können und lediglich die Signatur nicht interpretiert werden kann. Nachteil ist, das Virenscanner für gewöhnlich CMS bzw. S/Mime nicht kennen, und dass diese Signaturen von Virenscannern auf "falsch" konfigurierten E-Mailserver leicht "abzuschneiden" sind. Für den Empfänger ist dies nicht erkennbar, wohl aber folgendes Problem. Virenscanner auf den Rechnern der Kommunikationsteilnehmer können vor dem Versand oder beim Empfang den Klartext-Teil prüfen und eventuell auch ändern oder hinzufügen, was die vorher angebrachte Signatur natürlich ungültig macht.

Eine Opak-Signatur besteht aus einem einzigen Teil, wo Klartext und Signatur in einem einzigen CMS-Objekt zusammengefasst sind. Der Vorteil ist eine größere "Virenscannerresistenz", d.h. Virenscanner ändern die kodierten (nicht verschlüsselten) Nachrichten nicht mehr, da sie dieses Format für gewöhnlich nicht interpretieren können. Allerdings können E-Mailclients ohne S/Mime-Fähigkeit dies auch nicht mehr, bzw. in Vorschaufenstern wird dieses Objekt oft ebenfalls nicht interpretiert. Zusätzlich tritt mit diesem Format auch das Problem auf, das "malicious Code" an Virenscannern auf E-Mailserver vorbeigeschleust werden kann, ohne dass die Nachricht verschlüsselt werden muss.

Verschlüsselt und signierte Nachrichten werden mit einem "Übereinanderlegen" (Wrapping) von Signatur und Verschlüsselung realisiert. Verschlüsseln ist bei S/Mime auch ohne das Anbringen einer Signatur möglich. Zusätzlich gibt es bei S/Mime v3 die Enhanced Security Services (ESS) wie Signed Receipts, Security Labels oder Secure Mailing Lists, die mit einem Triple-Wrapping verwirklicht werden können.

S/MIME