SS-11 1

11 Kryptographische Systemsicherung

bedeutet: Einsatz kryptographischer Verfahrenzur systematischen Sicherung der Integrität und Authentizität von Code

(schützt nicht gegen fehlerhaften,verletzlichen oder bösartigen Code!)

SS-11 2

11.1 Signierter Code

am Beispiel Java

Zur Erinnerung (4.7.4.2):

Richtlinien (Strategien) bestimmen Zugriffsrechte von Code(wenn der Security Manager installiert ist)

Beispiel eines grant-Eintrags:

grant codeBase "file:/home/datsche/buddy/classes/*" {permission java.io.FilePermission "/usr/lohr/*", "read";

}

Auch für die Authentisierung von Code benutzbar !

SS-11 3

Infrastruktur für kryptographische Sicherung:

Zugriffsschutzrichtlinien:

Speicherung ~/.java.policy u.a.Verwaltung policytool

Schlüssel und Zertifikate (X.509):

Speicherung ~/.keystore u.a.Verwaltung keytool

Signieren von JAR-Dateien: jarsigner

SS-11 4

11.1.1 Schlüsselverwaltung

Datei ~/.keystore enthält eigene Schlüssel und fremde Zertifikate

Inhalt von .keystore abfragen:

$ keytool -listEnter keystore password: ********

Keystore type: jksKeystore provider: SUN

Your keystore contains 1 entry

lohr, Jan 24, 2006, keyEntry,Certificate fingerprint (MD5): 43:99:DC:7A:B1:7E:0D:35:F0:8D:1C:DA:18:C8:8D:7E$

SS-11 5

Vollständige Information für einen bestimmten Eintrag:

$ keytool -list -alias lohr -vEnter keystore password: ********Alias name: lohrCreation date: Jan 24, 2006Entry type: keyEntryCertificate chain length: 1Certificate[1]:Owner: CN=Klaus-Peter Löhr, OU=Institut für Informatik, O=Freie Universit?ät Berlin, L=Berlin, ST=Unknown, C=DEIssuer: CN=Klaus-Peter Löhr, OU=Institut für Informatik, O=Freie Universit?ät Berlin, L=Berlin, ST=Unknown, C=DESerial number: 43d66f29Valid from: Tue Jan 24 19:17:13 CET 2006 until: Mon Apr 24 20:17:13 CEST 2006Certificate fingerprints: MD5: ED:EC:CA:E5:79:47:0E:1B:D5:81:DF:05:15:24:3B:2C SHA1: CE:22:AD:0B:5E:2C:4E:3D:ED:D4:01:BB:EC:43:92:0E:43:20:55:B8$

! Dies ist ein self-signed certificate !

SS-11 6

Erzeugung eines DSA-Schlüsselpaars mit automatischer Ablagein der Datei .keystore :

$ keytool -genkey -alias lohrEnter keystore password: ********What is your first and last name? [Unknown]: Klaus-Peter LöhrWhat is the name of your organizational unit? [Unknown]: Institut für InformatikWhat is the name of your organization? [Unknown]: Freie Universität BerlinWhat is the name of your City or Locality? [Unknown]: BerlinWhat is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: DEIs CN=Klaus-Peter Löhr, OU=Institut für Informatik, O=Freie Universit?ät Berlin, L=Berlin, ST=Unknown, C=DE correct? [no]: yes

Enter key password for <lohr> (RETURN if same as keystore password): $

! Erzeugt ein self-signed certificate !

SS-11 7

11.1.2 Richtlinienverwaltung

$ policytool

SS-11 8

Allgemeine Form eines grant-Eintrags:

grant signedBy "names", codeBase "URL", principal "name", principal "name", ... {

permission PermissionClass "targetName", "action", signedBy "names"; permission PermissionClass "targetName", "action", signedBy "names";... };

Die hier verwendeten Namen für Unterzeichner und Principalsidentifizieren Zertifikate im keystore :

SS-11 9

Der keystore wird in der Richtliniendatei durch keystore-Eintrag identifiziert:

keystore "keystoreURL", "keystoreType", "keystoreProvider";keystorePasswordURL "passwordURL";

keystoreURL kann eine absolute oder relative URL sein (relativ zum Verzeichnis der Richtliniendatei, typisch ist .keystore)

keystoreType ist typischerweise JKS (Voreinstellung, von Sun)

keystoreProvider ist typischerweise Sun (Voreinstellung)

SS-11 10

Beispiel für die Forderung nach signiertem Code:

grant signedBy "max, moritz", .....

fordert digitale Unterschriften von Max und Moritz, genauer:

es werden genau solche Klassen akzeptiert, derenenthaltende JAR-Dateien von denjenigen Personensigniert wurden, zu denen die mit max und moritz identifizierten Zertifikate in keystore gehören.

SS-11 11

11.1.3 Signieren und Verifizieren von JAR-Dateien

$ jarsigner Main.jar lohrEnter Passphrase for keystore: ********$$ jarsigner Main.jar moritzEnter Passphrase for keystore: ********$

zusätzlicheUnterschrift

$ jarsigner -verify Main.jarjar verified.$ jarsigner -verify Jar.jar jar is unsigned. (signatures missing or not parsable)$

SS-11 12

$ jarsigner -verify -verbose -certs Main.jar

172 Wed Jan 25 12:18:18 CET 2006 META-INF/MANIFEST.MF 186 Wed Jan 25 12:18:18 CET 2006 META-INF/LOHR.SF 1200 Wed Jan 25 12:18:18 CET 2006 META-INF/LOHR.DSA 0 Tue May 03 16:50:10 CEST 2005 META-INF/smk 581 Tue May 03 16:25:38 CEST 2005 Main.class

X.509, CN=Klaus-Peter Löhr, OU=Institut für Informatik, O=Freie Universit?ät Berlin, L=Berlin, ST=Unknown, C=DE (lohr)

s = signature was verified m = entry is listed in manifest k = at least one certificate was found in keystore i = at least one certificate was found in identity scope

jar verified.$

SS-11 13

11.2 Gesicherter Systemstart

Beachte: Ein hohes Maß an Systemsicherheit kann solangenicht erzielt werden, wie die Basis-Software nicht vertrauenswürdig ist.

Wenn ein Angreifer beispielsweise das Sicherheits-system 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 hohenSicherheitseigenschaften und Authentizitätsgarantieerforderlich usw. bis herunter zum Systemstart (booting).

SS-11 14

Terminologisches:

trusted system, trusted platform, trusted computing base (TCB), ...

ist ein System zur Unterstützung von Sicherheit, desseneinwandfreies Funktionieren axiomatisch vorausgesetzt wird.

"Wir gehen davon aus, dass das System korrektist und nicht unterlaufen werden kann."

trustworthy system, ...

vertrauenswürdiges System, verdient das Vertrauen, das ihmentgegengebracht wird - weil ein hochkarätiges Entwicklerteamdahintersteht und/oder weil es formal verifiziert wurdeund/oder weil es schon lange zuverlässig gearbeitet hat .....

SS-11 15

Historisches zur Systemsicherung:

Sicherheitskerne von Betriebssystemen:Ein kleiner Kern des Betriebssystems stellt Sicherheits-mechanismen 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). . . . .

SS-11 16

Krypto-Koprozessoren zur Unterstützung kryptographischerMaßnahmen zur Systemsicherung.

Beispiele:

physically secure coprocessors, CMU 19914758 secure coprocessor, IBM 1999. . . . .

Secure and Reliable Bootstrap

AEGIS (Univ. of Pennsylvania, 1996)

Trusted Computing (Trusted Computing Group, 1999 - ...)( 11.3)

SS-11 17

AEGIS - eine Hardware/Software-Architektur für sicheren Systemstart (secure bootstrap):

wie kann erreicht werden, dass beim Starteneines Systems vom ersten Augenblick an nur Codezur Ausführung kommt, dessen Authentizitätgesichert ist?

(Beachte: das Problem wird "wegdefiniert", wenn der BootCode der TCB zugerechnet wird.)

Kontext: IBM PC mit FreeBSD, relativ geringe Modifikationen,insbesondere durch Erweiterung des ROM

Annahme: kein Angriff auf Motherboard oder BIOS

SS-11 18

Ansatz: Die nacheinander zu ladenden Code-Teile sindsigniert und werden schrittweise verifiziert.

Zu diesem Zweck wird das BIOS im ROM modifiziertund 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.

SS-11 19

Was macht AEGIS stattdessen?Ein Teil des BIOS, zusammen mit dem AEGIS-Erweiterungs-ROM, 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 eventuellvorhandener 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 desLaders.

Dieser lädt den Betriebssystem-Kern und verifiziert ihn;damit ist das Betriebssystem sicher gestartet.

SS-11 20

11.3 Trusted Computing

Begriffe und Akronyme:

TC Trusted Computing (zu "trusted" vgl. 11.2)TCPA Trusted Computing Platform Alliance, jetzt TCG:TCG Trusted Computing Group (IBM, Intel, Microsoft, ...)

* auch Edelmetall auch Παλλαδιον = Standbild der Pallas Athene im antiken Troja

Palladium* die TC-Realisierung von Microsoft, jetzt NGSCB:NGSCB Next-Generation Secure Computing Base (Microsoft)Longhorn Codename für nächste Windows-Version mit TC

LaGrande Intel's Hardware-Unterstützung für TC

SS-11 21

Ziele: (technisch; zu ökonomisch/politisch siehe 11.3.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 Anwendungs-programm, 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 voneiner bestimmten Anwendung (in bestimmter Version) entschlüsselt werden können

SS-11 22

11.3.1 Hardware: der TPM-Koprozessor

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"

(Spezifikation: TCG Specification Architecture Overview)

* benannt nach dem US-Senator Fritz Hollings

SS-11 23

SS-11 24

SS-11 25

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

SS-11 26

Weitere Komponenten des TPM:

Random Number Generatorfür Erzeugung von Schlüsseln und Nonces (9.8.1)

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 EngineBerechnung von Hashcodes

. . . . .

SS-11 27

Weitere Komponenten des TPM:

Execution EngineInitialisierung; Verifizierung unter Einsatz der PCRs

Input/OutputKommunikation mit der Außenwelt

Opt-InInterne Konfigurierung des TPM: verschiedeneMöglichkeiten im Spektrum von inaktiv bisvoll funktionsfähig

SS-11 28

11.3.2 Sicherstellung der Systemintegrität

Measurement = Information über Code (oder Daten) Hashwert darüber

! Kein gesicherter Systemstart, aber 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

SS-11 29

SS-11 30

Die Identität der so aufgebauten Plattform wird in einemHashwert codiert, der sich aus einem "akkumulierendenHashing" ("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 einemStored Measurement Log - SML - gespeichert. Die Speiche-rung muss nicht hundertprozentig sicher sein: Manipulationenwerden über die Hashwerte erkannt, und bei Verlust ist eineWiedergewinnung möglich.

SS-11 31

11.3.3 Authentisierung der Plattform

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

(integrity reporting)

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)

SS-11 32

SS-11 33

11.3.4 Quo vadit?

Vorteile von TC:

Allgemeine Verbesserung der Systemsicherheit,insbesondere im Netz,

insbesondere bezüglich Authentizität und Integritätvon Software und Daten

Achtung:

TC ist keine Allheilmittel gegen Schadsoftware(z.B. Trojanische Pferde!) oder unzuverlässigeSoftware (Beispiel Pufferüberlauf!)

SS-11 34

Kritik an TC:

Eigentliche Motivation ist Durchsetzung einesbeliebig rigorosen Umsetzung des Schutzes vonUrheberrechten (Digital Rights Management - DRM).

Bindung von Daten an Programme und von Programmenan Plattformen, die weit über das bisherige hinausgeht.

Dadurch weitere Machtkonzentration bei Oligopolen.

Dem Benutzer wird die freie Verfügungsgewalt überseinen Rechner genommen.

SS-11 35

Erwiderungen:

Man kann den TPM ja abschalten . . .

Auch Linux-Entwickler arbeiten an TC . . .

Der Markt wird es richten . . .

Lektüre: Spezifikation: TCG Specification Architecture OverviewC. 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