docs: add obsidian hwr docs

IT-Sicherheit/Zusammenfassungen/itsec6-11 - zusammenfassung.md

@@ -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.