mirror of
https://github.com/theoleuthardt/hwr-notes.git
synced 2026-06-06 01:21:09 +00:00
docs: add obsidian hwr docs
This commit is contained in:
theoleuthardt
parent
b2636f4b92
commit
850aa3455d
245 changed files with 30757 additions and 0 deletions
121
IT-Sicherheit/Zusammenfassungen/itsec1-3 - zusammenfassung.md
Normal file
121
IT-Sicherheit/Zusammenfassungen/itsec1-3 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,121 @@
|
|||
# IT-Sicherheit – Vorlesungszusammenfassung Foliensätze 1-3
|
||||
**Vorlesung von Gerrit Kalkbrenner | HWR Berlin | 2026**
|
||||
|
||||
---
|
||||
## 1. Einleitung
|
||||
|
||||
### Warum IT-Sicherheit wichtig ist
|
||||
|
||||
IT-Sicherheit ist ein zentrales Thema der modernen Informationstechnologie. Fast täglich berichten Medien über Daten-Diebstahl, Spionage und Sabotage. Die Kernprobleme dabei: Ausgespähte Daten haben einen erheblichen finanziellen Wert, und viele Daten werden per Funk übertragen – und sind damit prinzipiell öffentlich zugänglich.
|
||||
|
||||
### Warum IT-Sicherheit so schwierig ist
|
||||
|
||||
IT-Sicherheit muss **vollständig** sein. Es gilt das Prinzip der Kette: Das schwächste Glied bestimmt die Gesamtsicherheit. Hinzu kommt das Problem fehlerhafter Software – die Zahl der veröffentlichten Sicherheitslücken ist von 4.383 im Jahr 2011 auf über 11.000 im Jahr 2017 gestiegen (Quelle: Hasso Plattner Institut).
|
||||
|
||||
### Die 3 (+1) Ziele der Datensicherheit
|
||||
|
||||
1. **Vertraulichkeit (Geheimhaltung)** – Nur Befugte dürfen Daten einsehen.
|
||||
2. **Integrität (Unversehrtheit)** – Daten dürfen nicht unbefugt verändert werden.
|
||||
3. **Verbindlichkeit (Nichtabstreitbarkeit)** – Vorgänge sind nachvollziehbar und verifizierbar.
|
||||
4. **Verfügbarkeit** – Befugten ist der Zugriff jederzeit gewährleistet.
|
||||
|
||||
### Angreifer und ihre Motivation
|
||||
|
||||
Motivationen für Angriffe reichen von Spaß an der Technik, Neugierde und Herausforderung über Zerstörungswut und Geld bis hin zu nationaler Sicherheit. Zu den Angreifergruppen zählen Hacker, Unternehmens-Cracker, IT-Spione, IT-Terroristen, professionelle Kriminelle, Vandalen und sogar Behörden.
|
||||
|
||||
### Telekommunikation und ihre Geschichte
|
||||
|
||||
Kommunikation hat sich von Rauchzeichen, Signalfahnen und Lichtzeichen über die Telegraphie (das „viktorianische Internet") bis hin zu modernen Computernetzwerken entwickelt. Schon bei der Telegraphie war Abhörbarkeit ein Problem – sowohl auf Verbindungswegen als auch in Vermittlungsstationen. Als Gegenmaßnahmen wurden Beteiligte verbeamtet, Kabel regelmäßig geprüft und spezielle Projekte wie Polykom (verteiltes Regieren Berlin/Bonn mit evakuierten Glasfaserröhren) realisiert.
|
||||
|
||||
### Standards und Schichtenmodell
|
||||
|
||||
Wichtige Standards umfassen das ISO-OSI-7-Schichtenmodell, ITU-Standards (ehemals CCITT) sowie Internet-Standards (RFCs, Drafts, Internet Standards). Das OSI-Modell gliedert sich in sieben Schichten: Physical, Data Link, Network, Transport, Session, Presentation und Application.
|
||||
|
||||
### Netzwerktypen
|
||||
|
||||
Netzwerke werden nach Reichweite klassifiziert: von VLAN/PAN auf wenigen Metern über LAN (Raum/Gebäude/Campus) und MAN (Stadt) bis hin zu WAN (Land/Kontinent) und dem globalen Internet (GAN).
|
||||
|
||||
---
|
||||
## 2. Kryptographische Primitiven
|
||||
|
||||
### Grundprinzip
|
||||
|
||||
Kryptographische Funktionen schaffen nicht per se Sicherheit – aber mit ihrer Hilfe kann ein sicheres System konstruiert werden. Sie bilden den „Baukasten" für alle Sicherheitsmechanismen.
|
||||
|
||||
### Vertrauliche Nachrichten – Symmetrische Verschlüsselung
|
||||
|
||||
Um Nachrichten vertraulich zu halten, wird ein **symmetrischer Verschlüsselungsalgorithmus (Chiffre)** verwendet. Dabei gibt es zwei zentrale Funktionen: **Encrypt** (Verschlüsseln) und **Decrypt** (Entschlüsseln). Beide Seiten verwenden denselben geheimen Schlüssel.
|
||||
|
||||
### Authentische Nachrichten – MAC
|
||||
|
||||
Ein **Message Authentication Code (MAC)** stellt sicher, dass eine Nachricht tatsächlich vom angegebenen Absender stammt. Dabei wird die Nachricht im Klartext zusammen mit einem chiffrierten Fingerabdruck übertragen. Der Empfänger kann mit dem gemeinsamen Schlüssel prüfen, ob die Nachricht authentisch ist.
|
||||
|
||||
### Schlüsselaustausch – Diffie-Hellman
|
||||
|
||||
Das zentrale Problem: Wie gelangen zwei Parteien zu einem gemeinsamen geheimen Schlüssel? Dieses Problem war lange ungelöst, bis in den 1970er Jahren die **asymmetrische Kryptografie** erfunden wurde. Beim **Diffie-Hellman-Verfahren** erzeugen Alice und Bob jeweils private Schlüssel, tauschen öffentliche Schlüssel aus und berechnen daraus ein gemeinsames Geheimnis – ohne dass ein Lauscher dieses rekonstruieren kann.
|
||||
|
||||
### RSA – Asymmetrische Verschlüsselung
|
||||
|
||||
Aufbauend auf Diffie-Hellman wurde **RSA** (Ron Rivest, Adi Shamir, Leonard Adelman) entwickelt. RSA arbeitet mit einem Schlüsselpaar und bietet zwei Funktionen:
|
||||
|
||||
- **Verschlüsseln / Entschlüsseln** – Der Sender verschlüsselt mit dem öffentlichen Schlüssel des Empfängers; nur der Empfänger kann mit seinem privaten Schlüssel entschlüsseln.
|
||||
- **Signieren / Signatur prüfen** – Der Sender signiert mit seinem privaten Schlüssel; jeder kann die Signatur mit dem öffentlichen Schlüssel des Senders verifizieren.
|
||||
|
||||
### Kryptographische Hash-Funktionen
|
||||
|
||||
Hash-Funktionen erzeugen einen digitalen „Fingerabdruck" einer Nachricht beliebiger Länge. Über eine **One-Way-Hashfunktion** wird eine kryptografische Prüfsumme berechnet, mit der die Integrität einer Nachricht überprüft werden kann.
|
||||
|
||||
**Fazit:** Symmetrische Verschlüsselung, asymmetrische Verschlüsselung (RSA), MAC und Hash-Funktionen – mehr kryptographische Grundbausteine braucht man nicht.
|
||||
|
||||
---
|
||||
## 3. Sicherheitsunterweisung – Praxisbeispiel Forschungszentrum Jülich
|
||||
|
||||
### Motivation
|
||||
|
||||
IT-Sicherheitsmaßnahmen werden oft als lästig und kontraproduktiv empfunden. Die Analogie zu Sicherheitsgurten im Auto zeigt jedoch: Auch wenn sie unbequem sind, schützen sie im Ernstfall.
|
||||
|
||||
### Häufige Gegenargumente und Antworten
|
||||
|
||||
- *„Ich surfe selten im Internet"* → Angriffe benötigen oft keine aktive Mitwirkung des Nutzers.
|
||||
- *„Auf meinem Rechner ist kaum etwas drauf"* → Übernommene Systeme können als Sprungbrett für weitere Angriffe dienen.
|
||||
- *„Meine Forschung wird ohnehin veröffentlicht"* → Unveröffentlichte Erkenntnisse, Forschungsmethoden und persönliche Daten sind dennoch schützenswert.
|
||||
|
||||
### Grundwerte und Bedrohungen
|
||||
|
||||
Die vier Grundwerte von IT-Ressourcen (Vertraulichkeit, Integrität, Verfügbarkeit, Verbindlichkeit) können durch verschiedene Bedrohungen gefährdet werden: vorsätzliche Manipulation, technisches Versagen, menschliches Fehlverhalten, personelle/organisatorische Mängel und Naturkatastrophen.
|
||||
|
||||
### Risikobewertung
|
||||
|
||||
Das Risiko R ergibt sich aus der Formel **R = S × W** (Schadenshöhe × Eintrittswahrscheinlichkeit). IT-Sicherheitsmaßnahmen zielen darauf ab, das Risiko auf ein tragbares Niveau zu reduzieren. Was als „tragbar" gilt, definiert der Eigentümer der Ressource.
|
||||
|
||||
### BSI IT-Grundschutz
|
||||
|
||||
Der IT-Grundschutzkatalog des BSI (Ausgabe 2011) umfasst 4.068 Seiten mit 583 Gefährdungen, 1.327 Maßnahmen und 85 Bausteinen. Die Kernidee: Standard-Sicherheitsmaßnahmen für standardisierte Systeme, wodurch für ca. 80 % der Systeme mit normalem Schutzbedarf keine aufwändige individuelle Risikoanalyse nötig ist.
|
||||
|
||||
### Schutzklassen
|
||||
|
||||
- **Sehr hoch:** Ausfallzeit unter 1 Stunde nicht tolerabel, finanzielle Schäden über 10 Mio. €
|
||||
- **Hoch:** Erhebliche Beeinträchtigungen, Ausfallzeit 1–24 h, Schäden über 2 Mio. €
|
||||
- **Normal:** Beeinträchtigungen tolerabel, Ausfallzeit über 24 h akzeptabel
|
||||
|
||||
### IT-Grundschutzregeln im FZJ
|
||||
|
||||
Das FZJ nutzt ein dreistufiges Konzept (IT-Sicherheitsrichtlinie → Grundschutzregeln → spezielle Regeln) mit 25 Regeln in sieben Kategorien: Infrastruktur, Organisation, Personal, Daten, Hardware/Software, Kommunikation und Notfallvorsorge.
|
||||
|
||||
---
|
||||
## Themenübersicht der Veranstaltung
|
||||
|
||||
Die Vorlesung behandelt insgesamt folgende Themen: Sichtweisen auf Cyber-Sicherheit, Kryptographie, Hardware- und Sicherheitsmodule, digitale Signaturen und Zertifikate, Identifikation und Authentifikation, Trusted Computing, Cyber-Sicherheit Frühwarnung, Firewall-Systeme, IPSec, TLS/SSL, DDoS-Angriffe, Email-Sicherheit, Blockchain, KI und Cyber-Sicherheit, Social Web Sicherheit sowie Wirtschaftlichkeit.
|
||||
|
||||
## Bewertung
|
||||
|
||||
- Klausur: 80 %
|
||||
- Hausaufgaben: 10 % (z. B. Public-Private-Schlüsselpaar generieren)
|
||||
- Kurzvortrag: 10 % (Bericht über einen Sicherheitsvorfall)
|
||||
|
||||
## Literatur
|
||||
|
||||
- David Wong: *Kryptografie in der Praxis* (dpunkt)
|
||||
- Norbert Pohlmann: *Cyber-Sicherheit* (Springer)
|
||||
- Claudia Eckert: *IT-Sicherheit* (De Gruyter)
|
||||
- c't Magazin (regelmäßige Berichte, c't Security, c't DSGVO)
|
||||
319
IT-Sicherheit/Zusammenfassungen/itsec4 - zusammenfassung.md
Normal file
319
IT-Sicherheit/Zusammenfassungen/itsec4 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,319 @@
|
|||
# Datenforensik
|
||||
|
||||
# 1. Grundlagen der Datenforensik
|
||||
|
||||
## 1.1 Definition
|
||||
|
||||
**Datenforensik** (auch IT-Forensik oder digitale Forensik) ist die systematische Untersuchung von IT-Systemen zur:
|
||||
|
||||
- Feststellung eines Tatbestandes
|
||||
- Identifizierung von Tätern
|
||||
- Rekonstruktion eines Vorfalls
|
||||
- gerichtsfesten Sicherung digitaler Beweise
|
||||
|
||||
Sie ist ein interdisziplinäres Feld aus:
|
||||
|
||||
- Informatik
|
||||
- Netzwerktechnik
|
||||
- Betriebssystemtechnik
|
||||
- Recht
|
||||
- Kriminalistik
|
||||
|
||||
---
|
||||
|
||||
## 1.2 Zielsetzung
|
||||
|
||||
Zentrale Ziele einer forensischen Untersuchung:
|
||||
|
||||
- 🔎 **Rekonstruktion des Tathergangs**
|
||||
- 👤 **Identifikation beteiligter Personen**
|
||||
- ⏱ **Bestimmung des Tatzeitraums (Timeline)**
|
||||
- 📦 **Ermittlung des Schadensumfangs**
|
||||
- ⚖ **Gerichtsfeste Beweisführung**
|
||||
|
||||
---
|
||||
|
||||
# 2. Arten von Computerkriminalität
|
||||
|
||||
## 2.1 Klassische Delikte mit IT-Bezug
|
||||
|
||||
- Betrug
|
||||
- Erpressung
|
||||
- Urheberrechtsverletzung
|
||||
- Geheimnisverrat
|
||||
- Verbreitung illegaler Inhalte
|
||||
|
||||
## 2.2 Computerkriminalität im engeren Sinne
|
||||
|
||||
- Ausspähen von Daten
|
||||
- Abfangen von Daten
|
||||
- Computerbetrug
|
||||
- Datenveränderung
|
||||
- Computersabotage
|
||||
- Fälschung beweiserheblicher Daten
|
||||
|
||||
---
|
||||
|
||||
# 3. Motivation von Tätern
|
||||
|
||||
- 💰 finanzielle Interessen
|
||||
- 🧠 technische Neugier
|
||||
- 🧨 Rache oder Frustration
|
||||
- 🏛 politische Motivation
|
||||
- 🌍 staatlich organisierte Spionage
|
||||
|
||||
---
|
||||
|
||||
# 4. Forensischer Untersuchungsprozess
|
||||
|
||||
Die Untersuchung erfolgt strukturiert und nachvollziehbar.
|
||||
|
||||
## 4.1 Standardprozess (SAP-Modell)
|
||||
|
||||
1. **Identifizierung**
|
||||
2. **Sicherstellung (Secure)**
|
||||
3. **Analyse**
|
||||
4. **Präsentation**
|
||||
|
||||
---
|
||||
|
||||
# 5. Phase 1: Identifizierung
|
||||
|
||||
Ziel: Feststellung, ob ein Sicherheitsvorfall vorliegt.
|
||||
|
||||
### Aufgaben:
|
||||
|
||||
- Dokumentation der vorgefundenen Situation
|
||||
- Bestandsaufnahme betroffener Systeme
|
||||
- Identifikation relevanter Datenquellen:
|
||||
- Log-Dateien
|
||||
- Server
|
||||
- Endgeräte
|
||||
- Netzwerkgeräte
|
||||
- Cloud-Systeme
|
||||
|
||||
### Leitfragen:
|
||||
|
||||
- Wer hatte Zugriff?
|
||||
- Wann trat der Vorfall auf?
|
||||
- Welche Systeme sind betroffen?
|
||||
|
||||
---
|
||||
|
||||
# 6. Phase 2: Sicherstellung von Beweisen
|
||||
|
||||
## 6.1 Grundprinzipien
|
||||
|
||||
- Minimale Veränderung der Originaldaten
|
||||
- Lückenlose Dokumentation (Chain of Custody)
|
||||
- Erstellung forensischer Kopien
|
||||
- Sicherung der Integrität durch Hash-Werte
|
||||
|
||||
## 6.2 Forensisches Duplikat
|
||||
|
||||
- Bitweise 1:1-Kopie eines Datenträgers
|
||||
- Keine logische Kopie!
|
||||
- Einsatz von Write-Blockern
|
||||
- Dokumentation von:
|
||||
- Datum
|
||||
- Uhrzeit
|
||||
- beteiligte Personen
|
||||
- verwendete Tools
|
||||
|
||||
## 6.3 Integritätsnachweis
|
||||
|
||||
- Bildung kryptographischer Hash-Werte (z. B. SHA-256)
|
||||
- Vergleich vor und nach Analyse
|
||||
- Sicherstellung der Unverändertheit
|
||||
|
||||
---
|
||||
|
||||
# 7. Flüchtige vs. nicht-flüchtige Daten
|
||||
|
||||
## 7.1 Flüchtige Daten (RAM)
|
||||
|
||||
Vor Abschalten sichern:
|
||||
|
||||
- angemeldete Benutzer
|
||||
- laufende Prozesse
|
||||
- Netzwerkverbindungen
|
||||
- offene Dateien
|
||||
- gespeicherte Schlüssel im Speicher
|
||||
|
||||
Problem:
|
||||
Ein einfaches Ausschalten zerstört diese Beweise.
|
||||
|
||||
## 7.2 Nicht-flüchtige Daten
|
||||
|
||||
- Festplatten
|
||||
- SSD
|
||||
- USB-Sticks
|
||||
- Smartphones
|
||||
- Cloud-Speicher
|
||||
|
||||
---
|
||||
|
||||
# 8. Live-Response vs. Offline-Analyse
|
||||
|
||||
## 8.1 Live-Response
|
||||
|
||||
Analyse eines laufenden Systems.
|
||||
|
||||
Vorteile:
|
||||
- Sicherung flüchtiger Daten
|
||||
- Erkennung von Rootkits
|
||||
|
||||
Risiken:
|
||||
- Veränderung des Systems
|
||||
- Manipulation durch Schadsoftware
|
||||
|
||||
## 8.2 Offline-Analyse
|
||||
|
||||
- Untersuchung auf separatem Analyse-System
|
||||
- Arbeit mit forensischem Image
|
||||
- bevorzugte Methode bei gerichtlichen Verfahren
|
||||
|
||||
---
|
||||
|
||||
# 9. Phase 3: Forensische Analyse
|
||||
|
||||
## 9.1 Anforderungen an den Analysten
|
||||
|
||||
- tiefgehende OS-Kenntnisse
|
||||
- Verständnis von Dateisystemen
|
||||
- Netzwerkforensik
|
||||
- Kenntnisse aktueller Angriffstechniken
|
||||
- Improvisationsfähigkeit
|
||||
|
||||
## 9.2 Analysebereiche
|
||||
|
||||
### Dateisystemanalyse
|
||||
- gelöschte Dateien
|
||||
- versteckte Dateien
|
||||
- Zeitstempelanalyse (MAC-Times)
|
||||
|
||||
### Log-Analyse
|
||||
- Authentifizierungsversuche
|
||||
- Administratorzugriffe
|
||||
- ungewöhnliche Aktivitäten
|
||||
|
||||
### Netzwerkforensik
|
||||
- Analyse von Netzwerkverkehr
|
||||
- Rekonstruktion von Datenströmen
|
||||
- Identifikation externer Verbindungen
|
||||
|
||||
### Malware-Analyse
|
||||
- statische Analyse
|
||||
- dynamische Analyse
|
||||
- Reverse Engineering
|
||||
|
||||
---
|
||||
|
||||
# 10. Timeline-Erstellung
|
||||
|
||||
Erstellung einer chronologischen Ereigniskette:
|
||||
|
||||
- Login-Zeiten
|
||||
- Dateiänderungen
|
||||
- Prozessstarts
|
||||
- Netzwerkverbindungen
|
||||
|
||||
Ziel:
|
||||
Rekonstruktion des exakten Tathergangs.
|
||||
|
||||
---
|
||||
|
||||
# 11. Phase 4: Aufbereitung und Präsentation
|
||||
|
||||
## 11.1 Berichtserstellung
|
||||
|
||||
Ein forensischer Bericht enthält:
|
||||
|
||||
- Beschreibung des Vorfalls
|
||||
- angewandte Methoden
|
||||
- verwendete Werkzeuge
|
||||
- Analyseergebnisse
|
||||
- Schlussfolgerungen
|
||||
|
||||
## 11.2 Gerichtsfeste Präsentation
|
||||
|
||||
Erforderlich:
|
||||
|
||||
- Nachvollziehbarkeit
|
||||
- Reproduzierbarkeit
|
||||
- Beweiskette
|
||||
- Integritätsnachweise
|
||||
|
||||
Beweise müssen:
|
||||
|
||||
- unverändert
|
||||
- dokumentiert
|
||||
- überprüfbar sein
|
||||
|
||||
---
|
||||
|
||||
# 12. Incident Response vs. Forensik
|
||||
|
||||
## Incident Response
|
||||
|
||||
- schnelle Wiederherstellung des Betriebs
|
||||
- Schadensbegrenzung
|
||||
- Schließen von Sicherheitslücken
|
||||
|
||||
## Forensik
|
||||
|
||||
- Täterermittlung
|
||||
- gerichtliche Verwertung
|
||||
- langfristige Ursachenanalyse
|
||||
|
||||
---
|
||||
|
||||
# 13. Beweiskette (Chain of Custody)
|
||||
|
||||
Dokumentiert:
|
||||
|
||||
- Wer hatte wann Zugriff?
|
||||
- Wo wurde das Beweismittel aufbewahrt?
|
||||
- Welche Maßnahmen wurden durchgeführt?
|
||||
|
||||
Fehlende Dokumentation kann Beweise unbrauchbar machen.
|
||||
|
||||
---
|
||||
|
||||
# 14. Typische Fehler bei der Spurensicherung
|
||||
|
||||
- vorschnelles Abschalten des Systems
|
||||
- Arbeiten auf dem Originalsystem
|
||||
- fehlende Hash-Werte
|
||||
- unvollständige Dokumentation
|
||||
- Vermischung von Incident Response und Forensik
|
||||
|
||||
---
|
||||
|
||||
# 15. Moderne Herausforderungen
|
||||
|
||||
- Verschlüsselte Datenträger
|
||||
- Cloud-Umgebungen
|
||||
- Container und virtuelle Maschinen
|
||||
- Smartphones
|
||||
- flüchtige Malware im RAM
|
||||
- Anti-Forensik-Techniken
|
||||
|
||||
---
|
||||
|
||||
# 16. Gesamtbedeutung
|
||||
|
||||
Datenforensik ist:
|
||||
|
||||
- technisch anspruchsvoll
|
||||
- rechtlich sensibel
|
||||
- organisatorisch komplex
|
||||
|
||||
Sie bildet die Grundlage für:
|
||||
|
||||
- Strafverfolgung
|
||||
- interne Ermittlungen
|
||||
- Compliance-Prüfungen
|
||||
- IT-Sicherheitsverbesserungen
|
||||
|
||||
In modernen IT-Infrastrukturen ist sie ein zentraler Bestandteil professioneller Sicherheitsarchitekturen.
|
||||
|
|
@ -0,0 +1,577 @@
|
|||
# Zusammenfassung: Kryptographie
|
||||
|
||||
**Vorlesung IT-Sicherheit – Gerrit Kalkbrenner, HWR Berlin, 2026** _Erweitert mit aktuellen Informationen und Diagrammen_
|
||||
|
||||
---
|
||||
## 1. Einführung
|
||||
|
||||
Kryptographie ist eine moderne, mathematisch geprägte Wissenschaft mit einer Geschichte von über 3.000 Jahren. Bekannte historische Beispiele sind das Babington-Komplott (1586), das Zimmermann-Telegramm (Erster Weltkrieg) und die Enigma-Entschlüsselung im Zweiten Weltkrieg. Heute ist Kryptographie allgegenwärtig – in Mobilfunk, EC-Karten, SSL/TLS, Bitcoin, Wegfahrsperren und vielen weiteren Bereichen.
|
||||
|
||||
> **Wichtig:** Kryptographie ≠ Sicherheit. Sie ist ein unverzichtbarer Baustein, aber kein vollständiger Ersatz für ein ganzheitliches Sicherheitskonzept. _(Quelle: Bart Preneel, „Cryptographic Algorithms and Protocols for Network Security", 2008)_
|
||||
|
||||
---
|
||||
|
||||
## 2. Grundlagen der Verschlüsselung
|
||||
|
||||
### Begriffe
|
||||
|
||||
|Begriff|Bedeutung|
|
||||
|---|---|
|
||||
|**Klartext** (Plaintext)|Die Originaldaten|
|
||||
|**Schlüsseltext / Chiffrat** (Ciphertext)|Die transformierten, unlesbaren Daten|
|
||||
|**Verschlüsselung**|Die mathematische Transformation|
|
||||
|**Entschlüsselung**|Die Umkehrung der Transformation|
|
||||
|**Kryptoanalyse**|Analyse eines Kryptosystems zur Bewertung seiner Stärke|
|
||||
|**Steganographie**|Verbergen der _Existenz_ einer Information (z. B. digitale Wasserzeichen)|
|
||||
|
||||
### Kryptographisches System (6-Tupel)
|
||||
|
||||
Ein Kryptosystem wird formal als **(M, C, K_E, K_D, E, D)** beschrieben:
|
||||
|
||||
```
|
||||
Klartext m ──► [ Verschlüsselung E(m, ke) ] ──► Chiffrat c
|
||||
▲
|
||||
Schlüssel ke
|
||||
|
||||
Chiffrat c ──► [ Entschlüsselung D(c, kd) ] ──► Klartext m
|
||||
▲
|
||||
Schlüssel kd
|
||||
|
||||
Bedingung: D( E(m, ke), kd ) = m
|
||||
```
|
||||
|
||||
**Kerckhoffs-Prinzip:** Der Algorithmus darf öffentlich bekannt sein – die Sicherheit beruht allein auf der Geheimhaltung des Schlüssels. Ein Verschlüsselungsverfahren sollte mindestens **5 Jahre öffentlich diskutiert** werden, bevor es eingesetzt wird.
|
||||
|
||||
### Kryptoanalyse-Strategien
|
||||
|
||||
|Angriffsart|Was der Angreifer kennt|Stärke|
|
||||
|---|---|---|
|
||||
|**Ciphertext-only**|Nur den Schlüsseltext|Schwächster Angriff|
|
||||
|**Known-plaintext**|Klartext-/Schlüsseltext-Paare|Mittel|
|
||||
|**Chosen-plaintext**|Kann beliebige Klartexte verschlüsseln|Stärkster Angriff|
|
||||
|**Brute Force**|Alle Schlüssel werden durchprobiert|Immer möglich|
|
||||
|**Statistische Analyse**|Buchstaben-/Worthäufigkeiten im Chiffretext|Gegen schwache Verfahren|
|
||||
|**Trial & Error**|Eingeschränkte Schlüsselräume (z. B. nur Wörter)|Gegen schlechte Schlüssel|
|
||||
|
||||
> **Rainbow Tables** ermöglichen vorberechnete Brute-Force-Angriffe – Qualität der Schlüsselgenerierung ist entscheidend!
|
||||
|
||||
### Sicherheitskategorien und Schlüssellängen
|
||||
|
||||
- **Absolute Sicherheit:** Theoretisch unmöglich zu brechen (nur mit One-Time-Pad, OTP)
|
||||
- **Praktische/Rechnerische Sicherheit:** Theoretisch brechbar, aber der Aufwand ist prohibitiv hoch
|
||||
|
||||
**Brute-Force-Aufwand bei 10⁹ Versuchen/Sekunde:**
|
||||
|
||||
```
|
||||
Schlüssellänge │ Mögliche Schlüssel │ Aufwand (Jahre)
|
||||
───────────────┼────────────────────┼──────────────────────
|
||||
8 Bit │ 256 │ < 0,000001
|
||||
40 Bit │ ~1,1 × 10¹² │ 0,00002
|
||||
56 Bit │ ~7,2 × 10¹⁶ │ ~1,14 ← DES (veraltet!)
|
||||
64 Bit │ ~1,8 × 10¹⁹ │ ~292
|
||||
128 Bit │ ~3,4 × 10³⁸ │ > 5 × 10²¹ ← AES-128
|
||||
256 Bit │ ~1,2 × 10⁷⁷ │ > 10⁵⁹ ← AES-256
|
||||
```
|
||||
|
||||
> Aufgrund steigender Rechenleistung (und Quantencomputer) ist alle **10–15 Jahre** ein Algorithmenwechsel notwendig: DES 56 Bit (1977) → AES 128 Bit (2001) → AES 256 Bit (empfohlen für die nächsten ~20 Jahre)
|
||||
>
|
||||
> _Quelle: BSI TR-02102-1, Version 2026-01 – [bsi.bund.de](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf)_
|
||||
|
||||
---
|
||||
|
||||
## 3. Elementarverschlüsselungen
|
||||
|
||||
### Einmal-Schlüssel (One-Time-Pad, OTP)
|
||||
|
||||
```
|
||||
Klartext: K R Y P T O L O G I E
|
||||
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
|
||||
Schlüssel: (zufällig, gleiche Länge, nur einmal verwenden!)
|
||||
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ XOR (mod 2)
|
||||
Chiffrat: ? ? ? ? ? ? ? ? ? ? ?
|
||||
```
|
||||
|
||||
- Das einzig **absolut sichere** Verfahren (mathematisch beweisbar – Shannon 1949)
|
||||
- Schlüssel muss mindestens so lang wie die Nachricht sein
|
||||
- Schlüssel darf **niemals wiederverwendet** werden
|
||||
- Wurde für den „Heißen Draht" Washington–Moskau genutzt
|
||||
- Im kommerziellen Einsatz unpraktisch (Schlüsselverteilungsproblem)
|
||||
|
||||
### Monoalphabetische Substitution
|
||||
|
||||
```
|
||||
Klartext: A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
|
||||
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
|
||||
Chiffre: G W X V L O A K U B C N D R M F H Y P Q T Z E I J S
|
||||
|
||||
Beispiel: KRYPTOLOGIE → CYJFQMNMAUL
|
||||
```
|
||||
|
||||
Jedes Zeichen wird durch ein **festes** anderes ersetzt. Leicht durch **Häufigkeitsanalyse** zu brechen:
|
||||
|
||||
```
|
||||
Häufigkeit in Deutsch (Auszug):
|
||||
E: 17,4% ████████████████████
|
||||
N: 9,8% ███████████
|
||||
I: 7,6% ████████
|
||||
S: 7,3% ████████
|
||||
R: 7,0% ███████
|
||||
A: 6,5% ███████
|
||||
...
|
||||
```
|
||||
|
||||
### Polyalphabetische Substitution (Vigenère)
|
||||
|
||||
```
|
||||
Klartext: K R Y P T O L O G I E
|
||||
Schlüssel: 5 3 2 5 3 2 5 3 2 5 3 (wird wiederholt)
|
||||
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
|
||||
Chiffrat: O T Z T V P P Q H M G
|
||||
```
|
||||
|
||||
Verwendet mehrere Alphabete (gesteuert durch einen Schlüssel). Verdeckt Häufigkeitsverteilungen besser als monoalphabetische Substitution, aber bei langen Texten durch Kasiski-Test und statistische Analyse brechbar.
|
||||
|
||||
### Transpositionsverfahren
|
||||
|
||||
```
|
||||
Zick-Zack (Tiefe 5), Klartext: L-A-B-O-R-F-Ü-R-V-E-R-T-E-I-L-T-E-S-Y-S-T-E-M-E
|
||||
|
||||
L R L E
|
||||
A Ü - I T T M
|
||||
B F V E E S E
|
||||
O - E T - Y
|
||||
R R S
|
||||
|
||||
→ Schlüsseltext: LRLE AÜ-IT TM BFVEESEД0-ET-Y-NRRSU
|
||||
```
|
||||
|
||||
Die Zeichen werden **permutiert** (vertauscht), nicht ersetzt. Historisches Beispiel: Spartanische Skytale (~500 v. Chr.)
|
||||
|
||||
---
|
||||
|
||||
## 4. Symmetrische Verschlüsselung (Private-Key)
|
||||
|
||||
Sender und Empfänger verwenden **denselben geheimen Schlüssel**.
|
||||
|
||||
```
|
||||
Geheimer Schlüssel K
|
||||
│ │
|
||||
▼ ▼
|
||||
Alice ──[m]──► [ E_K ] ──[c]──► [ D_K ] ──[m]──► Bob
|
||||
Verschlüsseln Entschlüsseln
|
||||
```
|
||||
|
||||
**Schlüsselverwaltungsproblem:** Bei _n_ Teilnehmern werden **n(n−1)/2** Schlüssel benötigt:
|
||||
|
||||
- 12 Partner → 66 Schlüssel
|
||||
- 100 Partner → 4.950 Schlüssel
|
||||
- 1.000 Partner → 499.500 Schlüssel
|
||||
|
||||
### Überblick: Symmetrische Algorithmen
|
||||
|
||||
|Verfahren|Schlüssellänge|Blockgröße|Status|
|
||||
|---|---|---|---|
|
||||
|DES|56 Bit|64 Bit|❌ Veraltet (1998 in 22h gebrochen)|
|
||||
|Triple-DES (2 Keys)|112 Bit|64 Bit|⚠️ Auslaufend|
|
||||
|Triple-DES (3 Keys)|168 Bit|64 Bit|⚠️ Auslaufend|
|
||||
|IDEA|128 Bit|64 Bit|✅ Als stark betrachtet|
|
||||
|RC4|variabel|Strom|❌ Veraltet (gebrochen)|
|
||||
|Blowfish|variabel|64 Bit|⚠️ Nicht mehr empfohlen|
|
||||
|**AES-128**|**128 Bit**|**128 Bit**|✅ **Aktueller Standard**|
|
||||
|**AES-256**|**256 Bit**|**128 Bit**|✅ **Empfohlen für Langzeitschutz**|
|
||||
|
||||
### AES (Advanced Encryption Standard) – Aufbau einer Runde
|
||||
|
||||
Entwickelt von Joan Daemen und Vincent Rijmen als „Rijndael", 2001 als FIPS 197 standardisiert. **Patentfrei**.
|
||||
|
||||
**Rundenanzahl nach Schlüssel- und Blocklänge:**
|
||||
|
||||
```
|
||||
Schlüssellänge │ 128 Bit │ 192 Bit │ 256 Bit
|
||||
───────────────┼─────────┼─────────┼─────────
|
||||
128 Bit │ 10 │ 12 │ 14
|
||||
192 Bit │ 12 │ 12 │ 14
|
||||
256 Bit │ 14 │ 14 │ 14
|
||||
```
|
||||
|
||||
**Jede Runde in 4 Schritten (der interne Zustand ist eine 4×4-Byte-Matrix):**
|
||||
|
||||
```
|
||||
┌──────────────────────────────────────────────────────────┐
|
||||
│ Runde i │
|
||||
│ │
|
||||
│ [4×4 Byte-Matrix] │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 1. SubBytes – Jedes Byte durch S-Box ersetzen │
|
||||
│ (nichtlinear, basiert auf Galoisfeld GF(2⁸)) │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 2. ShiftRows – Zeilen zyklisch verschieben │
|
||||
│ Zeile 0: keine Verschiebung │
|
||||
│ Zeile 1: 1 Byte nach links │
|
||||
│ Zeile 2: 2 Bytes nach links │
|
||||
│ Zeile 3: 3 Bytes nach links │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 3. MixColumns – Spalten mit fester MDS-Matrix │
|
||||
│ multiplizieren (Diffusion, Galoisfeld GF(2⁸)) │
|
||||
│ [entfällt in der letzten Runde!] │
|
||||
│ │ │
|
||||
│ ▼ │
|
||||
│ 4. AddRoundKey – XOR mit Rundenschlüssel │
|
||||
│ (aus Key-Schedule erzeugt) │
|
||||
└──────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
> **Warum ist AES sicher?** SubBytes + MixColumns liefern **Konfusion und Diffusion** (Shannon): Ein einzelnes geändertes Eingabebit beeinflusst nach 2 Runden statistisch alle 128 Ausgabebits (Lawineneffekt). _Quelle: NIST FIPS 197 – [csrc.nist.gov](https://csrc.nist.gov/pubs/fips/197/final)_
|
||||
|
||||
### AES-Betriebsmodi im Vergleich
|
||||
|
||||
```
|
||||
ECB (Electronic Codebook) – NICHT empfohlen!
|
||||
┌─────┐ ┌─────┐ ┌─────┐
|
||||
│ P₁ │ │ P₂ │ │ P₃ │ ← gleiche Blöcke
|
||||
└──┬──┘ └──┬──┘ └──┬──┘
|
||||
│E(K) │E(K) │E(K) ← gleicher Schlüssel
|
||||
└──┴──┘ └──┴──┘ └──┴──┘
|
||||
│ C₁ │ │ C₂ │ │ C₃ │ ← gleiche Chiffrate! Muster sichtbar
|
||||
└─────┘ └─────┘ └─────┘
|
||||
|
||||
CBC (Cipher Block Chaining) – Verkettung
|
||||
IV──►XOR◄──────────────────────────────
|
||||
│P₁ ┌──►XOR◄──────────────
|
||||
▼ │ │P₂ ┌──►XOR
|
||||
E(K)────►C₁┘ ▼ │ │P₃
|
||||
E(K)────►C₂──┘ ▼
|
||||
E(K)────►C₃
|
||||
|
||||
GCM (Galois/Counter Mode) – Authenticated Encryption
|
||||
Counter: CTR₀ CTR₁ CTR₂ CTR₃ ← Zähler, eindeutig pro Nachricht
|
||||
│E(K) │E(K) │E(K) │E(K)
|
||||
▼ ▼ ▼ ▼
|
||||
Auth XOR XOR XOR XOR
|
||||
tag P₁►C₁ P₂►C₂ P₃►C₃
|
||||
└────GHASH────────► Auth-Tag
|
||||
(Integrität + Vertraulichkeit in einem Schritt)
|
||||
```
|
||||
|
||||
**Modus-Empfehlungen laut BSI TR-02102-1 (2026-01):**
|
||||
|
||||
|Modus|Vertraulichkeit|Integrität|BSI-Status|Einsatz|
|
||||
|---|---|---|---|---|
|
||||
|ECB|⚠️ Schwach|❌|❌ Nicht empfohlen|–|
|
||||
|CBC|✅|❌ nur mit MAC|⚠️ Mit HMAC|Ältere Systeme|
|
||||
|CFB|✅|❌ nur mit MAC|⚠️ Mit HMAC|Zeichenorientiert|
|
||||
|OFB|✅|❌ nur mit MAC|⚠️ Mit HMAC|Fehleranfällige Kanäle|
|
||||
|CTR|✅|❌ nur mit MAC|⚠️ Mit HMAC|Massendaten, ZIP|
|
||||
|**GCM**|✅|✅ **(AEAD)**|✅ **Bevorzugt**|TLS, IPSec, SSH|
|
||||
|
||||
_Quelle: BSI TR-02102-1 – [bsi.bund.de](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf)_
|
||||
|
||||
---
|
||||
|
||||
## 5. Asymmetrische Verschlüsselung (Public-Key)
|
||||
|
||||
### Grundidee: Das Briefkasten-Prinzip
|
||||
|
||||
```
|
||||
Öffentlicher Schlüssel (frei verfügbar)
|
||||
│
|
||||
▼
|
||||
Alice ──[m]──► [ E_pub(B) ] ──[c]──► Bob ──► [ D_priv(B) ] ──[m]►
|
||||
▲
|
||||
Nur Bob kennt seinen privaten Schlüssel!
|
||||
|
||||
Schlüsselproblem: n Partner → nur n Schlüsselpaare (statt n(n-1)/2)
|
||||
```
|
||||
|
||||
Der private Schlüssel ist aus dem öffentlichen **nicht in vertretbarer Zeit ableitbar** – basiert auf mathematisch schwer lösbaren Problemen (**One-Way-Trapdoor-Funktionen**).
|
||||
|
||||
### Digitale Signatur
|
||||
|
||||
```
|
||||
Signieren (Sender Alice): Verifizieren (Empfänger Bob):
|
||||
|
||||
Dokument ──► Hash ──► h Dokument ──► Hash ──► h'
|
||||
│ │
|
||||
priv(A) ▼ pub(A) ▼
|
||||
E(h) = Signatur ──────────► D(Sig) = h''
|
||||
|
||||
Gültig wenn: h' == h''
|
||||
```
|
||||
|
||||
- Entspricht einem digitalen Äquivalent zur handschriftlichen Unterschrift
|
||||
- Setzt eine **Public-Key-Infrastruktur (PKI)** mit Zertifizierungsstellen (CA/Trustcenter) voraus
|
||||
|
||||
### RSA (Rivest, Shamir, Adleman, 1978)
|
||||
|
||||
**Schlüsselgenerierung:**
|
||||
|
||||
```
|
||||
1. Wähle zwei große Primzahlen p und q
|
||||
2. Berechne: n = p × q (Modulus)
|
||||
3. Berechne: φ(n) = (p-1)(q-1)
|
||||
4. Wähle e mit: ggT(e, φ(n)) = 1 (öffentlicher Exponent, oft 65537)
|
||||
5. Berechne d mit: e × d ≡ 1 (mod φ(n)) (privater Exponent)
|
||||
|
||||
Öffentlicher Schlüssel: (e, n)
|
||||
Privater Schlüssel: (d, n)
|
||||
```
|
||||
|
||||
**Ver- und Entschlüsselung:**
|
||||
|
||||
```
|
||||
Verschlüsseln: c = mᵉ mod n
|
||||
Entschlüsseln: m = cᵈ mod n
|
||||
|
||||
Beispiel (vereinfacht, p=61, q=53, n=3233, e=17, d=2753):
|
||||
m = 123 → c = 123¹⁷ mod 3233 = 855
|
||||
c = 855 → m = 855²⁷⁵³ mod 3233 = 123 ✓
|
||||
```
|
||||
|
||||
**Sicherheit basiert auf:** Schwierigkeit der Primfaktorzerlegung großer Zahlen.
|
||||
|
||||
**Aktuelle Schlüssellängen-Empfehlungen (2024–2026):**
|
||||
|
||||
```
|
||||
Schlüssellänge │ Symmetr. Äquivalenz │ BSI │ NIST
|
||||
───────────────┼─────────────────────┼──────────────┼──────────────
|
||||
1024 Bit │ ~80 Bit │ ❌ Verboten │ ❌ Seit 2013
|
||||
2048 Bit │ ~112 Bit │ ⚠️ bis 2026 │ ⚠️ bis 2030
|
||||
3000 Bit │ ~128 Bit │ ✅ Minimum │ ✅ ab 2030
|
||||
4096 Bit │ ~140 Bit │ ✅ Empfohlen │ ✅ Empfohlen
|
||||
```
|
||||
|
||||
_Quelle: BSI TR-02102-1 (2026-01) – [bsi.bund.de](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf)_
|
||||
|
||||
### Diffie-Hellman Schlüsselaustausch (1976)
|
||||
|
||||
Ermöglicht zwei Parteien, über einen **unsicheren Kanal** ein gemeinsames Geheimnis zu vereinbaren – ohne es vorher ausgetauscht zu haben.
|
||||
|
||||
```
|
||||
Öffentlich bekannt: Primzahl p, Generator g
|
||||
|
||||
Alice Bob
|
||||
───── ───
|
||||
Wählt geheimes a Wählt geheimes b
|
||||
A = gᵃ mod p ────────────────────►
|
||||
◄─────────────────── B = gᵇ mod p
|
||||
K = Bᵃ mod p = gᵃᵇ mod p K = Aᵇ mod p = gᵃᵇ mod p
|
||||
└────── Gemeinsames Geheimnis K ──────┘
|
||||
|
||||
Lauscher sieht: g, p, A, B → kann K NICHT effizient berechnen
|
||||
(Diskretes-Logarithmusproblem)
|
||||
```
|
||||
|
||||
**ECDH (Elliptic Curve Diffie-Hellman):** Gleiches Prinzip auf elliptischen Kurven – gleiche Sicherheit bei **viel kleineren Schlüsseln** (256-Bit ECDH ≈ 3072-Bit klassisches DH). In TLS 1.3 ist **ECDHE** (ephemeral) der Standard für den Schlüsselaustausch – neue Schlüssel pro Sitzung garantieren **Perfect Forward Secrecy**.
|
||||
|
||||
### Hybridverschlüsselung in der Praxis (TLS 1.3)
|
||||
|
||||
In der Praxis werden symmetrische und asymmetrische Verfahren kombiniert:
|
||||
|
||||
```
|
||||
TLS 1.3 Handshake (vereinfacht):
|
||||
|
||||
Client Server
|
||||
────── ──────
|
||||
1. ClientHello ──────────────────►
|
||||
(ECDHE Public Key,
|
||||
unterstützte Cipher Suites)
|
||||
|
||||
2. ◄─────────────── ServerHello
|
||||
(ECDHE Public Key,
|
||||
gewählte Cipher Suite,
|
||||
Zertifikat + Signatur)
|
||||
|
||||
3. Beide berechnen: gemeinsames Geheimnis via ECDHE
|
||||
→ Sitzungsschlüssel für AES-GCM (symmetrisch)
|
||||
|
||||
4. Alle weiteren Daten: AES-256-GCM (schnell, AEAD)
|
||||
|
||||
Asymmetrisch (langsam) → nur für Schlüsselaustausch + Authentifizierung
|
||||
Symmetrisch (schnell) → für alle Nutzdaten
|
||||
```
|
||||
|
||||
_Quelle: Cloudflare Blog zu RFC 8446 – [blog.cloudflare.com](https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/)_
|
||||
|
||||
---
|
||||
|
||||
## 6. One-Way-Hashfunktionen
|
||||
|
||||
### Grundprinzip
|
||||
|
||||
```
|
||||
Beliebig langer Input M Fester kurzer Output h
|
||||
──────────────────────► H(M) ──────────────────────►
|
||||
"Hamlet" (200.000 Zeichen) a89de23fede8... (256 Bit)
|
||||
"Hamiet" (1 Buchstabe anders) 38fe38aa9c2d... (256 Bit, komplett anders!)
|
||||
└── Lawineneffekt
|
||||
```
|
||||
|
||||
**Drei Sicherheitseigenschaften:**
|
||||
|
||||
1. **Einwegfunktion:** `h = H(M)` leicht berechnen; aus `h` das `M` finden – praktisch unmöglich
|
||||
2. **Zweites Urbild:** Zu gegebenem `M` kein anderes `M'` finden mit `H(M) = H(M')`
|
||||
3. **Kollisionsresistenz:** Kein beliebiges Paar `(M, M')` mit `H(M) = H(M')` finden
|
||||
|
||||
### Das Geburtstagsparadox
|
||||
|
||||
```
|
||||
Wie viele Menschen braucht man, damit 2 am gleichen Tag
|
||||
Geburtstag haben (p > 50%)?
|
||||
→ Nur 23 Menschen! (bei 365 Tagen)
|
||||
|
||||
Übertragen auf Hashfunktionen:
|
||||
Bei n-Bit-Hashwert genügen ~2^(n/2) Versuche für eine Kollision.
|
||||
|
||||
Beispiel: 60-Bit-Hash → nur 2³⁰ ≈ 10⁹ Versuche!
|
||||
→ Hashwerte müssen länger als symmetrische Schlüssel sein
|
||||
(Faustregel: mindestens 2× die gewünschte Sicherheit in Bit)
|
||||
```
|
||||
|
||||
### Wichtige Hashfunktionen
|
||||
|
||||
|Algorithmus|Hashwert|Konstruktion|Status|
|
||||
|---|---|---|---|
|
||||
|MD5|128 Bit|Merkle-Damgård|❌ Gebrochen (Kollisionen in Sekunden)|
|
||||
|SHA-1|160 Bit|Merkle-Damgård|❌ Gebrochen (SHAttered 2017, ~63 USD/GPU)|
|
||||
|**SHA-256**|**256 Bit**|Merkle-Damgård|✅ **Standard**|
|
||||
|**SHA-512**|**512 Bit**|Merkle-Damgård|✅ **Standard**|
|
||||
|**SHA3-256**|**256 Bit**|Keccak/Sponge|✅ **Empfohlen (FIPS 202)**|
|
||||
|RIPEMD-160|160 Bit|Merkle-Damgård|⚠️ Nur noch in Bitcoin|
|
||||
|
||||
> **Warum SHA-1 gebrochen ist:** Google und CWI Amsterdam erzeugten 2017 zwei verschiedene PDF-Dateien mit **identischem SHA-1-Hash** (SHAttered-Angriff). SHA-1 ist für alle Sicherheitsanwendungen verboten. _Quelle: [shattered.io](https://shattered.io)_
|
||||
|
||||
> **SHA-256 vs. SHA3-256:** SHA-256 basiert auf der Merkle-Damgård-Konstruktion (anfällig für Length-Extension-Angriffe ohne HMAC); SHA-3/Keccak nutzt die **Sponge-Konstruktion** und ist immun dagegen. Beide sind aktuell sicher und vom BSI empfohlen. _Quelle: NIST FIPS 202 – [csrc.nist.gov](https://csrc.nist.gov/pubs/fips/202/final)_
|
||||
|
||||
### Message Authentication Code (MAC)
|
||||
|
||||
```
|
||||
Normale Hashfunktion: MAC (Keyed Hash):
|
||||
H(M) → jeder kann prüfen HMAC(K, M) → nur Schlüsselinhaber kann prüfen
|
||||
|
||||
HMAC-Konstruktion (RFC 2104):
|
||||
HMAC(K, M) = H( (K ⊕ opad) ‖ H( (K ⊕ ipad) ‖ M ) )
|
||||
|
||||
ipad = 0x36363636... (Schlüssellänge)
|
||||
opad = 0x5C5C5C5C... (Schlüssellänge)
|
||||
```
|
||||
|
||||
- **CBC-MAC:** Letzter Block einer CBC-Verschlüsselung als Prüfsumme – Standard im Bankwesen
|
||||
- **HMAC:** Internet-Standard RFC 2104, z. B. in IPSec, TLS (für ältere Modi), SSH
|
||||
|
||||
---
|
||||
|
||||
## 7. Aktueller Stand & Ausblick: Post-Quanten-Kryptographie
|
||||
|
||||
> **Neu ab 2024 – nicht Teil der Vorlesung, aber prüfungsrelevant für die Praxis!**
|
||||
|
||||
### Die Quantenbedrohung
|
||||
|
||||
```
|
||||
Klassische Computer:
|
||||
Brute Force RSA-2048 → ~300 Billionen Jahre
|
||||
|
||||
Quantencomputer (Shors Algorithmus):
|
||||
RSA-2048 brechen → Stunden bis Tage
|
||||
(benötigt ~1 Mio. logische Qubits – noch nicht erreicht)
|
||||
|
||||
Auswirkung:
|
||||
RSA, ECDSA, ECDH, DH → VOLLSTÄNDIG GEBROCHEN durch Shor
|
||||
AES-128 → ~64 Bit Sicherheit (Grover-Algorithmus)
|
||||
AES-256 → ~128 Bit Sicherheit ✅ weiterhin sicher
|
||||
SHA-256 → ~128 Bit Sicherheit ✅ weiterhin sicher
|
||||
```
|
||||
|
||||
### NIST Post-Quanten-Standards (August 2024)
|
||||
|
||||
Im **August 2024** veröffentlichte NIST die ersten drei finalisierten Post-Quanten-Standards:
|
||||
|
||||
|Standard|Algorithmus|Typ|Mathematisches Problem|
|
||||
|---|---|---|---|
|
||||
|**FIPS 203**|ML-KEM (Kyber)|Schlüsselkapselung|Module-LWE (Gitter)|
|
||||
|**FIPS 204**|ML-DSA (Dilithium)|Digitale Signatur|Module-LWE (Gitter)|
|
||||
|**FIPS 205**|SLH-DSA (SPHINCS+)|Digitale Signatur|Hashfunktionen|
|
||||
|
||||
_Quelle: NIST – [nist.gov](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards)_
|
||||
|
||||
### BSI-Strategie: Hybrid ist Pflicht
|
||||
|
||||
Das BSI verfolgt einen konservativeren Ansatz als NIST: **PQC-Verfahren müssen mit klassischen Verfahren kombiniert werden** (Hybridmodus), bis ausreichend Vertrauen aufgebaut ist.
|
||||
|
||||
```
|
||||
Hybride Verschlüsselung (BSI-Empfehlung):
|
||||
|
||||
Schlüsselkapselung: ECDH (P-256) + ML-KEM-768
|
||||
└────────────────────► kombiniertes Geheimnis
|
||||
→ AES-256-GCM
|
||||
|
||||
Signatur: ECDSA (P-256) + ML-DSA-65
|
||||
(beide Signaturen werden erstellt und verifiziert)
|
||||
```
|
||||
|
||||
**Migrationsfristen laut BSI TR-02102-1 (2026-01):**
|
||||
|
||||
```
|
||||
Heute (2026) 2030 2032 2035
|
||||
│ │ │ │
|
||||
▼ ▼ ▼ ▼
|
||||
─────────────────────────────────────────────────────────────
|
||||
Klassische Verfahren ████████
|
||||
(RSA, ECDH) allein ████████████████████████
|
||||
|
||||
Hybride Verfahren ████████████████████
|
||||
(PQC + klassisch) ████████████████████████████████████
|
||||
|
||||
Reine PQC-Verfahren ████████████████████████
|
||||
|
||||
Kritische Infrastruktur muss bis 2030 migriert sein!
|
||||
```
|
||||
|
||||
_Quelle: BSI TR-02102-1 Version 2026-01 – [bsi.bund.de](https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/Publications/TechGuidelines/TG02102/BSI-TR-02102-1.pdf)_
|
||||
|
||||
> **„Harvest Now, Decrypt Later" (HNDL):** Staatliche Akteure speichern heute bereits verschlüsselte Kommunikation, um sie nach Verfügbarkeit eines Quantencomputers zu entschlüsseln. Daten mit **langfristiger Vertraulichkeitsanforderung müssen JETZT** mit PQC geschützt werden!
|
||||
|
||||
---
|
||||
|
||||
## 8. Zusammenfassung
|
||||
|
||||
```
|
||||
Kryptographie-Überblick:
|
||||
|
||||
ELEMENTAR SYMMETRISCH ASYMMETRISCH HASH
|
||||
─────────── ─────────── ──────────── ────
|
||||
OTP (absolut AES-256-GCM ✅ RSA ≥ 3000 Bit ✅ SHA-256 ✅
|
||||
sicher, aber (BSI-Empfehlung) ECDH (P-256/ SHA3-256 ✅
|
||||
unpraktisch) X25519) ✅
|
||||
DES ❌ MD5 ❌
|
||||
Substitution RC4 ❌ RSA-1024 ❌ SHA-1 ❌
|
||||
(historisch) Triple-DES ⚠️
|
||||
Transposition ► Hybridverschlüsselung
|
||||
(historisch) in TLS 1.3, IPSec, ...
|
||||
|
||||
ZUKUNFT: Post-Quanten-Kryptographie
|
||||
ML-KEM + ECDH (hybrid) ✅ (BSI ab 2026 empfohlen)
|
||||
```
|
||||
|
||||
**Kernprinzipien der Vorlesung:**
|
||||
|
||||
- Die Sicherheit hängt **niemals** von der Geheimhaltung des Algorithmus ab, sondern **ausschließlich** von der Geheimhaltung des privaten Schlüssels
|
||||
- Kosten des Brechens müssen **höher** sein als der Wert der geschützten Information
|
||||
- Zeitaufwand zum Knacken muss **länger** sein als das Interesse an der Information
|
||||
- Empfehlungen nationaler Behörden beachten (BSI, NIST) – und alle **10–15 Jahre** Algorithmen überprüfen
|
||||
|
||||
---
|
||||
|
||||
## Weiterführende Ressourcen
|
||||
|
||||
|Ressource|Link|
|
||||
|---|---|
|
||||
|BSI Technische Richtlinien (TR-02102)|[bsi.bund.de](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Technische-Richtlinien/TR-nach-Thema-sortiert/tr02102/tr02102_node.html)|
|
||||
|NIST Kryptographie-Standards|[csrc.nist.gov](https://csrc.nist.gov/projects/cryptographic-standards-and-guidelines)|
|
||||
|NIST Post-Quanten-Standards|[nist.gov/pqc](https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards)|
|
||||
|CrypTool (interaktives Lerntool)|[cryptool.de](https://www.cryptool.de)|
|
||||
|Bundesnetzagentur|[bundesnetzagentur.de](https://www.bundesnetzagentur.de)|
|
||||
|SHAttered (SHA-1 gebrochen)|[shattered.io](https://shattered.io)|
|
||||
|TLS 1.3 erklärt (Cloudflare)|[blog.cloudflare.com](https://blog.cloudflare.com/rfc-8446-aka-tls-1-3/)|
|
||||
202
IT-Sicherheit/Zusammenfassungen/itsec5 - zusammenfassung.md
Normal file
202
IT-Sicherheit/Zusammenfassungen/itsec5 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,202 @@
|
|||
# Zusammenfassung: Kryptographie
|
||||
|
||||
**Vorlesung IT-Sicherheit – Gerrit Kalkbrenner, HWR Berlin, 2026**
|
||||
|
||||
---
|
||||
## 1. Einführung
|
||||
|
||||
Kryptographie ist eine moderne, mathematisch geprägte Wissenschaft mit einer Geschichte von über 3.000 Jahren. Bekannte historische Beispiele sind das Babington-Komplott (1586), das Zimmermann-Telegramm (Erster Weltkrieg) und die Enigma-Entschlüsselung im Zweiten Weltkrieg. Heute ist Kryptographie allgegenwärtig – in Mobilfunk, EC-Karten, SSL/TLS, Bitcoin, Wegfahrsperren und vielen weiteren Bereichen.
|
||||
|
||||
> **Wichtig:** Kryptographie ≠ Sicherheit. Sie ist ein unverzichtbarer Baustein, aber kein vollständiger Ersatz für ein ganzheitliches Sicherheitskonzept.
|
||||
|
||||
---
|
||||
|
||||
## 2. Grundlagen der Verschlüsselung
|
||||
|
||||
### Begriffe
|
||||
|
||||
- **Klartext (Plaintext):** Die Originaldaten
|
||||
- **Schlüsseltext / Chiffrat (Ciphertext):** Die transformierten, unlesbaren Daten
|
||||
- **Verschlüsselung / Entschlüsselung:** Die mathematische Transformation und ihre Umkehrung
|
||||
|
||||
### Kryptographisches System (6-Tupel)
|
||||
|
||||
Ein Kryptosystem wird formal als **(M, C, KE, KD, E, D)** beschrieben:
|
||||
|
||||
- M = Klartextnachrichten, C = Kryptogramme
|
||||
- KE / KD = Verschlüsselungs-/Entschlüsselungsschlüssel
|
||||
- E / D = Ver-/Entschlüsselungsfunktion
|
||||
|
||||
**Grundprinzip (Kerckhoffs-Prinzip):** Der Algorithmus darf öffentlich bekannt sein – die Sicherheit beruht allein auf der Geheimhaltung des Schlüssels.
|
||||
|
||||
### Kryptoanalyse-Strategien
|
||||
|
||||
|Angriffsart|Beschreibung|
|
||||
|---|---|
|
||||
|**Ciphertext-only**|Nur der Schlüsseltext ist bekannt|
|
||||
|**Known-plaintext**|Klartext-/Schlüsseltext-Paare verfügbar|
|
||||
|**Chosen-plaintext**|Angreifer kann beliebige Klartexte verschlüsseln|
|
||||
|**Brute Force**|Vollständige Schlüsselsuche (alle möglichen Schlüssel)|
|
||||
|**Statistische Methoden**|Häufigkeitsanalyse von Buchstaben/Wörtern|
|
||||
|**Trial & Error**|Reduktion des Schlüsselraums durch Teiltreffer|
|
||||
|
||||
### Sicherheitskategorien
|
||||
|
||||
- **Absolute Sicherheit:** Theoretisch unmöglich zu brechen (nur mit Einmal-Schlüssel/OTP)
|
||||
- **Praktische/Rechnerische Sicherheit:** Brechen ist theoretisch möglich, aber praktisch nicht durchführbar
|
||||
|
||||
**Schlüssellängen und Brute-Force-Aufwand (Annahme: 10⁹ Versuche/s):**
|
||||
|
||||
|Schlüssellänge (Bit)|Aufwand (Jahre)|
|
||||
|---|---|
|
||||
|56|~1,14|
|
||||
|64|~292|
|
||||
|128|> 5 × 10²¹|
|
||||
|256|> 10⁵⁹|
|
||||
|
||||
Aufgrund steigender Rechenleistung und Quantencomputer ist alle **10–15 Jahre** ein Wechsel der Algorithmen notwendig (64 Bit → 128 Bit AES → 256 Bit AES).
|
||||
|
||||
---
|
||||
|
||||
## 3. Elementarverschlüsselungen
|
||||
|
||||
### Einmal-Schlüssel (One-Time-Pad, OTP)
|
||||
|
||||
- Absolut sicheres Verfahren
|
||||
- Schlüssel muss mindestens so lang wie die Nachricht sein
|
||||
- Klartext und Schlüssel werden bitweise XOR-verknüpft
|
||||
- Unpraktisch für den kommerziellen Einsatz (Schlüsselverteilungsproblem)
|
||||
|
||||
### Monoalphabetische Substitution
|
||||
|
||||
- Jedes Klartextzeichen wird durch ein festes anderes Zeichen ersetzt
|
||||
- Leicht durch **Häufigkeitsanalyse** zu brechen (z. B. E = 17,4 % in Deutsch)
|
||||
|
||||
### Polyalphabetische Substitution (Vigenère)
|
||||
|
||||
- Verwendet mehrere Alphabete, gesteuert durch einen Schlüssel
|
||||
- Verdeckt Häufigkeiten besser, aber bei langen Texten durch statistische Analyse angreifbar
|
||||
|
||||
### Transpositionsverfahren
|
||||
|
||||
- Zeichen des Klartextes werden nach fester Regel permutiert (vertauscht), nicht ersetzt
|
||||
- Beispiele: Zick-Zack-Verfahren, spartanische Skytale (500 v. Chr.)
|
||||
|
||||
---
|
||||
|
||||
## 4. Symmetrische Verschlüsselung (Private-Key)
|
||||
|
||||
Sender und Empfänger verwenden denselben geheimen Schlüssel. Nachteil: Bei _n_ Teilnehmern werden **n(n−1)/2** Schlüssel benötigt (z. B. 66 Schlüssel bei 12 Teilnehmern).
|
||||
|
||||
### Wichtige Algorithmen
|
||||
|
||||
|Verfahren|Schlüssellänge|Status|
|
||||
|---|---|---|
|
||||
|DES|56 Bit|Veraltet, nicht mehr sicher|
|
||||
|Triple DES (3-Keys)|168 Bit|Übergangsverfahren|
|
||||
|IDEA|128 Bit|Als stark betrachtet|
|
||||
|RC2, RC4, RC5|variabel|Teils veraltet|
|
||||
|**AES (Rijndael)**|128 / 192 / 256 Bit|Aktueller Standard|
|
||||
|
||||
### AES (Advanced Encryption Standard)
|
||||
|
||||
- Entwickelt von Joan Daemen und Vincent Rijmen (patentfrei)
|
||||
- Blockgröße: 128, 192 oder 256 Bit; Schlüssellänge: 128, 192 oder 256 Bit
|
||||
- Anzahl der Runden: 10, 12 oder 14 (je nach Block-/Schlüssellänge)
|
||||
- Jede Runde besteht aus vier Transformationen:
|
||||
1. **ByteSub** – nichtlineare Byte-Substitution (S-Box)
|
||||
2. **ShiftRow** – zyklisches Verschieben der Zeilen
|
||||
3. **MixColumn** – Spaltenmultiplikation über einem Galoisfeld
|
||||
4. **AddRoundKey** – XOR-Verknüpfung mit dem Rundenschlüssel
|
||||
|
||||
### Betriebsmodi
|
||||
|
||||
|Modus|Merkmal|Einsatz|
|
||||
|---|---|---|
|
||||
|**ECB**|Jeder Block unabhängig; identischer Klartext = identischer Schlüsseltext|Nur für spezielle Anwendungen|
|
||||
|**CBC**|Verkettung mit Vorgängerblock; benötigt Initialisierungsvektor|Allgemein|
|
||||
|**CFB**|Stromchiffre aus Blockchiffre; begrenzte Fehlerfortpflanzung; selbstsynchronisierend|Zeichenorientierte Übertragung|
|
||||
|**OFB**|Keine Fehlerfortpflanzung; nicht selbstsynchronisierend|Störungsanfällige Kanäle (z. B. Satellit)|
|
||||
|**CTR**|Parallelisierbar; wahlfreier Zugriff|Massendaten (Festplatte, ZIP)|
|
||||
|**GCM**|Authenticated Encryption (AEAD); hoher Durchsatz|TLS, IPSec, SSH, IEEE 802.11|
|
||||
|
||||
---
|
||||
|
||||
## 5. Asymmetrische Verschlüsselung (Public-Key)
|
||||
|
||||
### Grundidee
|
||||
|
||||
Jeder Teilnehmer besitzt ein Schlüsselpaar:
|
||||
|
||||
- **Öffentlicher Schlüssel (Public Key):** Frei zugänglich, zum Verschlüsseln
|
||||
- **Privater Schlüssel (Private Key):** Geheim, zum Entschlüsseln
|
||||
|
||||
Der private Schlüssel ist aus dem öffentlichen Schlüssel **nicht in vertretbarer Zeit ableitbar** (basiert auf mathematisch schwer lösbaren Problemen – sog. **One-Way-Trapdoor-Funktionen**).
|
||||
|
||||
### RSA (Rivest, Shamir, Adleman, 1978)
|
||||
|
||||
- Basiert auf der Schwierigkeit, das Produkt zweier großer Primzahlen zu faktorisieren
|
||||
- Nutzbar für Verschlüsselung, digitale Signatur und Schlüsselmanagement
|
||||
- Verschlüsselung: `c = m^e mod n` | Entschlüsselung: `m = c^d mod n`
|
||||
- Empfohlene Schlüssellänge: ≥ 2048 Bit (1024 Bit gilt heute als unsicher)
|
||||
|
||||
### Digitale Signatur
|
||||
|
||||
- Mit dem **privaten Schlüssel** signiert → mit dem **öffentlichen Schlüssel** verifizierbar
|
||||
- Entspricht einem digitalen Äquivalent zur handschriftlichen Unterschrift
|
||||
- Setzt eine **Public-Key-Infrastruktur (PKI)** mit Zertifizierungsstellen (Trustcenter) voraus
|
||||
|
||||
### Diffie-Hellman (1976)
|
||||
|
||||
- Erster Public-Key-Algorithmus; dient **nur** dem gesicherten Schlüsselaustausch
|
||||
- Keine direkte Verschlüsselung und keine Authentifizierung der Partner
|
||||
- Grundlage für hybride Verschlüsselungsverfahren
|
||||
|
||||
---
|
||||
|
||||
## 6. One-Way-Hashfunktionen
|
||||
|
||||
### Grundlagen
|
||||
|
||||
Eine Hashfunktion H bildet eine beliebig lange Nachricht M auf einen **Hashwert h fester Länge** ab:
|
||||
|
||||
- `h = H(M)` – einfach zu berechnen
|
||||
- Umkehrung: praktisch unmöglich (`M = f(h)` ist nicht berechenbar)
|
||||
- **Kollisionsresistenz:** Es ist praktisch unmöglich, zwei verschiedene Nachrichten M und M' mit `H(M) = H(M')` zu finden
|
||||
|
||||
### Geburtstagsproblem
|
||||
|
||||
Durch das Geburtstagsparadox genügen statistisch ~2^(n/2) Versuche, um eine Kollision bei einer n-Bit-Hashfunktion zu finden → Hashwerte sollten deutlich länger als Schlüssellängen symmetrischer Verfahren sein (mind. 160 Bit).
|
||||
|
||||
### Wichtige Hashfunktionen
|
||||
|
||||
|Algorithmus|Hashwertlänge|Status|
|
||||
|---|---|---|
|
||||
|MD5|128 Bit|Veraltet – nicht mehr verwenden!|
|
||||
|SHA-1|160 Bit|Veraltet|
|
||||
|SHA-3 (Keccak)|224 / 256 / 384 / 512 Bit|Aktueller NIST-Standard (seit 2012)|
|
||||
|RIPEMD|160 Bit|EU-Projekt RIPE (1992)|
|
||||
|
||||
### Message Authentication Code (MAC)
|
||||
|
||||
- Hashfunktion **mit geheimem Schlüssel** → nur der Schlüsselinhaber kann den Hashwert verifizieren
|
||||
- Gewährleistet **Authentizität** (ohne Geheimhaltung des Inhalts)
|
||||
- **CBC-MAC:** Basiert auf AES/DES im CBC-Modus; weit verbreitet im Bankwesen
|
||||
- **HMAC:** Internet-Standard (RFC 2104), z. B. in IPSec; kombiniert Hashfunktion mit geheimem Schlüssel über XOR-Verknüpfungen mit ipad/opad
|
||||
|
||||
---
|
||||
|
||||
## 7. Zusammenfassung
|
||||
|
||||
- Kryptographische Verfahren sind die **Basis der meisten Sicherheitssysteme**
|
||||
- Die Sicherheit hängt **niemals** von der Geheimhaltung des Algorithmus ab, sondern **ausschließlich** von der Geheimhaltung des privaten Schlüssels
|
||||
- Algorithmen sollten so gewählt werden, dass:
|
||||
- die **Kosten des Brechens** höher sind als der Wert der geschützten Informationen
|
||||
- der **zeitliche Aufwand** länger ist als das Interesse an den Informationen
|
||||
- Empfehlungen von Experten und Behörden beachten (in Deutschland: **BSI**, **Bundesnetzagentur**)
|
||||
|
||||
**Weiterführende Ressourcen:**
|
||||
|
||||
- [www.bsi.de](https://www.bsi.de)
|
||||
- [www.bundesnetzagentur.de](https://www.bundesnetzagentur.de)
|
||||
- [www.cryptool.de](https://www.cryptool.de)
|
||||
815
IT-Sicherheit/Zusammenfassungen/itsec6-11 - zusammenfassung.md
Normal file
815
IT-Sicherheit/Zusammenfassungen/itsec6-11 - zusammenfassung.md
Normal file
|
|
@ -0,0 +1,815 @@
|
|||
# IT-Sicherheit – Ausführliche Zusammenfassung (Vorlesungen 5–9)
|
||||
|
||||
---
|
||||
## 1. Hardware-Sicherheitsmodule (HSM)
|
||||
### 1.1 Grundidee
|
||||
Ein Hardware-Sicherheitsmodul ist ein physisch geschützter Bereich (typischerweise ein Chip oder ein eigenständiges Gerät), dessen Aufgabe es ist, sicherheitsrelevante Informationen vor dem Auslesen und vor Manipulation zu schützen. Der entscheidende Vorteil gegenüber reiner Software: Die geheimen Daten verlassen die Hardware nie. Alle kryptographischen Operationen finden direkt innerhalb des Moduls statt.
|
||||
|
||||
Zu den sicherheitsrelevanten Informationen gehören drei Kategorien:
|
||||
|
||||
- **Geheime Schlüssel** – für Verschlüsselung, Authentisierung und digitale Signaturen
|
||||
- **Programme** – die weder kopiert noch modifiziert werden dürfen
|
||||
- **Daten** – etwa Transaktionsdaten, die einen monetären oder rechtlichen Wert repräsentieren
|
||||
|
||||
In der Vorlesung werden drei Klassen von HSMs behandelt, die sich in Einsatzzweck, Sicherheitsniveau und Kosten unterscheiden: Smartcards, TPM und HLSM.
|
||||
|
||||
---
|
||||
|
||||
### 1.2 Smartcards
|
||||
|
||||
#### Aufbau
|
||||
|
||||
Eine Smartcard ist ein vollständiges IT-System im Format einer EC-Karte (86 × 54 × 0,76 mm). Trotz dieser winzigen Abmessungen enthält sie alle wesentlichen Komponenten eines Computers:
|
||||
|
||||
- **CPU** – führt Berechnungen und kryptographische Operationen aus
|
||||
- **RAM und ROM** – flüchtiger Arbeitsspeicher bzw. permanenter Speicher mit dem Betriebssystem
|
||||
- **EEPROM/Flash** – hier werden die geheimen Schlüssel (z. B. ein privater RSA-Schlüssel), Passwörter und persönliche Daten dauerhaft und sicher gespeichert
|
||||
- **I/O-Schnittstelle** – die gesamte Kommunikation mit der Außenwelt läuft über einen einzigen Kanal (Kontaktflächen oder kontaktloses Interface)
|
||||
- **Krypto-Prozessor** – ein optionaler, auf kryptographische Berechnungen spezialisierter Co-Prozessor
|
||||
|
||||
#### Sicherheitsdienste
|
||||
|
||||
Smartcards bieten dem Nutzer eine breite Palette an Sicherheitsdienstleistungen:
|
||||
|
||||
- Laden und Entladen von Werteinheiten für elektronisches Bezahlen
|
||||
- Kryptographische Anwendungen wie das Erstellen digitaler Signaturen
|
||||
- Identifikation und Authentisierung des Nutzers (Aktivierung der Karte per PIN)
|
||||
- Single-Sign-On-Anwendungen, bei denen die Karte Passwörter und PINs für verschiedene Dienste verwaltet
|
||||
- Sicheres Speichern von Daten direkt auf der Karte
|
||||
- Lesen von gespeicherten Servicedaten und Ausführung sonstiger Rechenoperationen
|
||||
|
||||
#### Hardware-Sicherheitsmechanismen
|
||||
|
||||
Die physische Sicherheit einer Smartcard wird durch eine Reihe von Hardware-Maßnahmen gewährleistet:
|
||||
|
||||
- **Unter- und Überspannungsdetektion** – erkennt Versuche, den Chip durch manipulierte Stromversorgung in undefinierten Zuständen zu bringen
|
||||
- **Erkennung niedriger Frequenzen** – verhindert, dass der Chip absichtlich langsam getaktet wird, um einzelne Operationen beobachtbar zu machen
|
||||
- **Gescramblete Busse** – die internen Datenleitungen sind verwürfelt, so dass ein Angreifer selbst bei physischem Zugriff keine sinnvollen Daten auslesen kann
|
||||
- **Sensoren** für Licht, Temperatur und andere Umgebungsparameter – erkennen, wenn jemand den Chip aufdeckt oder unter extremen Bedingungen betreibt
|
||||
- **Passivierungs- und Metallisierungsschichten** über Bus- und Speicherstrukturen oder der gesamten CPU – physische Schutzschichten, die Mikroskopie und Probing erschweren
|
||||
- **Hardware-Zufallszahlengenerator** – erzeugt echte Zufallszahlen statt nur pseudozufälliger Werte
|
||||
- **Spezielle CPU-Befehle** für kryptographische Funktionen und Speicherschutzfunktionen
|
||||
|
||||
#### Software-Sicherheitsmechanismen
|
||||
|
||||
Auf der Softwareseite kommen hinzu:
|
||||
|
||||
- Zugriffskontrolle auf gespeicherte Objekte
|
||||
- Zustandsautomaten, die in Abhängigkeit von vorheriger Identifikation und Authentisierung bestimmte Befehle zulassen oder blockieren
|
||||
|
||||
#### Sicherheitsprinzip und Vorteile
|
||||
|
||||
Die Sicherheit einer Smartcard beruht auf dem **Zwei-Faktor-Prinzip**: Wissen (die PIN) und Besitz (die physische Karte). Geheime Schlüssel verlassen die Karte niemals – alle geheimen Operationen finden direkt auf dem Chip statt. Das bedeutet: Ein Schlüssel kann benutzt werden, ohne ihn jemals zu kennen. Die Daten sind manipulationssicher in der Karte gespeichert. Der geschätzte Aufwand für einen erfolgreichen Angriff liegt bei etwa **1 Million Euro**.
|
||||
|
||||
#### Biometrische Smartcard
|
||||
|
||||
Eine Erweiterung ist die biometrische Smartcard, die zusätzlich einen **MatchOnCard-Algorithmus** im Betriebssystem enthält. Auf dem EEPROM sind neben den RSA-Schlüsseln und Zertifikaten auch bis zu vier Fingerabdrücke gespeichert. Der biometrische Vergleich findet vollständig auf der Karte statt – die Fingerabdruckdaten verlassen sie nie.
|
||||
|
||||
#### Alternative: YubiKey
|
||||
|
||||
Als kompaktere Alternative zu klassischen Smartcards bietet Yubico USB-Sicherheitstoken mit FIPS-Zertifizierung, manipulationssicherem Gehäuse, Hardware-basierter Zwei-Faktor-Authentifizierung und AES-Verschlüsselung. Die Programmierung eigener Schlüssel ist dabei bewusst einfach gehalten.
|
||||
|
||||
---
|
||||
|
||||
### 1.3 Trusted Platform Module (TPM)
|
||||
|
||||
#### Idee
|
||||
|
||||
Ein TPM ist ein kleines, kostengünstiges (unter 1 €!) Sicherheitsmodul, das in nahezu jedes Rechnersystem integriert werden kann – PCs, Notebooks, Smartphones, Drucker, Router und sogar IoT-Geräte wie Kühlschränke. Das Sicherheitsniveau gleicht dem einer Smartcard, allerdings ist ein TPM fest in die Plattform eingebaut und nicht tragbar.
|
||||
|
||||
#### Organisation
|
||||
|
||||
Das TPM wird durch die **Trusted Computing Group (TCG)** gesteuert, deren Hauptmitglieder Microsoft, Intel, HP, IBM, AMD, Sony, Oracle, Infineon, Utimaco und Lenovo sind. Die TCG definiert einheitliche Standards für die TPM-Software, auf deren Basis die einzelnen Unternehmen dann ihre eigenen Lösungen entwickeln. Microsofts Implementierung heißt beispielsweise **Next Generation Secure Computing Base (NGSCB)**.
|
||||
|
||||
#### Sicherheitsfunktionen
|
||||
|
||||
Die beiden zentralen Sicherheitsmechanismen eines TPM sind:
|
||||
|
||||
- **Sealing** – Daten werden so verschlüsselt, dass sie nur entschlüsselt werden können, wenn sich das System in einem bestimmten, vordefinierten Zustand befindet (mehr dazu im Abschnitt Trusted Computing)
|
||||
- **Attestation** – das TPM kann gegenüber einem Prüfer authentisch bestätigen, in welchem Zustand sich die Plattform befindet
|
||||
|
||||
#### Vorteile und Nachteile
|
||||
|
||||
Vorteile: Sehr hohe Sicherheit bei minimalen Kosten, Smartcard-vergleichbares Sicherheitsniveau, einfaches Sicherheitsmanagement durch Einbindung in bestehende PKI-Infrastrukturen, und in den meisten Fällen Microsoft-Readiness.
|
||||
|
||||
Nachteile: Die TCG arbeitet teilweise intransparent, und physikalische Backdoors in der Hardware sind theoretisch möglich.
|
||||
|
||||
---
|
||||
|
||||
### 1.4 High-Level Security Module (HLSM)
|
||||
|
||||
#### Ziele
|
||||
|
||||
HLSMs sind für Szenarien gedacht, in denen besonders sichere und wertvolle Informationen geschützt werden müssen (z. B. Master-Keys) und gleichzeitig sehr hohe Performance-Anforderungen bestehen. Ein zentrales Designprinzip: Wenn ein Angriff vom Sicherheitsmodul erkannt wird, werden die sicherheitsrelevanten Informationen **sofort aktiv gelöscht** – der Angreifer bekommt unter keinen Umständen Zugriff.
|
||||
|
||||
#### Potentielle Angriffe
|
||||
|
||||
HLSMs müssen gegen eine Vielzahl physischer Angriffe geschützt sein: Durchleuchten (z. B. Röntgen), Temperaturangriffe (Einfrieren oder Erhitzen), mechanische Attacken (Aufbohren, Aufschleifen), chemische Attacken (Ätzen von Schutzschichten) und Manipulationen über die Spannungsversorgung.
|
||||
|
||||
#### Anforderungen
|
||||
|
||||
Neben den Sicherheitsanforderungen müssen HLSMs auch hohe Performance, Skalierbarkeit und Verfügbarkeit bieten. Sie benötigen flexible Schnittstellen zu Host-Systemen (physikalisch über TCP/IP mit 100 Mbit, 1 Gbit oder FDDI; logisch durch Support bestehender Schnittstellen). Weitere Anforderungen sind die Möglichkeit zur Umstellung auf neue kryptographische Verfahren, der Übergang der kryptographischen Hoheit an den Betreiber und eine möglichst vertrauenswürdige Basis (wenige Lines of Code).
|
||||
|
||||
#### Anwendungen
|
||||
|
||||
Der geschätzte Aufwand für einen erfolgreichen Angriff auf ein HLSM liegt bei etwa **5 Millionen Euro**. Typische Einsatzgebiete sind:
|
||||
|
||||
- **PKI**: Schlüsselgenerierung gemäß Signaturgesetz
|
||||
- **Banken**: Autorisierungsstationen für Geldfreigabe, Sicherheit für Netzbetreiber (EC-Systeme, Mineralölunternehmen)
|
||||
- **Industrie**: Schlüsselgenerierung für Auto-Schlüssel, Maut-Systeme, Authentifikation im Mobilfunknetz, digitale Signatur zentraler Geschäftsprozesse
|
||||
|
||||
---
|
||||
|
||||
### 1.5 Rahmenbedingungen
|
||||
|
||||
#### Evaluierung und Zertifizierung
|
||||
|
||||
Die Sicherheit von HSMs muss durch unabhängige, qualifizierte Organisationen nachgewiesen werden. Relevante Standards sind FIPS 140-1, FIPS 140-2 und das CC-Schutzprofil CWA 14167-2. Typische Prüffragen betreffen z. B. die Gütekriterien eines Zufallszahlengenerators (Streuung, Periodizität, Gleichverteilung) oder die sichere Implementierung von Sicherheitsprotokollen.
|
||||
|
||||
#### Key-Management
|
||||
|
||||
Generelle Anforderungen: Niemand darf direkten Zugriff auf geheime Schlüssel haben. Die Nutzung kryptographischer Funktionen und die Definition oder Änderung von Funktionalitäten darf nur nach Autorisierung erfolgen.
|
||||
|
||||
Für TPMs geschieht die Personalisierung durch einen einzigartigen **Endorsement Key (EK)**, der durch eine öffentliche PKI verwaltet und signiert wird. Für HLSMs gilt das **Vier-Augen-Prinzip**: Kritische Tätigkeiten dürfen nicht von einer einzelnen Person durchgeführt werden. Schlüssel werden stets unter Aufsicht zweier autorisierter Personen eingegeben.
|
||||
|
||||
---
|
||||
|
||||
### 1.6 Zusammenfassung und Einordnung
|
||||
|
||||
|Eigenschaft|Smartcard|TPM|HLSM|
|
||||
|---|---|---|---|
|
||||
|Einsatz|Personen|Kleine Rechner|Große Systeme|
|
||||
|Kosten|Gering|Unter 1 €|Hoch|
|
||||
|Angriffskosten|~1 Mio. €|≈ Smartcard|~5 Mio. €|
|
||||
|Mobilität|Tragbar|Fest eingebaut|Stationär|
|
||||
|Performance|Gering|Gering|Hoch|
|
||||
|
||||
---
|
||||
|
||||
## 2. OpenSSL
|
||||
|
||||
### 2.1 Was ist OpenSSL?
|
||||
|
||||
OpenSSL ist eine robuste, vollständige und universelle Open-Source-Bibliothek für Kryptographie und sichere Kommunikation. Sie bietet sowohl eine Command-Line-Anwendung als auch Programmbibliotheken für die Integration in eigene Software. Ab Version 3.6 steht OpenSSL unter der Apache v2 License.
|
||||
|
||||
OpenSSL deckt drei Hauptbereiche ab:
|
||||
|
||||
- Kryptographische Funktionen (Hashing, Verschlüsselung, Signierung)
|
||||
- Generierung von Schlüsseln und Zertifikaten
|
||||
- Sichere Kommunikation via TLS/SSL
|
||||
|
||||
### 2.2 Praktische Nutzung auf der Kommandozeile
|
||||
|
||||
#### Hashing mit SHA-256
|
||||
|
||||
```
|
||||
openssl dgst -sha256 name.txt
|
||||
```
|
||||
|
||||
Erzeugt den SHA-256-Hashwert einer Datei. Die Ausgabe ist ein 256-Bit-Wert als Hexadezimalstring, z. B. `99671587e0856ec3a860...`.
|
||||
|
||||
#### Symmetrische Verschlüsselung mit AES-256
|
||||
|
||||
Verschlüsseln:
|
||||
|
||||
```
|
||||
openssl enc -e -aes256 -in name.txt -out name.aes
|
||||
```
|
||||
|
||||
Entschlüsseln:
|
||||
|
||||
```
|
||||
openssl enc -d -aes256 -out name2.txt -in name.aes
|
||||
```
|
||||
|
||||
OpenSSL unterstützt eine Vielzahl symmetrischer Verfahren, die mit `openssl enc -ciphers` aufgelistet werden können – darunter AES-128/192/256 in den Modi CBC, CFB, CTR, ECB und OFB.
|
||||
|
||||
---
|
||||
|
||||
## 3. TLS/SSL – Transport Layer Security / Secure Socket Layer
|
||||
|
||||
### 3.1 Einleitung und Motivation
|
||||
|
||||
Da das Internet ein offenes Netz ist und die Angriffsmöglichkeiten sowie Angriffswahrscheinlichkeiten sehr groß sind, ist die Nutzung einer verschlüsselten und integritätsgesicherten Kommunikation zwischen Client und Server von besonderer Bedeutung. Passwörter, Kreditkartendaten und andere sensible Informationen werden ständig über das Internet übertragen – ohne TLS/SSL wären sie für jeden Angreifer lesbar.
|
||||
|
||||
TLS/SSL ist ein **anwendungsunabhängiges Sicherheitsprotokoll**, das logisch auf einem Transportprotokoll (TCP) aufsetzt. Es bündelt drei zentrale Sicherheitsdienste:
|
||||
|
||||
1. **Authentifikation** von Server und Client unter Verwendung asymmetrischer Verschlüsselung und elektronischer Zertifikate
|
||||
2. **Vertraulichkeit** durch symmetrische Ende-zu-Ende-Verschlüsselung mit einem gemeinsamen Sitzungsschlüssel
|
||||
3. **Integrität und Authentizität** der transportierten Daten unter Verwendung des HMAC-Verfahrens
|
||||
|
||||
Zusätzlich bietet TLS/SSL optional die Komprimierung der Daten an.
|
||||
|
||||
#### Geschichte
|
||||
|
||||
Die Idee stammte von Netscape; die erste Version von SSL wurde 1994 veröffentlicht. 1999 übernahm die IETF den Standard und benannte ihn in **Transport Layer Security (TLS)** um. Da TLS/SSL in allen wichtigen Internet-Technologien (Browser, Web-Server, E-Mail-Server) eingebunden ist, ist es der De-facto-Standard für Transportverschlüsselung.
|
||||
|
||||
---
|
||||
|
||||
### 3.2 Architektur und Protokolle
|
||||
|
||||
#### Einordnung im Schichtenmodell
|
||||
|
||||
TLS/SSL befindet sich zwischen der Transport- und der Anwendungsschicht. Es übernimmt zusätzlich die Aufgaben der Sitzungs- und Präsentationsschicht (Schichten 5 und 6 des ISO/OSI-Modells). Ein wesentlicher Vorteil: Zustandsinformationen können über einen längeren Zeitraum und über verschiedene Einzelverbindungen hinweg gespeichert werden. Für das zustandslose HTTP-Protokoll bedeutet das, dass mehrere TCP-Verbindungen zu einer TLS/SSL-Sitzung gebündelt werden können.
|
||||
|
||||
TLS/SSL kann eine Vielzahl höherer Anwendungsprotokolle unterstützen – HTTP, SMTP, SIP, IMAP, FTP, Telnet und weitere. Der Client entscheidet durch die Wahl des Ports, ob die Kommunikation gesichert sein soll oder nicht.
|
||||
|
||||
#### Port-Zuordnungen
|
||||
|
||||
|Protokoll|Standard-Port|TLS/SSL-Port|
|
||||
|---|---|---|
|
||||
|HTTP|80|443|
|
||||
|SMTP|25|465|
|
||||
|IMAP|143|993|
|
||||
|SIP|5060|5061|
|
||||
|FTP|20, 21|989, 990|
|
||||
|Telnet|23|992|
|
||||
|
||||
#### Aufbau der TLS/SSL-Schicht
|
||||
|
||||
Die TLS/SSL-Schicht besteht aus zwei Teilschichten:
|
||||
|
||||
1. **Höhere Schicht** mit vier TLS/SSL-Teilprotokollen: ChangeCipherSpec (CCS), Alert, Handshake und Application Data
|
||||
2. **Record-Schicht** mit dem Record Layer Protokoll
|
||||
|
||||
Die Protokolle sind erweiterbar und flexibel gestaltet, um Zukunftssicherheit bei den Verschlüsselungsalgorithmen zu gewährleisten. TLS/SSL arbeitet transparent – es kann jedes Anwendungsprotokoll absichern, das keine eigenen Sicherheitsmechanismen mitbringt.
|
||||
|
||||
---
|
||||
|
||||
### 3.3 Record Layer Protokoll
|
||||
|
||||
#### Aufgaben
|
||||
|
||||
Das Record Layer Protokoll ist das Arbeitspferd von TLS/SSL. Es nimmt die Klartext-Anwendungsdaten aus der Anwendungsschicht entgegen und leitet sie verschlüsselt an die Transportschicht weiter. Es bietet zwei Sicherheitsdienste, die zusammen oder einzeln genutzt werden können: Client-to-Server-Verschlüsselung und Sicherung der Nachrichten-Integrität und -Authentizität.
|
||||
|
||||
#### Verarbeitungsschritte
|
||||
|
||||
Die Record-Schicht führt folgende Schritte aus:
|
||||
|
||||
1. **Fragmentierung** der Klartext-Anwendungsdaten in Records mit maximal 2¹⁴ Byte (16.384 Byte)
|
||||
2. **Kompression** der Fragmente (optional, Verfahren wird beim Handshake ausgehandelt)
|
||||
3. **HMAC-Berechnung** über die (komprimierten) Fragmente plus Sequenznummer
|
||||
4. **Verschlüsselung** des komprimierten Fragments zusammen mit dem HMAC
|
||||
5. **Record-Bildung** durch Voranstellen des Record-Headers
|
||||
|
||||
#### Record-Header
|
||||
|
||||
Der Record-Header ist 5 Byte groß und enthält:
|
||||
|
||||
- **Type** (1 Byte): Nummer des höheren TLS/SSL-Protokolls (20 = CCS, 21 = Alert, 22 = Handshake, 23 = Application Data)
|
||||
- **Version Major** (1 Byte): Hauptversionsnummer
|
||||
- **Version Minor** (1 Byte): Unterversionsnummer
|
||||
- **Length** (2 Byte): Länge der Nutzdaten (maximal 2¹⁴ + 2.048 Byte)
|
||||
|
||||
Wichtig: Der gesamte Record-Layer-Header ist ungeschützt und somit für jeden Mitleser sichtbar. Nur die Nutzdaten sind verschlüsselt.
|
||||
|
||||
#### HMAC-Berechnung
|
||||
|
||||
Die HMAC-Berechnung bezieht bewusst nicht nur die Daten, sondern auch Metainformationen ein:
|
||||
|
||||
```
|
||||
HMAC = KH(HMAC-Key, SeqNum || Compressed.type || Compressed.version ||
|
||||
Compressed.length || Compressed.fragment)
|
||||
```
|
||||
|
||||
Durch die Einbeziehung der Sequenznummer wird Replay-Schutz erreicht, durch Type und Version wird sichergestellt, dass ein Angreifer den Record-Typ nicht unbemerkt ändern kann.
|
||||
|
||||
---
|
||||
|
||||
### 3.4 Die vier Teilprotokolle
|
||||
|
||||
#### Application Data Protokoll
|
||||
|
||||
Dieses Protokoll reicht die eigentlichen Anwendungsdaten transparent – also ohne Betrachtung des Inhalts – durch. Die Daten werden gemäß den im Handshake ausgehandelten Sicherheitsparametern fragmentiert, komprimiert, gegen Verfälschung geschützt und verschlüsselt.
|
||||
|
||||
#### ChangeCipherSpec (CCS) Protokoll
|
||||
|
||||
Dieses minimale Protokoll wird bei Änderung des kryptographischen Algorithmus oder der Parameter genutzt. Es enthält nur eine einzige Meldung: ein Byte mit dem Wert 1. CCS bewirkt, dass der Empfänger die während des Handshakes ausgehandelten Parameter für die aktive Sitzung übernimmt.
|
||||
|
||||
#### Alert Protokoll
|
||||
|
||||
Das Alert-Protokoll dient der Signalisierung von Problemen wie Fehlern oder Verbindungsabbrüchen. Eine Alert-Nachricht besteht aus nur 2 Byte: dem Sicherheitslevel und dem Fehlercode.
|
||||
|
||||
Das erste Byte kann zwei Werte annehmen:
|
||||
|
||||
- **warning (1)** – die Verbindung kann fortgesetzt werden
|
||||
- **fatal (2)** – TLS/SSL beendet die Verbindung sofort
|
||||
|
||||
Fatale Alerts umfassen unter anderem: falscher HMAC (`bad_record_mac`), Record zu groß (`record_overflow`), Handshake-Fehler (`handshake_failure`), unbekannte CA (`unknown_ca`), Zugriff verweigert (`access_denied`), Protokollversion nicht unterstützt (`protocol_version`) und unzureichende Sicherheit (`insufficient_security`).
|
||||
|
||||
Warnungs-Alerts betreffen typischerweise Zertifikatsprobleme: ungültiges Zertifikat (`bad_certificate`), gesperrtes Zertifikat (`certificate_revoked`), abgelaufenes Zertifikat (`certificate_expired`) und weitere.
|
||||
|
||||
#### Handshake Protokoll
|
||||
|
||||
Das Handshake-Protokoll ist das komplexeste der vier Teilprotokolle. Es ermöglicht den Aufbau einer TLS/SSL-Verbindung, indem es die Kommunikationspartner identifiziert und authentifiziert, kryptographische Algorithmen, Schlüssel und Parameter aushandelt und den Austausch geheimer Informationen durchführt.
|
||||
|
||||
Eine Handshake-Nachricht besteht aus: Type (1 Byte), Length (3 Byte) und Content (variabel).
|
||||
|
||||
---
|
||||
|
||||
### 3.5 Sitzungs- und Verbindungskonzepte
|
||||
|
||||
TLS/SSL ist ein zustandsbehaftetes Protokoll mit zwei wichtigen Konzepten: Sessions und Connections.
|
||||
|
||||
#### Session
|
||||
|
||||
Eine TLS/SSL-Session ist eine "Security Association" zwischen Client und Server. Sie wird über das Handshake-Protokoll aufgebaut und definiert eine Menge kryptographischer Sicherheitsparameter, die über mehrere Verbindungen hinweg genutzt werden können. Der Sinn: Es muss nicht jedes Mal eine neue, zeitaufwendige Verhandlung der Sicherheitsparameter stattfinden.
|
||||
|
||||
Session-Zustände umfassen:
|
||||
|
||||
- **Session-Identifier**: Zufällige Bytesequenz vom Server zur Identifikation der Session
|
||||
- **Peer-Certificate**: X.509v3-Zertifikat des Clients (falls vorhanden)
|
||||
- **Compression-Method**: Vereinbarter Kompressionsalgorithmus
|
||||
- **Cipher-Spec**: Verschlüsselungsalgorithmus, Hash-Funktion für HMAC und weitere Attribute
|
||||
- **Master-Secret**: 48 Byte, aus denen Client und Server die geheimen Schlüssel ableiten
|
||||
- **Is-Resumable**: Flag, das anzeigt, ob die Session wiederverwendet werden kann
|
||||
|
||||
#### Connection
|
||||
|
||||
Eine TLS/SSL-Connection ist ein logischer, temporärer Transportkanal zwischen Client und Server. Sie ist immer mit einer Session assoziiert, und aus einer Session können mehrere Connections parallel aufgebaut werden.
|
||||
|
||||
Connection-Zustände umfassen unter anderem:
|
||||
|
||||
- **Server-/Client-Random**: Zufallszahlen, die für jede Verbindung neu erzeugt werden
|
||||
- **Server-/Client-Write-MAC-Secret**: Geheime Schlüssel für HMAC-Operationen in jeder Richtung
|
||||
- **Server-/Client-Write-Key**: Symmetrische Schlüssel für Ver- und Entschlüsselung in jeder Richtung
|
||||
- **Initialization Vectors**: Für Modi wie CBC, die einen IV benötigen
|
||||
- **Sequence Numbers**: Für gesendete und empfangene Daten jeder Verbindung; werden bei CCS auf Null zurückgesetzt
|
||||
|
||||
Entscheidend: Die Schlüssel gelten jeweils nur für eine Verbindung, aber die Verfahren werden pro Session ausgehandelt. Bei Wiederverwendung einer bestehenden Session entfällt die Neuverhandlung.
|
||||
|
||||
---
|
||||
|
||||
### 3.6 Protokollablauf: Der Handshake im Detail
|
||||
|
||||
Der Protokollablauf erfolgt in zwei Schritten: dem Verbindungsaufbau (vier Phasen) und dem Transfer-Mode.
|
||||
|
||||
#### Phase 0: HelloRequest
|
||||
|
||||
Der Server kann jederzeit ein HelloRequest an den Client senden, um ihn zu einem neuen ClientHello zu veranlassen. Diese Nachricht hat keine Parameter. Der Client antwortet nur, wenn er sich nicht bereits in einem Handshake befindet. Erhält der Server keine Antwort, kann er die Verbindung schließen.
|
||||
|
||||
#### Phase 1: Aushandlung der Sicherheitsparameter
|
||||
|
||||
**ClientHello**: Der Client startet den Verbindungsaufbau. Diese Klartextnachricht enthält:
|
||||
|
||||
- **Random Client (RC)**: 4 Byte Zeitstempel + 28 Byte Zufallszahl
|
||||
- **Sitzungs-ID**: Falls eine bestehende Sitzung wiederaufgenommen werden soll
|
||||
- **Prioritätenliste der Cipher Suites**: Alle Kryptographie- und Kompressionsverfahren, die der Client unterstützt
|
||||
|
||||
Der Client sollte nur Verfahren und Schlüssellängen anbieten, die sein gewünschtes Sicherheitsniveau erfüllen.
|
||||
|
||||
**ServerHello**: Der Server antwortet mit den gleichen Parametertypen:
|
||||
|
||||
- **Random Server (RS)**: 4 Byte Zeitstempel + 28 Byte Zufallszahl
|
||||
- Die vom Server **ausgewählte Cipher Suite**, die nachfolgend verwendet wird
|
||||
- Die Sitzungs-ID: Übernimmt der Server die vom Client vorgeschlagene ID, kann die Sitzung später wieder aufgenommen werden. Gibt er keine an, ist die Sitzung nicht wiederherstellbar.
|
||||
|
||||
#### Cipher Suites
|
||||
|
||||
Eine Cipher Suite ist eine Kombination aus drei Komponenten:
|
||||
|
||||
1. **Schlüsselaustauschverfahren** (z. B. DHE_RSA)
|
||||
2. **Verschlüsselungsalgorithmus** mit Schlüssellänge und Mode of Operation (z. B. AES_256_GCM)
|
||||
3. **Hash-Funktion** für den HMAC (z. B. SHA384)
|
||||
|
||||
Beispiel: `TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256` bedeutet: Schlüsselaustausch über Elliptic-Curve Diffie-Hellman Ephemeral mit RSA-Signatur, Verschlüsselung mit AES-128 im GCM-Modus, HMAC mit SHA-256.
|
||||
|
||||
#### Phase 2: Serverauthentifizierung und Schlüsselaustausch
|
||||
|
||||
- **Certificate (11)**: Der Server sendet sein X.509v3-Zertifikat, das für eine Domäne von einer Zertifizierungsinstanz ausgestellt wurde. Das Zertifikat muss zur gewählten Cipher Suite passen.
|
||||
- **ServerKeyExchange (12)**: Wird nur gesendet, wenn der Server kein Zertifikat mit festen DH-Parametern oder RSA-Schlüssel besitzt. Enthält einen temporären öffentlichen Schlüssel.
|
||||
- **CertificateRequest (13)**: Optional – der Server fordert eine Client-Authentifikation per Zertifikat an.
|
||||
- **ServerHelloDone (14)**: Signalisiert dem Client das Ende von Phase 2. Diese Nachricht ist nötig, weil die vorherigen drei Nachrichten optional sind.
|
||||
|
||||
#### Phase 3: Clientauthentifizierung und Schlüsselaustausch
|
||||
|
||||
- **Certificate (11)**: Wurde ein CertificateRequest gesendet, muss der Client nun sein Zertifikat übermitteln.
|
||||
- **ClientKeyExchange (16)**: Der Client prüft zunächst die Gültigkeit des Server-Zertifikats. Dann übermittelt er das **Pre-Master-Secret (48 Byte)**: Bei RSA verschlüsselt der Client es mit dem öffentlichen Schlüssel des Servers. Bei Diffie-Hellman sendet er seinen öffentlichen DH-Schlüssel, und beide Seiten berechnen das Pre-Master-Secret dezentral.
|
||||
- **CertificateVerify (15)**: Der Client beweist, dass er den zum Zertifikat gehörigen geheimen Schlüssel besitzt, indem er einen Hashwert über alle bisherigen Handshake-Nachrichten berechnet und mit seinem privaten Schlüssel signiert. Der Server verifiziert diese Signatur.
|
||||
|
||||
#### Master Secret und Schlüsselerzeugung
|
||||
|
||||
Das Pre-Master-Secret und die ausgetauschten Zufallszahlen werden verwendet, um das 48 Byte große **Master-Secret** zu berechnen:
|
||||
|
||||
```
|
||||
Master-Secret = KH(Pre-Master-Secret, ClientHello.random || ServerHello.random)
|
||||
```
|
||||
|
||||
Aus dem Master-Secret werden dann alle benötigten Schlüssel (Session Keys, HMAC-Schlüssel, IVs) abgeleitet:
|
||||
|
||||
```
|
||||
Key-Block = KH(Master-Secret, ServerHello.random || ClientHello.random)
|
||||
```
|
||||
|
||||
Der Key-Block wird so lange generiert, bis alle Schlüssel daraus konstruiert sind. Beide Seiten (Client und Server) führen diese Berechnung unabhängig voneinander durch und kommen zum gleichen Ergebnis.
|
||||
|
||||
#### Phase 4: Beendigung des Handshakes
|
||||
|
||||
Client und Server senden jeweils eine **ChangeCipherSpec**-Nachricht, die signalisiert, dass ab jetzt die ausgehandelten Verfahren und Parameter genutzt werden. Darauf folgt die **Finished (20)**-Nachricht, die bestätigt, dass der jeweilige Teil des Verbindungsaufbaus abgeschlossen ist. Die Finished-Nachricht ist die erste Nachricht, die bereits mit den neuen Sicherheitsparametern verschlüsselt und integritätsgesichert wird.
|
||||
|
||||
---
|
||||
|
||||
### 3.7 Domänen-Zertifikate
|
||||
|
||||
Domänen-Zertifikate ordnen einen öffentlichen Schlüssel eindeutig einer Organisation (Domäne) zu. Die Zertifizierungsstelle signiert das Zertifikat und verbürgt sich dafür, dass die Organisation, die den passenden geheimen Schlüssel besitzt, auch tatsächlich existiert.
|
||||
|
||||
#### Vertrauensstufen
|
||||
|
||||
Es gibt drei Stufen der Überprüfung:
|
||||
|
||||
- **Domain Validated (DV)**: Die einfachste Stufe. Die Zertifizierungsstelle bestätigt lediglich, dass der Antragsteller die administrative Kontrolle über die Domain nachweisen kann. Das Zertifikat enthält keinerlei Unternehmensinformationen.
|
||||
- **Organization Validated (OV)**: Enthält verifizierte Unternehmensinformationen, die aber nur in den Zertifikatdetails sichtbar sind.
|
||||
- **Extended Validation (EV)**: Die strengste Stufe. Der Unternehmensname wird prominent in der grünen Adresszeile des Browsers angezeigt. Unternehmen müssen die strengsten Anforderungen erfüllen.
|
||||
|
||||
#### Root-Zertifikate
|
||||
|
||||
Das Root-Zertifikat ist das oberste Zertifikat im Verzeichnisbaum. Browser haben die Root-Zertifikate der wichtigsten Zertifizierungsstellen vorinstalliert. Ist ein Root-Zertifikat dem Browser unbekannt, erhält der Nutzer einen Warnhinweis mit der Möglichkeit, dem Zertifikat einmalig oder dauerhaft zu vertrauen.
|
||||
|
||||
#### Bewertung der Authentikationsqualität
|
||||
|
||||
Die Qualität hängt ab von: der Vertrauenswürdigkeit der Zertifizierungsinstanz, dem Level der Identitätsprüfung und der Bereitstellung einer Certificate Revocation List (CRL). Die Zertifikatsklassen reichen von Klasse 1 (nur Name und E-Mail nötig) über Klasse 2 (Kopie des Ausweises) bis zu höheren Klassen (persönliche Authentisierung bei einer Registration Authority).
|
||||
|
||||
---
|
||||
|
||||
### 3.8 Authentifikationsmethoden
|
||||
|
||||
TLS/SSL unterscheidet drei Verbindungsarten:
|
||||
|
||||
**1. Server und Client ohne Authentifizierung**: Weder Server noch Client weisen sich per Zertifikat aus. Diese Variante ist **nicht sicher gegen Man-in-the-Middle-Angriffe** und sollte vermieden werden.
|
||||
|
||||
**2. Server authentifiziert, Client anonym** (gängigste Art): Der Server übermittelt sein Zertifikat. Der Client kann nach Verifikation sicher sein, dass die Verbindung zum echten Server besteht. Ein MITM-Angreifer kann sich nicht als falscher Server ausgeben. Dies ist das Standardverfahren beim Aufruf von HTTPS-Webseiten.
|
||||
|
||||
Ablauf im Detail:
|
||||
|
||||
1. Client wählt Internetseite an
|
||||
2. Server übermittelt sein Domänen-Zertifikat mit dem öffentlichen RSA-Schlüssel
|
||||
3. Client prüft das Zertifikat auf Gültigkeit
|
||||
4. Client generiert das Pre-Master-Secret und verschlüsselt es mit dem öffentlichen Schlüssel des Servers
|
||||
5. Server entschlüsselt das Pre-Master-Secret, generiert die Session Keys
|
||||
6. Verschlüsselter Datenaustausch beginnt
|
||||
|
||||
**3. Server und Client authentifiziert**: Der Server fordert per CertificateRequest auch ein Client-Zertifikat an. Der Client beweist per CertificateVerify, dass er tatsächlich der Inhaber des Zertifikats ist. Falls der Client kein passendes Zertifikat besitzt, wird der Verbindungsaufbau abgebrochen.
|
||||
|
||||
---
|
||||
|
||||
### 3.9 Anwendungsformen
|
||||
|
||||
TLS/SSL sichert nicht nur Web-Kommunikation (HTTPS), sondern auch:
|
||||
|
||||
- **Mail-Kommunikation**: SMTPS, IMAPS, POP3S
|
||||
- **SIP-Kommunikation**: Für VoIP und Echtzeitkommunikation
|
||||
|
||||
---
|
||||
|
||||
## 4. QUIC – Quick UDP Internet Connections
|
||||
|
||||
### 4.1 Motivation
|
||||
|
||||
Das klassische Verfahren zum Aufbau einer gesicherten Web-Verbindung erfordert drei aufeinanderfolgende Handshakes: den TCP-3-Wege-Handshake, den TLS-Handshake und den HTTP-Handshake. Bei einem Round-Trip von 200 ms summiert sich das auf bis zu 2 Sekunden allein für den Verbindungsaufbau – und das für jede einzelne Ressource einer Webseite, die aus Dutzenden oder Hunderten Teilen bestehen kann.
|
||||
|
||||
Gleichzeitig haben sich die Internet-Geschwindigkeiten rasant gesteigert, selbst Privatanwender verfügen über Gigabit-Anschlüsse. TCP kann diese Bandbreite nicht vollständig ausschöpfen.
|
||||
|
||||
### 4.2 Die QUIC-Lösung
|
||||
|
||||
QUIC wurde 2012 bei Google begonnen und 2017 an die IETF übergeben. Der Kernansatz: Die drei sequentiellen Handshakes werden **verschachtelt** und in einem einzigen Schritt zusammengefasst. QUIC basiert auf UDP statt TCP und integriert TLS 1.3 direkt in das Transportprotokoll. Dafür wurde auch HTTP/3 als neues Anwendungsprotokoll entwickelt.
|
||||
|
||||
Der Vergleich: Während TCP + TLS mehrere Round-Trips benötigt, kann QUIC den gesamten Verbindungsaufbau in einem einzigen Round-Trip erledigen – bei bekannten Servern sogar in null Round-Trips (0-RTT).
|
||||
|
||||
### 4.3 Verbreitung und offene Fragen
|
||||
|
||||
QUIC wird bereits für die Hälfte des Verkehrs zwischen Google-Servern und Chrome genutzt. Facebook setzt QUIC vollständig ein, und es befindet sich in den Beta-Stadien von Edge, Firefox und Safari.
|
||||
|
||||
Offene Fragen und Bedenken: QUIC ist ein komplexes Protokoll, das drei Schritte auf einmal durchführt – was passiert, wenn ein Schritt scheitert? Außerdem bietet QUIC ausschließlich Verschlüsselung an, was von Rechenzentren und Nachrichtendiensten kritisch gesehen wird, da diese zur Netzwerkdiagnose oder Überwachung gerne den Klartext-Verkehr analysieren möchten.
|
||||
|
||||
---
|
||||
|
||||
## 5. Digitale Signaturen, Zertifikate und PKI
|
||||
|
||||
### 5.1 Eigenhändige Unterschrift als Ausgangspunkt
|
||||
|
||||
Um digitale Signaturen zu verstehen, lohnt ein Blick auf die Funktionen der eigenhändigen Unterschrift, die die digitale Signatur elektronisch nachbilden soll:
|
||||
|
||||
- **Abschlussfunktion**: Die Unterschrift vollendet eine Erklärung und hebt sie vom Entwurf ab
|
||||
- **Identitätsfunktion**: Sie macht die Identität des Ausstellers kenntlich
|
||||
- **Echtheitsfunktion**: Sie bestätigt, dass das Dokument vom Aussteller stammt
|
||||
- **Warnfunktion**: Sie schützt den Unterzeichner vor Übereilung
|
||||
- **Beweisfunktion**: Sie erleichtert die Beweisführung im Streitfall (Urkundenbeweis)
|
||||
|
||||
### 5.2 Digitale Signatur
|
||||
|
||||
#### Grundprinzip
|
||||
|
||||
Die Signaturerstellung zu einer Nachricht m funktioniert mit einem asymmetrischen Verfahren:
|
||||
|
||||
```
|
||||
s = S(m, GSₐ)
|
||||
```
|
||||
|
||||
Dabei ist S die Signaturfunktion (z. B. RSA), m die zu signierende Nachricht, s die resultierende Signatur (z. B. eine 3.000-Bit-Zeichenkette) und GSₐ der geheime Schlüssel des Nutzers A.
|
||||
|
||||
Die Verifikation erfolgt durch:
|
||||
|
||||
```
|
||||
V(m, s, ÖSₐ) = true?
|
||||
```
|
||||
|
||||
Hierbei ist V die Verifikationsfunktion und ÖSₐ der öffentliche Schlüssel des Nutzers A.
|
||||
|
||||
#### Performance-Problem und Lösung
|
||||
|
||||
Public-Key-Verfahren haben eine relativ hohe Verarbeitungszeit. Eine direkte Signatur einer großen Datei wäre unpraktikabel: 100 MB bei 2.048 Bit Schlüssellänge würden etwa 400.000 Operationen erfordern – bei 100 ms pro Operation wären das rund 11 Stunden. Zudem wäre die Zusammengehörigkeit der einzelnen Signaturblöcke nicht gegeben.
|
||||
|
||||
Die Lösung ist die Verwendung einer **One-Way-Hashfunktion**: Statt die gesamte Nachricht zu signieren, wird zuerst ein kompakter Hashwert berechnet und nur dieser signiert:
|
||||
|
||||
```
|
||||
AV(hm = H(m), s, ÖSₐ) = true
|
||||
```
|
||||
|
||||
Vorteile: Beliebig lange Nachrichten können signiert werden, die Signaturerstellung ist schnell, und jedes einzelne Bit der Nachricht ist über den Hashwert in die Signatur eingeschlossen (Integritätsschutz).
|
||||
|
||||
### 5.3 Digitale Zertifikate
|
||||
|
||||
Ein digitales Zertifikat ermöglicht es, Attribute von Nutzern überprüfbar nachzuweisen und die Authentizität öffentlicher Schlüssel zu bestätigen. Ausgestellt werden Zertifikate durch Zertifizierungsinstanzen – das können spezialisierte Anbieter, Berufsverbände (Notare, Steuerberater, Ärzte), Personalabteilungen oder Behörden sein.
|
||||
|
||||
Der Prozess zur Erstellung und Verifikation eines Zertifikats: Die Zertifizierungsinstanz prüft alle relevanten Daten (Identität, Ausweis, Urkunden, weitere Attribute), erstellt das Zertifikat mit dem öffentlichen Schlüssel des Nutzers und signiert es mit ihrem eigenen geheimen Schlüssel. Jeder Dritte kann das Zertifikat dann mit dem öffentlichen Schlüssel der Zertifizierungsinstanz verifizieren.
|
||||
|
||||
---
|
||||
|
||||
### 5.4 Public-Key-Infrastrukturen (PKI)
|
||||
|
||||
#### Definition und Aufgabe
|
||||
|
||||
Eine PKI verwaltet Zertifikate mit öffentlichen Schlüsseln und weiteren Attributen über deren gesamten Lebenszyklus: Erstellung, Aufbewahrung, Verwendung und Löschung. Die Analogie aus der analogen Welt: Standesamt und Einwohnermeldeamt.
|
||||
|
||||
Eine PKI besteht aus Hardware, Software und einem Regelwerk und deckt folgende Sicherheitsbedürfnisse ab:
|
||||
|
||||
|Sicherheitsbedürfnis|Mechanismus|
|
||||
|---|---|
|
||||
|Authentizität|Signatur|
|
||||
|Integrität|Signatur|
|
||||
|Verbindlichkeit|Signatur|
|
||||
|Einmaligkeit|Zeitstempel|
|
||||
|Vertraulichkeit|Verschlüsselung|
|
||||
|
||||
#### Bestandteile einer PKI
|
||||
|
||||
- **Registration Authority (RA)**: Schnittstelle zwischen PKI-Nutzer und CA. Erfasst Anträge auf Zertifizierung und prüft die Identität der Antragsteller gemäß des Regelwerks. Kann eine private oder öffentliche Einrichtung sein.
|
||||
|
||||
- **Certification Authority (CA)**: Vergibt eindeutige digitale Identitäten, erzeugt Zertifikate und verwaltet Schlüsselpaare pro Nutzer.
|
||||
|
||||
- **Directory Service (DIR)**: Öffentlich zugreifbarer Verzeichnisdienst zur Verwaltung der Zertifikate.
|
||||
|
||||
- **Certificate Revocation List (CRL)**: Sperrliste für zurückgezogene oder kompromittierte Schlüssel und Zertifikate. Vor jeder Verifikation sollte ein Abgleich mit der Sperrliste erfolgen.
|
||||
|
||||
- **Time Stamping Service**: Erstellt gesicherte Zeitsignaturen gemäß des Regelwerks.
|
||||
|
||||
- **Personal Security Environment (PSE)**: Sammlung aller sicherheitsrelevanten Daten eines Teilnehmers – geheimer Schlüssel, öffentlicher Schlüssel der CA, ggf. Zertifikate der Kommunikationspartner. Mögliche Formen: Software, Smartcards, USB-Token, HSMs, SIM-Karten, TPMs.
|
||||
|
||||
- **PKI-enabled Application (PKA)**: Anwendungen, die auf den Sicherheitsmechanismen der PKI aufbauen (Dokumentenverschlüsselung, Zahlungssysteme, IPSec, ...).
|
||||
|
||||
|
||||
#### Wirksamkeit und Lesegeräte-Kategorien
|
||||
|
||||
Unsicher gespeicherte Schlüssel sind das größte Sicherheitsrisiko. Daher werden in der Regel Smartcards oder USB-Token verwendet. Es gibt drei Kategorien von Lesegeräten:
|
||||
|
||||
1. **Basisleser**: Anzeige und Eingabe über dasselbe IT-System des Nutzers – hohes Restrisiko durch Malware
|
||||
2. **Standardleser**: Anzeige und Eingabe über ein externes IT-System
|
||||
3. **Komfortleser**: Ein zertifizierter Standardleser mit höchster Sicherheitsstufe
|
||||
|
||||
#### PKI-Konzepte
|
||||
|
||||
Es gibt drei grundlegende PKI-Architekturen:
|
||||
|
||||
- **Geschlossene, dezentrale PKI**: Funktioniert nur innerhalb einer Organisation; keine Kommunikation nach außen möglich. Problem: In der Praxis existieren viele organisationsübergreifende Prozesse.
|
||||
|
||||
- **Offene, dezentrale PKI**: Mehrere unabhängige CAs, die untereinander Zertifikate austauschen. Problem: Abgleich verschiedener Regelwerke nötig, um eine gemeinsame Vertrauensbasis zu schaffen.
|
||||
|
||||
- **Offene, zentrale PKI**: Eine übergeordnete Wurzel-CA als gemeinsame Vertrauensbasis. Problem: Organisationen akzeptieren selten eine solche Unterordnung.
|
||||
|
||||
|
||||
#### Vertrauensmodelle
|
||||
|
||||
1. **Übergeordnete CA (Root CA)**: Hierarchisches Modell, in dem die Wurzel-CA die Zertifikate aller untergeordneten CAs signiert. Nur in großen, geschlossenen Systemen etabliert, da Organisationen selten eine Unterordnung akzeptieren.
|
||||
|
||||
2. **n:n-Cross-Zertifizierung**: Jede CA tauscht ihre öffentlichen Schlüssel selbstständig mit jeder anderen CA aus. Sehr aufwendig bei vielen Teilnehmern, nur für kleine Gruppen geeignet.
|
||||
|
||||
3. **1:n-Cross-Zertifizierung (Bridge CA)**: Eine zentrale Bridge CA fungiert als Vermittlungsinstanz. Jede CA hat nur einen Vertragspartner, der Verwaltungsaufwand ist gering. Die CAs übergeben ihre öffentlichen Schlüssel authentisch an die Bridge CA, die eine signierte Tabelle aller beteiligten öffentlichen Schlüssel erstellt.
|
||||
|
||||
|
||||
#### Praxisprobleme
|
||||
|
||||
- Unterschiedliche Verantwortlichkeiten für PKIs und PKAs in Unternehmen erschweren die Abstimmung
|
||||
- Das Henne-Ei-Problem: PKIs benötigen konsequenten Einsatz, aber Organisationen können sich nur schwer auf gemeinsame Sicherheitskonzepte einigen
|
||||
- Hoher personeller und organisatorischer Aufwand für Sensibilisierung, Schulung und Roll-Out
|
||||
- Key-Recovery: Was passiert bei technischen Defekten, verlorenen PSEs oder ausscheidenden Mitarbeitern?
|
||||
|
||||
---
|
||||
|
||||
### 5.5 Gesetzlicher Hintergrund: eIDAS
|
||||
|
||||
#### Grundlagen
|
||||
|
||||
Die EU-Verordnung 910/2014 (**eIDAS** – electronic Identification, Authentication and Trust Service) regelt die elektronische Identifizierung und Vertrauensdienste für elektronische Transaktionen im europäischen Binnenmarkt. Ziel: Gleichstellung, Interoperabilität und gegenseitige Anerkennung der Vertrauensdienste aller Mitgliedsstaaten.
|
||||
|
||||
In Deutschland umgesetzt durch das Signaturgesetz (SigG) und die Signaturverordnung (SigV). eIDAS gilt für alle in der EU niedergelassenen Vertrauensdienstanbieter (VDA), ausgenommen sind interne Unternehmenslösungen.
|
||||
|
||||
#### Kernregelungen
|
||||
|
||||
- **Rechtssicherheit**: Ein elektronisches Dokument soll in der EU den gleichen Stellenwert haben wie ein analoges
|
||||
- **Qualifizierte vs. nicht-qualifizierte VDA**: Freiwillige Akkreditierung alle drei Jahre möglich
|
||||
- **EU-Vertrauenssiegel** (Art. 13): Zusätzliches Vertrauensmerkmal, analog zum "IT Security made in Germany"-Qualitätssiegel
|
||||
- **Elektronische Siegel** (Art. 35-40): Pendant zu Signaturen – Signaturen gelten für natürliche Personen, Siegel für Organisationen
|
||||
- **Elektronische Fernsignaturen**: Die sichere Signaturerstellungseinheit befindet sich beim VDA, nicht beim Nutzer
|
||||
- **Haftung** (Art. 11, 13): Qualifizierte VDA sind in der Nachweispflicht, bei nicht-qualifizierten liegt die Beweislast beim Kunden
|
||||
- **Elektronisches Einschreiben** (Art. 43-44): Identifizierung von Absender und Empfänger, Schutz durch fortgeschrittene Signatur oder Siegel, qualifizierte Zeitstempel
|
||||
- **Sicherheitsanforderungen** (Art. 19): Alle VDA müssen Sicherheitsmaßnahmen gemäß dem Stand der Technik implementieren, Sicherheitsvorfälle innerhalb von 24 Stunden melden
|
||||
|
||||
#### De-Mail und eIDAS
|
||||
|
||||
De-Mail ist aktuell nicht vollständig eIDAS-konform: Der VDA selbst versieht Nachrichten mit qualifizierter Signatur (Fernsignatur), statt qualifizierter Zeitstempel werden Prüfsummen und qualifizierte Signaturen verwendet, und die sichere Dokumentenablage ist den Anbietern freigestellt.
|
||||
|
||||
---
|
||||
|
||||
### 5.6 PKI-enabled Applications
|
||||
|
||||
#### E-Mail-Sicherheit
|
||||
|
||||
E-Mail-Sicherheit bedeutet, die gleiche Sicherheit bei elektronischen Nachrichten herzustellen, die bei Briefen selbstverständlich ist: der Briefumschlag (Vertraulichkeit), die Unterschrift (Authentizität und Integrität), der Poststempel (Zeitnachweis).
|
||||
|
||||
Die digitale Signatur bietet nach erfolgreicher Verifikation folgende Garantien: Das Dokument wurde nicht manipuliert, die angegebene Zeit wurde nicht geändert, und nur der angegebene Absender konnte die Signatur erstellen. Als zusätzlicher Sicherheitsdienst steht die Verschlüsselung zur Verfügung.
|
||||
|
||||
Der **digitale Zeitstempel** löst das Problem, dass Systemuhren leicht manipulierbar sind: Eine Zertifizierungsstelle bestätigt per digitaler Signatur, dass ein Dokument zum angegebenen Zeitpunkt vorgelegen hat.
|
||||
|
||||
Für den Endnutzer werden die Sicherheitsfunktionen direkt in die Mailsoftware integriert und per Mausklick aufrufbar. E-Mail-Gateways können eingehende Mails zentral entschlüsseln und ausgehende Mails signieren.
|
||||
|
||||
#### Lotto – Online-Glücksspiel
|
||||
|
||||
Ein anschauliches Beispiel für den Einsatz digitaler Signaturen: Bei Online-Glücksspielen müssen Transaktionsdaten (Wetten) manipulationssicher gespeichert werden. Das alte Verfahren nutzte WORM-Speicher (Write Once, Read Many). Das neue Verfahren nutzt stattdessen einen Zeitstempeldienst:
|
||||
|
||||
1. Es wird ein Hashwert über die Transaktion, das Datum und die Uhrzeit berechnet: `h = H(Transaction, Datum, Uhrzeit)`
|
||||
2. Dieser Hashwert wird mit dem geheimen Schlüssel von Lotto signiert: `s = S(h, GSLotto)`
|
||||
3. Nach der Ziehung kann jede Transaktion verifiziert werden: `V(H(Transaktion, Datum, Uhrzeit), s, ÖSLotto) = true?`
|
||||
|
||||
---
|
||||
|
||||
## 6. Trusted Computing
|
||||
|
||||
### 6.1 Herausforderung: Von reaktiv zu proaktiv
|
||||
|
||||
Traditionelle IT-Sicherheitssysteme arbeiten reaktiv – wie ein Airbag, der erst bei einem Aufprall auslöst. Trusted Computing verfolgt einen proaktiven Ansatz: Das System soll vorausschauend sicherstellen, dass nur vertrauenswürdige Software in einer vertrauenswürdigen Umgebung ausgeführt wird.
|
||||
|
||||
Das fundamentale Problem: Software allein kann keine verlässliche Vertrauensbasis sein, da sie manipuliert werden kann. Daher braucht man einen Hardware-Vertrauensanker.
|
||||
|
||||
### 6.2 Sicherheitsprinzipien
|
||||
|
||||
Trusted Computing basiert auf mehreren zusammenwirkenden Prinzipien:
|
||||
|
||||
- **Robustheit und Modularität**: Das System wird in isolierte, kontrollierbare Module aufgeteilt (Virtualisierung, Mikrokernel)
|
||||
- **Trusted Process**: Isolierte Prozesse, die sich nicht gegenseitig beeinflussen können
|
||||
- **Integritätsprüfung**: Kontinuierliche Überprüfung der System- und Softwareintegrität
|
||||
- **Trusted Platform**: Hardware-Vertrauensanker (TPM) als Basis
|
||||
|
||||
Die Gesamtarchitektur besteht aus: Hardware mit Security Module → Security Kernel / Virtualization → Trusted Software Layer → Isolierte Virtual Domains mit Anwendungen.
|
||||
|
||||
---
|
||||
|
||||
### 6.3 Kernelarchitekturen
|
||||
|
||||
#### Monolithischer Kernel
|
||||
|
||||
Beim monolithischen Kernel (z. B. Linux, Windows) laufen alle Treiber und Systemdienste im Kernel-Space.
|
||||
|
||||
Vorteile: Lange etabliert, gute Performance.
|
||||
|
||||
Nachteile: Alle Treiber sind im Kernel-Space vereint, was zu geringerer Flexibilität, höherer Komplexität, weniger Robustheit und schlechten Sicherheitsmechanismen führt. Ein fehlerhafter Treiber kann das gesamte System kompromittieren.
|
||||
|
||||
#### Mikrokernel
|
||||
|
||||
Beim Mikrokernel (z. B. L4, MINIX, QNX) laufen nur die absolut notwendigen Funktionen im Kernel – alles andere läuft als eigenständiger Prozess im User-Space.
|
||||
|
||||
Vorteile: Höhere Robustheit, Modularität und Flexibilität, kontrollierbare Interprozesskommunikation und damit höhere IT-Sicherheit, weniger benötigter Speicherplatz.
|
||||
|
||||
Nachteile: Geringere Performance, da die erhöhte Kommunikation zwischen den Prozessen Overhead verursacht.
|
||||
|
||||
Für Trusted Computing ist der Mikrokernel die bevorzugte Architektur, da er eine bessere Isolation und Kontrolle der einzelnen Systemkomponenten ermöglicht.
|
||||
|
||||
---
|
||||
|
||||
### 6.4 TPM-Schlüsselhierarchie und Identitäten
|
||||
|
||||
#### Endorsement Key (EK)
|
||||
|
||||
Der EK ist die eindeutige, nicht migrierbare Identität des TPM. Er wird als RSA-Schlüsselpaar während des Herstellungsprozesses erzeugt. Der geheime Schlüssel ist im TPM gespeichert, der öffentliche Schlüssel ist datenschutzsensibel (da er das TPM und damit potenziell den Nutzer eindeutig identifiziert). Die PKI wird vom TPM-Hersteller verwaltet.
|
||||
|
||||
Das **Endorsement Credential (EC)** ist ein elektronisches Zertifikat vom Hersteller, das die ordnungsgemäße Erstellung und Einbettung des EK bestätigt. Es enthält: TPM-Herstellername, Modellnummer, Version und den öffentlichen EK-Schlüssel.
|
||||
|
||||
#### Storage Root Key (SRK)
|
||||
|
||||
Der SRK ist die Wurzel der gesamten Schlüsselhierarchie im TPM. Er wird während der Installation des TPM-Eigentümers generiert, steht im nicht-flüchtigen Speicher und ist nicht migrierbar. Die Löschung des TPM-Eigentümers löscht den SRK und damit den Zugriff auf die gesamte Schlüsselhierarchie.
|
||||
|
||||
#### Attestation Identity Keys (AIK)
|
||||
|
||||
AIKs werden für die Attestation-Funktion verwendet – also die authentische Bestätigung der Plattformintegrität. Sie sind nötig, weil der EK datenschutzsensibel ist und nicht direkt für Attestation verwendet werden sollte. AIKs werden vom TPM-Besitzer generiert, ein TPM kann mehrere AIKs besitzen (z. B. einen für Online-Banking, einen für E-Mail). Sie sind nicht migrierbar.
|
||||
|
||||
#### Weitere Schlüsseltypen
|
||||
|
||||
- **Storage Keys (StorK)**: Verschlüsseln weitere Schlüssel und Daten außerhalb des TPM. Werden für Sealing verwendet. RSA-Schlüsselpaare, im Allgemeinen migrierbar.
|
||||
- **Binding Keys (BindK)**: Verschlüsseln beliebige Daten (asymmetrische Verschlüsselung). Migrierbar, können nur mit Binding-Befehlen verwendet werden.
|
||||
- **Signing Keys (SigK)**: Nachweis der Authentizität und Integrität von Daten und Protokollnachrichten. RSA-Schlüsselpaare, migrierbar.
|
||||
|
||||
Schlüssel sind entweder **migrierbar** (auf andere Plattformen übertragbar) oder **nicht migrierbar** (an die Plattform gebunden). EK, SRK und AIKs sind nicht migrierbar.
|
||||
|
||||
---
|
||||
|
||||
### 6.5 Core Root of Trust for Measurement (CRTM)
|
||||
|
||||
Der CRTM ist die Vertrauensbasis des gesamten Systems. Er führt Messungen über einzelne Systemzustände (Hardware und Software) durch und speichert die Ergebnisse in den **Platform Configuration Registers (PCRs)** des TPM.
|
||||
|
||||
Es gibt zwei Boot-Varianten:
|
||||
|
||||
- **Authenticated Boot**: Systemzustände werden gemessen und in den PCRs gespeichert, die Integrität wird überprüft – aber der Bootvorgang wird **nicht** gestoppt. Man hat einen nachprüfbaren Zustandsnachweis, aber kein erzwungenes Sicherheitsniveau.
|
||||
|
||||
- **Secure Boot**: Systemzustände werden gemessen, die Integrität wird überprüft, und bei einer Abweichung wird der Bootvorgang **gestoppt**. Nur verifizierte Software kann starten.
|
||||
|
||||
|
||||
Das Vertrauen ist **transitiv**: Der CRTM vertraut dem BIOS, das BIOS vertraut dem Bootloader, der Bootloader vertraut dem Betriebssystem, und so weiter. Jede Stufe misst die nächste, bevor sie ihr die Kontrolle übergibt.
|
||||
|
||||
---
|
||||
|
||||
### 6.6 Die vier zentralen Trusted-Computing-Funktionen
|
||||
|
||||
#### Sealing
|
||||
|
||||
Sealing verschlüsselt Daten so, dass sie nur entschlüsselt werden können, wenn sich das System in einem bestimmten Zustand befindet. Der aktuelle Zustand der Plattform (gespeichert in den PCRs) wird Teil der Verschlüsselung.
|
||||
|
||||
Ablauf des Sealings:
|
||||
|
||||
1. Ein symmetrischer Schlüssel (`plainKEY`) wird erzeugt
|
||||
2. Die Daten werden zusammen mit einem Hash über die Daten und die aktuellen PCR-Werte verschlüsselt: `cipher = encrypt(plainKEY, (daten || H(daten || PCR-0 || ... || PCR-x)))`
|
||||
3. Der symmetrische Schlüssel wird mit dem SRK verschlüsselt: `cryptedKEY = encrypt(SRK, plainKEY || H(plainKEY))`
|
||||
|
||||
Ablauf des Un-Sealings:
|
||||
|
||||
1. Der symmetrische Schlüssel wird mit dem SRK entschlüsselt
|
||||
2. Die Daten werden entschlüsselt
|
||||
3. Die enthaltenen PCR-Werte werden mit den aktuellen PCR-Werten verglichen
|
||||
4. Nur wenn die Werte übereinstimmen, werden die Daten freigegeben – andernfalls wird ein Fehler zurückgegeben
|
||||
|
||||
Praktisches Beispiel: Festplattenverschlüsselung per BitLocker nutzt Sealing, damit die Festplatte nur in dem PC entschlüsselt werden kann, in dem sie verschlüsselt wurde, und nur wenn das Betriebssystem nicht manipuliert wurde.
|
||||
|
||||
#### Binding
|
||||
|
||||
Binding ist die einfachere Variante: Daten werden mit dem öffentlichen Schlüssel des TPM verschlüsselt und können nur auf dieser Plattform entschlüsselt werden. Im Gegensatz zu Sealing wird der Plattformzustand dabei nicht berücksichtigt.
|
||||
|
||||
#### Attestation (Remote Attestation)
|
||||
|
||||
Attestation ermöglicht es einem externen Prüfer, den Integritätszustand einer Plattform zu überprüfen.
|
||||
|
||||
Signaturfunktion (auf der geprüften Plattform):
|
||||
|
||||
1. Der Prüfer sendet eine Zufallszahl (`random`)
|
||||
2. Das TPM berechnet: `σTPM = sign(GSAIK, H(random || PCR-0 || ... || PCR-x))`
|
||||
3. Die Signatur und das AIK-Zertifikat werden zurückgesendet
|
||||
|
||||
Verifikationsfunktion (beim Prüfer):
|
||||
|
||||
1. Die Signatur wird mit dem öffentlichen AIK-Schlüssel verifiziert
|
||||
2. Das AIK-Zertifikat wird auf Gültigkeit geprüft
|
||||
3. Die PCR-Werte werden mit den erwarteten Werten verglichen
|
||||
4. Nur wenn alle drei Prüfungen erfolgreich sind, gilt die Plattform als vertrauenswürdig
|
||||
|
||||
#### Authenticated Boot
|
||||
|
||||
Beim Authenticated Boot wird jede Komponente der Bootkette gemessen, bevor ihr die Kontrolle übergeben wird. Die Messungen werden in den PCRs des TPM gespeichert und können später für Attestation oder Sealing verwendet werden.
|
||||
|
||||
---
|
||||
|
||||
### 6.7 Trusted Network Connect (TNC)
|
||||
|
||||
#### Problemstellung
|
||||
|
||||
In einem Netzwerk reicht es nicht, nur die Authentizität, Integrität und Vertraulichkeit der Kommunikation sicherzustellen – man muss auch sicherstellen, dass die **Endgeräte selbst** in einem vertrauenswürdigen Zustand sind. Ein PC mit veraltetem Virenscanner oder kompromittiertem Betriebssystem ist ein Sicherheitsrisiko für das gesamte Netzwerk.
|
||||
|
||||
Lösungsansätze: Microsoft NAP, Cisco NAC und die TCG-Lösung **Trusted Network Connect (TNC)**.
|
||||
|
||||
#### Prinzip
|
||||
|
||||
TNC betrachtet die Vertrauenswürdigkeit in Abhängigkeit von der Integrität aller beteiligten Kommunikationspartner, IT-Systeme, Infrastrukturelemente und des Umfelds. Anforderungen werden in Policies definiert (erlaubte Konfigurationen, Betriebssysteme, Hard- und Software). Die Überprüfung erfolgt **vor** dem Zugriff auf das Netzwerk (Prävention), und die Kommunikationsrichtung wird getrennt betrachtet.
|
||||
|
||||
TNC nutzt die Attestation-Funktion des TPM: Bevor ein Gerät Zugang zum Netzwerk erhält, muss es seinen aktuellen Zustand per Remote Attestation nachweisen. Entspricht der Zustand nicht der Policy, wird der Zugang verweigert oder eingeschränkt.
|
||||
|
||||
---
|
||||
|
||||
### 6.8 Beispielanwendungen: Turaya
|
||||
|
||||
Turaya ist eine Trusted-Computing-Plattform, die die Konzepte in der Praxis umsetzt:
|
||||
|
||||
- **Turaya.Crypt**: Vertrauenswürdige Festplattenverschlüsselung mittels Sealing
|
||||
- **Turaya.VPN**: Vertrauenswürdige VPN-Verbindungen, bei denen per Attestation sichergestellt wird, dass beide Endpunkte in einem sicheren Zustand sind
|
||||
- **Turaya.FairDRM**: Vertrauenswürdiges Digital Rights Management, das die Rechte sowohl des Anbieters als auch des Nutzers schützt
|
||||
|
||||
---
|
||||
|
||||
### 6.9 Zusammenfassung Trusted Computing
|
||||
|
||||
Die Kernfunktionalitäten sind Robustheit/Modularität, Integritätsprüfung, Trusted Process und Trusted Platform. Der CRTM bildet die Vertrauensbasis, das Vertrauen ist transitiv. Die TPM-Schlüsselhierarchie ermöglicht sichere Speicherung auch auf externen Medien. Die vier zentralen Funktionen (Authenticated Boot, Binding, Sealing, Attestation) bilden zusammen ein umfassendes Sicherheitskonzept. Vertrauenswürdige Netzwerkverbindungen können durch TNC realisiert werden. Die Festlegung einer sicheren und vertrauenswürdigen Systemkonfiguration bleibt jedoch mit zahlreichen technischen und politischen Schwierigkeiten verbunden.
|
||||
Loading…
Add table
Add a link
Reference in a new issue