14. E-Mail-Sicherheit (S/MIME und PGP) | Kryptographie-Dokumentation

Das Problem: E-Mail ist von Natur aus unsicher

E-Mail wurde in den 1970er Jahren entwickelt – ohne jegliche Sicherheitsanforderungen. Eine E-Mail, die heute von sender@firma.de zu empfaenger@example.com reist, durchläuft mehrere Mail-Server und wird dort im Klartext gespeichert und weitergeleitet.

Sender          Mail-Server A      Mail-Server B       Empfänger
  │                   │                  │                  │
  │──── E-Mail ──────►│                  │                  │
  │    (Klartext)     │──── E-Mail ─────►│                  │
  │                   │    (Klartext)    │──── E-Mail ─────►│
  │                   │                  │    (Klartext)    │

  Jeder Mailserver-Administrator kann mitlesen.
  Jeder im Netzwerk kann beim Transport mitlesen (ohne TLS).
  Der Absender kann ohne Signatur beliebig gefälscht werden (Spoofing).

Drei Probleme:

Vertraulichkeit: Inhalt kann unterwegs von Dritten gelesen werden
Integrität: Inhalt könnte unbemerkt verändert werden
Authentizität: Absenderadresse kann trivial gefälscht werden (E-Mail-Spoofing)

SMTP mit TLS (Transport Encryption) löst das Abhören zwischen Mailservern – aber der Inhalt liegt auf jedem Mailserver im Klartext vor. Für echte Sicherheit braucht man Ende-zu-Ende-Verschlüsselung.

Nach diesem Block könnt ihr:

Den Unterschied zwischen Transportverschlüsselung (TLS) und Ende-zu-Ende-Verschlüsselung (S/MIME, PGP) erklären

S/MIME und PGP in Funktion, Vertrauensmodell (CA vs. Web of Trust) und Einsatzbereich gegenüberstellen

Mit GPG ein Schlüsselpaar erzeugen, Dateien verschlüsseln, entschlüsseln und Signaturen prüfen

SPF, DKIM und DMARC als Schutzmechanismen gegen E-Mail-Spoofing beschreiben und ihr Zusammenspiel erklären

Beurteilen, welche Maßnahmen in einem gegebenen Szenario sinnvoll sind

S/MIME – Secure/Multipurpose Internet Mail Extensions

S/MIME ist der Standard für Ende-zu-Ende-verschlüsselte und signierte E-Mails in Unternehmensumgebungen. Es basiert auf X.509-Zertifikaten – dem gleichen System wie TLS.

Wie S/MIME funktioniert:

Signatur (Absender signiert):
  Absender                              Empfänger
    │                                       │
    │  E-Mail-Inhalt                        │
    │       ↓                               │
    │  Hash berechnen                       │
    │       ↓                               │
    │  Hash mit Private Key signieren       │
    │       ↓                               │
    │  E-Mail + Signatur ──────────────────►│
    │                                       │  Hash neu berechnen
    │                                       │  Signatur mit Public Key prüfen
    │                                       │  → Identisch: Authentisch + unverändert

Verschlüsselung (Absender verschlüsselt für Empfänger):
  Absender                              Empfänger
    │                                       │
    │  Public Key des Empfängers holen      │
    │  (aus Zertifikat oder Verzeichnis)    │
    │       ↓                               │
    │  E-Mail mit Public Key verschlüsseln ►│
    │                                       │  Mit eigenem Private Key entschlüsseln

Voraussetzungen für S/MIME:

Jeder Teilnehmer braucht ein S/MIME-Zertifikat (persönliches Zertifikat für seine E-Mail-Adresse)
Das Zertifikat muss von einer CA ausgestellt sein (kostenlos: Actalis, günstig: Sectigo)
Der Empfänger muss den Public Key des Senders kennen (z.B. durch vorherigen signierten E-Mail-Austausch oder Unternehmensverzeichnis)
Unterstützung durch den E-Mail-Client (Outlook, Thunderbird, Apple Mail)

Zertifikat für S/MIME mit OpenSSL erstellen (für interne PKI):

# Schritt 1: Private Key generieren
openssl genrsa -out user.key 4096

# Schritt 2: CSR erstellen (emailAddress ist Pflichtfeld)
openssl req -new -key user.key -out user.csr \
    -subj "/C=DE/O=TechWerk GmbH/CN=Max Mustermann/emailAddress=max@techwerk.de"

# Schritt 3: Zertifikat durch eigene CA signieren
openssl x509 -req -in user.csr -CA ca.crt -CAkey ca.key \
    -CAcreateserial -out user.crt -days 365 -sha256

# Schritt 4: PKCS#12-Datei erstellen (für Import in Mail-Client)
openssl pkcs12 -export -out user.p12 -inkey user.key -in user.crt -certfile ca.crt
# → user.p12 kann in Outlook / Thunderbird importiert werden

PGP / GPG – Pretty Good Privacy

PGP (und seine freie Implementierung GPG – GNU Privacy Guard) ist eine Alternative zu S/MIME ohne zentralen PKI-Ansatz. Statt einer CA zu vertrauen, wird dem Web of Trust vertraut: Menschen signieren gegenseitig ihre Schlüssel und bestätigen damit ihre Identität.

Schlüsselverwaltung in PGP:

Web of Trust:
  Alice hat Bob persönlich getroffen und seinen Schlüssel signiert.
  Charlie vertraut Alice → Charlie vertraut (transitiv) auch Bob.

  vs.

S/MIME:
  CA hat Bobs Identität geprüft und sein Zertifikat ausgestellt.
  Alle, die der CA vertrauen, vertrauen automatisch Bob.

GPG-Praxis:

# Schlüsselpaar generieren
gpg --full-generate-key
# Wählen: RSA und RSA (oder Ed25519), 4096 Bit, Name und E-Mail-Adresse eingeben

# Eigenen Public Key anzeigen (zum Weitergeben)
gpg --armor --export max@techwerk.de

# Public Key auf Keyserver hochladen
gpg --keyserver keys.openpgp.org --send-keys <KEY-ID>

# Public Key eines anderen importieren
gpg --keyserver keys.openpgp.org --recv-keys <KEY-ID>
# oder aus Datei:
gpg --import pubkey.asc

# Fremden Schlüssel verifizieren und signieren (Web of Trust)
gpg --fingerprint max@techwerk.de   # Fingerprint persönlich vergleichen!
gpg --sign-key max@techwerk.de       # Schlüssel signieren → "ich kenne diese Person"

# Datei verschlüsseln (für Empfänger)
gpg --encrypt --recipient empfaenger@example.com datei.txt
# → datei.txt.gpg (nur Empfänger kann entschlüsseln)

# Datei entschlüsseln
gpg --decrypt datei.txt.gpg > datei.txt

# Datei signieren
gpg --sign --armor datei.txt
# → datei.txt.asc

# Datei signieren und verschlüsseln (kombiniert)
gpg --sign --encrypt --recipient empfaenger@example.com datei.txt

# Signatur prüfen
gpg --verify datei.txt.asc datei.txt

Typischer Denkfehler

“TLS zwischen Mailservern reicht doch – die E-Mail ist verschlüsselt, also sicher.”

Falsch. TLS schützt nur den Transport zwischen zwei Servern (Hop-to-Hop). Auf jedem Mailserver dazwischen liegt der Inhalt im Klartext vor – Administratoren, Angreifer mit Zugriff auf den Server oder staatliche Stellen können mitlesen. Außerdem ist TLS zwischen Mailservern optional – nicht jeder Server erzwingt es. Echte Vertraulichkeit gibt es nur mit Ende-zu-Ende-Verschlüsselung (S/MIME oder PGP), bei der ausschließlich Sender und Empfänger den Inhalt lesen können.

Vergleich S/MIME vs. PGP

Beide Verfahren lösen dasselbe Problem – Ende-zu-Ende-Verschlüsselung und Signatur für E-Mails – aber mit grundlegend verschiedenen Annahmen darüber, wem man vertrauen kann. S/MIME setzt auf Hierarchie (eine CA bestätigt alles), PGP auf Dezentralisierung (Menschen bestätigen sich gegenseitig). Welches besser ist, hängt vom Kontext ab.

Eigenschaft	S/MIME	PGP / GPG
Vertrauensmodell	Hierarchisch (CA)	Web of Trust (dezentral)
Zertifikat nötig?	Ja (von CA ausgestellt)	Nein (eigenes Schlüsselpaar genügt)
Unternehmenseinsatz	Standard, gut integriert	Weniger verbreitet
Client-Unterstützung	Outlook, Apple Mail, Thunderbird	Thunderbird (Enigmail), GPG4Win
Kosten	CA-Zertifikat (kostenlos bis ~50€/Jahr)	Kostenlos
Skalierung	Gut (zentrale CA-Verwaltung)	Aufwändig (jede Schlüsselverteilung manuell)
Standard für IHK	Ja – kennen und erklären können	Ja – Konzept und Unterschied erklären

Merke: S/MIME und PGP lösen dasselbe Problem auf unterschiedliche Weise. In Unternehmensumgebungen, in denen ihr arbeiten werdet, ist S/MIME Standard (weil es in Outlook und Exchange integriert ist). PGP begegnet euch bei Einzelpersonen und in Open-Source-Projekten. Beide könnt ihr in der IHK-Prüfung erklären und gegenüberstellen.

E-Mail-Spoofing und Gegenmaßnahmen

E-Mail-Spoofing bedeutet, die Absenderadresse zu fälschen – und das ist erschreckend einfach. SMTP, das Protokoll hinter jedem E-Mail-Versand, wurde in den 1980er Jahren ohne Authentifizierung entworfen. Ein Angreifer kann eine E-Mail senden, die aussieht, als käme sie von chef@techwerk.de – und ohne Gegenmaßnahmen würde der Mailserver des Empfängers sie akzeptieren. Drei DNS-basierte Verfahren arbeiten zusammen, um genau das zu verhindern:

SPF (Sender Policy Framework) – „Wer darf für meine Domain senden?”

Ein DNS-TXT-Eintrag, der festlegt, welche IP-Adressen und Mailserver berechtigt sind, E-Mails im Namen der Domain zu verschicken. Der empfangende Mailserver schaut im DNS nach, ob der sendende Server in der Liste steht.

SPF-Eintrag für techwerk.de:
  v=spf1 mx ip4:203.0.113.10 -all

  mx:               Die Mailserver aus dem MX-Record dürfen senden
  ip4:203.0.113.10: Dieser spezifische Server darf senden
  -all:             Alle anderen → ablehnen (hartes Fail)

DKIM (DomainKeys Identified Mail) – „Ist die E-Mail unterwegs verändert worden?”

Der sendende Mailserver signiert jede ausgehende E-Mail mit einem Private Key – digitale Signatur, genau wie in Block 04. Der empfangende Server holt den zugehörigen Public Key aus dem DNS und prüft die Signatur. Stimmt sie nicht, wurde die E-Mail manipuliert oder stammt nicht vom angegebenen Server.

DKIM-Eintrag im DNS:
  selector._domainkey.techwerk.de  v=DKIM1; k=rsa; p=<Public Key>

E-Mail-Header (automatisch hinzugefügt):
  DKIM-Signature: v=1; a=rsa-sha256; d=techwerk.de; s=selector;
                  h=from:to:subject:date; b=<Signatur>

DMARC (Domain-based Message Authentication, Reporting & Conformance) – „Was soll passieren, wenn SPF oder DKIM fehlschlagen?”

DMARC baut auf SPF und DKIM auf und definiert die Policy: Soll der empfangende Server die E-Mail ablehnen (reject), in den Spam-Ordner verschieben (quarantine) oder durchlassen (none)? Zusätzlich sendet DMARC Berichte an den Domaininhaber – so erfahrt ihr, ob jemand versucht, eure Domain zu spoofen.

DNS-Einträge für techwerk.de (Zusammenfassung):
  SPF:   v=spf1 mx ip4:203.0.113.10 -all
  DKIM:  v=DKIM1; k=rsa; p=<Public Key>
  DMARC: v=DMARC1; p=reject; rua=mailto:dmarc-reports@techwerk.de

Wie die drei zusammenarbeiten:

  Empfangender Mailserver bekommt E-Mail von „chef@techwerk.de":
    1. SPF prüfen:  Kommt die Mail von einem autorisierten Server? → Ja/Nein
    2. DKIM prüfen: Ist die Signatur im Header gültig? → Ja/Nein
    3. DMARC prüfen: Was sagt die Policy?
       → Beide bestanden: E-Mail annehmen
       → Eines fehlgeschlagen + Policy „reject": E-Mail ablehnen
       → Bericht an Domaininhaber senden

Merke: SPF, DKIM und DMARC schützen nicht den Inhalt der E-Mail – dafür braucht ihr S/MIME oder PGP. Sie schützen die Absender-Identität: Niemand kann sich als @techwerk.de ausgeben, ohne dass es auffällt. Wenn ihr einen Mailserver administriert, sind alle drei Pflicht.

Probiert es selbst: Verschlüsselt und signiert eine Datei mit GPG auf eurem Rechner.

# 1. Schlüsselpaar erzeugen (einmalig)
gpg --full-generate-key

# 2. Eigenen Public Key exportieren (zum Weitergeben)
gpg --armor --export eure@email.de > mein_publickey.asc

# 3. Testdatei erstellen und verschlüsseln (für euch selbst)
echo "Geheime Nachricht" > test.txt
gpg --encrypt --recipient eure@email.de test.txt

# 4. Entschlüsseln und Inhalt prüfen
gpg --decrypt test.txt.gpg

# 5. Datei signieren und Signatur verifizieren
gpg --sign --armor test.txt
gpg --verify test.txt.asc test.txt

Beobachtet: Die .gpg-Datei ist ohne euren Private Key unlesbar. Die Signatur bestätigt, dass die Datei von euch stammt und nicht verändert wurde.

Zusammenfassung

E-Mail ist unsicher by Design – SMTP überträgt Inhalte im Klartext, und Absenderadressen lassen sich trivial fälschen.
S/MIME nutzt X.509-Zertifikate (CA-basiert) für Ende-zu-Ende-Verschlüsselung und Signatur – Standard in Unternehmen.
PGP/GPG nutzt ein dezentrales Web of Trust statt einer CA – verbreitet bei Einzelpersonen und Open-Source-Projekten.
SPF, DKIM und DMARC sind DNS-basierte Mechanismen gegen E-Mail-Spoofing: SPF prüft den sendenden Server, DKIM die Integrität der Nachricht, DMARC definiert die Policy bei Verstößen.
Transportverschlüsselung (TLS) ist kein Ersatz für Ende-zu-Ende-Verschlüsselung – auf jedem Mailserver liegt der Inhalt im Klartext vor.

Selbsttest

1. Ein Kollege sagt: “Wir haben TLS auf unserem Mailserver aktiviert, also sind unsere E-Mails Ende-zu-Ende-verschlüsselt.” Was antwortet ihr?

2. Worin unterscheidet sich das Vertrauensmodell von S/MIME und PGP? Nennt je einen Vor- und Nachteil.

3. Ein Unternehmen stellt fest, dass Phishing-Mails mit gefälschter Absenderadresse @firma.de verschickt werden. Welche drei DNS-Einträge sollten konfiguriert werden, und was bewirkt jeder?

Wie geht es weiter?

Ihr wisst jetzt, wie E-Mail-Kommunikation auf Protokollebene abgesichert wird – in Block 14 (WLAN-Sicherheit) schauen wir uns an, wie die darunterliegende Funkverbindung geschützt wird, denn ohne sichere WLAN-Verschlüsselung kann ein Angreifer den gesamten Netzwerkverkehr inklusive eurer E-Mails bereits vor dem ersten Mailserver abfangen.