4. Asymmetrische Verschlüsselung | Kryptographie-Dokumentation

Das Schlüsseltauschproblem aus Block 02 hat eine elegante Lösung: asymmetrische Kryptografie. Stellt euch vor, jemand gibt euch ein offenes Vorhängeschloss – ihr könnt Nachrichten darin einschließen, aber nur derjenige, der den passenden Schlüssel hat, kann es öffnen. Genau so funktioniert der Public Key.

Nach diesem Block könnt ihr:

das Prinzip asymmetrischer Verschlüsselung erklären (Public Key verschlüsselt, Private Key entschlüsselt)

erklären, warum asymmetrische Schlüssel länger sein müssen als symmetrische

RSA, ECC und Ed25519 einordnen und Einsatzgebiete benennen

den Diffie-Hellman-Schlüsselaustausch erklären und seine Bedeutung für Perfect Forward Secrecy

ein RSA- und ein Ed25519-Schlüsselpaar mit OpenSSL erstellen

einordnen, warum Quantencomputer eine Bedrohung für asymmetrische Verfahren sind und welche Post-Quantum-Standards existieren

Grundprinzip

Bei asymmetrischer Verschlüsselung gibt es immer ein Schlüsselpaar: einen öffentlichen Schlüssel (Public Key) und einen privaten Schlüssel (Private Key). Die beiden Schlüssel sind mathematisch miteinander verknüpft, aber der private Schlüssel kann nicht aus dem öffentlichen berechnet werden.

                    Schlüsselpaar
                    ┌──────────────────────────────┐
                    │  Public Key   (öffentlich)   │
                    │  Private Key  (geheim!)      │
                    └──────────────────────────────┘

Regel 1 – Verschlüsselung:

Sender                                         Empfänger
  │                                                │
  │  Holt den Public Key des Empfängers            │
  │      (öffentlich verfügbar)                    │
  │                                                │ 
  │  Klartext + Public Key des Empfängers          │
  │       ↓                                        │
  │  Verschlüsseln → Geheimtext ──────────────────►│
  │                                                │  Geheimtext + Private Key
  │                                                │       ↓
  │                                                │  Entschlüsseln → Klartext

Nur der Empfänger kann entschlüsseln – weil nur er den Private Key hat. Jeder kann verschlüsseln (mit dem Public Key), aber nur einer kann lesen.

Regel 2 – Digitale Signatur:

Sender                                  Empfänger
  │                                         │
  │  Nachricht + Private Key des Senders    │
  │       ↓                                 │
  │  Signieren → Signatur ─────────────────►│
  │  (Nachricht + Signatur werden gesendet) │
  │                                         │ Signatur + Public Key des Senders
  │                                         │       ↓
  │                                         │ Verifizieren → gültig / ungültig

Nur der Sender konnte signieren (weil nur er den Private Key hat). Jeder kann verifizieren (mit dem Public Key). Beweist Authentizität und Integrität. → Tiefe Behandlung in Block 04.

Warum funktioniert das überhaupt? – Einwegfunktionen

Das mathematische Fundament der asymmetrischen Kryptografie sind Einwegfunktionen mit Falltür (Trapdoor-Funktionen). Das sind Berechnungen, die in eine Richtung leicht, in die andere Richtung praktisch unmöglich sind – es sei denn, man kennt die geheime Zusatzinformation (die „Falltür”).

RSA – Primfaktorzerlegung:

Leicht:   17 × 19 = 323   → Multiplikation: trivial
Schwer:   323 = ? × ?     → Faktorisierung: muss alle Primzahlen durchprobieren

In der Praxis:
  Leicht:  Zwei 2048-Bit-Primzahlen p und q multiplizieren → n = p × q
  Schwer:  n (eine ~600-stellige Zahl) wieder in p und q zerlegen
           → Mit heutiger Hardware: länger als das Universum alt ist

Der Public Key enthält n (das Produkt). Der Private Key enthält p und q (die Faktoren). Wer p und q kennt, kann entschlüsseln. Wer nur n kennt, kann es nicht – weil Faktorisierung zu aufwändig ist.

ECC – Diskreter Logarithmus auf elliptischen Kurven:

Leicht:   Punkt P auf einer elliptischen Kurve, 256 mal "addieren" → Ergebnis Q
Schwer:   Gegeben P und Q: Wie oft wurde addiert?
          → Kein effizienter Algorithmus bekannt

ECC nutzt diese Asymmetrie: Der Private Key ist die Zahl (wie oft addiert wurde), der Public Key ist der resultierende Punkt Q. Aus Q allein kommt man nicht zurück zur Zahl.

Warum asymmetrische Schlüssel so viel länger sein müssen:

Symmetrische Verfahren (AES) haben keine bekannte mathematische Schwäche – ein Angreifer muss wirklich alle Schlüssel brute-forcen. Bei RSA und ECC gibt es spezielle Algorithmen (Zahlenkörpersieb, Baby-Step-Giant-Step), die die Suche massiv verkürzen. Deshalb braucht man viel längere Schlüssel für vergleichbare Sicherheit:

Symmetrisch	RSA	ECC	Sicherheitsniveau
80 Bit	1024 Bit	160 Bit	Veraltet
112 Bit	2048 Bit	224 Bit	Akzeptabel
128 Bit	3072 Bit	256 Bit	Empfohlen
256 Bit	15360 Bit	512 Bit	Langfristig

Das Schlüsseltauschproblem – gelöst

Das größte Problem der symmetrischen Verschlüsselung: Wie tauscht man den gemeinsamen Schlüssel sicher aus, wenn der Kanal unsicher ist?

Mit asymmetrischer Verschlüsselung ist das gelöst: Der Public Key kann öffentlich verteilt werden. Jeder darf ihn kennen. Nur der Private Key bleibt geheim. Es gibt kein Schlüsseltauschproblem mehr.

Stärken:

Kein sicherer Kanal für Schlüsselaustausch nötig
Skaliert gut – jeder hat nur ein Schlüsselpaar, kommuniziert damit mit beliebig vielen Partnern
Ermöglicht digitale Signaturen und Zertifikate

Schwächen:

Sehr langsam – 100 bis 1000-mal langsamer als symmetrische Verfahren
Nicht geeignet für große Datenmengen direkt
Schlüssellängen müssen viel größer sein (siehe Tabelle oben)

Diffie-Hellman – gemeinsamen Schlüssel ohne Übertragung erzeugen

Diffie-Hellman (DH) ist kein Verschlüsselungs-, sondern ein Schlüsselaustauschalgorithmus. Er löst eine elegantere Variante des Schlüsselproblems: Zwei Parteien können sich auf ein gemeinsames Geheimnis einigen, ohne dass dieses Geheimnis jemals über das Netz übertragen wird.

Intuition – die Farbanalogie:

Alice und Bob wollen eine gemeinsame Geheimfarbe, ohne sie direkt zu übertragen.

1. Öffentliche Farbe (für alle sichtbar): Gelb

2. Alice wählt geheime Farbe: Rot         Bob wählt geheime Farbe: Blau
   Alice mischt:  Gelb + Rot = Orange     Bob mischt:  Gelb + Blau = Grün
   Alice sendet Orange →                ← Bob sendet Grün

3. Alice mischt: Orange + Rot = Braun  Bob mischt: Grün + Blau = Braun
   → Beide haben dieselbe Geheimfarbe (Braun), ohne sie je zu übertragen!

Ein Angreifer sieht: Gelb, Orange, Grün – kann aber Braun nicht rekonstruieren,
weil er die geheimen Einzelfarben (Rot, Blau) nicht kennt.

Technisch (vereinfacht):

Öffentliche Parameter: Primzahl p, Generator g (für alle bekannt, kein Geheimnis)

Alice wählt geheimen Wert a        Bob wählt geheimen Wert b
Alice berechnet: A = g^a mod p     Bob berechnet: B = g^b mod p
Alice sendet A →                 ← Bob sendet B

Alice berechnet: S = B^a mod p  Bob berechnet: S = A^b mod p
→ Beide erhalten denselben Wert S = g^(ab) mod p

Angreifer sieht A und B, kennt p und g, aber:
  S aus A, B, p, g zu berechnen = diskretes Logarithmusproblem → praktisch unmöglich

ECDH (Elliptic Curve Diffie-Hellman): Dasselbe Prinzip, aber auf elliptischen Kurven statt mit Primzahlen. Deutlich effizienter, kürzere Schlüssel, in modernen Protokollen (TLS 1.3) Standard.

Ephemeral DH (DHE / ECDHE): Wenn für jede Verbindung ein neues, kurzlebiges DH-Schlüsselpaar generiert wird (ephemeral = kurzlebig), wird Perfect Forward Secrecy erreicht – vergangene Sessions bleiben sicher, selbst wenn der langfristige Server-Key später kompromittiert wird.

Wichtige asymmetrische Algorithmen

Diese Algorithmen begegnen euch in Zertifikaten, SSH-Schlüsseln, TLS-Handshakes und digitalen Signaturen. Es lohnt sich, sie auseinanderhalten zu können – sowohl für die Prüfung als auch dafür, in einer Konfiguration die richtige Wahl zu treffen.

RSA (Rivest–Shamir–Adleman) 1977 entwickelt, ältester und am weitesten verbreiteter asymmetrischer Algorithmus. Basiert auf Primfaktorzerlegung (siehe oben). Wird für Verschlüsselung und Signaturen verwendet. Schlüssellängen: mindestens 2048 Bit, empfohlen 3072–4096 Bit. Nachteil: langsam, große Schlüssel, RSA-Schlüsselaustausch bietet keine Forward Secrecy.

ECC (Elliptic Curve Cryptography) Modernes Verfahren basierend auf elliptischen Kurven. Viel kürzere Schlüssel für gleiche Sicherheit (256-Bit ECC ≈ 3072-Bit RSA). Schneller, geringerer Ressourcenverbrauch – besonders relevant für Mobile und IoT. Grundlage für ECDSA und Ed25519. Wichtige Kurven: P-256 und P-384 (NIST-Standard), Curve25519 (bevorzugt in modernen Protokollen, da unabhängig von NIST-Parametern).

Ed25519 (EdDSA auf Curve25519) Modernes Signaturverfahren. Gilt als sicherer implementierbar als ECDSA, weil es keinen internen Zufallswert benötigt (ein schwacher Zufallsgenerator kann bei ECDSA den Private Key enthüllen). Sehr schnell. Wird verwendet in: SSH-Schlüsseln, TLS 1.3, Signal-Protokoll, modernen Zertifikaten.

ECDSA (Elliptic Curve Digital Signature Algorithm) Älteres ECC-Signaturverfahren, in TLS-Zertifikaten weit verbreitet. Sicher wenn korrekt implementiert. Kurven P-256 und P-384.

Diffie-Hellman (DH) / ECDH Kein Verschlüsselungsalgorithmus, sondern reiner Schlüsselaustausch (siehe Abschnitt oben). Grundlage für Perfect Forward Secrecy in TLS. In der Praxis fast ausschließlich in der ephemeren Variante (ECDHE) eingesetzt.

Typischer Denkfehler

„Asymmetrische Verschlüsselung ist sicherer als symmetrische.” – Das stimmt so nicht. Asymmetrische Verfahren lösen ein anderes Problem (Schlüsseltausch), sind aber nicht „sicherer” als AES. Sie sind 100–1000x langsamer und können keine großen Datenmengen direkt verarbeiten. In der Praxis werden beide kombiniert (Block 05). Die Frage ist nicht „welches ist sicherer?”, sondern „welches löst welches Problem?”.

Asymmetrische Verschlüsselung mit OpenSSL

RSA-Schlüsselpaar erstellen:

# Privaten RSA-Schlüssel generieren (4096 Bit)
openssl genrsa -out private.pem 4096

# Mit Passwortschutz (empfohlen für gespeicherte Keys)
openssl genrsa -aes256 -out private_geschuetzt.pem 4096

# Öffentlichen Schlüssel aus privatem ableiten
openssl rsa -in private.pem -pubout -out public.pem

# Schlüsseldetails anzeigen
openssl rsa -in private.pem -text -noout       # Private Key Details
openssl rsa -in public.pem -pubin -text -noout # Public Key Details

Datei mit RSA verschlüsseln und entschlüsseln:

# Verschlüsseln mit öffentlichem Schlüssel (nur für kleine Daten!)
openssl pkeyutl -encrypt -inkey public.pem -pubin -in klartext.txt -out geheimtext.enc
# RSA kann nur kleine Datenmengen direkt verschlüsseln – in der Praxis wird
# RSA deshalb nur für den Session-Key eingesetzt (→ Hybride Verschlüsselung, Block 05)

# Entschlüsseln mit privatem Schlüssel
openssl pkeyutl -decrypt -inkey private.pem -in geheimtext.enc -out klartext_neu.txt

EC-Schlüsselpaar erstellen:

# EC-Schlüssel mit Kurve P-256
openssl ecparam -genkey -name prime256v1 -out ec_private.pem
openssl ec -in ec_private.pem -pubout -out ec_public.pem

# Ed25519 (moderner, empfohlen für neue Implementierungen)
openssl genpkey -algorithm Ed25519 -out ed_private.pem
openssl pkey -in ed_private.pem -pubout -out ed_public.pem

# Verfügbare Kurven anzeigen
openssl ecparam -list_curves

Probiert es selbst:

Erstellt ein RSA-Schlüsselpaar: openssl genrsa -out mein_private.pem 4096 und openssl rsa -in mein_private.pem -pubout -out mein_public.pem

Schaut euch den Private Key an: cat mein_private.pem – was seht ihr?

Erstellt eine kleine Textdatei und verschlüsselt sie mit dem Public Key: openssl pkeyutl -encrypt -inkey mein_public.pem -pubin -in test.txt -out test.enc

Entschlüsselt mit dem Private Key: openssl pkeyutl -decrypt -inkey mein_private.pem -in test.enc -out test_neu.txt

Was passiert, wenn ihr versucht, mit dem Public Key zu entschlüsseln?

Merke: Schlüsseldateien gibt es in verschiedenen Formaten (PEM, DER, .p12 usw.). Da diese Formate eng mit Zertifikaten zusammenhängen, werden sie in Block 06 erklärt – dort wo auch CA, CSR und Zertifikatsverwaltung behandelt werden.

Post-Quantum-Kryptografie

Alle asymmetrischen Verfahren, die ihr bisher kennengelernt habt – RSA, ECC, ECDH – basieren auf mathematischen Problemen, die ein Quantencomputer effizient lösen kann. Das ist heute noch kein akutes Problem, aber eines, auf das sich die Branche bereits vorbereitet.

Warum das relevant ist:

Shor’s Algorithmus kann Primfaktorzerlegung und diskrete Logarithmen effizient lösen – damit wären RSA und ECC gebrochen. Nicht heute, aber möglicherweise in 10–15 Jahren.
„Harvest now, decrypt later” – Angreifer zeichnen heute verschlüsselten Traffic auf und entschlüsseln ihn, sobald Quantencomputer verfügbar sind. Wer langfristig vertrauliche Daten schützen muss, hat jetzt ein Problem.

NIST Post-Quantum-Standards (2024):

Das NIST hat 2024 die ersten standardisierten Post-Quantum-Algorithmen veröffentlicht:

ML-KEM (Kyber) – für Schlüsselaustausch (ersetzt ECDHE)
ML-DSA (Dilithium) – für digitale Signaturen (ersetzt ECDSA/Ed25519)

Beide basieren auf Gitterproblemen (Lattice-based Cryptography) – mathematische Probleme, für die auch Quantencomputer keinen effizienten Algorithmus kennen.

Was müssen Admins heute tun?

Kryptoagilität: Systeme so bauen, dass Algorithmen austauschbar sind, ohne alles neu zu entwickeln
TLS 1.3 unterstützt bereits hybride Schlüsselvereinbarung (klassisch + PQ gleichzeitig)
Chrome und andere Browser experimentieren bereits mit ML-KEM
Das BSI empfiehlt, sich aktiv auf die Migration vorzubereiten

Merke: Quantencomputer bedrohen nicht die symmetrische Verschlüsselung. AES-256 bleibt sicher – Grover’s Algorithmus halbiert nur die effektive Schlüssellänge (AES-256 → 128 Bit Sicherheit, immer noch ausreichend). Das Problem betrifft ausschließlich asymmetrische Verfahren.

Zusammenfassung

Asymmetrische Verschlüsselung nutzt Schlüsselpaare: Public Key zum Verschlüsseln, Private Key zum Entschlüsseln
Die mathematische Grundlage sind Einwegfunktionen (Primfaktorzerlegung bei RSA, diskrete Logarithmen bei ECC)
RSA ist weit verbreitet aber langsam; ECC/Ed25519 ist modern, schneller und braucht kürzere Schlüssel
Diffie-Hellman (ECDHE) ermöglicht gemeinsame Schlüssel ohne Übertragung – Grundlage für Perfect Forward Secrecy
Asymmetrische Verfahren sind zu langsam für große Datenmengen – deshalb werden sie mit symmetrischen kombiniert (→ Block 05)

Selbsttest

Erklärt in einem Satz, warum der Private Key aus dem Public Key nicht berechenbar ist.
Warum braucht ein RSA-Schlüssel 3072 Bit für die gleiche Sicherheit wie ein AES-Schlüssel mit 128 Bit?
Was ist der Unterschied zwischen Diffie-Hellman und RSA – und warum ist ECDHE für Perfect Forward Secrecy entscheidend?

Wie geht es weiter?

Jetzt wisst ihr, wie asymmetrische Verschlüsselung funktioniert – aber wie beweist man, wer eine Nachricht geschickt hat? Block 04 zeigt, wie digitale Signaturen Authentizität und Integrität sicherstellen – das digitale Äquivalent einer Unterschrift, nur mathematisch wasserdicht.