Erweiterte Konzepte der Kryptographie

In den letzten Kapiteln haben wir gelernt, wie man Nachrichten verschlüsselt. Aber Kryptographie kann noch viel mehr! In diesem Kapitel schauen wir uns drei wichtige erweiterte Konzepte an.

Digitale Signaturen

Stell dir vor, Bob erhält eine verschlüsselte E-Mail, die angeblich von Alice kommt. Aber woher weiß Bob, dass sie wirklich von Alice stammt? Ein Angreifer könnte sich als Alice ausgeben!

Das Problem

Beim Verschlüsseln geht es um Vertraulichkeit (niemand kann mitlesen). Aber wir brauchen auch:

• Authentizität: Wer hat die Nachricht wirklich geschrieben?
• Integrität: Wurde die Nachricht unterwegs verändert?

Die Lösung: Digitale Signaturen

Eine digitale Signatur funktioniert wie eine Unterschrift - aber viel sicherer!

Das Prinzip: Alice verwendet asymmetrische Verschlüsselung umgekehrt:

• Verschlüsseln mit privatem Schlüssel → Signieren
• Entschlüsseln mit öffentlichem Schlüssel → Verifizieren

Wie funktioniert's?

1. Alice signiert eine Nachricht

┌─────────────────────────────────┐
│ Alice                           │
├─────────────────────────────────┤
│ 1. Schreibt Nachricht           │
│ 2. Berechnet Hash der Nachricht │
│ 3. Verschlüsselt Hash mit       │
│    ihrem PRIVATEN Schlüssel     │
│                                  │
│ → Das ist die Signatur!         │
└─────────────────────────────────┘

Wichtig: Alice signiert nicht die ganze Nachricht, sondern nur einen Hash (digitaler Fingerabdruck) der Nachricht. Das ist schneller und die Signatur hat eine feste Länge.

2. Bob verifiziert die Signatur

┌─────────────────────────────────┐
│ Bob                             │
├─────────────────────────────────┤
│ 1. Erhält Nachricht + Signatur  │
│ 2. Entschlüsselt Signatur mit   │
│    Alices ÖFFENTLICHEM Schlüssel│
│ 3. Berechnet Hash der Nachricht │
│ 4. Vergleicht beide Hashes      │
│                                  │
│ ✅ Gleich? → Signatur gültig!   │
│ ❌ Unterschiedlich? → Gefälscht!│
└─────────────────────────────────┘

Was beweist eine Signatur?

✅ Authentizität: Nur Alice hat den privaten Schlüssel → Nachricht stammt von Alice ✅ Integrität: Wenn die Nachricht verändert wurde, stimmt der Hash nicht mehr ✅ Nicht-Abstreitbarkeit: Alice kann später nicht behaupten, sie hätte die Nachricht nicht geschickt

Interaktiv: Digitale Signatur

Probiere selbst aus, wie digitale Signaturen funktionieren:

Digitale Signatur

Probiere aus, wie Alice eine Nachricht signiert und Bob die Signatur verifiziert.

Nachricht von Alice:

Alices privater Schlüssel (zum Signieren):

Praktische Anwendungen

Software-Downloads:

• Programme werden vom Entwickler signiert
• Dein Betriebssystem prüft die Signatur vor der Installation
• Schützt vor manipulierter Software

E-Mail (PGP/S/MIME):

• E-Mails können signiert werden
• Empfänger kann Absender verifizieren

Digitale Verträge:

• PDF-Dokumente können signiert werden
• Rechtlich bindend (in vielen Ländern wie Unterschrift anerkannt)

Blockchain/Kryptowährungen:

• Jede Transaktion wird digital signiert
• Beweist, dass du der Besitzer der Coins bist

Diffie-Hellman Schlüsselaustausch

Wir haben gesehen, wie RSA das Schlüsselaustausch-Problem löst. Aber es gibt noch einen anderen, eleganteren Ansatz: Diffie-Hellman.

Das Prinzip

Diffie-Hellman (1976) war die erste praktische Lösung für sicheren Schlüsselaustausch. Die Idee:

Alice und Bob einigen sich öffentlich auf einen gemeinsamen geheimen Schlüssel - auch wenn ein Angreifer alles mithört!

Klingt unmöglich? Schauen wir uns an, wie's funktioniert!

Die Farben-Analogie

Stell dir vor, Alice und Bob wollen sich auf eine geheime Farbe einigen:

1. Öffentliche Basis: Alice und Bob einigen sich öffentlich auf eine Basis-Farbe: Gelb (Ein Angreifer Eve hört mit und kennt auch Gelb)

2. Private Farben:

• Alice wählt geheim: Rot
• Bob wählt geheim: Cyan (Hellblau)

3. Mischen und Austauschen:

• Alice mischt: Gelb + Rot = Orange → sendet Orange an Bob
• Bob mischt: Gelb + Cyan = Grün → sendet Grün an Alice
• Eve sieht: Gelb, Orange, Grün (aber nicht die geheimen Farben!)

4. Gemeinsames Geheimnis:

• Alice mischt: Orange + (ihr geheimes) Rot = Braun
• Bob mischt: Grün + (sein geheimes) Cyan = Braun
• Beide haben jetzt die gleiche Farbe (Braun), ohne sie jemals übertragen zu haben!

Eve kann Braun nicht herstellen, weil sie weder Rot noch Cyan kennt!

Interaktiv: Farben-Analogie

Probiere es selbst aus! Wähle geheime Farben für Alice und Bob und beobachte, wie sie zur gleichen Mischfarbe gelangen:

Diffie-Hellman mit Farben

Visualisiere den Schlüsselaustausch mit Farben! Wähle geheime Farben und beobachte, wie Alice und Bob zur gleichen Mischfarbe gelangen.

🌍 Öffentliche Basis-Farbe

Alle kennen diese Farbe:

Gelb

👩 Alice

🔒 Alices geheime Farbe:

Nur Alice kennt diese Farbe!

Rot

Blau

Magenta

👨 Bob

🔒 Bobs geheime Farbe:

Nur Bob kennt diese Farbe!

Cyan

Grün

Lila

RSA vs. Diffie-Hellman

Beide lösen das Schlüsselaustausch-Problem, aber unterschiedlich:

RSA	Diffie-Hellman
Ver- und Entschlüsselung	Nur Schlüsselaustausch
Ein Schlüsselpaar pro Person	Neues Geheimnis pro Sitzung
Langsamer	Schneller
Kann auch signieren	Nur für Schlüssel

In der Praxis: Moderne Protokolle wie TLS 1.3 (HTTPS) verwenden Diffie-Hellman für den Schlüsselaustausch und RSA für Signaturen!

Public Key Infrastructure (PKI)

Wir haben gelernt, wie asymmetrische Verschlüsselung funktioniert. Aber es gibt ein riesiges Problem, das wir bisher ignoriert haben:

Das Vertrauensproblem

Stell dir vor, Alice will Bob eine Nachricht schicken:

1. Alice braucht Bobs öffentlichen Schlüssel
2. Alice findet einen Schlüssel, der angeblich Bob gehört
3. Alice verschlüsselt die Nachricht damit

Die kritische Frage: Woher weiß Alice, dass der Schlüssel wirklich Bob gehört?

Ein Angreifer (Eve) könnte:

• Einen eigenen Schlüssel erstellen
• Behaupten, es sei Bobs Schlüssel
• Alles entschlüsseln und mitlesen!

Alice ----[Nachricht verschlüsselt mit Eves Schlüssel]----> Eve ----[weiterleitet]----> Bob
                                                            ↑
                                                    Eve liest alles!

Die Lösung: Zertifikate

Ein digitales Zertifikat ist wie ein digitaler Ausweis. Es bestätigt:

"Dieser öffentliche Schlüssel gehört wirklich zu Bob!"

Ein Zertifikat enthält:

• Den öffentlichen Schlüssel
• Den Namen des Besitzers (z.B. "Bob" oder "google.com")
• Gültigkeitsdauer (von - bis)
• Digitale Signatur einer vertrauenswürdigen Stelle

Certificate Authorities (CAs)

Aber wer erstellt diese Zertifikate? Certificate Authorities (CAs) - vertrauenswürdige Organisationen!

Bekannte CAs:

• Let's Encrypt (kostenlos)
• DigiCert
• GlobalSign
• Deutsche Telekom

Wie funktioniert's?

1. Website beantragt Zertifikat

┌─────────────────────────────────┐
│ google.com                      │
├─────────────────────────────────┤
│ 1. Erstellt Schlüsselpaar       │
│ 2. Sendet Certificate Request   │
│    an CA (mit Public Key)       │
└─────────────────────────────────┘

2. CA überprüft Identität

┌─────────────────────────────────┐
│ Certificate Authority (CA)      │
├─────────────────────────────────┤
│ 1. Prüft: Gehört die Domain     │
│    wirklich dem Antragsteller?  │
│ 2. Erstellt Zertifikat          │
│ 3. SIGNIERT es mit eigenem      │
│    Private Key                  │
│ 4. Sendet Zertifikat zurück     │
└─────────────────────────────────┘

3. Browser verifiziert Zertifikat

┌─────────────────────────────────┐
│ Dein Browser                    │
├─────────────────────────────────┤
│ 1. Verbindet zu google.com      │
│ 2. Erhält Zertifikat            │
│ 3. Prüft Signatur der CA        │
│ 4. Prüft Gültigkeit             │
│                                  │
│ ✅ Alles OK? → Zeigt Schloss 🔒 │
│ ❌ Problem? → Warnung!          │
└─────────────────────────────────┘

Vertrauenskette (Chain of Trust)

Aber wer garantiert, dass die CA vertrauenswürdig ist? Root CAs!

Root CA (im Browser eingebaut)
    ↓ signiert
Intermediate CA
    ↓ signiert
Website-Zertifikat (z.B. google.com)

Root CAs sind in deinem Browser und Betriebssystem vorinstalliert. Es gibt weltweit nur etwa 100 Root CAs - sie werden streng kontrolliert!

Zertifikat im Browser ansehen

Du kannst dir das Zertifikat jeder HTTPS-Website ansehen:

Chrome/Firefox:

1. Klicke auf das Schloss-Symbol 🔒 in der Adressleiste
2. Klicke auf "Zertifikat"
3. Schau dir den Inhalt an!

Du siehst:

• Für wen das Zertifikat ausgestellt wurde
• Von wem es signiert wurde
• Gültigkeitsdauer
• Den öffentlichen Schlüssel

Wann wird's kritisch?

🚨 Zertifikatsfehler bedeuten GEFAHR!

Wenn dein Browser warnt:

• "Zertifikat ungültig"
• "Nicht vertrauenswürdig"
• "Abgelaufen"

→ NICHT weitergehen! Die Verbindung könnte von einem Angreifer abgefangen werden!

Ausnahme: Lokale Entwicklungsserver (localhost) haben oft selbst-signierte Zertifikate - das ist OK.

Selbst-signierte Zertifikate

Statt eine CA zu verwenden, kann man auch selbst ein Zertifikat signieren. Problem: Niemand vertraut dir!

Wo verwendet:

• Lokale Entwicklung
• Interne Firmennetzwerke
• Test-Umgebungen

Nicht geeignet für: Öffentliche Websites!

Zusammenfassung

Diese erweiterten Konzepte erweitern die Kryptographie über reine Verschlüsselung hinaus:

Digitale Signaturen

✅ Beweisen Authentizität und Integrität ✅ Funktionieren "umgekehrt": Private Key verschlüsselt, Public Key entschlüsselt ✅ Verwendet für Software, E-Mails, Verträge, Blockchain

Diffie-Hellman

✅ Alternativer Ansatz zum Schlüsselaustausch ✅ Beide Seiten einigen sich auf gemeinsames Geheimnis ✅ Schneller als RSA für Schlüsselaustausch ✅ Verwendet in TLS/HTTPS

PKI und Zertifikate

✅ Lösen das Vertrauensproblem ✅ Certificate Authorities bestätigen Identität ✅ Browser/OS haben Root CAs vorinstalliert ✅ Ermöglichen sichere Webseiten (HTTPS)

Das große Bild:

• Verschlüsselung schützt vor Mitlesen
• Signaturen beweisen Identität
• Zertifikate schaffen Vertrauen
• PKI organisiert alles in einem System

Zusammen bilden diese Technologien die Grundlage für sichere Kommunikation im Internet!