Chipsätze/Grafik/Prozessoren: ARM, ATI Technologies, Motorola,
National Semiconductor, NVIDIA, Seagate Technology, Texas Instruments, Transmeta,
VIA Technologies
"Beglaubigung" der Plattform gegenüber Dritten für
Server-Authentifizierung (statt VPN)
plattformgebundene digitale Inhalte (DRM)
verwendet öffentlichen Teil der AIK (Attestation Identity Key)
Verifizierung durch
CA (Certification Authority),
vertrauenswürdigem Drittanbieter (Trusted Party) oder
Zero Proof
Authentication
Attestation: Missverständnisse
Missverständnisse
kein Einsatz des Private EK (Endorsement Key)!
Trusted Party ist nicht die TCG!
dient nicht zur personenbezogenen
Identifikation
mehrere AIKs pro Plattform möglich
mehrere AIKs pro User möglich
Das ist neu: TCG Update
Fortschritte in der Spezifikation
TPM-Spezifikation 1.2
veröffentlichte Bestandteile
Design-Grundlagen
Struktur des TPM
TPM-Befehle
Einführung von "RevokeTrust", Invalidierung des EK
Direct Anonymous Attestation, Beglaubigung ohne CA
TCG Software Stack (TSS) Spezifikation 1.1
Unerreichte Ziele
Coming "Real Soon Now"
Advisory-Plätze
Zero-Fee-Liaisons
TPM-Spezifikation 1.2 Teil 4
Zusammenfassung - TCG
Vier Aufgaben
Daten versiegeln
Schlüssel sicher speichern
Plattform gegenüber Dritten beglaubigen
sichere Zufallszahlen generieren
Komponenten
Hardware: TPM, TCPA-BIOS
Software: CRTM (Core Root Of Trust Measurement), TSS (Trusted platform Support
Service)
bietet Authentifizierung und Beglaubigung der Plattform, nicht des
Anwenders
2. Microsoft und NGSCB
Next-Generation Secure Computing Base ("Inscabb")
alias "Palladium" (Änderung aus namensrechtlichen Gründen)
vom ursprünglichen Konzept ist nur noch die grobe Richtung übrig
Schutz vor Software-Angriffen
Schutz für Anwendungen
Schutz für Daten
Was kümmert uns Windows
Microsoft verwendet viel Gehirnschmalz darauf, NGSCB zum Laufen zu bringen
sowohl Linux als auch Microsoft sind Betriebssysteme für PC-Hardware
Warum nicht aus Microsofts Erfahrungen lernen?
NGSCB Reloaded
NGSCB erster großer Ansatz zu einem TC-Betriebssystem
Ziele:
Schutz vor Software-Angriffen bei maximaler Abwärtskompatibilität
Auslieferung als Teil von "Longhorn" (NGSCB 1.0)
NGSCB 2003: erste, sehr ambitionierte Architektur
tiefgreifende Änderungen der PC-Architektur
hohe Hardware-Anforderungen
keine Abwärtskompatibilität der Hardware
NGSCB 2004: neue Architektur, alte Namen für neue Konzepte
noch weitgehend unklar
stark reduzierte Hardware-Anforderungen
Ziele von NGSCB
Aufgaben
starker Speicherschutz (Process Isolation)
Beglaubigung (Attestation) *
versiegelter Speicher (Sealed Storage) *
gesicherter Pfad zum Anwender (Trusted Path) [2003]
Sicherung vor DoS-Attacken [2004]
Das war NGSCB 2003
Grundüberlegung
sicheres Windows nur auf Kosten der Kompatibilität
"Vaulted Computing" war erster Codename
Konsequenz
paralleles, gesichertes System aufbauen (Nexus Mode)
Ring -1 für sicherheitsrelevante Komponenten
gesicherte Ein- und Ausgabekanäle
Das Janus-Betriebssystem
Zweiteilung des Betriebssystems
Standardmodus (Left Hand Side, LHS)
Windows wie bisher
weitestgehende Kompatibilität zu bestehenden Anwendungen
leicht angepasstes Treibermodell für Ein- und Ausgabegeräte
übernimmt Scheduling für die rechte Seite über "Schattenprozesse"
Nexus-Modus (Right Hand Side, RHS)
Systemkern: Nexus
strenger Speicherschutz
gesicherte Agenten (Nexus Computing Agents, NCA)
separates Starten und Beenden möglich
NGSCB 2003: Aufbau
NGSCB 2003: Datenaustausch
NGSCB 2003: Pfade
NGSCB 2003: Fehlschläge
Das hat nicht geklappt
linke Seite ebenso unsicher wie zuvor
kein Schutz vor DoS-Attacken
NCAs leben in extrem eingeschränkter Umgebung
radikale Hardware-Umstellung verlangt
Mangelnde Kundenakzeptanz
Entwickler wollen keine NCAs entwickeln
Hardware-Hersteller wollen keine sichere Hardware herstellen
Performance-Probleme
Trusted Input war eine Schnecke
Was Microsofts Kunden wollen
Sicherheit auch für bisherige Anwendungen
keine Einschränkungen im Bedienkomfort
inkrementelle Sicherheit
zukunftssichere sichere Hardware erwerben (!)
Das ist NGSCB 2004
NGSCB 2004: Abschied von...
NGSCB 2004: Status Quo
NGSCB 2004: Das bleibt
NGSCB 2004: Das kommt
NGSCB 2004: Aufbau
NGSCB 2003: Aufbau (Reprise)
NGSCB 2004: Pfade
NGSCB 2003: Pfade (Reprise)
NGSCB 2004: Grundkonzept
Lesen im Kaffeesatz (aus einer [1] Präsentation)
(alle grundlegenden Informationen von Peter N. Biddle, dem Mann mit
der TCPA-Lizenz)
"Compartments" statt LHS und RHS
baut auf "Windows-Komponenten" auf
Nexus wird zu Hypervisor (IBM-Speak)
NGSCB 2004: Anpassungen
Windows (ehemals LHS)
einziges Echtzeitbetriebssystem im Stall
verwaltet die meiste Hardware
Sicherheitsvorteile durch Szenarien
Compartments (ehemals RHS)
braucht weniger Ressourcen
stark geschützte Abteile/Schotten
verwaltet Secure Devices direkt (je nachdem)
keine DMA-Zugriffe
Das ist (hoffentlich) neu: NGSCB
weitgehende Abhängigkeit von Intels LaGrande (Secure Chipset)
Das kann es jetzt (vermutlich)
Schutz vor DoS-Angriffen
Schutz des Eingabekanals bei integrierten Lösungen (Notebooks)
eingeschränkter Schutz für Windows-Anwendungen
Schutz pro Abteil, nicht mehr pro Agent
Das tut es (vermutlich) nicht mehr
komplett isolierte Nexus Computing Agents (NCA)
Schutz des Ausgabekanals (Secure Video)
Verwaltung von Secure Devices über Windows
Intermezzo: LaGrande
Ziele
geschützte Ausführung von Code *
Speicherschutz *
Schutz des Grafikkartenspeichers *
geschützte Anbindung von: TPM und Eingabegeräten
Funktionsweise
Prozessor (CPU):
offene und geschützte Bereiche (Protected Memory
Policy)
Speicher (RAM):
Zugangsschranken zu geschütztem Speicher (Access
Policy)
Konkrete Anwendungen für NGSCB
Cornerstone
(engl. "Grundstein, Eckpfeiler")
Übernahme des WinLogin-Vorgangs
Benutzerauthentifizierung in gesichertem Abteil
Schutz des Windows-Basisschlüssels (Syskey)
verhindert Umgehung von Windows-"Sicherheits"maßnahmen durch Boot-CD o.ä.
Code Integrity Rooting
Validierung von Bootvorgang und System
Integritätsüberprüfung vor Herausgabe des Syskey an Windows
Ungelöste Probleme
Trusted Input bei externen Eingabegeräten (Lösung im Herbst)
Umgang mit Legacy Devices ("unsichere" Peripherie)
Schutz des Ausgabekanals (Secure Video)
Schutz vor Datei-Löschungen
Zugang für behinderte Anwender
Remote Administration
abhängig von Intels Zeitplan für LaGrande
Was wird aus AMD, VIA & Co.?
4. Politisches
Ansätze der Kritik
Betriebe:
Wettbewerbsnachteile
Verlust an Interoperabilität
Entwickler:
begrenzter Zugriff auf Spezifikation
durch Patente gebremste Entwicklung
Anwender:
trügerische Sicherheit
Kontrollverlust
unumgehbares Digital Restrictions Management (DRM)
Der Chaos Computer Club (CCC)
Forderungskatalog für TCG, überreicht auf CeBIT 2003
vollständige Kontrolle des Anwenders über alle Schlüssel
im TPM,
inkl. EK und SRK
verborgenen Kanäle zur Schlüsselübertragung ausschließen,
Schutz
vor Covert Channels
Schlüsselübertragung auf andere Rechner ermöglichen
keine Non-Migratable Keys
keine neue Freischaltung von Software bei neuem Rechner
transparente Zertifizierungsmechanismen,
Bekanntgabe der Bedingungen zur
Zertifikatausstellung
kein
Missbrauch durch unfaire Preispolitik oder Verweigerung
Die Electronic Frontier Foundation (EFF)
Überraschend differenzierte Betrachtungsweise
potenzielle Vorteile von TC
potenzielle Nachteile von TC
konkreter Lösungsvorschlag
Vorteile von TC
Dritte können Kompromittierung des Systems erkennen und darauf reagieren
Verhinderung von Schummeln in Netzwerkspielen, Absicherung von verteilten
Anwendungen (z.B. SETI@Home)
Durchsetzung von Unternehmensrichtlinien gegenüber Mitgliedern/Angestellten
"Bevormundende" Sicherheitsrichtlinen schützen Anwender
vor eigenen Fehlern
Die Electronic Frontier Foundation (EFF) (...)
Nachteile von TC
Dritte können Richtlinien gegen den Computer-Besitzer faktisch durchsetzen
Digital Restrictions Management (DRM) / Zwangs-Aktivierung
Festlegung ein Betriebssystem / Anwendung / Zwangs-Bundling
Beschränkung der Umstellungsmöglichkeiten, Erzwingen von Up-
und Downgrades
Spyware mit TPM-Schutz / Verhinderung von Reverse Engineering
Lösungsvorschlag der EFF
Lösungsvorschlag: Owner Override
Vorteile von Owner Override
Dritte können weiterhin kompromittierte Systeme erkennen
Erweiterte Durchsetzung von Unternehmensrichtlinien auf Firmenrechnern
Computerbesitzer behält Kontrolle über lokale Software
Erhaltung von Wettbewerb, Interoperabilität, Kontrolle und freie Auswahl
des Anwenders
Nachteile von Owner Override
weiterhin kein Behelf gegen Schummler in Netzwerkspielen / verteilten Rechenprojekten
erschwerte Durchsetzung von "bevormundenden" Sicherheitsrichtlinien
keine positiven Nebenwirkungen von DRM-Richtlinien (Schutz eigener Daten)
Die Bundesregierung
Forderungskatalog vom 24.10.2003, bekanntgeworden im Frühling 2004
Forderungen
keine Vermischung von TPM-Funktionen mit anderen Funktionseinheiten
Daten müssen sich weiterhin auf Systeme ohne TPM übertragen lassen
...sofern
nicht urheberrechtlich geschützt
Löschung und Reinitialisierung des TPM muss möglich sein
TPM soll nicht Software an Hardware binden, sondern Plattformintegrität
sichern
Benutzeridentifikation (inkl. AIKs) soll in SmartCards
ausgelagert werden
keine externe Zertifizierung von TPM-bezogener Software
Die Bundesregierung und OSS
Wünsche für Open Source
TCG: keine Lizenzgebühren für Open-Source-Projekte (soll)
TCG: kostenlose Mitgliedschaft für Open-Source-Projekte (soll)
TCG: Mitwirkungsmöglichkeit für Open-Source-Entwickler (soll)
MS: kostenlose Zertifizierung für Open-Source-Projekte (soll)
Mit Linux wäre das nicht passiert
Linux ist schon weiter als Windows
Linux-TPM-Treiber von IBM
TrustedGRUB (Bochum), Enforcer (Dartmouth): Sicherung des Boot-Vorgangs
durch TPM
PERSEUS, Linux Security Kernel (Ruhr-Universität Bochum)
Secure User Interface, Trusted Viewer (Bochum): Sicherung gegen Spoofing
Warum TC für Linux
von Regierungsseite aus nicht mal ein Rückzugsgefecht
niemand geht heute noch davon aus, dass man TC "stoppen" kann
eventuell stoppt sich TC selbst
Empfohlene Betrachtungsweise: TC als Naturkatastrophe
