Cryptography Reference
In-Depth Information
36.2
S/MIME
S/MIME
ist ein standardisiertes Format für verschlüsselte und signierte E-Mails.
Die Abkürzung steht für
Secure MIME
und bezieht sich auf den bereits erwähn-
ten MIME-Standard, der das Strukturieren von E-Mails ermöglicht. S/MIME
wurde in den neunziger Jahren von der US-Firma RSA Data Security (heute RSA
Security) entwickelt und setzte sich gegen andere damals verbreitete E-Mail-
Krypto-Standards wie PEM oder MOSS durch. Ab der 1998 erschienenen Ver-
sion 2 wurde S/MIME innerhalb einer Arbeitsgruppe der IETF weiterentwickelt.
Inzwischen liegt Version 3.2 vor [RFC5751]. S/MIME sieht vor, dass Absenderin
Alice eine E-Mail digital signieren und verschlüsseln kann. Diese beiden Vor-
gänge sind voneinander unabhängig - es sind also auch unsignierte, verschlüs-
selte E-Mails sowie signierte, unverschlüsselte E-Mails zulässig. Das Verschlüs-
seln erfolgt stets über ein Hybridverfahren.
36.2.1
S/MIME-Format
Das von S/MIME verwendete Format für verschlüsselte und signierte E-Mails ist
aus PKCS#7 abgeleitet. Es wird auch als CMS (Cryptographic Message Syntax)
bezeichnet und ist unter diesem Namen in die S/MIME-Standardisierung einge-
gangen. RFC 3852 beschreibt die für S/MIME relevante CMS-Variante. Von den
sechs Inhaltstypen, die CMS vorsieht, verwendet S/MIME nur vier: Data, Signed-
Data, EnvelopedData und CompressedData. Wie der Name andeutet, verwendet
S/MIME für die Strukturierung einer E-Mail-Nachricht das MIME-Format. Das
bedeutet, dass die verschlüsselte Nachricht, der asymmetrisch verschlüsselte
Schlüssel und andere Bestandteile einer S/MIME-E-Mail in verschiedene MIME-
Blöcke aufgeteilt werden. Man kann S/MIME daher als MIME-Version von
PKCS#7 betrachten. S/MIME schreibt die Unterstützung folgender Verfahren vor:
■
Verschlüsselung
: Triple-DES-Unterstützung ist Pflicht. Die zusätzliche Unter-
stützung von RC2 (mit 40 Bit Schlüssellänge) und des AES wird im Standard
empfohlen.
■
Schlüsselaustausch
: RSA-Unterstützung ist Pflicht. Die zusätzliche Unterstüt-
zung von Diffie-Hellman wird im Standard empfohlen.
■
Digitale Signatur
: Die Möglichkeit zum Signieren mit DSA oder RSA ist Pflicht.
Eine konforme Implementierung muss beide Verfahren verifizieren können.
■
Kryptografische Hashfunktion
: Kommt DSA für digitale Signaturen zum Ein-
satz, dann ist SHA-1-Unterstützung Pflicht. Wird RSA eingesetzt, dann muss
MD5 oder SHA-1 unterstützt werden. Eine konforme Anwendung muss
außerdem alle genannten Kombinationen verifizieren können.
Es gibt noch zahlreiche weitere Algorithmen, die innerhalb von S/MIME einge-
setzt werden können. Deren Implementierung ist jedoch keine Pflicht. Vorge-
schrieben ist dagegen die Unterstützung von X.509v3-Zertifikaten und X.509v2-
