1 / 71

Unumgehbarkeit, Tamper Resistance und Trusted Computing Base

Unumgehbarkeit, Tamper Resistance und Trusted Computing Base. PG 450. Entwurf und Implementierung eines Prototyps zur zustandsabhängigen Zugriffskontrolle und -rechteverwaltung. Überblick. Einleitung 1.1 Motivation 1.2 Bestehende IT-Infrastruktur 1.3 Angriffsszenarien

renata
Download Presentation

Unumgehbarkeit, Tamper Resistance und Trusted Computing Base

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Überblick • Einleitung 1.1 Motivation 1.2 Bestehende IT-Infrastruktur 1.3 Angriffsszenarien 1.4 Lösungsansätze Christian Blichmann, Marc Seitz

  3. Überblick • Personal Secure Booting mit AEGIS/sAEGIS 2.1 Ziele 2.2 Arbeitsweise AEGIS/sAEGIS 2.3 Bootstrap-Prozess in 7 Schritten 2.4 Grundannahmen 2.5 Angriffsszenarien 2.6 Aktueller Stand Christian Blichmann, Marc Seitz

  4. Überblick • TCG und Trusted Computing Base 3.1 Organisation 3.2 TCG-Spezifikationen 3.3 Missverständnisse 3.4 Ausblick 3.5 Microsofts NGSCB • Java und .NET 4.1 Architektur 4.2 Sandboxing, Digital signierte Klassen und Policies 4.3 Schlussfolgerungen für SDSD-System Christian Blichmann, Marc Seitz

  5. Überblick • Anwendungsfälle im SDSD-System 5.1 Ideale Umgebung 5.2 Störfaktoren und Lösungen 5.3 Fazit • Schlussbetrachtung Christian Blichmann, Marc Seitz

  6. 1. Motivation http://ls6-www.cs.uni-dortmund.de/issi/teaching/lectures/04ss/pg450/ http://www.dilbert.com/ Christian Blichmann, Marc Seitz

  7. 1. Einleitung 1.1 Motivation • Konventionelle Betriebssysteme (Windows, Linux, MacOS, etc.) sehr komplex • Stark fehleranfällig • Lassen sich nicht vor Manipulation absichern • Maximale Sicherheitsstufe EAL3 (Common Criteria) • Vgl.: Bankkarten EAL4 oder EAL4+ • Sichere Hardwarebasis wünschenswert • Zertifizierte Komponenten • Unumgehbare Sicherheitssysteme (Idealfall) Christian Blichmann, Marc Seitz

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

  9. 1. Einleitung 1.2 Bestehende IT-Infrastruktur • Unsichere Laufzeitumgebung • Speicherschutz kann ausgehebelt werden • Buffer-Overflows • Exploits • Programme zur Laufzeit kompromittierbar Christian Blichmann, Marc Seitz

  10. 1. Einleitung 1.3 Angriffsszenarien • Hinreichend bekannt: • Viren • Trojaner • Würmer • Social Engineering • Backdoors • Password-/Network-Sniffer • Masterpasswörter • Clear CMOS Jumper • … Christian Blichmann, Marc Seitz

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

  12. 2. Personal Secure Booting http://www.missl.cs.umd.edu/Projects/sebos/main.shtml http://www.linuxbios.org http://www.citi.umich.edu/ Christian Blichmann, Marc Seitz

  13. 2. Personal Secure Booting 2.1 Ziel: • 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

  14. 2. Personal Secure Booting 2.2 Arbeitsweise AEGIS/sAEGIS • 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

  15. 2. Personal Secure Booting 2.2 Arbeitsweise AEGIS/sAEGIS • 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 • Integritätsgarantie gilt nur für den Systemstart Christian Blichmann, Marc Seitz

  16. 2. Personal Secure Booting 2.3 Bootstrap Prozess in 7 Schritten • Power-on Self Test • BIOS Section 1 • BIOS Section 2 • Erweiterungskarten • GRUB Stage 1 • GRUB Stage 2 • Betriebssystemkern Christian Blichmann, Marc Seitz

  17. BIOS BIOS BIOS BIOS Section Section Section Section 2 2 2 2 Zertifikate BIOS1, BIOS2, Zertifikate BIOS1, BIOS2, Zertifikate BIOS1, BIOS2, Zertifikate BIOS1, BIOS2, Erweiterungskarten, GRUB1 Erweiterungskarten, GRUB1 Erweiterungskarten, GRUB1 Erweiterungskarten, GRUB1 BIOS BIOS BIOS BIOS Section Section Section Section 1 1 1 1 POST 2. Personal Secure Booting • POST (Power-on Self Test) • Prozessor führt Selbsttest durch • Startet die Boot-Sequenz • BIOS Section 1 • Enthält Grundfunktionen zur Integritätsüberprüfung (MD5, SHA1 und RSA) • Überprüft sich selbst und BIOS Section 2 • Bootet Section 2 falls erfolgreich Christian Blichmann, Marc Seitz

  18. 2. Personal Secure Booting • 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 x86-Architektur ist der Master Boot Record (MBR) auf 512 Byte beschränkt, daher die Unterteilung in zwei Stages Christian Blichmann, Marc Seitz

  19. Smartcard Smartcard Kernel Kernel - - und und Anwendungs Anwendungs - - MACs MACs GRUB GRUB Stage Stage 2 2 Zertifikat GRUB Zertifikat GRUB Stage Stage 2 2 GRUB GRUB Stage Stage 1 1 Erweiterungskarten Erweiterungskarten BIOS BIOS Section Section 2 2 Zertifikate BIOS1, BIOS2, Zertifikate BIOS1, BIOS2, Erweiterungskarten, GRUB1 Erweiterungskarten, GRUB1 2. Personal Secure Booting • GRUB Stage 1 • Lädt und verifiziert GRUB Stage 2 • Benutzt die Routinen aus BIOS Section 1 Christian Blichmann, Marc Seitz

  20. Betriebssystemkern Betriebssystemkern Smartcard Smartcard Kernel Kernel - - und und Anwendungs Anwendungs - - MACs MACs GRUB GRUB Stage Stage 2 2 Zertifikat GRUB Zertifikat GRUB Stage Stage 2 2 GRUB GRUB Stage Stage 1 1 Erweiterungskarten Erweiterungskarten 2. Personal Secure Booting • 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 Christian Blichmann, Marc Seitz

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

  22. 2. Personal Secure Booting 2.4 Grundannahmen • „erste“ Komponente ist sicher • Benutzer muss Trustcenter glauben, Sicherheit nicht weiter gehend kontrollierbar • Bis dato noch keine unabhängige Lösung • sAEGIS nur auf dem Papier existent • Kryptographische Hashfunktionen sind kollisionsfrei, RSA kann nicht kompromittiert werden Christian Blichmann, Marc Seitz

  23. 2. Personal Secure Booting 2.4 Grundannahmen • 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

  24. 2. Personal Secure Booting 2.5 Angriffsszenarien • Mallory als Systemadministrator • Durch Einsatz von Smartcards lösbar;Benutzer muss Hardware zertifizieren (sAEGIS) • Modifikationen am System werden entdeckt • 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

  25. 2. Personal Secure Booting 2.5 Angriffsszenarien • Diebstahl des PCs • Abgesichert durch Smartcard und PIN, sowie die kryptographischen Protokolle • PIN Diebstahl Christian Blichmann, Marc Seitz

  26. 2. Personal Secure Booting 2.6 Aktueller Stand • AEGIS wird mit Hilfe von LinuxBIOS implementiert • SEBOS Projekt (Security Enhanced Bootloader for Operating Systems) • Bootfähig für viele Betriebssysteme (Linux, FreeBSD, Windows 2000, etc.) Christian Blichmann, Marc Seitz

  27. 2. Personal Secure Booting 2.6 Aktueller Stand • sAEGIS erst prototypisch vorhanden • Noch kein offizieller Release • Soll später unter GPL erfolgen Christian Blichmann, Marc Seitz

  28. 3. Trusted Computing Base https://www.trustedcomputinggroup.org/ https://www.trustedcomputinggroup.org/about/members/ http://www.microsoft.com/resources/ngscb/default.mspx Christian Blichmann, Marc Seitz

  29. 3. TCG und Trusted Computing Base 3.1 Organisation Christian Blichmann, Marc Seitz

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

  31. 3. TCG und Trusted Computing Base 3.1. Organisation o f D i r e c t o r s B o a r d i r m a n J i m W a r d , I B M , P r e s i d e n t a n d C h a d v i s o r y C o u n c i l T e c h n i c a l C o m m i t t e e B e s t P r a c t i c e s A A d m i n i s t r a t i o n M a r k e t i n g W o r k g r o u p G r a e m e P r o u d l e r , H P J e f f A u s t i n , I n t e l I n v i t e d P a r t i c i p a n t s V T M , I n c . N a n c y S u m r a l l , I n t e l P u b l i c T P M W o r k G r o u p C o n f o r m a n c e W G D a v i d G r a w r o c k , I n t e l R e l a t i o n s M a n n y N o v o a , H P A n n e P r i c e , P R W o r k s P C C l i e n t W G T S S W o r k G r o u p n t e l M o n t y W i s e m a n , I D a v i d C h a l l e n e r , I B M E v e n t s M o b i l e P h o n e W G I n f r a s t r u c t u r e W G M a r k e t i n g P a n u M a r k k a n e n , N o k i a T h o m a s H a r d j o n o , V e r i s i g n S u p p o r t V T M , I n c . P e r i p h e r a l s W G P D A W G J i m W e n d o r f , P h i l i p s J o n a t h a n T o u r z a n , S o n y e r v e r S p e c i f i c W G S U s e r A u t h W G L a r r y M c M a h a n , H P P o s i t i o n K e y L a s z l o E l t e t o , R a i n b o w G R E E N B o x : E l e c t e d O f f i c e r s i r s A p p o i n t e d b y B o a r d B L U E B o x : C h a S t o r a g e S y s t e m s x : R E D B o C h a i r s N o m i n a t e d b y W G , R o b e r t T h i b a d e a u , A p p o i n t e d b y B o a r d S e a g a t e C G B L A C K B o x : R e s o u r c e s C o n t r a c t e d b y T Christian Blichmann, Marc Seitz

  32. 3. TCG und Trusted Computing Base 3.2 TCG-Spezifikationen 3.2.1 TPM-Basisfunktionen 3.2.2 Funktionen im Detail 3.2.3 Trusted Software Stack Christian Blichmann, Marc Seitz

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

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

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

  36. 3. TCG und Trusted Computing Base 3.2.3 Trusted Software Stack • Aktuell TSS Spezifikation1.1 • Standardisierter Software-Stack für • CAPI CSP, PKCS#11, etc. • Spezialisierte Anwendungen • Schlüsselmanagement • Auditierung / Logging • Wrapper für die Funktionen des TPM Christian Blichmann, Marc Seitz

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

  38. 3. TCG und Trusted Computing Base 3.3 Missverständnisse • Digital Rights Management ausdrücklich kein Ziel • Benutzer behält Kontrolle • Kein Schutz vor physischer Manipulation • 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

  39. 3. TCG und Trusted Computing Base 3.3 Missverständnisse • Benutzer kontrolliert TPM • Opt-in beim Systemstart durch Management- Funktionen abschaltbar • Keine TCG Spezifikation bzgl. Betriebssystem, Systemkomponenten oder Anwendungen • Hierzu siehe NGSCB (3.5) Christian Blichmann, Marc Seitz

  40. 3. TCG und Trusted Computing Base 3.4 Ausblick • 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: • TPM Owner, TPM User • Platform Administrator, Platform User • Operator Public • Direct Dynamic Attestation (DDA) • Beglaubigung ohne ein Trustcenter  Zero-Knowledge-Beweis Christian Blichmann, Marc Seitz

  41. 3. TCG und Trusted Computing Base 3.5 Microsofts NGSCB 3.5.1 Überblick 3.5.2 Schlüsselfunktionen 3.5.3 TCG vs. NGSCB 3.5.4 Ausblick Christian Blichmann, Marc Seitz

  42. 3. TCG und Trusted Computing Base 3.5.1 Überblick Next Generation Secure Computing Base vormals „Palladium“ • Implementation eines TSS • Erweiterung der Win32/Win64-Architektur • Investitionssicherheit • Kompatibilität, „unsichere“ Anwendungen laufen • Für Microsoft einzige Möglichkeit • Erhaltung des Marktanteils Christian Blichmann, Marc Seitz

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

  44. TCG-Architektur NGSCB TCG-Process Conventional Process Agent Conventional Process TSS Service Provider Nexus Win32/Win64 Kernel TCG-Enabled Operating System NexusMgr.sys HAL HAL Hardware Hardware TPM CRTM SSC CRTM 3. TCG und Trusted Computing Base 3.5.3 TCG vs. NGSCB Christian Blichmann, Marc Seitz

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

  46. 4. Java, .NET http://www.microsoft.com/net/ http://www.java.sun.com Christian Blichmann, Marc Seitz

  47. 4. Java und .NET 4.1 Architektur • Bereits bekannt: • Quelltext • Compiler • Byte-Code •  Zielsystem • Verifier • Maschinen-Code • Ausführung Java .NET HelloWorld.java HelloWorld.cs javac csc HelloWorld.class HelloWorld.exe Byte-Code Verifier .NET Runtime Execution Engine JVM  JIT Native Native Christian Blichmann, Marc Seitz

  48. 4. Java und .NET 4.1 Architektur • Java und .NET prinzipiell sehr ähnlich • Alle Java-Spezifischen Aussagen lassen sich übertragen • Auch hier Klassen • zur Rechteverwaltung • für Policies • für Code-Signing über AuthentiCode • Ebenfalls Reflection API für nativen Methodenaufruf • Unterstützung von COM/DCOM Christian Blichmann, Marc Seitz

  49. 4. Java und .NET 4.1 Architektur • Wesentliche Unterschiede zu Java • Unterstützung von über 40 Programmiersprachen • VisualBasic.NET, JScript.NET, Python.NET, Delphi.NET, Oberon.NET, Haskell.NET, Cobol.NET… • Code wird • 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

  50. 4. Java und .NET 4.2 Java 1.0: Sandboxing • Byte-Code-Prüfung • Unterbindet Buffer-Overflows und Exploits in der VM • Kapselt laufende Software ein • Zugriff auf Betriebssystem und Hardware nur über definierte Schnittstellen der VM • Flexible Rechtevergabe über Packagejava.security • Klassen und Interfaces für die Authentifizierung • Code muss Rechte explizit anfordern • z.B. java.lang.SecurityManager.checkRead() Christian Blichmann, Marc Seitz

More Related