© photocase.com

Das Thema Trusted Computing für Linux ist ein heißes Eisen, kein Artikel wird es abkühlen können. Wohl aber vermag er Leser in die Lage zu versetzen, sich selber ein Bild über die Chancen und Risiken der Fritz-Chip-Technik zu machen.

Dass Bill Gates vielleicht später als andere dahinter gekommen ist, ändert nicht die Tatsache: Sicherheit ist ein elementares Bedürfnis aller Nutzer des Internets. Denn Angriffe auf die Vertrauenswürdigkeit elektronischer Kommunikations- und Geschäftsprozesse durch Phishing, Pharming, Würmer, Trojanische Pferde und Rootkits sind Teil unserer Erlebniswelt und werden es bleiben.

Ein Weg, der Gefahr Herr zu werden, wäre es, Netzwerke stärker zu überwachen und zwecks Abschreckung per Gesetz unerwünschte Aktivitäten mit Strafen zu belegen. Die damit verbundenen Risiken in Sachen Datenschutz und Privatsphäre sind eigentlich bekannt. Trotzdem scheinen es immer mehr Bürgerinnen und Bürger als das kleinere Übel anzusehen.

Eine Alternative oder Ergänzung könnte sein, die begrenzte Sicherheit, die eine reine Softwarelösungen erreichen kann, mit Hilfe von Hardwarekomponenten zu verbessern. Diese Idee ist nicht neu: Mit Kryptochips ausgestattete Smartcards arbeiten schon lange als sichere Umgebung für kryptographische Operationen und geheime Schlüssel. Kritik erwächst der Alternative dadurch, dass sich die geplanten Verfahren auch eignen, um digitale Inhalte fest an eine Plattform zu binden und so eine (unerlaubte) Wieder- und Weitergabe zu unterbinden.

Funktionsbausteine des Trusted Platform Module

Eine Trusted Platform muss in der Lage sein, wichtige Geheimnisse, Zertifikate, Schlüssel sowie kritische (kryptographische) Operationen sicher in einer geschützten Hardware-Umgebung zu speichern beziehungsweise auszuführen. Das TPM der TCG (siehe Kasten “Trusted Computing der TCG”) ist das Herzstück dieser Plattform.

Es lässt sich in seiner Arbeitsweise mit einer auf dem Motherboard verlöteten Smartcard vergleichen, wobei es anders als diese nicht den Benutzer authentisiert, sondern die Integrität der Hard- und Software dieser Plattform. Details zum TPM sind in [3] zu finden, den Grundaufbau zeigt Abbildung 1.

Abbildung 1: Ein TPM besteht aus fünf kryptographische Funktionseinheiten, einem nicht-flüchtigen Speicher mit drei Schlüsseln und einem flüchtigen Bereich.

Das TPM – zeitweise Fritz-Chip genannt – enthält fünf kryptographische Funktionseinheiten. Der Hardware-Zahlengenerator liefert Zufallszahlen von sehr hoher Qualität, die sowohl für die Schlüsselerzeugung auf dem Chip selber als auch für Applikationen nutzbar sind. Die Hash- und die HMAC-Einheit (Hashing for Message Authentication Calculator) signiert Daten. Das TPM kann 2048 Bit lange RSA-Schlüssel direkt auf dem Chip erzeugen. Die fünfte Einheit nimmt RSA-Ver- und Entschlüsselungen vor.

Im nicht-flüchtigen TPM-Speicher liegen drei wichtige Schlüssel: Der Endorsement Key ist ein 2048 Bit langes RSA-Schlüsselpaar, das der Hersteller auf den Chip schreibt. Er bildet die Grundlage für eine unverwechselbare Kennung des TPMs und ist mit dem Master Key einer Zertifizierungsstelle unterschrieben. Die beglaubigt damit, dass es sich um einen Originalschlüssel handelt.

Während der private Teil des Schlüssels das TPM niemals verlässt, erfüllt der öffentliche Teil zwei Aufgaben. Erstens werden mit ihm die Daten verschlüsselt, die der Chip gesendet bekommt – das ist zum Beispiel beim Übernehmen des Besitzes nötig (siehe unten). Zweitens dient der öffentliche Schlüssel der Platform Attestation (Beglaubigung der Plattform). Da der öffentliche Teil des Schlüssels aus Sicht der Privatsphäre kritisch ist, darf der Benutzer die Weitergabe deaktivieren. Eine Platform Attestation ist dann aber nicht mehr möglich.

Der Storage Root Key (SRK) ist ebenfalls ein RSA-Schlüsselpaar mit 2048 Bit. Der Besitzer erzeugt es beim Übernehmen der Hardware. Das Paar verlässt den Chip nie, der Besitzer darf es aber löschen. Der SRK verschlüsselt weitere Schlüsselpaare (Wrap). Der 160 Bit lange Owner Authorization Secret Key lädt sich wie der SRK bei der Besitznahme in den Chip. Er hilft dort Befehle autorisieren, die der Benutzer an das TPM übergeben hat.

Zugeständnisse nach Kritik

Der flüchtige Bereich bietet Platz für zehn temporäre RSA-Schlüssel, 16 PCRs (Platform Configuration Register), die Hashwerte von Hard- und Softwarekonfigurationen aufnehmen, und zwei Arten von Handles. So genanntes Sealing (Versiegeln) bindet Daten durch eine Verschlüsselung über die PCRs an die Systemkonfiguration. Das Unsealing läuft nur erfolgreich, wenn die Werte in den Registern mit denen bei der Verschlüsselung übereinstimmen.

Key Handles braucht das TPM, um den geladenen Schlüsseln Namen zuzuordnen. Befehle greifen auf diese Schlüsselnamen zu. Das Authorization Session Handle hilft den Status der Autorisierung konservieren, wenn mehrere Befehle hintereinander eintreffen.

Kritiker sehen in dem unveränderlichen Endorsement Key und der darauf fußenden Platform Attestation die Basis für ein Hardware-DRM. Mit der TPM-Spezifikation 1.2 hat es die TCG als Zugeständnis den TPM-Herstellern erlaubt, einen überschreibbaren Endorsement Key in den Chip zu integrieren. Der Besitzer kann so den vorgegebenen Schlüssel löschen und für ungültig erklären. Dadurch verliert er allerdings unwiederbringlich den Zugang zum ursprünglichen Vertrauenssystem und muss ein eigenes System von Vertrauensstellungen aufbauen.

Ebenfalls neu ist die so genannte Direct Anonymous Attestation (direkte anonyme Beglaubigung). Der Benutzer eines TPM-Systems darf hierbei für seine öffentliche Kommunikation beliebig viele anonyme Zertifikate ausstellen und bei jedem Kommunikationspartner ein anderes benutzen – dies soll das Erstellen eines Benutzerprofils verhindern.

Unterstützung durch Hard- und Software

Laut TCG haben Hersteller bereits Millionen von TPM-Chips hergestellt und verbaut – die meisten nach der alten Spezifikation 1.1b [4]. Seit Mitte 2005 sind auch 1.2er TPM-Bausteine in größeren Mengen erhältlich. So ziemlich jeder große PC-Hersteller verkauft Modelle, die serienmäßig mit TPM ausgestattet sind. Auch in einigen Apple-Rechnern mit Intel-Prozessoren, die an Entwickler gingen, wurden auf den Motherboards TPMs von Infinion gesichtet.

Üblicherweise ist heute ein TPM-Chip über den Low-Pin-Count-Bus (LPC) mit dem Motherboard verbunden. In Mode kommt gerade der Ansatz, das TPM in andere Hardware wie I/O-Chips, Netzwerkadapter und gar CPUs zu integrieren. Die Vanderpool-Prozessoren rüstet Intel mit der La-Grand-Technologie aus, AMD nimmt in die neuen Pacifica-CPUs solche Funktionen auf. Die Verbreitung der Bausteine wird künftig verhindern, TPM-freie Hardware zu kaufen.

Aber: Entgegen den Prognosen zu Beginn des Trusted Computing existiert bis heute kein Betriebssystem, das alle Sicherheitsfunktionen der Hardware unterstützt. Jedoch arbeiten die Betriebssystem- und Prozessorhersteller, unter anderem AMD, Intel, IBM und Microsoft, an Architekturen, die Hard- und Software verbinden. Auch Forschungsgruppen beschäftigen sich mit dem Thema (siehe unten).

Vereinzelt ist kommerzielle Spezialsoftware erhältlich. So bietet Utimaco Produkte zur Verschlüsselung von Festplatten oder Verzeichnissen an, die auf Embedded Security Subsystem (ESS) bauen. Auch Verisign, Checkpoint, Cisco und andere benutzen den TPM-Kryptochip.

Abbildung 2: Die Architektur des TCG Software Stack unterscheidet peinlich genau zwischen Kernel- und Usermodus. Darüber türmt sich ein extra Protokollstapel.

TPM für den Linux-Kernel

Neben der kommerziellen Client Security Software (CSS), die IBM zusammen mit dem TPM als ESS für Windows anbietet, hat Big Blue im Jahre 2003 die ersten Programmpakete für den Linux-Kernel 2.4 [5] im Internet veröffentlicht, deren Installation und Anwendung ebenfalls [3] beschreibt. Seit Oktober 2004 gibt es auch Pakete für den Kernel 2.6, die als Basis für den TPM-Gerätetreiber des offiziellen 2.6.12er Kernels vom Juni 2005 dienten.

Das neue Interface stellt einige generische Funktionen bereit, die herstellerabhängige Eigenschaften der einzelnen TPM-Chips abstrahieren. Die Kommunikation zwischen den Komponenten im Usermodus und der Hardware übernimmt das Kernelmodul »tpm.ko«. Für die herstellerspezifischen Dinge der Kryptochips zeichnen die TPM-Kernelmodule für National Semiconductor, Atmel und Infinion verantwortlich.

Trousers für den Usermodus

Der TCG Software Stack (TSS) ist eine Interface-Spezifikation, die dem Betriebssystem und den darauf laufenden Anwendungen per API die Funktionen des TPM bereitstellen, also solche, die den Speicher und die kryptographischen Module des TPM nicht direkt benötigen. Die Spezifikationen des TSS sind nahezu systemunabhängig, sehen aber vor, dass der jeweilige Prozessor zwischen Software im Kernel- und der im Usermodus unterscheidet. Der TPM-Gerätetreiber im Kernelmodus darf als einzige Komponente direkt mit dem TPM kommunizieren. Alle anderen gehören in den Usermodus (siehe Abbildung 2).

Programme, die TPM benötigen, müssen einen so genannten TCG Service Provider (TSP) nutzen. Jede Applikation bekommt einen eigenen TSP, der in ihrem Prozesskontext läuft. Die TSPs kommunizieren mit dem TSS Core Service (TCS) des Betriebssystems, der ihnen abstrahierte Funktionen bereitstellt. Zwischen dem TCS und dem TPM-Gerätetreiber befindet sich die TPM Device Driver Library (TDDL), das ist eine Abstraktionsschicht für die unterschiedlichen TPM-Implementierungen.

Die zu den Kerneltreibern passende Usermodus-Software entwickelt das Trousers-Projekt auf Sourceforge ([6], [7]). Trousers ist ein unter der CPL (Common Public License) stehender Open-Source-TSS gemäß Spezifikation 1.1. Das Projekt hat den TSS Core Service als Unix-Dienst (»tcsd«) und die TCG Service Provider als Shared Libraries implementiert.

Als TSS verwaltet Trousers zwei Arten persistenten Speichers:

• Den User Persistant Storage unter
  »/usr/local/var/lib/tpm/user.PID«. Seine Lebensdauer
  entspricht der Laufzeit der Anwendung, die ihn nutzt. Der TSP der
  Anwendung steuert den Speicher und löscht ihn, sobald sie sich
  beendet.
• Den System Persistant Storage unter
  »/usr/local/var/lib/tpm/system.data«. Trousers erzeugt
  den Speicher, wenn das TPM in den Besitz des Benutzers geht. Der
  Systemspeicher bleibt über Anwendungen, TCS-Dienst- und
  Computer-Neustarts hinweg erhalten. Der TCS verwaltet den Speicher;
  er löscht hier abgelegte Daten nur, wenn die betreffende
  Anwendung dies anweist.

TPM und Trousers zum Ausprobieren

Die folgende Installationsanleitung bezieht sich auf ein Fedora Core 4 mit Updates, lässt sich aber ohne Mühe auf andere Linux-Distributionen übertragen. Als Testrechner diente ein IBM Thinkpad T42p mit einem integrierten TPM der Firma Atmel. Voraussetzung ist ein Kernel (hier ein 2.6.15.3er Kernel von [www.kernel.org]) mit TPM-Support. Es bietet sich an, die benötigten Treiber, zu finden unter »Character Devices«, als Module einzubinden (Abbildung 3). Der TPM-Hardwaresupport und mindestens ein zum TPM-Hersteller passendes TPM-Interface sind zwingend.

Abbildung 3: Beim Kernel-»make menuconfig« sind der TPM-Hardwaresupport und ein zur Hardware passendes TPM-Interface zwingend.

Nach dem Übersetzen, Installieren und Neustart stehen die neuen Module bereit. Root lädt zunächst das Hauptmodul »tpm.ko« und dann das Interfacemodul, hier »tpm_atmel.ko«. Letzteres legt selbst das passende Character-Device »/dev/tpm0« an (siehe Abbildung 4). Der nächste Schritt ist das Übersetzen und Installieren des Trousers-Projekts. Folgende Schritte sind notwendig: Entpacken der Quellen, Wechseln ins Projektverzeichnis und:

sh bootstrap.sh
./configure
make
make install

Normalerweise installiert sich Trousers nach »/usr/local«, was wie üblich der Configure-Parameter »–prefix=/ Beliebiger_Pfad« ändern kann. Eventuell bedarf es noch des Eintrags »/usr/local/lib« in der Datei »/etc/ld.so.conf«. Dann ruft Root »ldconfig« auf, damit die Program- me die Bibliotheken finden.

Der Usermodus-Dienst »tscd« (siehe Abbildung 5) ist der einzige Kommunikationsweg zum TPM-Gerätetreiber. Er sollte beim Booten starten und von da an sowohl lokale als auch Remote-Anfragen von TSPs an das TPM handhaben. Der Dienst ist auch von außen erreichbar, sobald man in der Konfigurationsdatei »tscd.conf« einen Port angibt. Darum ist es keine gute Idee, ihn mit Root-Rechten laufen zu lassen, besser ist der Benutzer »tss«, den die Installation automatisch anlegt. Auch ist auf die korrekten Rechte von »/dev/tpm0« zu achten.

Abbildung 4: Zwischendurch ein spannender Augenblick: das große Kernelmodule-Laden.

Nachdem der TCS-Dienst konfiguriert und gestartet ist, geht\’s an die Installation der TPM-Tools. Die von den Autoren getestete Version 1.2.2 ließ sich anfänglich wegen Konflikten mit »gettextize« nicht übersetzen. Ein kleiner Workaround (gefunden in der Gentoo-Distribution) im Verzeichnis der entpackten Quellen beseitigt das Problem:

sed -i '/^gettextize/d' ./bootstrap.sh
sed -i '/<po>/d' Makefile.am
sed -i -e '/AM_GNU_GETTEXT/d' -e ':po/Makefile.in:d' configure.in

Danach übersetzen und installieren folgende Befehle das Paket:

sh ./bootstrap.sh
./configure --disable-nls # ein Workaround
make
make install

Anschließend funktionieren die in Tabelle 1 aufgelisteten Befehle. Bei gestartetem »tcsd« liefert die Eingabe von »tpm_version« als Root nun eine Ausgabe wie diese:

TPM Version:         01010006
Manufacturer Info:   41544d4c

Noch kann der Besitzer mit seinem TPM aber nicht viel anfangen. Vor dem Gebrauch muss er die TCG-Plattform und das TPM aktivieren sowie explizit den Besitz mit »tpm_takeownership« übernehmen (siehe Tabelle 1 und [3]). Der Befehl erfragt das Benutzerpasswort (Owner Authorization Secret) und das Passwort für den SRK, der bei dem Prozess entsteht (Abbildung 6). In Kenntnis der Passwörter läuft dann der Zugriff auf Funktionen und Inhalte des TPM wie auch auf die Befehle der TPM-Tools.

Weitere Projekte

Während sich die öffentliche Diskussion hauptsächlich mit den Gefahren von Trusted Computing und den möglichen Features des nächsten Microsoft-Betriebssystems beschäftigte, sind andernorts die ersten Demonstrationsapplikationen und Forschungsprojekte entstanden. Das gilt insbesondere für Open Source Software und Linux. Einige dieser Ansätze seien hier kurz vorgestellt.

Tcg Linux: TPM-based Linux Runtime Attestation

Aus den Forschungslabors von IBM stammt das Projekt Tcg Linux [8], das mittels TPM nicht nur die Integrität des Bootprozesses, sondern auch die aller in den Speicher geladener Programme und Konfigurationsdateien mit Hashwerten erfasst. Einem anfragenden System, das eine Datenbank mit allen Hashes enthält, kann Tcg Linux eine bestimmte Boot- und Software-Zusammenstellung und -konfiguration attestieren. Die Forscher haben bislang noch keinen Quellcode veröffentlicht. Die Gruppe kündigt auf ihrer Webseite an, Tcg Linux als Linux Security Modul mit Anbindung an SE-Linux realisieren zu wollen.

Enforcer LSM

Das Projekt Enforcer [9] ist als Linux Security Module (LSM) entworfen und nutzt die Open-Source-Treiber von IBM zum Ansprechen des TPMs. Die aktuelle Quellcode-Release stammt vom April 2004. Das Modul will Manipulationen am Dateisystem verhindern.

Enforcer führt eine Datenbank mit SHA-Werten sensibler Dateien. Bei jedem Datei-Aufruf berechnet das Modul den Hash neu und gleicht ihn mit der Datenbank ab. Um Manipulationen der Datenbank zu verhindern, ist sie signiert und versiegelt. Enforcer liefert auch einen Lilo-Bootloader, der die Integrität des Kernelimage und des Master Boot Record prüft und in die PCRs 8 und 9 speichert.

Trusted Grub

Sichereres Booten ist wichtig für Trusted Computing. Man versucht sicherzustellen, dass in der gesamten Kette vom Systemstart bis zur vertrauenswürdigen Applikation kein Glied der Kette (Chain of trust) kompromittiert wird.

Während des Bootprozesses muss ein geeignetes System unter anderem die Integrität des Bootloaders, des Kernels und seiner Module, der Gerätetreiber und aller Konfigurationsdateien überprüfen. Trusted Grub [10] liegt im Quellcode (aktuell: Version 0.8.1) unter der GPL vor und erweitert den Bootloader Grub um genau die beschriebenen Features.

Perseus

Die Ideen zu Perseus [11] entstand bereits 1999 an der Universität des Saarlandes. Zurzeit führt das European Competence Centre for IT Security (Eurobits) der Ruhr-Universität Bochum das Projekt weiter. Perseus ist eine Security-Softwareschicht, die auf dem L4-Mikrokernel aufbaut und zum Schutz von sicherheitsrelevanten Anwendungen und sensiblen Daten alle kritischen Hardware-Ressourcen einschließlich TPM kontrolliert.

Der L4-Mikrokernel besteht aus rund 7000 Zeilen Code: Zusammen mit Diensten und wichtigen Anwendungen sollen maximal 100000 Zeilen Code zusammenkommen. Damit bleibt die Codebasis von Perseus im Vergleich zu Betriebssystemen wie Linux oder Windows überschaubar – und damit überprüfbar.

European Multilateral Secure Computing Base

Mit der European Multilateral Secure Computing Base (EMSBC, [12], [13]) liegt der Vorschlag für eine offene Computing Platform vor, die es erlauben soll, herkömmliche Betriebssysteme mit einer Security-Softwareschicht wie Perseus und TPM-Hardware zu kombinieren. Neben einer schlanken sowie offenen und damit überprüfbaren Architektur bietet dieser Ansatz den Vorteil, keine Eingriffe am Betriebssystem selbst vornehmen zu müssen. Vorhandene Applikationen bleiben voraussichtlich lauffähig. Verwendbaren Quellcode gibt es noch nicht.

Open Trusted Computing

Das europäische Projekt Open TC [14] ist ein Zusammenschluss von zurzeit 23 Partnern aus Wissenschaft und Industrie. Open TC hat als Ziel, auf Basis offener Software ein sicheres Betriebssystem zu entwickeln. Dabei sollen sowohl Standard-PCs als auch mobile und eingebettete Geräte bei der Entwicklung Berücksichtigung finden. Neben dem Betriebssystem an sich sind auch die Entwicklung der entsprechenden Softwareprotokolle sowie exemplarischer Anwendungen Ziele des Projekts.

Wachsamkeit nötig

Für eine fundierte Bewertung der Auswirkungen von Trusted Computing auf die IT-Sicherheit existiert auch nach Jahren nicht genug einsatzfähige Software. Andererseits tauchen in der letzten Zeit vermehrt Projekte und Prototypen von Software zusammen mit Quellcode und entsprechender Dokumentation auf, die der interessieren Allgemeinheit frei zugänglich sind. Ob dies dazu ausreichen wird, hinreichend viel Vertrauen zu erzeugen und Endbenutzer quelloffener Betriebssysteme zu Trusted Computing zu bewegen, bleibt abzuwarten.

Klug ist es daher sicherlich, die Initiativen der Anbieter im Auge zu behalten und deren Reaktion auf kritische Vorschläge von der Open-Source-Community und Verbraucherschutzorganisationen zu bewerten. Trotz einer Reihe von quelloffenen Ansätzen ist damit zu rechnen, dass sich proprietäre Lösungen durchsetzen, falls nicht bald eine umfassende, freie und akzeptable Trusted-Computing-Implementierung auftaucht. Im schlimmsten Fall bilden sich zwei unterschiedliche Welten heraus, zwischen denen der Informationsaustausch wahrscheinlich noch schwerer als heute laufen wird. (jk)