unumgehbarkeit, tamper resistance und trusted computing base

Christian Blichmann, Marc Seitz

Unumgehbarkeit,Tamper Resistance und

Trusted Computing Base

Entwurf und Implementierung eines Prototyps zur zustandsabhängigen Zugriffskontrolle und -rechteverwaltung

PG 450

Christian Blichmann, Marc Seitz 2

Universität Dortmund - PG 450Universität Dortmund - PG 450 Überblick

1. Einleitung1.1 Motivation1.2 Bestehende IT-Infrastruktur1.3 Angriffsszenarien1.4 Lösungsansätze



2. Personal Secure Booting mit AEGIS/sAEGIS

2.1 Ziele2.2 Arbeitsweise AEGIS/sAEGIS2.3 Bootstrap-Prozess in 7 Schritten2.4 Grundannahmen2.5 Angriffsszenarien2.6 Aktueller Stand



3. TCG und Trusted Computing Base3.1 Organisation3.2 TCG-Spezifikationen3.3 Missverständnisse3.4 Ausblick3.5 Microsofts NGSCB

4. Java und .NET4.1 Architektur4.2 Sandboxing, Digital signierte Klassen und

Policies4.3 Schlussfolgerungen für SDSD-System



5. Anwendungsfälle im SDSD-System5.1 Ideale Umgebung5.2 Störfaktoren und Lösungen5.3 Fazit

6. Schlussbetrachtung


Universität Dortmund - PG 450Universität Dortmund - PG 450 1. Motivation

http://ls6-www.cs.uni-dortmund.de/issi/teaching/lectures/04ss/pg450/

http://www.dilbert.com/


Universität Dortmund - PG 450Universität Dortmund - PG 450 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)



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



1.2 Bestehende IT-Infrastruktur Unsichere Laufzeitumgebung

Speicherschutz kann ausgehebelt werden Buffer-Overflows Exploits Programme zur Laufzeit kompromittierbar



1.3 Angriffsszenarien Hinreichend bekannt:

Viren Trojaner Würmer Social Engineering Backdoors Password-/Network-Sniffer Masterpasswörter Clear CMOS Jumper …



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”


Universität Dortmund - PG 450Universität Dortmund - PG 4502. Personal Secure Booting

http://www.missl.cs.umd.edu/Projects/sebos/main.shtml

http://www.linuxbios.org

http://www.citi.umich.edu/



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)



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



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



1. Power-on Self Test2. BIOS Section 13. BIOS Section 24. Erweiterungskarten5. GRUB Stage 16. GRUB Stage 27. Betriebssystemkern

Anwendung 1 Anwendung 2

Betriebssystemkern

GRUB Stage 2

Kernel- und Anwendungs-MACs

Verifyprogram

GRUB Stage 1

BIOS Section 2

BIOS Section 1

Erweiterungskarten

Zertifikat GRUB Stage2

Zertifikate BIOS1, BIOS2, Erweiterungskarten, GRUB1

Smartcard

BootenMAC (MessageAuth. Code) überprüfenReferenz


Betriebssystemkern

GRUB Stage 2

Kernel- und Anwendungs-MACs

Verifyprogram

GRUB Stage 1

BIOS Section 2

BIOS Section 1

Erweiterungskarten



Smartcard

BootenMAC (MessageAuth. Code) überprüfenReferenz

2.3 Bootstrap Prozess in 7Schritten



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

BIOS Section 2

BIOS Section1


BIOS Section 2

BIOS Section1


BIOS Section 2

BIOS Section1


BIOS Section 2

BIOS Section1


POST



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*

GRUB Stage1

BIOS Section 2

BIOS Section 1

Erweiterungskarten


GRUB Stage1

BIOS Section 2

BIOS Section 1

Erweiterungskarten


GRUB Stage1

BIOS Section 2

BIOS Section 1

Erweiterungskarten


GRUB Stage1

BIOS Section 2

BIOS Section 1

Erweiterungskarten


* Bei der Intel x86-Architektur ist der Master Boot Record (MBR) auf 512 Byte beschränkt, daher die Unterteilung in zwei Stages



GRUB Stage 1 Lädt und verifiziert

GRUB Stage 2 Benutzt die

Routinen aus BIOS Section 1

GRUB Stage 2

Kernel - und Anwendungs -MACs

GRUB Stage 1

BIOS Section 2

Erweiterungskarten

Zertifikat GRUB Stage 2

Zertifikate BIOS1, BIOS2,

Erweiterungskarten, GRUB1

Smartcard

GRUB Stage 2

Kernel - und Anwendungs -MACs

GRUB Stage 1

BIOS Section 2

Erweiterungskarten

Zertifikat GRUB Stage 2

Zertifikate BIOS1, BIOS2,

Erweiterungskarten, GRUB1

Smartcard



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

GRUB Stage2

Kernel-und Anwendungs-MACs

GRUB Stage1 Erweiterungskarten


SmartcardBetriebssystemkern

GRUB Stage2


GRUB Stage1 Erweiterungskarten


Smartcard



Kernel Benutzt das „Verify

Program“ zum verifizieren der wichtigen Systemdateien

Startet die Systemdienste


Betriebssystemkern

GRUB Stage2


Verifyprogram


Smartcard


Betriebssystemkern

GRUB Stage2


Verifyprogram


Smartcard

Bootstrap-Vorgang ist damit abgeschlossen



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



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



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



2.5 Angriffsszenarien Diebstahl des PCs

Abgesichert durch Smartcard und PIN, sowie die kryptographischen Protokolle

PIN Diebstahl



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



2.6 Aktueller Stand sAEGIS erst prototypisch vorhanden Noch kein offizieller Release

Soll später unter GPL erfolgen


Universität Dortmund - PG 450Universität Dortmund - PG 4503. Trusted Computing Base

https://www.trustedcomputinggroup.org/https://www.trustedcomputinggroup.org/about/members/

http://www.microsoft.com/resources/ngscb/default.mspx


Universität Dortmund - PG 450Universität Dortmund - PG 4503. TCG und Trusted Computing Base

3.1 Organisation



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, …



3.1. Organisation

Marketing Workgroup Nancy Sumrall, Intel

Board of DirectorsJim Ward, IBM, President and Chairman

Server Specific WGLarry McMahan, HP Position Key

GREEN Box: Elected OfficersBLUE Box: Chairs Appointed by BoardRED Box: Chairs Nominated by WG,

Appointed by BoardBLACK Box: Resources Contracted by TCG

User Auth WGLaszlo Elteto, Rainbow

TSS Work GroupDavid Challener, IBM

TPM Work GroupDavid Grawrock, Intel

Storage Systems Robert Thibadeau,

Seagate

AdministrationVTM, Inc.

Advisory Council Invited Participants

Best Practices Jeff Austin, Intel

Technical Committee Graeme Proudler, HP

Public RelationsAnne Price,PR Works

EventsMarketingSupportVTM, Inc.

Peripherals WGJ im Wendorf, Philips

PDA WGJonathan Tourzan, Sony

PC Client WGMonty Wiseman, Intel

Mobile Phone WGPanuMarkkanen, Nokia

Infrastructure WGThomas Hardjono, Verisign

Conformance WGManny Novoa, HP



3.2 TCG-Spezifikationen3.2.1 TPM-Basisfunktionen3.2.2 Funktionen im Detail3.2.3 Trusted Software Stack



3.2.1 Basisfunktionen

Packaging

Trusted Platform Module (TPM)

Non-Volatile Storage

Platform Control Register

(PCR)

Attestation Identity Key (AIK)

Program Code

I/O

Random Number

Generator

SHA-1 Engin

e

Key Generatio

n

RSA Engin

eOpt-In

Exec Engin

e

Com

mu

nic

ati

on

s



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)



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



3.2.3 Trusted Software Stack Aktuell TSS Spezifikation 1.1 Standardisierter Software-Stack für

CAPI CSP, PKCS#11, etc. Spezialisierte Anwendungen

Schlüsselmanagement Auditierung / Logging Wrapper für die Funktionen des TPM



3.2.3 Trusted Software StackProcess 1

TSS Service Provider

TSS SPI

Process 2

TSS Core ServicesTSS CSI

RPC Client

TPM Device Driver LibraryTPM DDLI

TPM Device Driver

TPM

RemoteProcess

RPC Client


TSS enables application

development and

interoperabilityU

ser

Pro

cess

Syst

em

Pro

cess

Kern

el M

ode



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



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)



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



3.5 Microsofts NGSCB3.5.1 Überblick3.5.2 Schlüsselfunktionen3.5.3 TCG vs. NGSCB3.5.4 Ausblick



3.5.1 ÜberblickNext Generation Secure Computing Basevormals „Palladium“

Implementation eines TSS Erweiterung der Win32/Win64-Architektur

InvestitionssicherheitKompatibilität, „unsichere“ Anwendungen

laufenFür Microsoft einzige Möglichkeit

Erhaltung des Marktanteils



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



3.5.3 TCG vs. NGSCBTCG-Architektur

TCG-Process

TPM CRTM

TCG-Enabled Operating System

Hardware

Conventional Process


NGSCB

SSC CRTM

Hardware

HAL HAL

Win32/Win64 Kernel Nexus

Conventional Process

Agent

NexusMgr.sys



3.5.4 Ausblick NGSCB nicht einmal Alpha-Stadium

Erstes Release frühestens 2006 („Longhorn“)Bis dahin noch deutliche VeränderungenZu 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


Universität Dortmund - PG 450Universität Dortmund - PG 450 4. Java, .NET

http://www.microsoft.com/net/

http://www.java.sun.com


Universität Dortmund - PG 450Universität Dortmund - PG 450 4. Java und .NET

4.1 Architektur Bereits bekannt:

1. Quelltext2. Compiler3. Byte-Code44 Zielsystem5. Verifier6. Maschinen-Code7. Ausführung

HelloWorld.java

javac

HelloWorld.class

Byte-Code Verifier

JVM JIT

Native

HelloWorld.cs

csc

HelloWorld.exe

.NET Runtime Execution Engine

Native

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



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



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 Package java.security

Klassen und Interfaces für die Authentifizierung

Code muss Rechte explizit anfordern z.B. java.lang.SecurityManager.checkRead()



4.2 Java 1.0: Sandboxing 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,

Java Reflection API nur für eigene Klassen erlaubt Grafik- und GUI eingeschränkt

Keine Druckaufträge absetzen, keine Zwischenablage nutzen

Fenster haben Markierung, dass sie „unsicher“ sind



4.2 Java 1.1: Digital signierte Klassen Sandkastenmodell beibehalten Neue Klassen in java.security:

Code-Signing Überprüfung von Zertifikaten

Heruntergeladener Code Vertrauenswürdig, wenn Zertifikat eines

vertrauenswürdigen Anbieters lokale Rechte „unsicher“, falls nicht eingeschränkte Rechte

javakey verwaltet Schlüssel und signiert JAR-Dateien



4.2 Java 1.2: Policies java.security.Policy

Bildet CodeSource-Objekte auf Permissions ab Weiterhin von SecurityManager verwaltet

Feinere Abstufungen von ZugriffsrechtenLokaler Code kann als unsicher deklariert werdenHeruntergeladene Klassen als sicher policytool ermöglicht Anwendern, eigene

Zugriffsrechte zu setzen Entwickler könne neue Zugriffsrechte definieren

Ableitung von Permission



4.2 Java 1.2: PoliciesBeispiel: Applet möchte /etc/passwd lesen

1. Konstruktor FileInputStream() ruft SecurityManager.checkRead() auf

2. checkRead() erzeugt FilePermission-Objekt mit Ziel /etc/passwd und Aktion: „lesen“

3. java.security.AccessController.checkPermission() Verwendet aktuelles Policy-Objekt Bestimmt letztendlich ob Zugriff erlaubt

In diesem Fall wahrscheinlich verboten



4.3 Schlussfolgerungen für SDSD-System

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.AdministrationPermission,issi.sdsd.TokenPermission

Definition eigener Policies


Universität Dortmund - PG 450Universität Dortmund - PG 4505. Anwendungsfälle im SDSD-System

http://ls6-www.cs.uni-dortmund.de/issi/

http://ls6-www.cs.uni-dortmund.de/issi/teaching/lectures/04ss/pg450/



5.1 Ideale Umgebung SDSD-System wird so ausgeführt, wie von

uns vorgesehen Kann zur Laufzeit nicht kompromittiert

werden Angriffe werden erkannt und abgewehrt



5.1 Ideale Umgebung 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)

Ebenso die Prozesse, die nebenläufig benutzt werden Speicherbereiche müssen vor unberechtigtem Zugriff

geschützt werden



5.1 Ideale Umgebung 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 SDSD-System gewährleistet werden



5.2 Störfaktoren und Lösungen Wir müssen sicherstellen, dass das System

nicht gestartet wird bzw. eine Warnung ausgibt, wenn Veränderungen am System vorgenommen wurden

Bei verändertem SDSD-Code ebenfalls Warnung oder Ausführungsstopp



5.2 Störfaktoren und deren Lösungen Folgende Kausalitätskette muss erfüllt

sein:

5. Sicheres Betriebssystem4. Sicheres Booten des Betriebssystems3. Sichere Hardware2. Sicherer Bootvorgang1. Sicheres BIOS



5.2 Störfaktoren und deren Lösungen Sicheres BIOS

Kann durch AEGIS/sAEGIS im Rahmen des Personal Secure Booting gewährleistet werden

TCG: Trusted Boot Funktion des TPM 1.2

Sicheres Booten Kann ebenfalls durch Personal Secure Booting

gewährleistet werden



5.2 Störfaktoren und deren Lösungen Sichere Hardware, sicheres Booten des

Betriebssystems Personal Secure Booting TCG: Trusted Boot Funktion des TPM 1.2

Sicheres Betriebssystem Umsetzung der TCG TSS-Spezifikation



5.2 Störfaktoren und deren Lösungen 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

Umsetzung durch Hashwerte etc.

Weitere Angriffe möglich Anhalten des Rechners Blockieren des Netzes



5.3 Fazit: 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



5.3 Fazit Kontrolle über Netzwerk (Hashwerte) auch

ohne Personal Secure Booting und TCG möglich Nicht manipulationssicher

Je mehr Sicherheitsmaßnahmen am Markt verfügbar (Personal Secure Booting, TPM-Chips), desto sicherer können wir das SDSD-System gestalten


Universität Dortmund - PG 450Universität Dortmund - PG 450 6. Schlussbetrachtung



„Personal Secure Booting“ bald am Markt verfügbar Evtl. prototypische Entwicklung des SDSD-

Systems im Zusammenspiel damit möglich

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



Umsetzung von TCG erfordert neue Hardware Teilweise inkompatibel zu bestehenden Systemen Benutzer muss in Sicherheit investieren Langwieriger Prozess

Markt entwickelt sich sehr schnell

Trustcenter schwer zu kontrollierenGesetzliche Rahmenbedingungen notwendigMöglicherweise EU-Richtlinien der

Datenschutzgruppe



Industrie hat Interesse an Überwachungs- und DRM-Funktionen Interessenkonflikte innerhalb der TCG

Bsp.: Sony als Plattenfirma Mitglied der TCG Nutzer sehen in der Regel nur „Gängelung“,

nicht den potentiellen Nutzen Öffentlichkeitsarbeit der TCG mangelhaft

Schwachpunkt aller IT-Systeme ist der Benutzer mit seinen vielfältigen Interessen Bsp.: Mallory als Administrator

Christian Blichmann, Marc Seitz

Unumgehbarkeit,Tamper Resistance und

Trusted Computing Base

Vielen Dankfür Eure Aufmerksamkeit

Folien:http://www.blichmann.de/downloads/unumgehbarkeit.ppt

Ausarbeitung:http://www.blichmann.de/downloads/unumgehbarkeit.pdf

unumgehbarkeit, tamper resistance und trusted computing base

Documents

systemuniversitt dortmund

pg 450berblickeinleitung1

personal secure booting2

bestehende it

personal secure bootinghttp

trusted computing base3

bankkarten eal4

autorisierter benutzer