Technische Funktionsweise nach RFC 8551 (S/MIME 4.0) und RFC 5652 (CMS)
S/MIME sichert E-Mails auf Nachrichtenebene: Der Inhalt wird im Client des Absenders verschlüsselt und signiert und erst beim Empfänger wieder geöffnet. Grundlage sind persönliche X.509-Zertifikate und ein hybrides Verfahren aus symmetrischer und asymmetrischer Kryptografie.
Kryptografische Bausteine
Asymmetrisch
RSA 2048/4096 Bit oder ECC (P-256/P-384). Der öffentliche Schlüssel verschlüsselt und prüft, der private entschlüsselt und signiert.
Symmetrisch
AES-128/256 im CBC- oder GCM-Modus. Pro Nachricht wird ein zufälliger Content Encryption Key (CEK) erzeugt und danach verworfen.
Hashfunktion
SHA-256/384/512 bildet den
Fingerabdruck (Digest) der Nachricht. Er wird signiert, nicht die Nachricht selbst.
Zertifikat und Vertrauenskette
Der Client prüft die gesamte Kette bis zu einer im Betriebssystem hinterlegten Root-CA sowie Gültigkeit und Sperrstatus. Alternativ sind interne CAs (z. B. Microsoft ADCS) möglich.
Signieren beim Absender – CMS SignedData
1. MIME-Teil kanonisieren
Text und Anhänge werden in eine kanonische Form mit CRLF-Zeilenenden gebracht, damit der Digest bei Sender und Empfänger identisch ausfällt.
2. Digest berechnen
Über den kanonisierten Inhalt und die signierten Attribute (Signaturzeitpunkt, Content-Type, Message-Digest) wird ein SHA-256-Hashwert gebildet.
3. Digest signieren
Der Hashwert wird mit dem privaten Schlüssel des Absenders verschlüsselt – RSASSA-PSS oder PKCS#1 v1.5, bei ECC per ECDSA.
4. SignedData verpacken
Signatur, signierte Attribute und das Absenderzertifikat inklusive Zwischenzertifikaten werden als CMS-Struktur beigelegt (multipart/signed mit smime.p7s oder application/pkcs7-mime).
Verschlüsseln beim Absender – CMS EnvelopedData
5. CEK erzeugen
Ein kryptografisch zufälliger 256-Bit-Sitzungsschlüssel (Content Encryption Key) wird nur für diese eine Nachricht erzeugt.
6. Inhalt symmetrisch verschlüsseln
Der komplette signierte MIME-Teil samt Anhängen wird mit AES-256 (CBC mit IV oder GCM mit Authentication Tag) verschlüsselt.
7. CEK je Empfänger verschlüsseln
Für jeden Empfänger wird der CEK mit dessen öffentlichem Schlüssel verschlüsselt (RSA-OAEP oder ECDH Key Agreement) und als eigener RecipientInfo-Block abgelegt.
Aufbau der übertragenen Nachricht
Beispiel: verschlüsselte und signierte Nachricht (gekürzt)
From: alice@example.de
To: bob@kunde.de
Subject: Angebot 2026-114 <– Kopfzeilen bleiben unverschluesselt
MIME-Version: 1.0
Content-Type: application/pkcs7-mime;
smime-type=enveloped-data; name=”smime.p7m”
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename=”smime.p7m”
MIIN0wYJKoZIhvcNAQcDoIINxDCCDcACAQAxggEwMIIBLAIBADCBkzB+MQswCQYD
VQQGEwJERTEQMA4GA1UECAwHSGVzc2VuMRIwEAYDVQQHDAlXaWVzYmFkZW4x …
Der gesamte Nachrichtenkörper wird durch einen einzigen Base64-Block (smime.p7m) ersetzt. Darin liegt die EnvelopedData-Struktur, die wiederum die SignedData-Struktur enthält. Absender, Empfänger, Betreff und Zeitstempel bleiben im Header sichtbar – sie werden von S/MIME nicht geschützt.
Entschlüsseln und Prüfen beim Empfänger
8. Passenden RecipientInfo finden
Der Client sucht anhand von Issuer und Seriennummer bzw. Subject Key Identifier den Block, der für sein eigenes Zertifikat bestimmt ist.
9. CEK entschlüsseln
Der verschlüsselte Sitzungsschlüssel wird mit dem privaten Schlüssel des Empfängers geöffnet. Ohne diesen Schlüssel ist die Nachricht dauerhaft unlesbar.
10. Inhalt entschlüsseln
Mit dem CEK wird der AES-Chiffretext entschlüsselt; im GCM-Modus wird zusätzlich das Authentication Tag auf Manipulation geprüft.
11. Signatur verifizieren
Der Digest wird neu berechnet und mit dem entschlüsselten Signaturwert verglichen. Stimmen beide überein, ist die Nachricht unverändert.
12. Zertifikat validieren
Kette bis zur vertrauenswürdigen Root-CA, Gültigkeitszeitraum, emailProtection und Sperrstatus per CRL oder OCSP; die Adresse im Zertifikat muss zum Absender passen.
Voraussetzungen und Grenzen in der Praxis
Voraussetzungen
- Persönliches Zertifikat je Postfach von einer öffentlichen oder internen CA
- Öffentliches Zertifikat des Empfängers muss vorliegen – meist über eine vorab signierte E-Mail
- Client mit S/MIME-Unterstützung (Outlook, Apple Mail, Thunderbird, iOS, Android)
- Sichere Ablage des privaten Schlüssels, z. B. in Smartcard, TPM oder Schlüsselspeicher
- Definierter Prozess für Erneuerung, Sperrung und Archivierung der Schlüssel
Grenzen
- Betreff und Metadaten bleiben lesbar – vertrauliche Angaben gehören nicht in die Betreffzeile
- Serverseitiger Viren- und Spamfilter kann verschlüsselte Inhalte nicht prüfen
- Volltextsuche und Archivsysteme greifen ohne Schlüsselhinterlegung nicht auf Inhalte zu
- Verlorener privater Schlüssel bedeutet dauerhaften Verlust aller alten Nachrichten
- Kein Schutz gegen kompromittierte Endgeräte oder unsichere Gateways