9.3 Sichere Systeme IT-Sicherheit = Systemsicherheit + Netzsicherheit (umfangreiches Thema eigene Veranstaltung(en), aber siehe auch 6.4 für Teilgebiet Zugriffsschutz) Hier: ausgewählte Themen: Sicherer Systemstart Trusted Computing Terra bs-9.3 1
9.3.1 Sicherer Systemstart Beachte: Ein hohes Maß an Systemsicherheit kann solange nicht erzielt werden, wie die Basis-Software nicht vertrauenswürdig ist. Wenn ein Angreifer beispielsweise das Sicherheitssystem von Java unterlaufen kann (Beispiel für Applets: ein manipulierter Browser), ist der ganze Aufwand, der unter Einsatz dieses Systems betrieben wird, sinnlos. Das wiederum macht eine Systemsoftware mit hohen Sicherheitseigenschaften und Authentizitätsgarantie erforderlich usw. bis herunter zum Systemstart (booting). bs-9.3 2
Terminologisches: trusted system, trusted platform, trusted computing base (TCB),... ist ein System zur Unterstützung von Sicherheit, dessen einwandfreies Funktionieren axiomatisch vorausgesetzt wird. Wir gehen davon aus, dass das System korrekt ist und nicht unterlaufen werden kann. trustworthy system,... vertrauenswürdiges System, verdient das Vertrauen, das ihm entgegengebracht wird - weil ein hochkarätiges Entwicklerteam dahintersteht und/oder weil es formal verifiziert wurde und/oder weil es schon lange zuverlässig gearbeitet hat... bs-9.3 3
Historisches zur Systemsicherung: Sicherheitskerne von Betriebssystemen: Ein kleiner Kern des Betriebssystems stellt Sicherheitsmechanismen zur Verfügung (hauptsächlich Zugriffsschutz), auf die sich alle anderen Teile des Systems abstützen ( trusted kernel). Der geringe Umfang des Kerns erlaubt eine formale Verifikation ( trustworthy). Beispiele: Secure Unix für DEC PDP-11 (UCLA 1979) KSOS-11 für DEC PDP-11 (Ford Aerospace 1979) KVM/370 für IBM/370 (SDC 1979) PSOS (SRI 1980)..... bs-9.3 4
Krypto-Koprozessoren zur Unterstützung kryptographischer Maßnahmen zur Systemsicherung. Beispiele: physically secure coprocessors, CMU 1991 4758 secure coprocessor, IBM 1999..... Secure and Reliable Bootstrap AEGIS (Univ. of Pennsylvania, 1996) Trusted Computing (Trusted Computing Group, 1999 -...) ( 9.3.2) bs-9.3 5
AEGIS - eine Hardware/Software-Architektur für sicheren Systemstart (secure bootstrap): wie kann erreicht werden, dass beim Starten eines Systems vom ersten Augenblick an nur Code zur Ausführung kommt, dessen Authentizität gesichert ist? (Beachte: das Problem wird "wegdefiniert", wenn der Boot Code der TCB zugerechnet wird.) Kontext: Annahme: IBM PC mit FreeBSD, relativ geringe Modifikationen, insbesondere durch Erweiterung des ROM kein Angriff auf Motherboard oder BIOS bs-9.3 6
Ansatz: Die nacheinander zu ladenden Code-Teile sind signiert und werden schrittweise verifiziert. Zu diesem Zweck wird das BIOS im ROM modifiziert und ein Erweiterungs-ROM hinzugefügt - für den Verifikations-Code und für Zertifikate. Normaler Startvorgang beim IBM PC: Power On/Self Test, danach Aktivierung des BIOS. BIOS veranlasst ggfls. Code-Ausführung in Erweiterungs-ROMs. BIOS durchsucht die Laufwerke (in hardwaremäßig festgelegter Reihenfolge) nach einer Platte mit boot block, lädt diesen in den Speicher und springt dorthin. Dieser Code lädt wiederum den Betriebssystem-Lader. Dieser lädt das Betriebssystem. bs-9.3 7
Was macht AEGIS stattdessen? Ein Teil des BIOS, zusammen mit dem AEGIS-Erweiterungs- ROM, ist für die Verifikation signierten Codes zuständig. Dies ist die einzige trusted software des Systems! Der restliche Teil des BIOS wird verifiziert (!). Dieser Teil übernimmt dann die Verifikation eventuell vorhandener zusätzlicher Erweiterungs-ROMs (!) und veranlasst die Ausführung des verifizierten Codes. Das BIOS durchsucht die Laufwerke, findet den boot block, lädt und verifiziert ihn, und führt ihn aus. Dies beinhaltet das Laden, Verifizieren und Starten des Laders. Dieser lädt den Betriebssystem-Kern und verifiziert ihn; damit ist das Betriebssystem sicher gestartet. bs-9.3 8
9.3.2 Trusted Computing Begriffe und Akronyme: TC Trusted Computing (zu "trusted" vgl. 9.3.1 ) TCPA Trusted Computing Platform Alliance, jetzt TCG: TCG Trusted Computing Group (IBM, Intel, Microsoft,...) Palladium* die TC-Realisierung von Microsoft, jetzt NGSCB: NGSCB Next-Generation Secure Computing Base, erstes Ergebnis: BitLocker in Windows Vista (s.u.) LaGrande Intel's Hardware-Unterstützung für TC, jetzt Trusted Execution Technology * auch Edelmetall; auch Παλλαδιον = Standbild der Pallas Athene im antiken Troja bs-9.3 9
Ziele: (technisch; zu ökonomisch/politisch siehe 9.3.2.4) Hochfahren des Rechners mit Buchführung über die damit etablierte Systemkonfiguration (HW/SW) Betriebssystem mit Sicherheitskern ("nexus", lat.: Verbindung) bietet weitreichende Sicherheitsmechanismen Attestation: auf Anfrage (vom Benutzer, vom Anwendungsprogramm, aus dem Netz,...) liefert das System seine Konfigurationsdaten, signiert mit dem privaten Schlüssel des Rechners (!)... desgl. für die Konfigurationsdaten von Anwendungssoftware Verschlüsselung von Daten derart, dass sie nur auf einem bestimmten Rechner (mit bestimmter Konfiguration) und von einer bestimmten Anwendung (in bestimmter Version) entschlüsselt werden können bs-9.3 10
9.3.2.1 Hardware: der TPM-Koprozessor (Spezifikation: TCG Specification Architecture Overview) TPM Trusted Platform Module (im Jargon auch Fritz chip*) = nichtmanipulierbares Chip auf dem Motherboard besorgt Schlüssel-Erzeugung und -Speicherung, ferner Hashing, Verschlüsselung, Signieren, Verifizieren; ist an/abschaltbar durch "Eigentümer" * benannt nach dem US-Senator Fritz Hollings bs-9.3 11
bs-9.3 12
(Quelle: TCG Specifications) bs-9.3 13
Register des TPM: PCRs EK SRK AIKs Platform Configuration Registers (flüchtig) 16 à 160 Bits für Hashwerte über Software-Komponenten Endorsement Key (persistent) privater Schlüssel des TPM und damit "des Rechners" oder "des Eigentümers" Storage Root Key (persistent) für Verschlüsselung von Speicherinhalten Attestation Identity Keys (persistent) weitere private Schlüssel für authentische Auskünfte bs-9.3 14
Weitere Komponenten des TPM: Random Number Generator für Erzeugung von Schlüsseln und Nonces RSA Key Generation für RSA-Schlüssel und symmetrische Schlüssel RSA Engine Ver/Entschlüsselung mit Storage Keys, Signieren/Verifizieren mit Signing Keys SHA-1 Engine Berechnung von Hashcodes..... bs-9.3 15
Weitere Komponenten des TPM: Execution Engine Initialisierung; Verifizierung unter Einsatz der PCRs Input/Output Kommunikation mit der Außenwelt Opt-In Interne Konfigurierung des TPM: verschiedene Möglichkeiten im Spektrum von inaktiv bis voll funktionsfähig bs-9.3 16
9.3.2.2 Sicherstellung der Systemintegrität Measurement = Information über Code (oder Daten) Hashwert darüber Sicherer Systemstart - oder lediglich Sicherung von Kenndaten, die das System identifizieren: jede Komponente, beginnend beim CRTM* Code im Boot ROM, ermittelt zunächst Hashwert der nächsten zu ladenden Komponente, bevor ihr die Kontrolle übergeben wird. * core root of trust for measurement bs-9.3 17
(Quelle: TCG Specifications) bs-9.3 18
Die Identität der so aufgebauten Plattform wird in einem Hashwert codiert, der sich aus einem "akkumulierenden Hashing" ("extending the digest") der Informationen X[i] (gemäß Measurement ) in einem PCR[n] wie folgt ergibt: PCR[n] := H ( PCR[n], X[i] ) für i=1,2,... In der Regel wird die Folge der Informationen X[i] in einem Stored Measurement Log - SML - gespeichert. Die Speicherung muss nicht hundertprozentig sicher sein: Manipulationen werden über die Hashwerte erkannt, und bei Verlust ist eine Wiedergewinnung möglich. bs-9.3 19
9.3.2.3 Authentisierung der Plattform (integrity reporting) gegenüber Anwendungen: Attestation Integrity Report = digitale Unterschrift für eine SW-Komponente (oder Folge von Komponenten); genauer: ein signierter Wert (PCR[n], Nonce), signiert mittels eines Attestation Identity Key Typische Konfigurations-Anfrage liefert Konfiguration der SW-Komponente(n) Integrity Report dazu Credentials zur HW-Plattform (signiert vom Hersteller) (z.b. Endorsement Credential mit TPM-Daten und EK Public Key) bs-9.3 20
(Quelle: TCG Specifications) bs-9.3 21
9.3.2.4 Quo vadit? Vorteile von TC: Allgemeine Verbesserung der Systemsicherheit, insbesondere im Netz, insbesondere bezüglich Authentizität und Integrität von Software und Daten Achtung: TC ist keine Allheilmittel gegen Schadsoftware (z.b. Trojanische Pferde!) oder unzuverlässige Software (Beispiel Pufferüberlauf!) bs-9.3 22
Kritik an TC: Eigentliche Motivation ist Durchsetzung eines beliebig rigorosen Umsetzung des Schutzes von Urheberrechten (Digital Rights Management - DRM). Bindung von Daten an Programme und von Programmen an Plattformen, die weit über das bisherige hinausgeht. Dadurch weitere Machtkonzentration bei Oligopolen. ( customer lock-in ) Dem Benutzer wird die freie Verfügungsgewalt über seinen Rechner genommen. bs-9.3 23
Erwiderungen: Man kann den TPM ja abschalten... Auch Linux-Entwickler arbeiten an TC... Der Markt wird es richten... Lektüre: Spezifikation: TCG Specification Architecture Overview C. Eckert: IT-Sicherheit, Kap. 11.10 (gute Darstellung!) R. Anderson: Trusted Computing Frequently Asked Questions... viele weitere Texte/Links in Zeitschriften, bei Wikipedia und bei Heise bs-9.3 24
9.3.3 Abschottung durch virtuelle Maschinen: Terra Ausgangspunkt: Anwendungen in getrennten Maschinen (realen oder virtuellen) laufen zu lassen ist sicherer als als nur in getrennten Prozessen in einer (realen oder virtuellen) Maschine. Zusätzlich: besondere Sicherungsmöglichkeit einer virtuellen Maschine ist wünschenswert: TVMM (trusted VMM) unterstützt closed box -VMs T. Garfinkel et al.: Terra: a virtual-machine-based platform for trusted computing. Proc. 19. ACM Symp. on Operating System Principles, 2003 bs-9.3 25
Fähigkeiten des TVMM zusätzlich zu normalen VMMs: Selbst der Systemverwalter kann den Schutz einer closed box gegen Manipulationen nicht durchbrechen ( root secure ). Eine Anwendung, die in einer closed box läuft, kann ihre Authentizität gegenüber einem entfernten Partner kryptographisch gesichert nachweisen ( attestation, vgl. 9.3.2.3 ). Zwischen einem menschlichen Benutzer und einer VM kann eine gesicherte Beziehung hergestellt werden ( trusted path ). bs-9.3 26
Typische zu lösende Probleme: Hardware-Unterstützung: Sicherheits-Koprozessor, z.b. gemäß Spezifikation der TCG, sicherer Zeitgeber u.a. Sichere Treiber: schwieriges Problem Treiber gibt es wie Sand am Meer, sie sind komplex und notorisch unsicher. Management der VMn: mit Operationen wie: VM erzeugen, virtuelles Gerät erzeugen, einer VM zuordnen, mit anderem (virtuellem oder realen) Gerät verbinden etc. bs-9.3 27
und weiter: Unterstützung für attestation einer closed-box VM durch den TVMM: closed-box VM übergibt ihren öffentlichen Schlüssel und eventuell weitere anwendungsspezifische Daten an TVMM; TVMM plaziert diese Daten zusammen mit dem Hashwert des VM-Codes in ein Zertifikat, signiert dieses Zertifikat mit seinem privaten Schlüssel und gibt es an die VM zurück; VM weist sich mit diesem Zertifikat gegenüber entfernten Partnern aus. bs-9.3 28
Prototyp von Terra - baut auf VMware auf - benutzt Linux in den VMs - X.509-Zertifikate (OpenSSL-Bibliothek), ohne Koprozessor für sicheres Booting - sichere Beispiel-Anwendung: Trusted Quake (Quake = Mehrpersonen-Online-Spiel, bei dem viel geschummelt wird!) bs-9.3 29
ENDE der Folien Betriebssysteme im WS 06/07 Empfohlene Fortsetzung im SS 07: Verteilte Systeme bs-9.3 30