Trusted Computing: Stand der Dinge

Ordnungsmerkmale

erschienen in: <kes> 2004^#4, Seite 20

Zusammenfassung: Fundierte Aussagen über die Sicherheitsimplikationen des Trusted Computing sind weiterhin schwierig. Hinter den Kulissen haben sich allerdings in den letzten Monaten einige Veränderungen an den Standards und Plänen der beteiligten Unternehmen und Konsortien ergeben.

Autor: Von Wilhelm Dolle, Berlin

Im Jahre 1999 trat mit der Trusted Computing Platform Alliance (TCPA) unter der Führung von Compaq, HP, IBM, Intel und Microsoft eine industrielle Interessensgruppe an und versprach mit einem fest in die Rechner integriertem Kryptographie-Chip eine signifikante Erhöhung der Sicherheit des gesamten Computersystems zu erreichen. Dieses Trusted Computing sollte vereinfacht gesagt Programme und Daten gegen Modifikationen und Missbrauch schützen und ermöglichen, Soft- und Hardware als "vertrauenswürdig" zu erkennen.

Auf die ersten von der TCPA im Jahr 2000 veröffentlichten Spezifikationen folgte erst Mitte 2002 eine nennenswert breite und öffentliche Diskussion, als Microsoft mit Palladium eine Sicherheitserweiterung des für 2006 angekündigten Windows-Betriebssystems mit Codenamen "Longhorn" ankündigte. Im Juli 2003 veranstaltete sogar das Bundesministerium für Wirtschaft und Arbeit (BMWA) angesichts der fortschreitenden Debatte ein eigenes Trusted Computing Symposium [4].

Kritiker haben Microsoft und der TCPA vor allem zum Vorwurf gemacht, mit ihrem Sicherheitskonzept als primäres Ziel die Verankerung der digitalen Rechteverwaltung (Digital Rights Management, DRM) voranzutreiben [3]. Im April 2003 hat die von AMD, HP, Intel und Microsoft gegründete Tusted Computing Group (TCG) [1] die Rechtsnachfolge und die Spezifikationen der TCPA übernommen. Mit Handys, Smart-Phones, Set-Top-Boxen und PDAs wurde die Palette der Zielplattformen deutlich erweitert. Und Microsoft hat inzwischen sein "Palladium" in Next Generation Secure Computing Base (NGSCB, [2]) umgetauft (vgl. Kasten).

Status Quo

Die TCG gliedert ihre Spezifikationen in einen Soft- und Hardwareteil. Für die Software ist zurzeit die TCG Software Stack Specification in der Version 1.1 vom September 2003 aktuell. Das so genannte Trusted Platform Module (TPM), also der Kryptogaphie-Chip selbst, wird in der über 600 Seiten starken Version 1.2 der dreiteiligen TCG TPM Specification vom November 2003 beschrieben.

Auch wenn die komplette Umsetzung der Spezifikationen noch deutlich in der Zukunft liegt, so gibt es seit geraumer Zeit bereits Geräte, die mit TPM-Chips ausgestattet sind, sowie einiges an verfügbarer Software. So liefern zum Beispiel IBM und HP Systeme mit TPM aus und verschiedene Sicherheits-Software-Anbieter wie Verisign, Check Point, Cisco und Utimaco unterstützen bereits die Kryptochips.

Neben diesen kommerziellen Anbietern gibt es auch eine kleine Anzahl an Forschungs- und Entwicklungsprojekten, die zum Teil frei verwendbare Quellen und Anwendungen zur Verfügung stellen: IBM hat beispielsweise eine Login-Prozedur und rudimentäre Verschlüsselungswerkzeuge für Windows sowie ein Experimentalpaket samt Quellcode für Linux im Internet veröffentlicht [5] (s. a. [6]). Beispiele aus dem universitären Bereich sind die Projekte Enforcer Linux Security Module [7] und PERSEUS [8].

Zurzeit basiert die verfügbare TPM-Hardware noch auf Version 1.1b der TCG-Spezifikationen. Nach Aussage der TCG werden heute bereits Millionen von 1.1b kompatiblen TPM-Chips hergestellt (z. B. von Infineon [11]). Obwohl die 1.2er-Spezifikation vorliegt, dürfte es noch einige Zeit dauern, bis die Produktion umgestellt wird. Das TPM kann man sich als eine Art auf dem Motherboard fest verlötete Smartcard vorstellen (vgl. Abb. 1): In einem typischen TPM steckt ein 8-Bit-RISC-Prozessor mit 33 MHz Takt, der für eine 2048-Bit-RSA-Berechnung etwa eine halbe Sekunde benötigt. Aus dieser geringen Performance ist ersichtlich, dass der Chip auf keinen Fall als genereller Kryptobeschleuniger fungieren kann und nicht für den Durchsatz großer Datenmengen geeignet ist.

Das TPM ist heute noch als separater Baustein realisiert, könnte aber nach Angaben von Herstellern bald auch in die CPU integriert werden. Dadurch entfiele dann auch die Möglichkeit, die Daten bei der Übertragung zum Prozessor über den Low-Pin-Count-Bus (LPC) abzuhören. Kritiker sehen durch die Integration die Wahlfreiheit der Anwender weiter eingeschränkt.

Abbildung 1: Motherboard-Architektur mit Trusted Platform Module (TPM)

Sicherheitsgewinn

Um die Herausforderungen der IT-Sicherheit zu lösen, liegt es nahe, wichtige Funktionen in manipulationssicherer Hardware zu realisieren, beispielsweise im TPM. Diese Hardware dient als Fundament, auf dem Sicherheitssoftware und Betriebssystem aufbauen können. Die notwendigen Funktionen sind vor allem sicherer Speicher und kyptographische Verfahren, die eine wichtige Rolle bei der Integritätsprüfung von Hard- und Software(-Signaturen) oder bei der Ver- und Entschlüsselung sensitiver Inhalte spielen. Ein TPM kann brauchbare Zufallszahlen produzieren, Schlüssel generieren und geschützt abspeichern, digitale Signaturen erzeugen und intern Ver- und Entschlüsselung durchführen (den schematischen Aufbau eines TPM zeigt Abb. 2).

Abbildung 2: Schematischer Aufbau eines aktuellen Trusted Platform Modules (TPM – ACE steht für Asymmetric Crypto Engine, RNG für Random Number Generator). Die Firmware des Systems SLD 9630 TT1.1 von Infineon residiert beispielsweise in 48 kByte updatefähigem EEPROM.

Mithilfe des TPMs und einer entsprechenden Anwendung beziehungsweise eines geeigneten Betriebssystems sollen gemäß TCG die folgenden vier Punkte die Grundpfeiler für ein vertrauenswürdiges System bilden:

• Sicherer Hardwarespeicher für kryptographische Schlüssel,
• Unterstützung eines sicheren Bootvorgangs,
• Versiegelung von Daten (Sealing),
• Beglaubigung der Plattform (Attestation).

Beim Bootvorgang werden Hash-Werte von Systemkomponenten in speziellen Platform Configuration Registers (PCRs) des TPM gespeichert. Solche Systemkomponenten können beispielsweise das BIOS und seine Optionen, angeschlossene Hardware, der Boot-Loader des Systems oder Teile des Betriebssystems selbst (Kernel) sein. Dabei zeichnet das TPM diese Werte nur auf, greift aber nicht aktiv in den Bootprozess ein. Die 20 Byte großen Speicherstellen für die PCRs entsprechen der Länge eines SHA-1-Hash-Werts.

Beim Versiegeln (Sealing) von Daten werden diese durch Verschlüsselung an eine, durch den aktuellen Inhalt der PCRs repräsentierte, Systemkonfiguration gebunden. Das TPM verschlüsselt die Daten unter Berücksichtigung der angegebenen Register; zusätzlich kann man auch noch einen Autorisierungscode angeben. Ein Dechiffrieren ist nur möglich, wenn neben dem Autorisierungscode auch die aktuellen Werte in den Registern mit den urspünglich benutzten übereinstimmen. Änderungen an der Systemkonfiguration verhindern also, dass Daten entschlüsselt werden, für die eine bestimmte Systemumgebung Voraussetzung sein soll (z. B. aktivierte Schutzsoftware). Für den Fall von Defekten des TPM oder anderer (einbezogener) Komponenten muss nach Aussagen der TCG die Anwendung, welche die Sealing-Funktion nutzt, selbst dafür sorgen, dass die Daten nicht endgültig verloren sind.

Bei der Beglaubigung der Plattform soll einem Kommunikationspartner gegenüber nachgewiesen werden, dass auf dem anfragenden System wirklich ein registriertes TPM aktiviert ist oder eine bestimmte Hard-/Softwarekonfiguration vorliegt. Hierfür wird der öffentliche Teil des so genannten Endorsement Key benutzt. Der zugehörige geheime Schlüssel verlässt das TPM niemals: Das Schlüsselpaar wird üblicherweise beim Herstellungsprozess in das TPM geschrieben und mit dem Master Key einer Zertifizierungsinstanz unterschrieben.

Dieses Verfahren legt nicht nur großes Vertrauen in diese Instanz, sondern ermöglicht es auch, Benutzerprofile zu erstellen, da der öffentliche Teil des Endorsement Key als eine Art Seriennummer anzusehen ist. Bis Version 1.1b der Spezifikationen war es nicht möglich, den Endorsement Key zu löschen oder zu ändern. Um seine Privatsphäre zu wahren, ist es allerdings möglich die Weitergabe zu deaktivieren – eine Plattform-Beglaubigung ist dann auf diesem Wege natürlich nicht mehr möglich.

Abbildung 3: Einbindung des TPM in die Betriebssystem- und Applikationsumgebung

Neues in Version 1.2

Der Endorsement Key und der Storage Root Key, der für die Verschlüsselung von weiteren Schlüsseln benutzt wird, haben zentrale Bedeutung für das TPM und sind als "Non-Migratable-Keys" konzipiert: Solche Schlüssel lassen sich zwar in das TPM schreiben, sich aber weder zu Backup-Zwecken sichern noch auf einen anderen Chip übertragen. Kritiker sehen in den nicht-migrierbaren Schlüsseln die Basis für hardwareunterstütztes DRM [9].

Die neue Spezifikation hat bezüglich der Kontrolle des Anwenders über die gespeicherten Schlüssel nun einige Zugeständnisse an die Kritiker gemacht. Ab Version 1.2 ist es Herstellern möglich, löschbare Endorsement Keys in den Chip zu integrieren. Der Besitzer kann den vorgegebenen Schlüssel dann löschen, für ungültig erklären und einen neuen erzeugen. Dadurch verliert er allerdings unwiederbringlich den Zugang zum ursprünglichen "Vertrauens-System" und muss gegebenenfalls ein eigenes System von Vertrauensbeziehungen aufbauen. Der Aufbau eines solchen Trust-Systems und aller zur Nutzung benötigten Zertifikate dürfte für Privatanwender aufgrund der Komplexität und damit verbundenen Kosten eher ausscheiden, könnte aber im Unternehmenseinsatz abgeschlossene, konzerneigene Systeme ermöglichen.

Ebenfalls neu ist die Möglichkeit zu einer so genannten Direct Anonymous Attestation (DAA, direkte anonyme Beglaubigung), auch Direct Proof genannt. Auch bei der DAA möchte ein Anbieter einer Dienstleistung feststellen, ob ein Kunde ein aktiviertes TPM benutzt. Im Gegensatz zur Platform Attestation soll der Kunde hier allerdings anonym bleiben können. Der Benutzer eines TPM-Systems kann hierzu für seine öffentliche Kommunikation beliebig viele anonyme Zertifikate ausstellen und bei jedem Kommunikationspartner ein anderes benutzen, um Querverbindungen und Benutzerprofile auszuschließen. Das von Intel, IBM und HP in die Spezifikationen eingebrachte Verfahren ist ein Zero-Knowledge-Protokoll: Mithilfe mathematischer Verfahren kann einem Anbieter von Dienstleistungen zugesichert werden, dass das verwendete anonyme Zertifikat tatsächlich aus einem gültigen TPM stammt, ohne dass er das eindeutige Zertifikat des TPM selbst kennen muss.

Die TCG ist auch auf die Kritik fehlender Hardwaresicherheit eingegangen und verlangt jetzt die Einhaltung von FIPS 140-2, einer Hardware-Sicherheits-Spezifikation des US-amerikanischen National Institute for Standards and Technology (NIST). Die Unterstützung von 192- und 256-Bit AES sowie Triple-DES sowie die Entscheidung bei der Auswahl von kryptographischen Algorithmen (weiterhin) auf standardisierte Verfahren wie RSA, SHA-1 und AES zu setzen, kann ebenso als positiv bewertet werden. Warum allerdings noch RSA-Schlüssellängen von 512, 768 und 1024 Bit unterstützt werden, obwohl die Spezifikationen selbst als minimale Schlüssellänge 2048 Bit angeben, bleibt ebenso offen wie die Frage, warum der Secure Hash Algorithm (SHA) nur mit 160 Bit angewandt wird (seit 2004 empfiehlt das BSI für ein "langfristiges Sicherheitsniveau" mindestens SHA-256).

Ob die TCG in Zukunft auf weitere Forderungen der Kritiker eingeht, bleibt zu beobachten. Ein interessanter Vorschlag wurde von der US-Bürgerrechtsorganisation Electronic Frontier Foundation (EFF) eingebracht: Mit dem so genannten Owner Override soll der Besitzer eines Rechners die Fernüberprüfung (Remote Attestation) des Systems deaktivieren oder beliebige Antworten dafür generieren können [10]. Mittels einer Fernüberprüfung können Informationen über den Zustand des Computersystems abgefragt werden, was unter anderem für hardwaregebundenes DRM dienlich wäre.

Fazit

Die zurzeit diskutierten Modelle laufen allesamt darauf hinaus, dass sie dem Endbenutzer mehr Sicherheit bieten können. In erster Linie wird aber nach wie vor der Rechner des Benutzers gegenüber Dritten beziehungsweise der Systemumgebung "vertrauenswürdig" gemacht. Für eine fundierte Bewertung der Auswirkungen von Trusted Computing auf die IT-Sicherheit existiert zum gegenwärtigen Zeitpunkt allerdings noch nicht genug einsatzfähige Software. Ebenso befinden sich die diskutierten Ansätze teilweise noch im reinen Planungsstadium und dürften sich vor der endgültigen Realisierung noch deutlich ändern.

Eine überwiegende Mehrheit der Experten spricht sich allerdings für die Idee aus, aktuelle Sicherheitsprobleme durch spezielle Hardware in Endgeräten zu lösen. Die Spezifikationen der TCG machen also einen Schritt in die richtige Richtung. Wichtige Problematiken wie der Schutz der Privatsphäre des Anwenders (bzw. der Informationshoheit eines Unternehmens), DRM, Zensur von Inhalten und Kontrolle des eigenen Rechners (bzw. Rechnerparks in Unternehmen) machen es dabei unumgänglich die Initiativen der Anbieter im Auge zu behalten. Gerade die Reaktion auf kritische Vorschläge von Verbraucherschutzorganisationen (etwa der Owner Override) könnten hier Auskünfte über die wahren Ziele geben.

Wilhelm Dolle (wilhelm.dolle@interactive-systems.de) ist als Mitglied der Geschäftsleitung der interActive Systems GmbH (iAS) für den Bereich Information Technology und IT-Security verantwortlich.

zurück zum Inhalt
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004^#4, Seite 20