Untersuchung zum Schutz der Software Arbeitspaket 7 Version: Datum: 1.0 23. Dezember 2010 Seite 1 von 76 | | 2010

Historie

Version Autor Kommentar Datum

Initiale Version erstellt 12.11.10
Review:

— Kapitel 3 - Angriffsszenarien 17.11.10
ausgefüllt

— Kapitel 4 - Angriffsbäume aus AP3
eliminiert

— Kapitel 4 - weiterer PBA-Schutz via
Smartphone

— Kapitel 5 beschrieben

24.11.10
— Einarbeitung BSI Review 25.11.10

— Review Kapitel 2.5 10.12.10
— Einarbeitung internes Review
— Neues Bild zu den unterschiedlichen
Möglichkeiten beim Systemstart
— _Finalisierung des Dokuments

Einarbeitung BSI-Kommentare 21.12.10

— Einarbeitung letzter Kommentare 23.12.10
— Version 1.0 zur Abnahme

 

Seite 2 von 76 Eu | 20:0

Inhaltsverzeichnis 1 Problembeschreibung.................................................................................................5 1.1 Bedrohte Werte...................................................................................................6 1.2 Authentisierung....................................................................................................7 1.2.1 Benutzer gegenüber Plattform.....................................................................7 1.2.2 Plattform gegenüber Benutzer.....................................................................8 2 Begriffsdefinitionen...................................................................................................10 2.1 Trusted Computing............................................................................................10 2.1.1 Trusted Computing Group.........................................................................10 2.1.2 TPM Work Group.......................................................................................10 2.1.3 Server Work Group....................................................................................10 2.1.4 Mobile Phone Work Group........................................................................10 2.1.5 Infrastructure Work Group.........................................................................10 2.1.6 Trusted Network Connect Work Group......................................................11 2.1.7 Storage Work Group..................................................................................11 2.2 Bootstrapping....................................................................................................12 2.2.1 Trusted Boot (Authenticated Boot)............................................................12 2.2.2 Secure Boot...............................................................................................12 2.3 Trusted Platform Module...................................................................................13 2.3.1 Platform Configuration Register.................................................................13 2.3.2 Roots Of Trust............................................................................................14 Root Of Trust For Measurement.....................................................................14 Core Root Of Trust For Measurement (CRTM / SRTM).................................14 Dynamic Root Of Trust For Measurement (DRTM)........................................15 Root Of Trust For Reporting...........................................................................15 Root Of Trust For Storage..............................................................................16 2.3.3 TPM-Shielded Keys...................................................................................16 Endorsement Key...........................................................................................17 Storage Root Key...........................................................................................17 2.3.4 Nicht-flüchtiger Speicher (Non-Volatile RAM)...........................................18 2.3.5 Sealing.......................................................................................................18 2.3.6 TPM Vertrauensbeglaubigung...................................................................19 Endorsement Credential.................................................................................19 Conformance Credential.................................................................................19 Platform Credential.........................................................................................19 2.4 Chain of Trust....................................................................................................20 2.5 Smartcard..........................................................................................................22 2.5.1 Grundlagen................................................................................................22 2.5.2 Leser..........................................................................................................22 2.5.3 Kommunikation..........................................................................................23 2.5.4 PKCS #11 ..................................................................................................23 2.5.5 Einsatz.......................................................................................................23 2.5.6 RFID...........................................................................................................24 3 Existierende Angriffe.................................................................................................25 3.1 Passwort per Brute-Force angreifen.................................................................25 Seite 3 von 76 | | 2010

3.2 Passwort per Keylogger erhalten......................................................................25 3.3 Passwort aus der Auslagerungsdatei auslesen................................................26 3.4 Passwort aus dem Hauptspeicher auslesen.....................................................26 3.4.1 via DMA und FireWire................................................................................26 3.4.2 via Tastasturpuffer des BIOS.....................................................................27 3.4.3 via Coldboot-Mechanismen.......................................................................27 3.5 Passwort durch Manipulation am Bootloader protokollieren............................28 3.5.1 Evil-Maid Angriff auf TrueCrypt..................................................................28 3.5.2 Reproduktion des Bootloaders (optisch) am Beispiel von Bitlocker..........28 3.5.3 Stoned Bootkit............................................................................................29 4 Lösungsmöglichkeiten..............................................................................................30 4.1 Lösungsansätze ohne Trusted Computing.......................................................35 4.1.1 M1.1 - Booten von externem Medium.......................................................35 4.1.2 M1.2 - Booten vom Netzwerk....................................................................37 4.1.3 M1.3 - Messung des Speichers mittels DMA.............................................39 4.2 Online-Lösungen mit Trusted Computing.........................................................41 4.2.1 M2.1 - Remote Attestation mit Schlüsselversand......................................41 4.3 Offline-Lösungen mit Trusted Computing.........................................................44 4.3.1 M3.1 - Sealing des Volume-Key................................................................44 4.3.2 M3.2 - Ablage des Volume-Schlüssels in NVRAM des TPM.....................46 4.3.3 M3.3 - Lokale „Remote“ Attestation via Smartcard....................................48 4.3.4 M3.4 - Gegenseitige Attestierung über ein „Trusted Device“, z.B. via Smartphone.........................................................................................................51 4.3.5 M3.5 - Gegenseitige Attestierung via Smartcard und Klasse-3-Leser (i). .54 4.3.6 M3.6 - Gegenseitige Attestierung via Smartcard und Klasse-3-Leser (ii). 57 4.3.7 M3.7 – Mehrstufige, gegenseitige Attestierung durch Bilder.....................60 4.3.8 M3.8 - Sealing des Volume-Key + Smartcard und Klasse-1-Leser...........62 4.4 Secure Boot ohne Trusted Computing..............................................................65 4.4.1 M4.1 - Sicheres BIOS................................................................................65 4.5 Secure Boot mit Trusted Computing.................................................................68 4.5.1 M5.1 - Unter Verwendung des DRTM und Intel TXT / AMD SVM.............68 5 Zusammenfassung...................................................................................................70 5.1 Produkte und Dienstleistungen fürs Geschäftsmodell......................................71 5.2 Empfehlung.......................................................................................................71 5.3 Vergleich – Bedrohungen, Maßnahmen und Szenarien...................................73 Seite 4 von 76 | | 2010

1 Problembeschreibung Heutige Computersysteme besitzen keine einfach umzusetzende Möglichkeit, die auf der Plattform laufende Software sicher zu starten. Rein funktionell ist der Startprozess – ab dem Einschaltzeitpunkt des PC bis zum Erreichen des geladenen Betriebssystems – wohl definiert und bereitet technisch keine Probleme, jedoch sind die Bootkomponenten bzw. die zu startenden Programme im Allgemeinen nicht vor Manipulation geschützt. Einem Angreifer ist es daher prinzipiell erst einmal möglich, von einem beliebigen Bootmedium zu starten, den Bootloader, das zu ladende Betriebssystem oder installierte Anwendungen auf einer Festplatte auszulesen, zu manipulieren oder ganz zu ersetzen. Ein Benutzer bzw. Administrator hat zunächst keine Möglichkeit, diese gewollten (z.B. durch einen Angreifer) oder ungewollten (z.B. durch Hardware-Fehler) Modifikationen zu bemerken. Eine gängige, erste Schutzmaßnahme stellt das Setzen eines Start- sowie eines BIOS-Passworts dar. Das Start-Passwort kann genutzt werden, um den PC vor unberechtigten Startvorgängen zu schützen, zum Hochfahren des Systems muss zwingend dieses Passwort eingegeben werden. Über das BIOS-Passwort lässt sich der Zugang zum sowie Modifikationen am BIOS nur durch gültige Benutzer (d.h. Inhaber des BIOS-Passworts) durchführen, wie z.B. die Änderung der 1 Bootreihenfolge. Als letzte Variante bieten die ATA-Spezifikationen ein Sicherheitskonzept namens „ATA security mode feature set“ vor. Hier lässt sich der Zugriff auf die Festplatte durch ein Passwort schützen. In der Regel kann ein Benutzer im BIOS das Setzen des Passworts veranlassen. Vor einem Startvorgang muss die Festplatte dann zunächst freigeschaltet werden, bevor von ihr Daten gelesen werden können. Bei einem Startvorgang würde das Passwort daher durch das BIOS abgefragt werden. Diese Passwort-basierten Lösungsansätze bieten jedoch keinen ausreichenden Schutz, vor allem nicht im Hinblick auf Vertraulichkeit: • BIOS-Passwörter von (zumindest) PC-Mainboards können durch das Setzen von Steckbrücken (Jumper) zurückgesetzt werden. Zusätzlich existieren für einige BIOS-Versionen Standard-Passwörter, die Angreifern ebenfalls Zugriff auf das BIOS gewähren. Alternativ kann auch das BIOS bzw. der Flash- Speicher, in dem das BIOS gespeichert ist, getauscht werden. • Start-Passwörter werden im gleichen Bereich gespeichert wie BIOS- Passwörter, sodass auch hier die gleichen Risiken und Umgehungsmöglichkeiten gelten. • Das Setzen von BIOS- oder Startpassworten schützt die Festplatte nicht, wenn ein Angreifer diese aus dem System entnehmen und in ein anderes System einbauen kann. • Bzgl. der Festplattenpasswörter gibt es zwar keine Möglichkeit, diese physikalisch zurückzusetzen, jedoch existieren für Festplattenhersteller 1 ATA-3 Spezifikation, Kapitel 6.5 „Security mode feature set“, siehe http://www.t10.org/t13/project/d2008r7b-ATA-3.pdf Seite 5 von 76 | | 2010

Möglichkeiten zum Zurücksetzen. Im übrigen schützt das Passwort lediglich den Zugriff auf die Daten, die Daten selbst liegen immer noch im Klartext auf dem Datenträger vor, sodass z.B. unter Laborbedingungen die einzelnen Speicherscheiben ausgelesen werden können. Alternativ lässt sich auch ein neuer, ungeschützter Festplattencontroller an die Festplatte montieren, um so Zugang zu den Daten zu erhalten. Um die auf dem System befindliche Software und Daten zu schützen, empfiehlt sich der Einsatz einer Festplattenverschlüsselung. Diese kann entweder durch den Einsatz einer Hardwarelösung realisiert werden, wie z.B. Festplatten mit direkt 2 eingebauter Verschlüsselung oder aber durch Software-basierte Verschlüsselungslösungen. Bei letzterem Fall gibt es verschiedene Ansätze, eine Festplatte zu verschlüsseln: • Verschlüsseln einer einzelnen (Daten-)Partition, • Verschlüsseln einer (Daten-)partition sowie der Systempartition, • Verschlüsseln der gesamten Festplatte (Full-Disc-Encryption (FDE)). Der letzte Fall ist zugleich der komplexeste Fall: In diesem Szenario wird eine gesamte Festplatte inkl. Betriebssystem, Anwendungen und Nutzerdaten verschlüsselt. Das problematische beim Einsatz einer Software-basierten FDE ist jedoch, dass ohne Entschlüsselungsroutine und den dazugehörigen Schlüssel nicht von der Festplatte gelesen werden kann. Für ein konventionelles BIOS, welches von Haus aus keinerlei Informationen über Algorithmus oder Betriebsart mitbringt, ist das Lesen und somit das Starten von einer FDE-verschlüsselten Festplatte nicht möglich. Eine gängige Lösung für dieses Problem besteht darin, nicht die gesamte Festplatte (d.h. angefangen von Sektor 0 bis einschließlich des letzten Sektors) zu verschlüsseln, sondern einen kleinen Bereich am Anfang der Festplatte im Klartext zu belassen. In diesem Bereich – dem Master Boot Record (Sektoren 0-62) – werden die Partitionstabelle sowie ein Bootloader eingebracht. Der Bootloader enthält die nötigen Entschlüsselungsroutinen, um auf den Rest der Festplatte zugreifen zu können und so das Betriebssystem zu starten. Üblicherweise fragt hierzu der Bootloader den Benutzer nach seinem Passwort, welches dann als Eingabe für eine „Password-Based Key Derivation Function“ (PBKDF) dient. Als Ergebnis dieser Funktion wird ein Schlüssel ausgegeben, welcher dann zur Entschlüsselung genutzt wird. 1.1 Bedrohte Werte Sämtliche bedrohten und damit zu schützenden Werte sind in AP3 definiert. Um aber konkret den Gefahren von Angriffen (siehe Kapitel 3) auf den Startvorgang (sog. Pre- Boot-Angriffe) zu begegnen, werden hier erneut die relevanten Werte aufgeführt, die 2 http://www.fujitsu.com/global/news/pr/archives/month/2008/20080421-01.html http://www.seagate.com/ww/v/index.jsp?locale=de- DE&name=Seagate Secure Technology: Selbstverschl%C3%BCsselnde Laptop- Festplatten_von_National_Security_Agency_qualifiziert&vgnextoid=9942aa95bf92a110VgnVCM10 0000f5ee0a0aRCRD Seite 6 von 76 | | 2010

vor und während des Startvorgangs besonders geschützt sein müssen. Kapitel 3 beschreibt existierende Angriffe gegen TrueCrypt und andere, gängige Festplattenverschlüsselungslösungen mit FDE. Direkt bedrohte Werte • Daten (abhängig vom Volume-Key) ◦ Betriebssystem ◦ Anwendungen ◦ Nutzerdaten (NfD) • Volume-Key Indirekt bedrohte Werte • Hardware ◦ Tastatur (durch Keylogger) ◦ TPM (durch Hardware-Angriffe) ◦ Smartcard-Leser (durch Manipulation) ◦ RAM (durch Auslesen) • Software (durch Manipulation) ◦ Master Boot Record (MBR) ◦ Bootloader ◦ BIOS Firmware • Authentifizierungsmerkmale (durch Ausspähen / Auslesen) ◦ Passwort (siehe z.B. 3.5.1 oder 3.5.2) ◦ PIN ◦ Smartcard 1.2 Authentisierung Eines der größten Probleme hinsichtlich der FDE besteht darin, vor dem eigentlichen Startvorgang eine „Vertrauensbeziehung“ zwischen der zu startenden Plattform und dem davor sitzenden Benutzer herzustellen. 1.2.1 Benutzer gegenüber Plattform Um die verschlüsselte Plattform zu starten, wird das Authentifizierungsmerkmal des Benutzers zur Ableitung des Volume-Keys benötigt. Dies kann indirekt als Authentisierung des Benutzers gegenüber der Plattform gewertet werden, denn die Plattform offenbart (implizit) nur ihre Geheimnisse, wenn die gültigen Credentials bereit gestellt wurden. Als Authentifizierungsmerkmal kommen drei Arten in Frage, Seite 7 von 76 | | 2010

welche zusätzlich untereinander kombiniert werden können: • (was man weiß) ◦ Komplexes Passwort (mit hoher Entropie) ◦ PIN, z.B. in Verbindung mit einer Smartcard • (was man hat) ◦ Smartcard ◦ Ausweis ▪ Neuer Personalausweis ▪ Truppenausweis der Bundeswehr ▪ elektronischer Dienstausweis • (was man kann) ◦ Biometrie, z.B. Fingerabdruck ◦ Eingabeverhalten, z.B. Verzögerung zwischen jedem Tastendruck 1.2.2 Plattform gegenüber Benutzer Die Authentifizierung des Benutzers stellt in der Regel kein Problem dar. Gibt ein Benutzer das falsche Passwort ein oder stellt nicht die benötigten Authentifizierungsmerkmale bereit, so lässt sich der Volume-Key nicht rekonstruieren und ein Zugriff auf die verschlüsselte Festplatte ist nicht möglich. Die entgegengesetzte Richtung, d.h. die Authentifizierung der Plattform gegenüber dem Benutzer ist hier schon komplizierter. Dieser Authentisierung ist insofern ein hoher Stellengrad beizumessen, da ein Benutzer sicher sein muss, wem er seine Credentials präsentiert. Gelingt es z.B. einem Angreifer, dem Benutzer ein modifiziertes System „unterzuschieben“, und gibt der Benutzer sein Passwort in das modifizierte System ein, so kann der Angreifer an die benötigten Informationen gelangen, um sich Zugriff auf die Daten zu verschaffen. Diese Problematik ist insofern als besonders schwerwiegend zu bewerten, da ein Angreifer diese Informationen an vielen Stellen während des Bootprozesses abgreifen kann, z.B.: • mit Hilfe eines Keyloggers zwischen Tastatur und PC (hier helfen nur organisatorische Maßnahmen) • durch ein modifiziertes BIOS, welches Tastatureingaben speichert • durch einen modifizierten Bootloader, welcher Tastatureingaben speichert Ein vollständiger Angriffsbaum ist in AP3 zu finden, eine Auflistung bereits existierender Angriffe ist in Kapitel 3 dargestellt. Im Rahmen dieses Arbeitspaketes können Angriffe, wie das [optische / akustische / via Keylogger] Auslesen von Benutzereingaben oder sonstige Hardware- Seite 8 von 76 | | 2010

Modifikationen nicht betrachtet werden. Angriffen dieser Art muss durch organisatorische Maßnahmen (z.B. Siegel, Räumlichkeiten, Mitarbeiterschulung etc.) vorgebeugt werden. Die hier beschriebenen Lösungen zielen darauf ab, Software- basierte Pre-Boot-Angriffe zu: a) erkennen b) verhindern Dazu müssen Lösungen erarbeitet werden, welche eine Vertrauenskette (chain of trust) durch den gesamten Startvorgang herstellen und zu dem Zeitpunkt, an welchem der Benutzer seine Credentials vorzeigt, diesen (explizit oder implizit) von der Korrektheit seiner Konfiguration überzeugt. Konkret bedeutet dies: 3 • Der Benutzer hat seine unmodifizierte Hardware vor sich. • Die Integrität des BIOS ist gewährleistet. • Die Integrität des MBR ist gewährleistet. • Die Integrität des Bootloaders ist gewährleistet. Im Folgenden werden zunächst einige grundlegende Begriffe und Technologien definiert und erläutert, welche technologisch zur Lösung der Pre-Boot-Problematik beitragen können. Darüber hinaus werden existierende Angriffe und Lösungsmöglichkeiten für TrueCrypt skizziert. Im Anschluss erfolgt eine Empfehlung, welche der dargestellten Lösungsmöglichkeiten geeignet für den Einsatz mit TrueCrypt sind. 3 Mit unmodifizerter Hardware ist gemeint, dass der Benutzer die selbe Hardware mit der selben Start-Software vor sich hat. Unter Software fällt hier insbesondere auch die Firmware von Hardware-Komponenten, welche unmittelbar am Startvorgang beteiligt ist, d.h. die Codeteile eines ROMs, welche vor dem Starten ausgeführt werden müssen, beispielsweise Grafik-BIOS, SCSI- BIOS, Raid-Controller-BIOS etc. Seite 9 von 76 | | 2010

2 Begriffsdefinitionen 2.1 Trusted Computing In diesem Zusammenhang wird der Begriff Trusted Computing in Anlehnung an die Definition durch die TCG verwendet, d. h. es werden Komponenten und Mechanismen beschrieben, die in der Spezifikation der TCG definiert oder zumindest dazu kompatibel sind und dazu beitragen, die Vertrauenswürdigkeit einer Plattform zu erhöhen. 2.1.1 Trusted Computing Group 4 Die Trusted Computing Group (TCG) ist ein internationales Konsortium aus verschiedenen Industrie- und Forschungseinrichtungen, mit dem Ziel, offene Standards und Spezifikationen im Bereich Trusted Computing zu entwickeln. Die TCG wurde im Jahre 2003 von AMD, Hewlett-Packard, IBM, Intel und Microsoft gegründet – damals noch unter der Bezeichnung Trusted Computing Platform Alliance (TCPA). Innerhalb der TCG existieren verschiedene Arbeitsgruppen, die sich mit den folgenden Themenbereichen beschäftigen: 2.1.2 TPM Work Group Die TPM Arbeitsgruppe spezifiziert die Kernkomponente im Bereich des Trusted Computing – das Trusted Platform Module (TPM) (siehe Kapitel 2.3). Hierzu hat die TCG verschiedene Spezifikationen erstellt, welche die Funktionalität, die Schnittstellen und die vom TPM zur Verfügung gestellte Funktionalität inkl. der zugehörigen Kommandos definiert. 2.1.3 Server Work Group Die Aufgabe der Server Work Group ist es, Definitionen, Spezifikationen, Anleitungen und technische Voraussetzungen bereitzustellen, die die Implementierungen von TCG-Technik in Servern betreffen. 2.1.4 Mobile Phone Work Group Die Mobile Phone Work Group arbeitet an der Anpassung des TCG-Konzeptes für mobile Geräte. Die Arbeitsgruppe erweitert die Spezifikationen der TCG um Spezifikationen, die spezielle Eigenschaften von mobilen Endgeräten, wie z.B. eingeschränkte Ressourcen, wechselnde Netzanbindung oder auch spezielle Nutzungsmodelle berücksichtigen. 2.1.5 Infrastructure Work Group Die Infrastructure Work Group arbeitet an der Erweiterung und Integration der TCG- 4 http://www.trustedcomputinggroup.org Seite 10 von 76 | 2010