9.3 Sichere Systeme

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:



bs-9.3
Sicherer Systemstart
Trusted Computing
Terra
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)

bs-9.3
Trusted Computing (Trusted Computing Group, 1999 - ...)
( 9.3.2)
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:
IBM PC mit FreeBSD, relativ geringe Modifikationen,
insbesondere durch Erweiterung des ROM
Annahme: 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-ErweiterungsROM, 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
TCPA
TCG
Trusted Computing (zu "trusted" vgl. 9.3.1)
Trusted Computing Platform Alliance, jetzt 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“
bs-9.3
* auch Edelmetall;
auch Παλλαδιον = Standbild der Pallas Athene im antiken Troja
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
bs-9.3
(Quelle: TCG Specifications)
13
Register des TPM:
PCRs
Platform Configuration Registers (flüchtig)
16 à 160 Bits für Hashwerte über Software-Komponenten
EK
Endorsement Key (persistent)
privater Schlüssel des TPM
und damit "des Rechners" oder "des Eigentümers"
SRK
Storage Root Key (persistent)
für Verschlüsselung von Speicherinhalten
AIKs
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
bs-9.3
Interne Konfigurierung des TPM: verschiedene
Möglichkeiten im Spektrum von inaktiv bis
voll funktionsfähig
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
bs-9.3
(Quelle: TCG Specifications)
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
bs-9.3
T. Garfinkel et al.: Terra: a virtual-machine-based platform
for trusted computing. Proc. 19. ACM Symp. on Operating
System Principles, 2003
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