Unumgehbarkeit Tamper Resistance und Trusted Computing Base PG

Unumgehbarkeit, Tamper Resistance und Trusted Computing Base PG 450 Entwurf und Implementierung eines Prototyps zur zustandsabhängigen Zugriffskontrolle und rechteverwaltung Christian Blichmann, Marc Seitz

Universität Dortmund - PG 450 Überblick 1. Einleitung 1. 1 1. 2 1. 3 1. 4 Motivation Bestehende IT-Infrastruktur Angriffsszenarien Lösungsansätze Christian Blichmann, Marc Seitz 2

Universität Dortmund - PG 450 Überblick 2. Personal Secure Booting mit AEGIS/s. AEGIS 2. 1 2. 2 2. 3 2. 4 2. 5 2. 6 Ziele Arbeitsweise AEGIS/s. AEGIS Bootstrap-Prozess in 7 Schritten Grundannahmen Angriffsszenarien Aktueller Stand Christian Blichmann, Marc Seitz 3

Universität Dortmund - PG 450 Überblick 3. TCG und Trusted Computing Base 3. 1 3. 2 3. 3 3. 4 3. 5 Organisation TCG-Spezifikationen Missverständnisse Ausblick Microsofts NGSCB 4. Java und. NET 4. 1 4. 2 4. 3 Architektur Sandboxing, Digital signierte Klassen und Policies Schlussfolgerungen für SDSD-System Christian Blichmann, Marc Seitz 4

Universität Dortmund - PG 450 Überblick 5. Anwendungsfälle im SDSD-System Ideale Umgebung 5. 2 Störfaktoren und Lösungen 5. 3 Fazit 5. 1 6. Schlussbetrachtung Christian Blichmann, Marc Seitz 5

Universität Dortmund - PG 450 1. Motivation http: //ls 6 -www. cs. uni-dortmund. de/issi/teaching/lectures/04 ss/pg 450/ http: //www. dilbert. com/ Christian Blichmann, Marc Seitz 6

Universität Dortmund - PG 450 1. Einleitung 1. 1 Motivation n Konventionelle Betriebssysteme (Windows, Linux, Mac. OS, etc. ) sehr komplex ¨ Stark fehleranfällig ¨ Lassen sich nicht vor Manipulation absichern ¨ Maximale Sicherheitsstufe EAL 3 (Common Criteria) n n Vgl. : Bankkarten EAL 4 oder EAL 4+ Sichere Hardwarebasis wünschenswert ¨ Zertifizierte Komponenten ¨ Unumgehbare Sicherheitssysteme (Idealfall) Christian Blichmann, Marc Seitz 7

Universität Dortmund - PG 450 1. Einleitung 1. 2 Bestehende IT-Infrastruktur n Angriffe erfolgen meist von „innen“ ¨ Kontrolle durch den Benutzer erwünscht n Ungesicherter Bootvorgang ¨ Jeder kann Hardware- oder Softwarekomponenten unbemerkt modifizieren n Ungesicherter Betriebssystemstart ¨ Login häufig ungesichert ¨ Fehlendes Sicherheitsbewusstsein n n Sorgloser Umgang mit Zugangsdaten Keine Rechteverwaltung Christian Blichmann, Marc Seitz 8

Universität Dortmund - PG 450 1. Einleitung 1. 2 Bestehende IT-Infrastruktur n Unsichere Laufzeitumgebung ¨ Speicherschutz kann ausgehebelt werden ¨ Buffer-Overflows ¨ Exploits ¨ Programme zur Laufzeit kompromittierbar Christian Blichmann, Marc Seitz 9

Universität Dortmund - PG 450 1. Einleitung 1. 3 Angriffsszenarien n Hinreichend bekannt: ¨ Viren ¨ Trojaner ¨ Würmer ¨ Social Engineering ¨ Backdoors ¨ Password-/Network-Sniffer ¨ Masterpasswörter ¨ Clear CMOS Jumper ¨… Christian Blichmann, Marc Seitz 10

Universität Dortmund - PG 450 1. Einleitung 1. 4 Lösungsansätze n n n Personal Secure Booting Trusted Computing Group Common Criteria (ISO/IEC 154080) ¨ Evaluation Assurance Level (EAL) ¨ Aktuell maximal Stufe 3 n n n Sandboxing Proprietäre Systeme (Multics, EROS, Birlix, …) “Security through obscurity” Christian Blichmann, Marc Seitz 11

Universität Dortmund - PG 450 2. Personal Secure Booting http: //www. missl. cs. umd. edu/Projects/s ebos/main. shtml http: //www. linuxbios. org http: //www. citi. umich. edu/ Christian Blichmann, Marc Seitz 12

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 1 Ziel: n n Sicheres Booten des Systems, bis OS Kontrolle übernimmt Alle Komponenten sind zertifiziert Kryptographische Speicherung der Zertifikate auf Smartcards Teile des BIOS müssen vertrauenswürdig sein (siehe 2. 4 - Grundannahmen) Christian Blichmann, Marc Seitz 13

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 2 Arbeitsweise AEGIS/s. AEGIS n n n Administrator oder autorisierter Benutzer generiert Hashwert (MAC) der Bootstrap-Komponenten und aus diesem ein Zertifikat C Autorisierter Dritter (z. B. Trustcenter) signiert C mit seinem privaten Schlüssel C wird in der Komponente selber gespeichert, wenn möglich, sonst im Flashspeicher des Motherboards Christian Blichmann, Marc Seitz 14

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 2 Arbeitsweise AEGIS/s. AEGIS n Ausführung des Komponenten-internen Codes (z. B. Firmware, Grafik-BIOS etc. ) nur wenn ¨ C nicht abgelaufen ¨ Signatur von C gültig ¨ Hashwert (MAC) übereinstimmt n Integritätsgarantie gilt nur für den Systemstart Christian Blichmann, Marc Seitz 15

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 3 Bootstrap Prozess in 7 Schritten 1. 2. 3. 4. 5. 6. 7. Power-on Self Test BIOS Section 1 BIOS Section 2 Erweiterungskarten GRUB Stage 1 GRUB Stage 2 Betriebssystemker n Christian Blichmann, Marc Seitz 16

Universität Dortmund - PG 450 2. Personal Secure Booting n POST (Power-on Self Test) ¨ Prozessor führt Selbsttest durch ¨ Startet die Boot-Sequenz n BIOS Section 1 ¨ Enthält Grundfunktionen zur Integritätsüberprüfung (MD 5, SHA 1 und RSA) ¨ Überprüft sich selbst und BIOS Section 2 ¨ Bootet Section 2 falls erfolgreich Christian Blichmann, Marc Seitz BIOS Section 2 Zertifikate BIOS 1, BIOS 2, Erweiterungskarten, GRUB 1 BIOS Section 1 POST 17

Universität Dortmund - PG 450 2. Personal Secure Booting n BIOS Section 2 ¨ Überprüft ROM der Erweiterungskarten durch Zertifikate ¨ Startet die ROMs der Erweiterungskarten ¨ Lädt den Primary Boot. Block (GRUB Stage 1) von Festplatte und überprüft ihn* * Bei der Intel x 86 -Architektur ist der Master Boot Record (MBR) auf 512 Byte beschränkt, daher die Unterteilung in zwei Stages Christian Blichmann, Marc Seitz 18

Universität Dortmund - PG 450 2. Personal Secure Booting n GRUB Stage 1 Smartcard ¨ Lädt und verifiziert GRUB Stage 2 ¨ Benutzt die Routinen aus BIOS Section 1 GRUB Stage Kernel - und Anwendungs 2 Zertifikat GRUB Stage BIOS Section -MACs Stage 2 1 Erweiterungskarten 2 Zertifikate BIOS 1, BIOS 2, Erweiterungskarten, GRUB 1 Christian Blichmann, Marc Seitz 19

Universität Dortmund - PG 450 2. Personal Secure Booting n GRUB Stage 2 ¨ Lädt Betriebssystemkern und verifiziert diesen ¨ Verifiziert die „Verification Tools“ des Kernels ¨ Mounted Dateisystem ¨ Lädt die MAC von der Smartcard und verifiziert damit die Startdateien Betriebssystemkern Smartcard GRUB Stage 2 Kernel- und Anwendungs-MACs Zertifikat GRUB Stage 2 GRUB Stage 1 Christian Blichmann, Marc Seitz Erweiterungskarten 20

Universität Dortmund - PG 450 2. Personal Secure Booting n Kernel ¨ Benutzt das „Verify Program“ zum verifizieren der wichtigen Systemdateien ¨ Startet die Systemdienste Anwendung 1 Anwendung 2 Verify program Betriebssystemkern Smartcard GRUB Stage 2 Kernel- und Anwendungs-MACs Zertifikat GRUB Stage 2 Bootstrap-Vorgang ist damit abgeschlossen Christian Blichmann, Marc Seitz 21

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 4 Grundannahmen n „erste“ Komponente ist sicher ¨ Benutzer muss Trustcenter glauben, Sicherheit nicht weiter gehend kontrollierbar ¨ Bis dato noch keine unabhängige Lösung ¨ s. AEGIS nur auf dem Papier existent n Kryptographische Hashfunktionen sind kollisionsfrei, RSA kann nicht kompromittiert werden Christian Blichmann, Marc Seitz 22

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 4 Grundannahmen n n Alices privater Schlüssel ist Mallory unbekannt Mallory hat keinen Zugang zur Smartcard BIOS Section 1 ist nicht manipulierbar Kommunikation mit der Smartcard ist sicher Christian Blichmann, Marc Seitz 23

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 5 Angriffsszenarien n Mallory als Systemadministrator ¨ Durch Einsatz von Smartcards lösbar; Benutzer muss Hardware zertifizieren (s. AEGIS) ¨ Modifikationen am System werden entdeckt n Modifikation von Systemkomponenten ¨ Nur der Startvorgang ist abgesichert, kein Schutz vor Trojanern, Viren etc. ¨ Benutzer kann Systemintegrität durch Reboot wiederherstellen Christian Blichmann, Marc Seitz 24

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 5 Angriffsszenarien n Diebstahl des PCs ¨ Abgesichert durch Smartcard und PIN, sowie die kryptographischen Protokolle n PIN Diebstahl Christian Blichmann, Marc Seitz 25

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 6 Aktueller Stand n AEGIS wird mit Hilfe von Linux. BIOS implementiert ¨ SEBOS Projekt (Security Enhanced Bootloader for Operating Systems) n Bootfähig für viele Betriebssysteme (Linux, Free. BSD, Windows 2000, etc. ) Christian Blichmann, Marc Seitz 26

Universität Dortmund - PG 450 2. Personal Secure Booting 2. 6 Aktueller Stand n n s. AEGIS erst prototypisch vorhanden Noch kein offizieller Release ¨ Soll später unter GPL erfolgen Christian Blichmann, Marc Seitz 27

Universität Dortmund - PG 450 3. Trusted Computing Base https: //www. trustedcomputinggroup. org/about/members/ http: //www. microsoft. com/resources/ngscb/default. mspx Christian Blichmann, Marc Seitz 28

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 1 Organisation Christian Blichmann, Marc Seitz 29

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 1 Organisation n Hervorgegangen aus der TCPA (Trusted Computing Platform Alliance) ¨ Wegen Handlungsunfähigkeit (zwingend einstimmige Beschlüsse) aufgelöst n Nahezu alle vorherigen Mitglieder übernommen: ¨ AMD, HP, IBM, Intel, Microsoft, Sony, Sun ¨ ARM, ATI, Dell, Fujitsu Siemens, Infineon, Motorola, Nokia, NVIDIA, RSA Security, Transmeta, Veri. Sign, VIA, Vodafone, … Christian Blichmann, Marc Seitz 30

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 1. Organisation Board of Directors Jim Ward, IBM, President and Chairman Marketing Workgroup Nancy Sumrall, Intel Public Relations Anne Price, PR Works Technical Committee Graeme Proudler, HP TPM Work Group David. Grawrock, Intel TSS Work Group David Challener, IBM Events Marketing Support VTM, Inc. Mobile Phone WG Panu. Markkanen, Nokia Server Specific WG Larry Mc. Mahan, HP Jeff Austin, Intel Advisory Coun cil Invited Participants Administration VTM, Inc. Conformance WG Manny Novoa, HP PC Client WG Monty Wiseman, Intel Infrastructure WG Thomas Hardjono, Verisign Peripherals WG Jim Wendorf, Philips Best Practices PDA WG Jonathan Tourzan, Sony User Auth WG Laszlo Elteto, Rainbow Position Key Storage Systems GREEN Box: BLUE Box: RED Box: Robert Thibadeau, Seagate BLACK Box: Christian Blichmann, Marc Seitz Elected Officers Chairs Appointed by Board Chairs Nominated by WG, Appointed by Board Resources Contracted by TCG 31

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 2 TCG-Spezifikationen 3. 2. 1 3. 2. 2 3. 2. 3 TPM-Basisfunktionen Funktionen im Detail Trusted Software Stack Christian Blichmann, Marc Seitz 32

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base Communications 3. 2. 1 Basisfunktionen Non-Volatile Storage Platform Control Register (PCR) Attestation Identity Key (AIK) Program Code I/O Random Number Generator SHA-1 Engine Key Generation RSA Engine Opt-In Exec Engine Trusted Platform Module (TPM) Packaging Christian Blichmann, Marc Seitz 33

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base Funktionen im Detail Endorsement Key (EK) 3. 2. 2 n ¨ Weltweit eindeutiger Schlüssel, soll Chip nie verlassen n Data Integrity Registers (DIR) ¨ Speicherort für digital signierte Werte n Identitätserzeugung und -überprüfung ¨ Jeder Identität wird eine Systemkonfiguration zugewiesen ¨ Überprüfung mit Attestation Identity Keys (AIK) Christian Blichmann, Marc Seitz 34

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base Funktionen im Detail Transportsicherheit 3. 2. 2 n ¨ Stromverschlüsselung ¨ Hash-Log aller Transaktionen n Revisionssicherheit ¨ Log-Files durch Hardware-unterstützte Monotonic Counters nicht nachträglich manipulierbar n Platform Control Registers (PCR) TPM 1. 2 ¨ Speichern Hashwerte während des Bootvorgangs ¨ „versiegeln“ von Speicherbereichen nach dem Booten Christian Blichmann, Marc Seitz 35

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base Trusted Software Stack Aktuell TSS Spezifikation 1. 1 Standardisierter Software-Stack für 3. 2. 3 n n ¨ CAPI CSP, PKCS#11, etc. ¨ Spezialisierte Anwendungen n Schlüsselmanagement Auditierung / Logging Wrapper für die Funktionen des TPM Christian Blichmann, Marc Seitz 36

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base Process 2 TSS Service Provider RPC Client TSS SPI TSS CSI TSS Core Services TPM DDLI TPM Device Driver Library TPM Device Driver TPM Christian Blichmann, Marc Seitz System Process 1 User Process Trusted Software Stack Kernel Mode 3. 2. 3 Remote Process TSS Service Provider RPC Client TSS enables application development and interoperability 37

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 3 Missverständnisse n Digital Rights Management ausdrücklich kein Ziel ¨ Benutzer behält Kontrolle ¨ Kein Schutz vor physischer Manipulation n n Diese wird in Zukunft allerdings immer schwerer Integration des TPM in Zwischenlayer von Motherboards Keine Kontrolle, Überwachung oder Messungen ¨ TPM sicherer Speicher für maschinenbezogene Daten ¨ Weiß nicht, welche Software gerade läuft Christian Blichmann, Marc Seitz 38

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 3 Missverständnisse n Benutzer kontrolliert TPM ¨ Opt-in beim Systemstart durch Management- Funktionen abschaltbar n Keine TCG Spezifikation bzgl. Betriebssystem, Systemkomponenten oder Anwendungen ¨ Hierzu siehe NGSCB (3. 5) Christian Blichmann, Marc Seitz 39

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 4 Ausblick n Hardware nach TPM-Spezifikation 1. 2 ¨ Neue Plattformen (PDAs, Handys, Server) ¨ Best Practices Group für Datenschutzfragen ¨ Sichere Bootsequenz (ähnlich. zu Kap. 2) ¨ Trennung von Benutzer und Eigentümer durch Rollen: n n n TPM Owner, TPM User Platform Administrator, Platform User Operator Public ¨ Direct Dynamic Attestation (DDA) Beglaubigung ohne ein Trustcenter Zero-Knowledge-Beweis n Christian Blichmann, Marc Seitz 40

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 5 Microsofts NGSCB 3. 5. 1 3. 5. 2 3. 5. 3 3. 5. 4 Überblick Schlüsselfunktionen TCG vs. NGSCB Ausblick Christian Blichmann, Marc Seitz 41

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base Überblick Next Generation Secure Computing Base 3. 5. 1 vormals „Palladium“ n n Implementation eines TSS Erweiterung der Win 32/Win 64 -Architektur Investitionssicherheit Kompatibilität, „unsichere“ Anwendungen laufen Für Microsoft einzige Möglichkeit Erhaltung des Marktanteils Christian Blichmann, Marc Seitz 42

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base Schlüsselfunktionen Starke Isolation von Prozessen 3. 5. 2 n ¨ Schutz vor schädlichem Aktivitäten aus dem Kernel ¨ Initialisiert durch Nexus und SSC n Sealed Storage ¨ Speichert vertrauliche Informationen ¨ Zugriff nur durch Nexus und Programm n Sicherer Kommunikationspfad zum Benutzer ¨ Sperrt Trojaner und Keylogger aus n Nachweisbarkeit und Beglaubigung (Attestation) ¨ Flexibles authentifizieren von Hard- und Software Christian Blichmann, Marc Seitz 43

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base 3. 5. 3 TCG vs. NGSCB TCG-Architektur NGSCB TCG-Process TSS Service Provider Conventional Process Win 32/Win 64 Kernel TCG-Enabled Operating System Nexus. Mgr. sys HAL Hardware TPM Agent HAL Hardware CRTM SSC Christian Blichmann, Marc Seitz CRTM 44

Universität Dortmund - PG 450 3. TCG und Trusted Computing Base Ausblick NGSCB nicht einmal Alpha-Stadium 3. 5. 4 n ¨ Erstes Release frühestens 2006 („Longhorn“) Bis dahin noch deutliche Veränderungen Zu früh für Spekulationen n Teil der Strategischen Planung Microsofts ¨ Nexus wird irgendwann einziger Windows-Kernel n n Standardmäßig wird NGCB deaktiviert sein Planung sieht „austauschbaren Nexus“ vor ¨ Neue Möglichkeiten für Open Source Christian Blichmann, Marc Seitz 45

Universität Dortmund - PG 450 4. Java, . NET http: //www. microsoft. com/net/ http: //www. java. sun. com Christian Blichmann, Marc Seitz 46

Universität Dortmund - PG 450 4. Java und. NET 4. 1 Architektur n Bereits bekannt: 1. Quelltext 2. Compiler 3. Byte-Code 4. Zielsystem 5. Verifier 6. Maschinen-Code 7. Ausführung Java . NET Hello. World. java Hello. World. cs javac csc Hello. World. class Hello. World. exe Byte-Code Verifier JVM JIT . NET Runtime Execution Engine Native Christian Blichmann, Marc Seitz 47

Universität Dortmund - PG 450 4. Java und. NET 4. 1 Architektur n Java und. NET prinzipiell sehr ähnlich ¨ Alle Java-Spezifischen Aussagen lassen sich übertragen ¨ Auch hier Klassen n zur Rechteverwaltung für Policies für Code-Signing über Authenti. Code ¨ Ebenfalls Reflection API für nativen Methodenaufruf n Unterstützung von COM/DCOM Christian Blichmann, Marc Seitz 48

Universität Dortmund - PG 450 4. Java und. NET 4. 1 Architektur n Wesentliche Unterschiede zu Java ¨ Unterstützung von über 40 Programmiersprachen n Visual. Basic. NET, JScript. NET, Python. NET, Delphi. NET, Oberon. NET, Haskell. NET, Cobol. NET… ¨ Code wird n n ins Portable-Executable Format kompiliert, Nativer Code dann zur Laufzeit generiert oder im GAC (Global Assembly Cache) als nativer Code gelagert (beschleunigt Ausführung häufig benutzen Codes) Daher Zusammenfassung von JIT und Verifier ¨ Anderes (zu Java inkompatibles) Maschinenmodell Christian Blichmann, Marc Seitz 49

Universität Dortmund - PG 450 4. Java und. NET 4. 2 Java 1. 0: Sandboxing n Byte-Code-Prüfung ¨ Unterbindet Buffer-Overflows und Exploits in der VM n Kapselt laufende Software ein ¨ Zugriff auf Betriebssystem und Hardware nur über definierte Schnittstellen der VM ¨ Flexible Rechtevergabe über Package java. security n n Klassen und Interfaces für die Authentifizierung Code muss Rechte explizit anfordern ¨ z. B. java. lang. Security. Manager. check. Read() Christian Blichmann, Marc Seitz 50

Universität Dortmund - PG 450 4. Java und. NET 4. 2 Java 1. 0: Sandboxing n Eingeschränkte Rechte für unsicheren Code ¨ Kein Zugriff auf Dateisystem ¨ Netzwerkverbindungen nur zu dem Rechner, von dem der Code stammt ¨ Keine privilegierten Ports (also Ports < 1024) ¨ Kein Laden von Nativen Bibliotheken, n Java Reflection API nur für eigene Klassen erlaubt ¨ Grafik- und GUI eingeschränkt n n Keine Druckaufträge absetzen, keine Zwischenablage nutzen Fenster haben Markierung, dass sie „unsicher“ sind Christian Blichmann, Marc Seitz 51

Universität Dortmund - PG 450 4. Java und. NET 4. 2 Java 1. 1: Digital signierte Klassen n n Sandkastenmodell beibehalten Neue Klassen in java. security: ¨ Code-Signing ¨ Überprüfung von Zertifikaten n Heruntergeladener Code ¨ Vertrauenswürdig, wenn Zertifikat eines vertrauenswürdigen Anbieters lokale Rechte ¨ „unsicher“, falls nicht eingeschränkte Rechte n javakey verwaltet Schlüssel und signiert JAR- Dateien Christian Blichmann, Marc Seitz 52

Universität Dortmund - PG 450 4. Java und. NET 4. 2 Java 1. 2: Policies n java. security. Policy ¨ Bildet Code. Source-Objekte auf Permissions ab ¨ Weiterhin von Security. Manager verwaltet Feinere Abstufungen von Zugriffsrechten Lokaler Code kann als unsicher deklariert werden Heruntergeladene Klassen als sicher ¨ policytool ermöglicht Anwendern, eigene Zugriffsrechte zu setzen ¨ Entwickler könne neue Zugriffsrechte definieren n Ableitung von Permission Christian Blichmann, Marc Seitz 53

Universität Dortmund - PG 450 4. Java und. NET 4. 2 Java 1. 2: Policies Beispiel: Applet möchte /etc/passwd lesen 1. 2. 3. Konstruktor File. Input. Stream() ruft Security. Manager. check. Read() auf check. Read() erzeugt File. Permission-Objekt mit Ziel /etc/passwd und Aktion: „lesen“ java. security. Access. Controller. check. Permission() ¨ Verwendet aktuelles Policy-Objekt ¨ Bestimmt letztendlich ob Zugriff erlaubt In diesem Fall wahrscheinlich verboten Christian Blichmann, Marc Seitz 54

Universität Dortmund - PG 450 4. Java und. NET 4. 3 Schlussfolgerungen für SDSD-System n Hinreichende Sicherheit durch Sandboxing ¨ Verbindung mit sicherem Startvorgang sinnvoll ¨ Digitales Signieren des gesamten Systems ¨ Implementierung mit möglichst niedrigen Zugriffrechten ¨ Ableitung eigener Permission-Klassen, z. B. issi. sdsd. Administration. Permission, issi. sdsd. Token. Permission ¨ Definition eigener Policies Christian Blichmann, Marc Seitz 55

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System http: //ls 6 -www. cs. uni-dortmund. de/issi/teaching/lectures/04 ss/pg 450/ Christian Blichmann, Marc Seitz 56

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 1 Ideale Umgebung n n n SDSD-System wird so ausgeführt, wie von uns vorgesehen Kann zur Laufzeit nicht kompromittiert werden Angriffe werden erkannt und abgewehrt Christian Blichmann, Marc Seitz 57

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 1 Ideale Umgebung n Notwendig dafür ¨ SDSD-System wird beim Start auf (böswillige) Veränderungen überprüft ¨ Prozesse, die SDSD-Code ausführen, müssen isoliert werden (Nexus oder Secure Booting + Sandboxing) n n Ebenso die Prozesse, die nebenläufig benutzt werden Speicherbereiche müssen vor unberechtigtem Zugriff geschützt werden Christian Blichmann, Marc Seitz 58

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 1 Ideale Umgebung n Das zu kontrollierende Objekt darf nur über das SDSD-System angesprochen werden ¨ Kapselung durch SDSD-System nötig Diese Bedingungen müssen durch OS und SDSDSystem gewährleistet werden Christian Blichmann, Marc Seitz 59

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 2 Störfaktoren und Lösungen n Wir müssen sicherstellen, dass das System nicht gestartet wird bzw. eine Warnung ausgibt, wenn Veränderungen am System vorgenommen wurden n Bei verändertem SDSD-Code ebenfalls Warnung oder Ausführungsstopp Christian Blichmann, Marc Seitz 60

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 2 Störfaktoren und deren Lösungen n Folgende Kausalitätskette muss erfüllt sein: 5. Sicheres Betriebssystem 4. Sicheres Booten des Betriebssystems 3. Sichere Hardware 2. Sicherer Bootvorgang 1. Sicheres BIOS Christian Blichmann, Marc Seitz 61

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 2 Störfaktoren und deren Lösungen n Sicheres BIOS ¨ Kann durch AEGIS/s. AEGIS im Rahmen des Personal Secure Booting gewährleistet werden ¨ TCG: Trusted Boot Funktion des TPM 1. 2 n Sicheres Booten ¨ Kann ebenfalls durch Personal Secure Booting gewährleistet werden Christian Blichmann, Marc Seitz 62

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 2 Störfaktoren und deren Lösungen n Sichere Hardware, sicheres Booten des Betriebssystems ¨ Personal Secure Booting ¨ TCG: Trusted Boot Funktion des TPM 1. 2 n Sicheres Betriebssystem ¨ Umsetzung der TCG TSS-Spezifikation Christian Blichmann, Marc Seitz 63

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 2 Störfaktoren und deren Lösungen n Beschriebene Maßnahmen und Systeme beziehen sich auf Einzelplatzsysteme ¨ Im Netzwerk noch andere Kontrollen denkbar, z. B. dass das zweite System erkennt, dass am ersten etwas verändert worden ist n n Umsetzung durch Hashwerte etc. Weitere Angriffe möglich ¨ Anhalten des Rechners ¨ Blockieren des Netzes Christian Blichmann, Marc Seitz 64

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 3 Fazit: n n Idealfall noch Illusion Mit Personal Secure Booting und TPM/TSS werden gute Möglichkeiten für sichere Systeme ¨ Trotzdem sollte SDSD selbst so gut es uns möglich ist abgesichert werden ¨ Nur geringe Änderungen an der Software nötig, um diese TCG-konform zu gestalten Christian Blichmann, Marc Seitz 65

Universität Dortmund - PG 450 5. Anwendungsfälle im SDSD-System 5. 3 Fazit n Kontrolle über Netzwerk (Hashwerte) auch ohne Personal Secure Booting und TCG möglich ¨ Nicht manipulationssicher n Je mehr Sicherheitsmaßnahmen am Markt verfügbar (Personal Secure Booting, TPM-Chips), desto sicherer können wir das SDSD-System gestalten Christian Blichmann, Marc Seitz 66

Universität Dortmund - PG 450 6. Schlussbetrachtung Christian Blichmann, Marc Seitz 67

Universität Dortmund - PG 450 6. Schlussbetrachtung n „Personal Secure Booting“ bald am Markt verfügbar ¨ Evtl. prototypische Entwicklung des SDSD-Systems im Zusammenspiel damit möglich n TPM 1. 1 bereits im Einsatz (z. B. IBM-Notebooks) ¨ Bietet nur reine Datensicherheit ¨ Zerstörung des TPM-Chips führt zum Datenverlust ¨ Daten sind das System gebunden, nicht an Nutzer Christian Blichmann, Marc Seitz 68

Universität Dortmund - PG 450 6. Schlussbetrachtung n Umsetzung von TCG erfordert neue Hardware ¨ Teilweise inkompatibel zu bestehenden Systemen ¨ Benutzer muss in Sicherheit investieren ¨ Langwieriger Prozess n Markt entwickelt sich sehr schnell n Trustcenter schwer zu kontrollieren Gesetzliche Rahmenbedingungen notwendig Möglicherweise EU-Richtlinien der Datenschutzgruppe Christian Blichmann, Marc Seitz 69

Universität Dortmund - PG 450 6. Schlussbetrachtung n Industrie hat Interesse an Überwachungs- und DRM-Funktionen ¨ Interessenkonflikte innerhalb der TCG n Bsp. : Sony als Plattenfirma Mitglied der TCG ¨ Nutzer sehen in der Regel nur „Gängelung“, nicht den potentiellen Nutzen ¨ Öffentlichkeitsarbeit der TCG mangelhaft n Schwachpunkt aller IT-Systeme ist der Benutzer mit seinen vielfältigen Interessen ¨ Bsp. : Mallory als Administrator Christian Blichmann, Marc Seitz 70

Unumgehbarkeit, Tamper Resistance und Trusted Computing Base Folien: http: //www. blichmann. de/downloads/unumgehbarkeit. ppt Vielen Dank für Eure Aufmerksamkeit Ausarbeitung: http: //www. blichmann. de/downloads/unumgehbarkeit. pdf Christian Blichmann, Marc Seitz