theo/hwr-notes

Fork 0

mirror of https://github.com/theoleuthardt/hwr-notes.git synced 2026-06-06 00:11:07 +00:00

theoleuthardt 850aa3455d docs: add obsidian hwr docs

2026-04-09 11:24:56 +02:00

50 KiB

Raw Permalink Blame History

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:

Authentifikation von Server und Client unter Verwendung asymmetrischer Verschlüsselung und elektronischer Zertifikate
Vertraulichkeit durch symmetrische Ende-zu-Ende-Verschlüsselung mit einem gemeinsamen Sitzungsschlüssel
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:

Höhere Schicht mit vier TLS/SSL-Teilprotokollen: ChangeCipherSpec (CCS), Alert, Handshake und Application Data
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:

Fragmentierung der Klartext-Anwendungsdaten in Records mit maximal 2¹⁴ Byte (16.384 Byte)
Kompression der Fragmente (optional, Verfahren wird beim Handshake ausgehandelt)
HMAC-Berechnung über die (komprimierten) Fragmente plus Sequenznummer
Verschlüsselung des komprimierten Fragments zusammen mit dem HMAC
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:

Schlüsselaustauschverfahren (z. B. DHE_RSA)
Verschlüsselungsalgorithmus mit Schlüssellänge und Mode of Operation (z. B. AES_256_GCM)
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:

Client wählt Internetseite an
Server übermittelt sein Domänen-Zertifikat mit dem öffentlichen RSA-Schlüssel
Client prüft das Zertifikat auf Gültigkeit
Client generiert das Pre-Master-Secret und verschlüsselt es mit dem öffentlichen Schlüssel des Servers
Server entschlüsselt das Pre-Master-Secret, generiert die Session Keys
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:

Basisleser: Anzeige und Eingabe über dasselbe IT-System des Nutzers – hohes Restrisiko durch Malware
Standardleser: Anzeige und Eingabe über ein externes IT-System
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

Ü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.
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.
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:

Es wird ein Hashwert über die Transaktion, das Datum und die Uhrzeit berechnet: h = H(Transaction, Datum, Uhrzeit)
Dieser Hashwert wird mit dem geheimen Schlüssel von Lotto signiert: s = S(h, GSLotto)
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:

Ein symmetrischer Schlüssel (plainKEY) wird erzeugt
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)))
Der symmetrische Schlüssel wird mit dem SRK verschlüsselt: cryptedKEY = encrypt(SRK, plainKEY || H(plainKEY))

Ablauf des Un-Sealings:

Der symmetrische Schlüssel wird mit dem SRK entschlüsselt
Die Daten werden entschlüsselt
Die enthaltenen PCR-Werte werden mit den aktuellen PCR-Werten verglichen
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):

Der Prüfer sendet eine Zufallszahl (random)
Das TPM berechnet: σTPM = sign(GSAIK, H(random || PCR-0 || ... || PCR-x))
Die Signatur und das AIK-Zertifikat werden zurückgesendet

Verifikationsfunktion (beim Prüfer):

Die Signatur wird mit dem öffentlichen AIK-Schlüssel verifiziert
Das AIK-Zertifikat wird auf Gültigkeit geprüft
Die PCR-Werte werden mit den erwarteten Werten verglichen
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.

50 KiB Raw Permalink Blame History Unescape Escape