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!

S/MIME

		INFO & KNOWLEGDE

Von der RSA initiiert baut S/MIME auf MIME und das klassische Internet - Mail auf, mittlerweile übernimmt die Standardisierungsarbeit aber die SMIME Arbeitsgruppe in der IETF. Die aktuelle Version ist die Version 3 (RFCs 2630 - 2634 und 3369) wobei die meisten Mailclients Version 3 wenn, dann nur zum Teil, umsetzen.

S/MIME baut auf den E-Mailstandards RFC 822 und MIME (RFC-2045-2049) auf. Es spezifiziert zusätzliche MIME Typen für Verschlüsselung und Signatur und verwendet die auf PKCS #7 aufbauende Cryptographic Message Syntax (CMS), die in der ASN.1 Notation beschrieben ist. Header-Dateien werden dabei natürlich nicht verschlüsselt oder signiert - d.h. Betreffs sind weiterhin für jedermann im Klartext lesbar.

Eine MIME-Einheit wird in ein base64 kodiertes CMS-Objekt eingepackt (wrapped), wobei das CMS-Objekt verschlüsselt oder signiert sein kann - nicht beides auf einmal - der Content-Typ ist application/pkcs7-mime und der "smime-type"-Parameter bestimmt ob das Objekt signiert oder verschlüsselt ist.

Die E-Mail kann auch einen Teil in Klartext enthalten. In diesem Fall ist das CMS Objekt in einen mulitpart/signed Inhalt eingebettet, wobei die Signatur dann den Content-Typ application/pkcs7-signature enthält, da diese Nachricht eine Klartext-Signatur darstellt. Signaturen können bei S/Mime auf 2 unterschiedliche Arten erstellt und übertragen werde, eben als diese Klartext-Signatur oder als opake Signatur, wie im obigen Absatz beschrieben.

S/MIME definiert gemäß PKCS #7 auch ein Nachrichtenformat, das ausschließlich Zertifikate beinhaltet - application/pkcs7-mime, smime-type: certs-only

Klartext Signatur

Eine Signatur besteht im Allgemeinen aus dem Zertifikat des Absenders (am besten inklusive Zertifikatskette), dem Signaturalgorithmus - Identifier, und dem verschlüsselten Hash-Wert.

Wie schon beschrieben, besteht eine Nachricht mit Klartext-Signatur (clear signed message) aus 2 Teilen, wobei der Erste die Klartextteile beinhaltet und der Zweite die Signatur als base64 kodiertes CMS-Objekt.

Vorteil: Mailclients, die nicht S/MIME fähig sind können die Klartextteile ohne Probleme darstellen, während die Signatur als smime.p7s Anhang angezeigt wird und nicht interpretiert wird. Virenscanner können die Klartext-Teile problemlos auf "Malicious Code" hin scannen.

Nachteil: Virenscanner können den Klartextteil auch (unbeabsichtigt) ändern - die Signatur wird ungültig. Auch kann es passieren, das ein "falsch konfigurierter" Virenscanner auf einem Mailserver das CMS-Objekt, sprich die Signatur, von der Mail abschneidet, was für den Empfänger nicht mehr ersichtlich ist.

Opak Signatur

Eine Opak-Signatur besteht aus einem einzigen base64 kodierten CMS-Objekt, der den signierten Inhalt und die Signatur beinhaltet, dadurch ist die Nachricht von Menschen nicht mehr lesbar, aber NICHT verschlüsselt.

Vorteil: Dadurch kann eine größere "Virenscannerresistenz" erreicht werden, da Virenscanner base64 kodierte CMS-Objekte für gewöhnlich nicht interpretieren können.

Nachteil: Auch Mailclients ohne S/MIME Fähigkeit können dies nicht und zeigen in diesem Fall nur ein Attachment mit Namen smime.p7m an. Selbst wenn der Mailclient S/MIME unterstützt, werden solche Nachrichten oft nicht in Vorschaufenstern angezeigt. "Malicous Code" kann mit diesem Format an Virenscannern auf Mailservern vorbeigeschleust werden, ohne dass die Nachricht verschlüsselt werden muss. Auch wenn Mailverschlüsselung in der Security-Policy eines Unternehmens Mailverschlüsselung aus diesem Grund verbietet, ist der Empfang von signierten Nachrichten vom solchen Typs nicht verboten, ein mehrstufiger Mailvirenschutz wird so reduziert. (Opak) signierte Virenmails sind aber noch nicht aufgetaucht.

Verschlüsselung

S/MIME verschlüsselt über ein Hybridverfahren, eine Nachricht enthält also den symmetrisch verschlüsselten Text, dazu den asymmetrisch verschlüsselten DEK (Data Encryption Key). Dieser ist gemäß der asymmetrischen Verschlüsselung mit dem öffentlichen Schlüssel des Empfängers verschlüsselt. Eine verschlüsselte Nachricht ohne Signatur ist möglich.

Damit auch der Absender authentifiziert werden kann ist zusätzlich eine Signierung sinnvoll. Das MIME-Objekt Signierung und Verschlüsselung werden dabei nacheinander angewendet (double wrapping). Die Reihenfolge ist beliebig, dennoch sollte erst ein signiertes CMS-Objekt erstellt werden, dass danach verschlüsselt wird. So wird auch die Information der Signierung versteckt.

Schlüsselmanagement

S/Mime basiert auf X.509v3 Public Key Zertifikaten, die in einer PKI eingebunden sind. Für die Verwendung im Internet sollte die PKI das PKIX Format implementieren.

Algorithmen

Die obligaten und optional verwendbaren Algorithmen waren anfangs innerhalb in der Cryptographic Message Syntax spezifiziert, mittlerweile werden die Algorithmen in eigenen RFCs behandelt, was mehr Flexibilität mit sich bringt. Zu beachten ist auch, dass zu Zeiten der amerikanischen Exportbeschränkung auf kryptographische Produkte auch unzureichende Schlüssellängen (RC2 40 Bit) Aufnahme fanden.

Hash-Algorithmen sind SHA 1, MD5, Signatur-Algorithmen sind DSA und RSA. Als Schlüsseltransportalgorithmus ist RSA spezifiziert, bzw. als Schlüsselvereinbarungsalgorithmen sind ephemeral-static Diffie Hellman (ESDH) als auch static-static Diffie Hellman möglich. Als Verschlüsselungsalgorithmen waren anfangs 3DES CBC und RC2 CBC spezifiziert. Mittlerweile sind in eigenen RFCs auch die Verwendung von AES, Camellia, GOST, Skipjack mit KEA, CAST 128, IDEA, sowie ECDSA und ECDH als Anwendungen der Elliptic Curve Cryptography abgehandelt.

Enhanced Security Services

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.

Signed Receipts: Eine signierte Bestätigung wird durch Signieren der vollständigen Originalnachricht erstellt und an den Absender versandt, der dies durch ein Flag anfordern kann. Diese Bestätigung beweist, den Erhalt der Nachricht und die erfolgreiche Verifikation der Signatur.

Security Labels: Security Labels spezifizieren die Klassifizierung eines Nachrichteninhaltes, auf Basis dessen ein Mailprogramm entscheiden kann, den Inhalt dem Benutzer anzuzeigen oder nicht. Die Label können nach der Security Policy des Unternehmens definiert sein.

Secure Mailing Lists: Dabei braucht der Absender ein Mail nicht mehr für jeden einzelnen Empfänger verschlüsseln, sondern nur mehr einmal mit dem Schlüssel des Mailing List Agents verschlüsseln, der die verschlüsselte Verteilung sodann übernimmt.

Zertifizierte E-Mailadresse

Während in S/MIME v2 die E-Mailadresse Bestandteil des Zertifikates sein muss, ist dies in S/MIME v3 nicht mehr zwingend notwendig, da durchaus vorstellbar ist, dass man ein Zertifikat für mehrere E-Mailadressen verwenden möchte. Zu beachten ist aber, dass einige Mailclients welche die Version 2 sauber implementiert haben, Signaturen mit solchen Zertifikaten als ungültig anzeigen, da der Absender mit der Mailadresse nicht übereinstimmt! Zu beachten ist auch, dass eine E-Mailadresse an mehreren Stellen im Zertifikat auftauchen kann.

Linktipps

	offizielle S/MIME - OIDs
	weitere wichtige S/MIME OIDs