S/MIME

aus Wikipedia, der freien Enzyklopädie
Zur Navigation springen Zur Suche springen

Secure / Multipurpose Internet Mail Extensions (S/MIME) ist ein Standard für die Verschlüsselung und das Signieren von MIME-Objekte durch ein hybrides Kryptosystem. S/MIME wird in sehr vielen Protokollen zur Absicherung in der Anwendungsschicht (Application Layer) eingesetzt. Typische Einsätzfälle von S/MIME sind E-Mail, AS2 und viele weitere. In der Praxis kann S/MIME (Inhaltsebene) mit TLS (Transportebene) kombiniert werden.

Funktion[Bearbeiten | Quelltext bearbeiten]

RFC 1847 (1995) definiert zwei Content-Types für MIME. Das multipart/signed-Format zur Signierung einer E-Mail und das multipart/encrypted-Format zu deren Verschlüsselung. Eine E-Mail kann dabei nur signiert, nur verschlüsselt oder beiden Operationen unterzogen werden. Sowohl S/MIME (RFC 2633) als auch OpenPGP (RFC 2440), die beide erst später spezifiziert wurden, verwenden multipart/signed, wohingegen multipart/encrypted nur von OpenPGP verwendet wird. S/MIME definiert (auch) für Verschlüsselung den neuen Content-Type application/pkcs7-mime. S/MIME wird von den meisten modernen Mailclients unterstützt. Es erfordert X.509-basierte Zertifikate für den Betrieb.

Multipart/Signed[Bearbeiten | Quelltext bearbeiten]

Das Format enthält genau zwei Blöcke. Der erste enthält die Daten, inklusive des MIME-Headers, über welche die digitale Signatur erstellt wurde. Der zweite enthält die Informationen, um die Signatur zu überprüfen. Die Mail bleibt dadurch auch für E-Mail-Clients lesbar, die kein S/MIME unterstützen. Deshalb ist multipart/signed die empfohlene von mehreren möglichen S/MIME-Methoden.

application/pkcs7-mime[Bearbeiten | Quelltext bearbeiten]

Der Content-Type application/pkcs7-mime hat den optionalen Parameter smime-type, der die Art der Daten beschreibt (ohne dass sie dafür decodiert werden müssen): enveloped-data (Verschlüsselung), signed-data (Signatur), certs-only (Zertifikat). Außerdem zeigt der Dateiname des optionalen, aber erbetenen Headereintrags Content-Disposition die Art der Daten an: smime.p7m (signierte oder verschlüsselte Daten), smime.p7c (Zertifikat), smime.p7s (Signatur).

Ein Abschnitt mit verschlüsselten Daten enthält ebenfalls genau zwei Blöcke. Der erste enthält benötigte Informationen zur Entschlüsselung. Im zweiten Block sind die verschlüsselten Daten enthalten. Der Mailrumpf ist komplett verschlüsselt und kann somit nur vom vorgesehenen Empfänger gelesen werden. Damit ist auch ein Scannen auf Viren und Spam erst auf dem Endgerät möglich. Die Mailheader (auch der Betreff) sind dagegen weiterhin unverschlüsselt und sollten daher keine vertraulichen Informationen enthalten.

So sieht eine verschlüsselte Nachricht beispielhaft aus:

   Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
           name=smime.p7m
   Content-Transfer-Encoding: base64
   Content-Disposition: attachment; filename=smime.p7m
   rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
   7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
   f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
   0GhIGfHfQbnj756YT64V

Zur Verschlüsselung einer E-Mail muss der Absender den öffentlichen Schlüssel des Empfängers kennen, den er beispielsweise dem Zertifikat einer zuvor vom Empfänger erhaltenen signierten E-Mail entnehmen kann. Ein E-Mail-Client vereinfacht die Handhabung, indem er automatisch alle erhaltenen Zertifikate speichert.

Klassifizierung der Zertifikate[Bearbeiten | Quelltext bearbeiten]

Die Anbieter von Zertifikaten für sichere E-Mail-Kommunikation klassifizieren diese meist in drei auf einander aufbauenden Klassen:

  • Klasse 1 — Die Zertifizierungsstelle (CA) sicher die Echtheit der E-Mail-Adresse zu und nur diese ist Teil des Zertifikats.
  • Klasse 2 — Zusätzlich zur E-Mail-Adresse wird der dazugehörende Name in das Zertifikat mit aufgenommen, sowie ggf. die Organisation/Firma.
  • Klasse 3 — Die Daten der Klasse 3 werden mithilfe von Drittdatenbanken, Ausweiskopien, Handelsregisterauszügen etc. verifiziert.
  • Klasse 4 — Bei Zertifikaten der Klasse 4 muss der Antragsteller sich persönlich ausweisen.

Kostenlose Zertifikate[Bearbeiten | Quelltext bearbeiten]

Manche Unternehmen und nichtkommerzielle Organisationen bieten kostenlose S/MIME-Zertifikate an. Es können dabei nach einer Registrierung mehrere Zertifikate erstellt werden, die aber erst nach einer gewissen Anzahl von Identitätsnachweisen den Namen beinhalten. Diese können durch Mitglieder in einem Web of Trust oder anderen vertrauenswürdigen Stellen wie Rechtsanwälten oder Wirtschaftstreuhändern erfolgen. Grundsätzlich zerstört eine Ausstellung von Zertifikaten durch Anbieter ohne Identitätsüberprüfung des Antragstellers den Grundgedanken des sicheren Informationsaustauschs zwischen zwei Computern im Netz. So ist es bei einigen Zertifikatsausstellern tatsächlich möglich, mit erfundenen Betreiberangaben ein Zertifikat für eine völlig fremde Website zu erhalten. Der Benutzer würde über ein Umleiten der Informationsübertragung beispielsweise durch den Browser nicht mehr informiert, wenn die Zertifizierungsstelle durch den Browserhersteller von vornherein als vertrauenswürdig eingestuft wurde.[1]

CAcert, eine nichtkommerzielle, gemeinschaftsbetriebene CA, stellt kostenlose Zertifikate zur Verfügung. Sie ist jedoch in vielen E-Mail-Clients und Webbrowsern nicht in der Zertifikatsdatenbank als vertrauenswürdige Zertifizierungsstelle eingetragen. Ein Benutzer, der eine Verbindung zu einem Server mit CAcert-Zertifikat aufbaut oder eine E-Mail mit einem von CAcert signierten S/MIME-Zertifikat erhält, wird daher die Fehlermeldung erhalten, dass die Herkunft des Zertifikates nicht überprüft werden konnte (sofern CAcert nicht zuvor manuell als vertrauenswürdig im Programm eingetragen wurde).

Weiterhin werden kostenlose Zertifikate der Klasse 1 (teilweise mit reduzierter Gültigkeitsdauer unter einem Jahr, beispielsweise als Testzertifikat) von Firmen angeboten, welche im Gegensatz zu CAcert auch in den Zertifikatsdatenbanken gängiger Software als vertrauenswürdig gelistet werden. Diese kostenlosen S/MIME-Zertifikate sind jedoch uneingeschränkt funktionsfähig. Beispiele für diese meist für den Privatgebrauch gedachten Zertifikate sind:

  • free secure email eID von WISeKey[2] (1 Jahr Gültigkeit)
  • Secorio S/MIME[3] (1 Monat Gültigkeit, verwendet Zertifikate von Comodo)
  • GlobalSign als Free Trial PersonalSign 1 Certificate[4] (30 Tage Gültigkeit)

Außerdem ist es möglich, Nachrichten mit einem selbst signierten Zertifikat zu verschlüsseln. Dazu ist ein selbst erstelltes Stammzertifikat notwendig, das die eigene Zertifizierungsstelle repräsentiert. Damit können prinzipiell beliebige Zertifikate signiert werden. Alle Kommunikationspartner müssen jedoch zunächst dieses Stammzertifikat importieren und diesem vertrauen, bevor eine verschlüsselte Kommunikation möglich wird.

Mithilfe von SMIMEA ist es möglich, dass der Administrator der Domain ein (Stamm-)Zertifikat über DNS veröffentlicht und so die Beglaubigung übernimmt.[5]

Sicherheit Schlüsselerzeugung[Bearbeiten | Quelltext bearbeiten]

Für die Nutzung von S/MIME-Zertifikaten zur Verschlüsselung und Signierung wird aufgrund des verwendeten Public-Key-Verschlüsselungsverfahrens ein Schlüsselpaar aus öffentlichem und privatem Schlüssel benötigt. Beide Schlüssel können durch einen Dienstleister erstellt werden. Die Erstellung des privaten Schlüssel durch den Dienstleister setzt das Vertrauen voraus, dass davon keine Kopie/Backup/Logdatei oder Ähnliches beim Dienstleister zurückbleibt nach der Übergabe. Seriöse Dienstleister Certificate Authority (CA) bieten stattdessen ein Verfahren an, wo die Erstellung des privaten Schlüssel durch den Kunden erfolgt und zu keinem Zeitpunkt der CA übergeben werden muss.[6] Der Kunde übergibt dazu "seinen initialen öffentlichen Schlüssel" per Certificate Signing Request (CSR-Antrag) an die CA und die CA erzeugt das weltweit überprüfbare öffentliche Zertifikat.[6]

Je nach Schutzbedarf kann der private Schlüssel und die CSR-Datei entweder bequem im Browser erzeugt werden über eine Website, welche die CA bereitstellt oder im anderem Extrem kann dies auf einem separaten Computer erfolgen der nur für diesem Einsatzzweck beschafft und dafür genutzt wird und über Konsolen-Befehle bedient wird. Das finale öffentliche Zertifikat der CA wird oft per E-Mail zugestellt. Seriöse CAs bieten jedes von ihr erzeugte öffentliche Zertifikat in einem eigenem öffentlich zugänglichen Zertifikatsverzeichnis inklusive öffentliche Sperrliste an.

Für Organisationen die sehr viele S/MIME-Zertifikate benötigen bieten die CAs auch spezielle Zertifikatsmanager-Verwaltungsprogramme mit der auch bei erhöhten Schutzbedarf der Verwaltungsaufwand sinkt.

Sicherheit S/MIME bei E-Mail[Bearbeiten | Quelltext bearbeiten]

Zur Sicherheit der signierten und verschlüsselten Kommunikation per E-Mail mittels S/MIME und PGP wurden 2018 und 2019 von einer Gruppe von deutschen Sicherheitsforschern diverse Studien durchgeführt:

  • Das kryptografischen Verfahren ist weiterhin sicher, aber die Umsetzung als Protokoll S/MIME weist einige konzeptionelle Schwächen auf durch gewisse optionale Varianten. Diese wurde unter den Schlagwort Efail in der Öffentlichkeit diskutiert. Mit RFC 8551 wurden die Änderungsvorschläge aufgegriffen als S/MIME 4.0 und Efail wird auch namentlich im RFC erwähnt.
  • 2019 wurden diese Studien erweitert um die Fragestellung in wieweit handelsübliche E-Mail-Software auf der Seite des Empfängers sich austricksen lässt bei der Signaturprüfung, wenn die Signatur per S/MIME mal als CMS oder mal auf dem Anhang angewendet wird oder eine E-Mail zwei Signaturen enthält. Die Forscher haben die Sicherheitslücken vor der Veröffentlichung den Herstellern mitgeteilt, so dass einige bereits Sicherheitsupdates bereitgestellt haben.[7]

Alternativen[Bearbeiten | Quelltext bearbeiten]

Als Alternative zu S/MIME kann auch PGP bzw. OpenPGP unter Verwendung einer PKI eingesetzt werden. Die beiden Verfahren sind allerdings nicht kompatibel, auch wenn sie teilweise die gleichen Verschlüsselungsverfahren einsetzen, da sie unterschiedliche Datenformate verwenden. Üblich sind hier PGP/INLINE oder PGP/MIME. Mit Pretty Easy privacy soll der Einsatz von S/MIME oder PGP automatisiert und somit massiv vereinfacht werden.

Siehe auch[Bearbeiten | Quelltext bearbeiten]

Normen und Standards[Bearbeiten | Quelltext bearbeiten]

S/MIME wird fortwährend weiterentwickelt:

  • RFC 2311 S/MIME Version 2 Message Specification (1998, veraltet)
  • RFC 2633 S/MIME Version 3 Message Specification (1999, veraltet)
  • RFC 3851 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification (2004, veraltet)
  • RFC 5751 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification (2010, veraltet)
  • RFC 8551 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Message Specification (2019)

Zusätzlich gibt es eine weitere S/MIME-Reihe die sich das Zertifikatshandling und Sperrlisten beschäftigt:

  • RFC 2632 S/MIME 3.0 Certificate Handling (1999, veraltet)
  • RFC 3850 S/MIME 3.1 Certificate Handling (2004, veraltet)
  • RFC 5750 S/MIME 3.2 Certificate Handling (2010, veraltet)
  • RFC 8550 S/MIME 4.0 Certificate Handling (2019)

Weblinks[Bearbeiten | Quelltext bearbeiten]

Einzelnachweise[Bearbeiten | Quelltext bearbeiten]

  1. https://www.heise.de/newsticker/meldung/Vorsicht-bei-kostenlosen-SSL-Zertifikaten-137817.html
  2. Free Secure email eID https://account.wisekey.com
  3. https://www.secorio.com/de/faqs/smime-zertifikate/78-how-much-does-an-email-certificate-for-private-use-cost
  4. GlobalSign PersonalSign Produkte https://www.globalsign.com/de-de/personalsign/
  5. Schlyter, Jakob, Hoffman, Paul: Using Secure DNS to Associate Certificates with Domain Names for S/MIME. Abgerufen am 10. Juli 2017 (englisch).
  6. a b Reiko Kaps: Noch ein Sargnagel. Wie CAs das Vertrauen in die SSL-Technik weiter untergraben. In: c't. Nr. 14, 2014, S. 46 f. (heise.de [abgerufen am 25. November 2018]).
  7. Fabian A. Scherschel: S/MIME und PGP: E-Mail-Signaturprüfung lässt sich austricksen. In: heise online. 1. Mai 2019, abgerufen am 4. Mai 2019.