6.5 Signierter Code. Einsatz asymmetrischer Verschlüsselung zur systematischen Sicherung der. schützt Code vor Manipulation durch Angreifer

Transkript

1 6.5 Signierter Code bedeutet: Einsatz asymmetrischer Verschlüsselung zur systematischen Sicherung der Integrität und Authentizität von Code schützt Code vor Manipulation durch Angreifer schließt nicht aus, dass der Code fehlerhaft, verletzlich, bösartig oder verstümmelt (nicht lauffähig) ist! ITS-6.5 1

2 6.5.1 Signierter Code am Beispiel Java Zur Erinnerung (4.5.6 ): Richtlinien (Strategien, policies) bestimmen die Zugriffsrechte von Code (wenn ein Security Manager installiert ist) Beispiel eines grant-eintrags: grant codebase "file:/home/datsche/buddy/classes/*" { permission java.io.filepermission "/usr/lohr/*", "read"; } Bietet auch Möglichkeiten für die Authentisierung von Code! ITS-6.5 2

3 Infrastruktur für kryptographische Sicherung: Zugriffsschutzrichtlinien ( ): Speicherung Verwaltung ~/.java.policy u.a. policytool Schlüssel und Zertifikate (X.509): Speicherung Verwaltung ~/.keystore u.a. keytool Signieren von JAR-Dateien: jarsigner ITS-6.5 3

4 Schlüsselverwaltung Datei ~/.keystore enthält eigene Schlüssel sowie eigene und fremde Zertifikate Inhalt von.keystore abfragen: $ keytool -list Enter keystore password: ******** Keystore type: jks Keystore provider: SUN Your keystore contains 1 entry lohr, Jan 24, 2006, keyentry, Certificate fingerprint (MD5): ED:EC:CA:E5:79:47:0E:1B:D5:81:D $ ITS-6.5 4

5 Vollständige Information für einen bestimmten Eintrag: $ keytool -list -alias lohr -v Enter keystore password: ******** Alias name: lohr Creation date: Jan 24, 2006 Entry type: keyentry Certificate chain length: 1 Certificate[1]: Owner: CN=Klaus-Peter Löhr, OU=Institut für Informatik, O=Freie Unive Issuer: CN=Klaus-Peter Löhr, OU=Institut für Informatik, O=Freie Univ Serial number: 43d66f29 Valid from: Tue Jan 24 19:17:13 CET 2006 until: Mon Apr 24 20:17:13 C Certificate 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: $! Dies ist ein selbstsigniertes Zertifikat! ITS-6.5 5

6 Erzeugung eines DSA-Schlüsselpaars mit automatischer Ablage in der Datei.keystore : $ keytool -genkey -alias lohr Enter keystore password: ******** What is your first and last name? [Unknown]: Klaus-Peter Löhr What is the name of your organizational unit? [Unknown]: Institut für Informatik What is the name of your organization? [Unknown]: Freie Universität Berlin What is the name of your City or Locality? [Unknown]: Berlin What is the name of your State or Province? [Unknown]: What is the two-letter country code for this unit? [Unknown]: DE Is CN=Klaus-Peter Löhr, OU=Institut für Informatik, O=Freie Universit?ät Berl [no]: yes Enter key password for <lohr> (RETURN if same as keystore password): $! Erzeugt ein selbstsigniertes Zertifikat! ITS-6.5 6

7 Richtlinienverwaltung 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 Principals identifizieren Zertifikate im keystore : ITS-6.5 7

8 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) ITS-6.5 8

9 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, deren enthaltende JAR-Dateien von denjenigen Personen signiert wurden, zu denen die mit max und moritz identifizierten Zertifikate in keystore gehören. ITS-6.5 9

10 principal "name, principal "name,..... (Die Namen bezeichnen wiederum Zertifikate im keystore.) Wenn solche Einträge vorhanden sind, werden die Zugriffsrechte weiter eingeschränkt: Nur solche Subjekte dürfen zugreifen, die durch ein Principal identifiziert werden, wie es im benannten Zertifikat verzeichnet ist (Person, Organisation,...) siehe JAAS - Java Authentication an Authorization Service ITS

11 $ policytool& ITS

12 Signieren und Verifizieren von JAR-Dateien $ jarsigner Main.jar lohr Enter Passphrase for keystore: ******** $ $ jarsigner Main.jar moritz Enter Passphrase for keystore: ******** $ zusätzliche Unterschrift $ jarsigner -verify Main.jar jar verified. $ jarsigner -verify Jar.jar jar is unsigned. (signatures missing or not parsable) $ ITS

13 $ jarsigner -verify -verbose -certs Main.jar smk 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/ 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 U 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. $ ITS

14 6.5.2 Gesicherter 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). ITS

15 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 (unterwandert, compromised) 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 sich schon lange bewährt hat... ITS

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

17 Krypto-Koprozessoren zur Unterstützung kryptographischer Maßnahmen zur Systemsicherung. Beispiele: physically secure coprocessors, CMU secure coprocessor, IBM Secure and Reliable Bootstrap AEGIS (Univ. of Pennsylvania, 1996) Trusted Computing (Trusted Computing Group, ) ( 6.5.3) ITS

18 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: Annahme: IBM PC mit FreeBSD, relativ geringe Modifikationen, insbesondere durch Erweiterung des ROM kein Angriff auf Motherboard oder BIOS ( TCB!) ITS

19 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. ITS

20 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 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. ITS

21 6.5.3 Trusted Computing Begriffe und Akronyme: TC Trusted Computing (zu "trusted" vgl ) TCPA Trusted Computing Platform Alliance, jetzt TCG: TCG Trusted Computing Group (IBM, Intel, Microsoft,...) Palladium* die geplante TC-Realisierung von Microsoft, jetzt: NGSCB Next-Generation Secure Computing Base Longhorn früherer Codename für nächste Windows-Version mit TC-Komponenten, jetzt Vista und Server 2008 LaGrande Intel's Hardware-Unterstützung für TC * auch Edelmetall auch Παλλαδιον = Standbild der Pallas Athene im antiken Troja ITS

22 Technische Ziele: 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 ITS

23 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 ITS

24 ITS

25 ITS

26 Register des TPM: PCRs EK SRK AIKs Platform Configuration Registers (flüchtig) 16 à 160 Bits für Hashwerte über Software-Komponenten Endorsement Key (persistent) privater Schlüssel des TPM und damit "des Rechners" oder "des Eigentümers" Storage Root Key (persistent) für Verschlüsselung von Speicherinhalten Attestation Identity Keys (persistent) weitere private Schlüssel für authentische Auskünfte ITS

27 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..... ITS

28 Weitere Komponenten des TPM: Execution Engine Initialisierung; Verifizierung unter Einsatz der PCRs Input/Output Kommunikation mit der Außenwelt Opt-In Interne Konfigurierung des TPM: verschiedene Möglichkeiten im Spektrum von inaktiv bis voll funktionsfähig ITS

29 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 ITS

30 ITS

31 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 unbedingt sicher sein: Manipulationen werden über die Hashwerte erkannt, und bei Verlust ist eine Wiedergewinnung möglich. ITS

32 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) ITS

33 ITS

34 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!) ITS

35 Kritik an TC: Eigentliche Motivation ist Kundenbindung (customer lock-in) und Durchsetzung eines restriktiven 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. Dem Benutzer wird die freie Verfügungsgewalt über seinen Rechner genommen. ITS

36 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 Glossar: C. Eckert: IT-Sicherheit, Kap (gute Darstellung!) R. Anderson: Trusted Computing Frequently Asked Questions... viele weitere Texte/Links in Zeitschriften, bei Wikipedia und bei Heise ITS