© stylephotographs, 123RF

Gut ausgestattete Mainboards bringen meist Trusted-Computing-Chips mit, die Benutzer und Betriebssysteme aber nur selten nutzen. Der Linux-Kernel beherrscht die Technik und ermöglicht mit Trusted Grub eine weitreichende Vertrauenskette – zumindest theoretisch.

Die digitale Unterschrift alleine reicht nicht. Selbst wenn die qualifizierte elektronische Signatur als Ersatz der händischen Unterschrift in der Praxis anerkannt wäre, müsste die Software garantieren können, dass die Anwendung auch das signiert hat, was auf dem Bildschirm angezeigt wurde.

Wer da von der Vertrauenswürdigkeit der verwendeten Hardware ausgeht (Stichwort “Trusted Display”), dem stellt sich die Frage nach der Glaubhaftigkeit der verwendeten Programme. Der folgende Artikel beschreibt eine Möglichkeit, wie sich die Integrität von Software mit Linux, entsprechender Hardware und den richtigen Tools überprüfen lässt, und zeigt, wo es noch hakt und an welchen Stellen das freie System dennoch gegenüber Microsofts Windows die Nase vorn hat.

Soll in einem PC-System eine Anwendung die Integrität einer anderen überprüfen, so muss sie dazu selbst vertrauenswürdig sein. Aber weil auch die Überprüfung dieser Annahme wiederum von einer anderen vertrauenswürdigen Anwendung zu erfolgen hat, bedarf es einer Kette von Überprüfungen, einer Chain of Trust. Damit nicht genug: An deren Anfang muss eine vollkommen vertrauenswürdige Instanz stehen, der Sicherheitsanker oder Root of Trust.

Trusted Platform Module als Anker

Im PC-Umfeld hat sich in den letzten Jahren das TPM (Trusted Platform Module, [1]) etabliert – als Hardware in Form eines Chips auf den Mainboards vieler PCs und Notebooks. In der Voreinstellung fristet es jedoch meist nur ein Schattendasein und bleibt deaktiviert. Das TPM ist von der TCG (Trusted Computing Group, siehe Kasten “TCG”) spezifiziert und standardisiert (ISO/IEC 11889). Es enthält Komponenten fürs Trusted Computing und verschafft einem Rechner Zugang zu folgenden Funktionen:

• Eindeutige Plattform-Identität
• Sicherer Schlüsselspeicher
• Versiegeln von Daten
• Kryptographie-Funktionen
• Bewertung der System-Integrität

Die standardkonforme Realisierung des Chips bestätigen diverse Zertifikate und Signaturen (siehe Kasten “TPM”). Seine Vertrauenswürdigkeit beruht damit auf der Vertrauenswürdigkeit des Herstellers sowie der unterzeichnenden Instanzen der enthaltenen Zertifikate.

Trusted Boot

Bei PC-Systemen initialisiert ein vertrauenswürdiger Bootvorgang (Trusted Boot) die Chain of Trust. Er nimmt seinen Anfang mit dem Einschalten des Systems und der Ausführung des ROM-Bios-Code. Hier finden die grundlegenden Hardware-Initialisierungen, speziell die des TPM-Chips, statt.

Damit dessen Funktionen schon beim Booten bereitstehen, hilft eine Bios-Erweiterung namens CRTM (Core Root of Trust for Measurement). Sie ist ebenfalls von der TCG spezifiziert und sorgt für die Messung von Systemzuständen noch vor dem Start des Betriebssystems. Die Messung erfolgt durch eine Hashfunktion über relevante Datenbereiche und das Speichern der Ergebnisse in den PCR-Registern des TPM.

Abbildung 1 zeigt, wie das TPM zunächst den Bios-Code selbst unter die Lupe nimmt, dann den Bios-Code von externer Hardware und schließlich Daten, die sich aus dem Ergebnis des Einlesens von Hardware-Informationen ergeben. Damit ist die vorliegende Hardwarekonfiguration bereits Bestandteil der Integritätsprüfung. Im weiteren Verlauf sucht das Bios nach einem bootfähigen Gerät. Findet es dabei eine Festplatte, liest es deren ersten Sektor ein, misst ihn und führt einen gefundenen MBR-Code aus.

Abbildung 1: Die Chain of Trust beginnt beim Einschalten des PCs und setzt sich im Idealfall lückenlos bis zum gestarteten Betriebssystem fort. Unter Linux hilft da Trusted Grub.

CRTM übergibt an den Master Boot Record

An dieser Stelle endet die Zuständigkeit des CRTM für den Trusted Boot, der im MBR enthaltene Bootloader sorgt nun für die Fortsetzung der Chain of Trust: Dieser Code muss folglich selbst den Code messen, den er im weiteren Verlauf lädt und ausführt.

Später startet der Betriebssystem-Loader den Kernel des Betriebssystems, der wiederum entsprechende Mechanismen zum Messen von auszuführendem Code (einschließlich Treibern) enthält. Da Systemaufrufe im Kernel letztlich auch die Programme starten, lassen sich so auch alle gestarteten Anwendungen messen.

Linux: Trusted Boot mit Trusted Grub

Wer solch ein sicheres System unter Linux aufsetzen will, hat zunächst die Unterstützung des TPM im Bios-Setup zu aktivieren. Beim ersten Mal erzeugt er dazu intern diverse Schlüssel (“Inbesitznahme”, siehe Kasten “TPM”). In den darauf folgenden Schritten braucht er noch

• den Bootmanager Trusted Grub und
• einen Kernel mit aktiviertem IMA.

Das im Folgenden vorgestellte Verfahren nutzt ein Patch auf die alte Grub-Version 0.9.7. Es gehört zum Trusted-Grub-Projekt, einer Zusammenarbeit der Firma Sirrix mit der Uni Bochum. Auf der Projektseite [4] stehen neben dem Sourcecode ein Wiki und eine detaillierte Installationsanleitung bereit. Die aktuelle Version 1.1.5 stammt vom August 2010.

Ein installierter Trusted Grub im MBR der Festplatte setzt den TPM-unterstützten Bootprozess in folgender Weise fort:

• Die TCG-Bios-Erweiterung (CRTM) prüft Grub Stage 1 (MBR-Code)
• Grub Stage 1 prüft den Beginn von Grub Stage 2
• Grub Stage 2 prüft den Rest von Grub Stage 2
• Grub Stage 2 prüft außerdem den Betriebssystemkernel und die zu ladenden Kernelmodule

Darüber hinaus ermöglicht Trusted Grub das Vermessen beliebiger Dateien, was der Admin durch eine neue Option in der Grub-Konfigurationsdatei »/boot/grub/menu.lst« definiert: »checkfile (hdX,X?)/Pfad_zur_Datei« . Die Partition mit der angegebenen Datei ist in der Grub-üblichen Weise anzugeben, die Dateigröße ist jedoch auf 8 KByte begrenzt. Dieses File enthält eine Liste zu prüfender Dateien sowie deren korrekte Prüfsumme (SHA-1, Listing 1 zeigt ein Beispiel).

01 792f802081e5193a304606026365797e69334adc (hd0,6)/boot/initrd.img-2.6.35.4-ima
02 b6787ae6767deacefc5758ef7a4c0cdcbd0665ca (hd0,6)/boot/vmlinuz-2.6.35.4-ima

Simple Grub-Konfiguration via <C>menu.lst<C>

Beim Bootvorgang überprüft Grub der Reihe nach jeden Eintrag dieser Liste. Stimmt die berechnete Prüfsumme nicht mit der angegebenen überein, bricht der Bootprozess mit einer Meldung an den Nutzer ab. Mit der Abfrage aus Listing 2 hat der Anwender die Wahl, ganz abzubrechen oder das Booten dennoch fortzusetzen.

01 ****Trusted GRUB now booting Ubuntu-IMA
02 ****Progress:****XX
03 tGRUB: Verifiying (hd0,6)/boot/initrd.img-2.6.35.4-ima -> Integrity Error!
04 tGRUB: Data integrity not Guaranteed, 1 problem(s) occurred
05 tGRUB: Press ESC to stop booting or any other key to continue ...

Ganz nebenbei landen hier die Prüfsummen über die Dateien stets mit TPM_Extend in den entsprechenden PCR-Registern des TPM. Beim Start des Linux-Kernels durch Trusted Grub übergibt der Bootloader die Zuständigkeit für die Chain of Trust an den Kernel.

Die Funktionen der TPM-gestützten Integritätsprüfung im Kernel existieren bereits seit 2005. Ein entsprechendes Kernelpatch für die Integrity Measurement Architecture (IMA) stammt von IBM Research ([5], [6]).

Die Integrity Measurement Architecture unter Linux

Seit Version 2.6.30 ist IMA offizieller Bestandteil des Linux-Kernels – aber üblicherweise nicht aktiviert, sodass Neu-Übersetzen erforderlich ist, und zwar mit diesen Einstellungen:

• CONFIG_IMA=Y
• CONFIG_IMA_MEASURE_PCR_INDEX=10
• CONFIG_IMA_AUDIT=Y
• CONFIG_IMA_LSM_RULES=Y

Außerdem bedarf es einer zusätzlichen Bootoption für den Kernel »ima_tcb=1« . Einen Ausschnitt aus der Grub-Konfiguration mit aktivem IMA sowie einer Grub-Checkdatei zeigt Listing 3.

01 title Ubuntu-IMA
02 root (hd0,6)
03 checkfile (hd0,6)/boot/grub/grub-check
04 kernel /boot/vmlinuz-2.6.35.4-ima root=/dev/sda7 vga=0x317 ima_tcb=1
05 initrd /boot/initrd.img-2.6.35.4-ima

IMA nutzt die so genannten LSM-Hooks (Linx Security Module) im Kernel, auf die beispielsweise auch Mandatory-Access-Control-Erweiterungen (MAC) wie SE Linux zurückgreifen. An diesen Hooks können Programmierer Kernel-interne Funktionen registrieren, die beim Zugriff auf sicherheitsrelevante Funktionen oder Systemcalls aufgerufen werden. Die IMA-Funktionen startet der Kernel etwa an jenen Hooks, die der Kernel vor jedem Laden ausführbarer Dateien durchläuft. Dies betrifft Systemcalls wie »mmap()« , »execve()« und »sys_init_module()« .

Zuerst kommt immer der IMA-Code

So ist sichergestellt, dass vor jedem Laden oder Ausführen von Kernelmodulen, Bibliotheken, Binärdateien oder Skripten der IMA-Code läuft. Dieser Code berechnet – analog zum vorherigen Booten – eine Prüfsumme über die entsprechende Datei. Das Ergebnis landet nicht in jedem Fall im TPM-Chip, sondern nur bisher ungeprüfte Dateien oder Dateien mit veränderter Prüfsumme.

Ein Cache-Mechanismus sorgt dafür, dass dieser Vorgang in der Praxis nicht zu spürbaren Performance-Einbußen führt. Zudem hält IMA im Kernel eine Tabelle mit den Namen aller gemessenen Dateien und ihren Prüfsummen. Diese Liste enthält stets den aktuellen Zustand der bisher ausgeführten Dateien. Ein Vergleich dieser Prüfsummen mit Sollwerten (Prüfsummen über die integren Versionen der entsprechenden Dateien) stellt Integritätsverletzungen fest.

Prüfsummen im Chip mit TPM_Extend

Auch die Prüfsummen aus dieser Liste sind mit TPM_Extend im TPM-Chip abgelegt. Ändert sich die Checksumme einer Datei im laufenden System, so finden sich die unterschiedlichen Prüfsummen in den Werten des PCR-Registers. Die Tabelle im Kernel enthält jedoch nur die aktuelle Prüfsumme der Dateien.

Zur Auswertung dieser Tabelle bietet IMA eine Schnittstelle zum Userspace an: Die Ascii-Repräsentation der Tabelle kann der Admin in »/sys/kernel/security/tpm0/ascii_Bios_measurements« auslesen (einen Ausschnitt zeigt Listing 4), in Listing 5 wertet das Linux-Bordwerkzeug Head die PCR-Register des TCM aus.

01 # head -5 /sys/kernel/security/ima/ascii_runtime_measurements
02 PCR template-hash                        filedata-hash                 filename-hint
03 10 0f7aa9805f51800bf1403c3de856c4bee66dfa21 ima dd16d778c4dbfdea44536cdc10890757684fe1e0 boot_aggregate
04 10 1dfdf1da8cca8248c420f365bbb7cb00ad59597e ima 648090bfe9593bcc2702461433d5c9ef64399ee5 /init
05 10 afaefb735a3d93f5c6f66f7893b558f04438e8c0 ima 5fb8c8479f31574c435aa06d5bae6ae5a737ca81 /init
06 10 08005d2b0ba3ee8c10c40f87eef76f3c4cea41d5 ima 195b25cdab5501b58858bc0923e51a0eab2447a3 ld-linux.so.2
07 10 63d7494f6da7fb0fc3332ab4fce2a2e1d45fbaf2 ima d3d48ff690110248aba853fdb0748bfe4dd64673 libc.so.6

01 # head -10 /sys/kernel/security/tpm0/ascii_Bios_measurements
02 6226702b792e3ddd4b33491ce19375c671a8f8a7 08 [S-CRTM Version]
03 4bb5a4e9f0f392abfa4eab2202b3bd924621dc63 01 [POST CODE]
04 1ea0e02ec49aaf3fda0bc8186da2cf246d7cfecf 01 [POST CODE]
05 dd261ca7511a7daf9e16cb572318e8e5fbd22963 01 [POST CODE]
06 df22cabc0e09aabf938bcb8ff76853dbcaae670d 01 [POST CODE]
07 a0d023a7f94efcdbc8bb95ab415d839bdfd73e9e 01 [POST CODE]
08 05ce5aa3a72f4dccdaa251bbac738a03296be1f7 01 [POST CODE]
09 dd261ca7511a7daf9e16cb572318e8e5fbd22963 01 [POST CODE]
10 df22cabc0e09aabf938bcb8ff76853dbcaae670d 01 [POST CODE]
11 a0d023a7f94efcdbc8bb95ab415d839bdfd73e9e 01 [POST CODE]

Überprüfung

Das Prinzip von Trusted Boot ermöglicht aber keine Garantie eines integren Bootvorgangs. Dazu müsste das System die Prüfsummen ständig gegen Sollwerte vergleichen und bei jeder Abweichung sofort reagieren wie beim Secure-Boot-Verfahren. Bei Trusted Boot jedoch bricht der Bootvorgang auch bei modifizierten Daten nicht ab. Stattdessen gestattet es der Prozess aber, ein nicht-integres System zu erkennen. Die Reaktion auf eine solche Erkennung obliegt der prüfenden Instanz und ist nicht Bestandteil von Trusted Boot.

Dieser Integritätscheck des Systems bildet den Kern von Trusted Boot. Die Sache hat allerdings einen Haken: Die Überprüfung eines gestarteten PC kann prinzipbedingt nicht durch den PC selbst erfolgen (Henne-Ei-Problem). Stattdessen sieht IMA eine Überprüfung durch eine vertrauenswürdige externe Instanz vor.

Remote Attestation mit Challenge und Response

Dieser Vorgang wird als “Remote Attestation” bezeichnet und läuft im so genannten Challenge-Response-Verfahren (siehe Abbildung 2) in den sechs folgenden Schritten ab:

Abbildung 2: Das Remote-Attestation-Protokoll erlaubt die Überprüfung der Integrität durch ein entferntes System. Leider existiert dafür noch keine Implementierung.

• Die prüfende Seite erzeugt eine Zufallszahl (Nonce), (1)
• Sie überträgt die Nonce zum Zielsystem (Challenge), (2)
• Das Zielsystem macht einen TPM_Quote-Request, lässt die Nonce und den PCR-Wert signieren und schickt das Ergebnis zusammen mit der Hashliste zurück, (3)
• Die prüfende Seite untersucht Signatur und Nonce auf Authentizität und Aktualität des PCR-Werts, (4)
• Sie rechnet den PCM-Wert (TPM_Extend) mit Hilfe der erhaltenen Hashliste nach, bei Gleichheit ist die Liste authentisch, (5)
• Sie prüft alle Hashwerte aus der Liste gegen Referenzwerte aus einer Datenbank, bei Gleichheit sind die entsprechenden Dateien auf dem Zielsystem integer, (6)

So weit die Theorie, doch leider mangelt es immer noch an einer nutzbaren Implementierung dieses Protokolls.

Varianten mit Smartcard und Crypto-Filesystemen

Als Variante der Überprüfung kämen auch Smartcards als Gegenstelle in Frage, die die Rolle der vertrauenswürdigen Instanz übernehmen, auf der das Remote-Attestation-Protokoll implementiert ist. Die im Kasten “Variante mit Smartcard und Vollverschlüsselung” vorgeschlagene Architektur sieht neben Trusted Boot eine 2-Faktor-Authentisierung des Nutzers sowie eine Vollverschlüsselung der Festplatte vor, was Integrität und Vertraulichkeit sämtlicher Daten sicherstellen würde.

Variante mit Smartcard und Vollverschlüsselung

Smartcards sind dafür ausgelegt, kryptographische Operationen auszuführen, Zufallszahlen zu generieren oder Daten und Schlüssel sicher aufzubewahren. Sie agieren als Challenging Party und übernehmen das Remote-Attestation-Protokoll sowie die Prüfung der Checksummen. Das Szenario besteht darin, eine sicherheitsrelevante Anwendung auf dem PC erst nach erfolgreicher Integritätsprüfung starten zu dürfen. Die Idee dahinter ist, diese Anwendung in einem verschlüsselten Container auf dem PC abzuspeichern, dessen Schlüssel auf der Smartcard gespeichert ist. Die Smartcard liefert ihn erst an den PC aus, nachdem sie die Integrität des Systems festgestellt hat.

Vertrauenswürdige Instanz

Zur Abwicklung des Remote-Attestation-Protokolls, zur Ansteuerung der Smartcard sowie zum Mounten des verschlüsselten Containers benötigt man eine Anwendung (Loader), die außerhalb des Containers gespeichert ist (Abbildung 3). In Schritt 1 startet der Loader, er initialisiert die Smartcard und steuert den Dialog mit dem Anwender. Eine Authentisierung des Nutzers an der Smartcard schaltet diese frei (2). Dann führt der Loader das Remote-Attestation-Protokoll gegen die Smartcard durch (3). Erst nach erfolgreicher Prüfung der Integrität liefert diese den Schlüssel zum Mounten des verschlüsselten Containers aus (4). Damit kann der Loader den Container mounten (5) und die darin enthaltene Applikation starten (6).

Abbildung 3: Ablauf des Remote-Attestation-Protokolls mit einer Smartcard zum Schutz einer Applikation.

Doch ganz so einfach funktioniert auch das in der Praxis nicht, gilt es doch einige Hürden zu überwinden: So wird die Smartcard aufgrund ihrer begrenzten Ressourcen gewiss nicht alle korrekten Prüfsummen aufnehmen können. Ebenso wird das Protokoll einige Zeit in Anspruch nehmen.

Weil der Linux-Kernel auch gleich Mechanismen mitbringt, um die Festplatten zu verschlüsseln (Dm-crypt, Device-mapper und das Crypto-API, [7]), ist ein noch komplexeres und umfassenderes Konzept denkbar. Abbildung 4 zeigt schematisch die Erweiterung des weiter oben beschriebenen Verfahrens.

Abbildung 4: Eine denkbare Realisierung von Secure Boot bei Verwendung einer Smartcard als überprüfender Instanz und Linux-Vollverschlüsselung der Festplatte.

Hier liegen außer den Partitions-Verwaltungsdaten keine unverschlüsselten Daten mehr auf der Festplatte. Das System bootet unter Verwendung von CRTM und Trusted Grub (Schritte 1 bis 4) von einem USB-Medium. Eleganterweise verwendet der Admin einen USB-Stick mit integriertem Smartcardleser und hat so alle Zugangsdaten auf dem Stick. Die Initial Ramdisk enthält den notwendigen Code, um die Smartcard anzusprechen, die Nutzerauthentisierung durchzuführen, eventuell sogar schon eine Integritätsprüfung zu triggern und bei Erfolg den Schlüssel für die transparente Plattenverschlüsselung aus der Smartcard zu lesen (Schritte 5 bis 8). Dann kann der Rechner das Root-Dateisystem mounten und den Bootvorgang fortsetzen (Schritte 9 bis 11). Danach beginnen die dargestellten Schritte zum Start der sensitiven Applikation (Schritte 12 bis 16).

Natürlich ist auch dieser Ansatz nicht frei von Schwierigkeiten: So ist die Administration der Smartcards und der USB-Sticks nicht für eine größere Nutzergruppe geeignet. Eine so komplexe Architektur eignet sich ohnehin eher für dedizierte Systeme mit hoher Sensitivität, die den Administrationsaufwand und den Overhead rechtfertigen.

Windows

Windows bietet in neueren Versionen (ab Windows Vista) eine Unterstützung des TPM-Chips durch die Pre-Boot-Authentisierung und die Festplattenverschlüsselung Bitlocker [8]. Die Software misst die Integrität des Systems in der frühen Bootphase, was dem Prinzip von Trusted Grub entspricht.

Danach bricht die Chain of Trust jedoch ab, der Kernel setzt die Integritätsmessungen per TPM-Chip nicht fort. Die Philosophie zum Schutz der Integrität sieht hier anders aus: Bitlocker stellt via TPM sicher, dass er Integritätsverletzungen bis zum Start des Kernels erkennt. Zudem gewährleistet Bitlocker die Vertraulichkeit aller Daten auf der Festplatte durch Vollverschlüsselung.

So verhindern Admins von Microsoft-Systemen, dass ein potenzieller Angreifer offline eine gezielte Modifikation bestimmter Dateien vornimmt. Dedizierte Funktionen wie Driver Signing, Patch Guard und User Account Control ergänzen diese Maßnahmen.

MS setzt auf UEFI

Eine detaillierte Untersuchung der Sicherheit von Windows Vista [9] kommt zu der Schlussfolgerung, Microsoft habe die Sicherheit von Windows gegenüber früheren Versionen zwar deutlich verbessert, ein durchgängiges Konzept des Herstellers im Sinne der TCG sei allerdings nicht erkennbar, zumindest nicht out-of-the-box.

Microsoft hat das aber wohl erkannt und arbeitet Schritt für Schritt daran. Auf der Build-Konferenz im September 2011 stellten die Entwickler ihren neuen “Secure Boot” genannten Ansatz unter Windows  8 vor, der über UEFI (Unified Extensible Firmware Interface, [10]) nur signierte Bootloader erlaubt und so wie bei Googles Chrome OS das Betriebssystem schützen soll. Die entsprechenden UEFI-Chips sind allerdings noch recht selten auf Hardware zu finden.

Die Absicherung der Integrität von Linux-Applikationen lässt sich durch eine Kombination aus CRTM, Trusted Grub und IMA zu einem nahtlosen Trusted Boot realisieren. So erkennen Admins Modifikationen an sicherheitsrelevanten Applikationen, etwa die zum Erzeugen digitaler Signaturen.

Die Anwendbarkeit in der Praxis hängt allerdings von einem zuverlässigen Überprüfungsverfahren ab, und leider fehlt immer noch eine nutzbare, leicht zu administrierende Implementierung des Remote-Attestation-Protokolls. Im Vergleich zu Windows jedoch findet sich in IMA auf jeden Fall eine weitaus konsequentere Realisierung des Trusted-Boot-Konzepts. (mfe)