Vertrauensfragen

IBMs Antworten auf die TCPA-Fragen des Chaos Computer Club

Trends & News | News

Im umstrittenen Thema Trusted Computing beobachten sich die Kontrahenten mittlerweile skeptisch aus Gräben heraus. Im März übergab der Chaos Computer Club (CCC) dem TCPA-Mitglied IBM auf der CeBIT eine Liste mit vier Forderungen, um den Standard für Anwender genießbar zu machen. Jetzt hat IBM geantwortet.

Mit dem angriffslustigen Slogan „Whom do we have to trust today?“ übergab der Chaos Computer Club auf der CeBIT am IBM-Stand eine Liste mit vier Forderungen an den TCPA-Standard [[#lit01 1]] (siehe [#kasten Kasten]).

Ende Mai hat IBM im Namen der TCG auf die Forderungen reagiert. Aus Termingründen konnte die formelle Übergabe der Antworten erst am 2. Juli am Rande des Berliner TCG-Symposiums (siehe c't 15/03 S. 20) stattfinden.

Die Reaktion von IBM/TCG fiel allerdings deutlich diplomatischer aus, als es skeptischen Anwendern lieb sein dürfte. Zudem orientiert sich die Stellungnahme formell eng am Forderungskatalog, der stellenweise missverständlich formuliert ist.

Im Einzelnen lauten die Forderungen des CCC:

  • Der Anwender muss die Kontrolle über alle Schlüssel im TPM erhalten.
  • Der TCPA-Chip darf keine verborgenen Kanäle enthalten, über den die geheimen Schlüssel des Anwenders nach außen gelangen können.
  • Alle im TPM gespeicherten Schlüssel müssen sich auch auf andere Rechner übertragen lassen.
  • Die für TCPA benötigten Zertifizierungsmechanismen müssen transparent gehandhabt werden.

Der CCC teilt die Befürchtungen zahlreicher Kritiker, dass der TCPA-Chip dem Anwender die Kontrolle über den PC entziehen könnte. Besondere Sorge gilt dem Umstand, dass jedes TPM kryptographische Schlüssel enthält, zu denen der Anwender keinen Zugang hat [[#lit02 2]].

Dieser Schlüssel kann theoretisch dazu verwendet werden, um Programme und Betriebssysteme an ein System binden. Auch per Digital Rights Management (DRM) gesicherte Dateien ließen sich an das TPM binden: Anhand der Eckdaten der Systemkonfiguration verschlüsselte Musikstücke oder Videos laufen dann nur noch auf exakt diesem System.

Die erste Forderung des CCC zielt genau auf diese Möglichkeit: Erhielte der Anwender tatsächlich Zugriff auf alle Schlüssel im TCPA-Chip, ließen sich keine TPM-geschützten DRM-Systeme mehr umsetzen. Digital Rights Management baut letztendlich darauf auf, dass der Anwender nur beschränkten Zugriff auf die lizenzierten Inhalte erhält.

Die Antwort von IBM beschränkt sich auf eine Beschreibung der Funktionsweise eines TPM, die einen wesentlichen Faktor herunterspielt. So weist sie darauf hin, dass die TCPA-Spezifikation eine komplette Kontrolle des Anwenders über alle Schlüssel vorsehe. Demnach bestimme das TPM weder über die Verwendung der Schlüssel, noch kann der Chip deren Entfernung verhindern.

Die einzigen Beschränkungen der Verwendung oder Verbreitung eines Schlüssels sei die Bindung des Schlüssels an ein Passwort oder an eine partielle Bootsequenz - wobei beide Optionen von einem Einverständnis des Benutzers ausgehen. Der einzige Schlüssel mit begrenzter Nutzung sei der Endorsement Key. Dieser weise das TPM lediglich als TCPA-konform aus und diene zum Anlegen von digitalen Signaturen, weshalb er nicht exportiert werden könne.

Statt klare Worte zu finden, versucht sich IBM mit dieser widersprüchlichen Antwort um die eigentliche Forderung des CCC herumzuwinden: Alle Schlüssel sind dem Anwender zugänglich, bis auf diesen einen. Hinzu kommt, dass IBM nur den Endorsement Key nennt, nicht aber den ebenfalls im TPM versiegelten Storage Root Key (SRK). Doch genau um diese Schlüssel dreht sich die Forderung des CCC.

In der Konzeptionsphase machte die TCPA auch keinen Hehl daraus, dass Digital Rights Management ein Ziel der Entwicklung war. Einige TCPA-Mitglieder geben mittlerweile zu, dass der eindeutige Schlüssel des TPM die Umgehung von DRM-Mechanismen effektiv verhindern werde. Dies bestätigte beispielsweise Dr. Herbert Cornelius von Intel Deutschland auf einer Konferenz - wenn auch nur auf Nachfrage. Microsoft räumt ebenfalls ein, dass man mit TCPA und dessen Windows-Umsetzung Palladium durchaus Filme schützen könne [[#lit03 3]].

Freilich gäbe es eine Möglichkeit, die Skeptiker zu beschwichtigen: Man könnte beispielsweise den Besitzer der TCPA-Plattform entscheiden lassen, ob er wirklich auf alle Schlüssel zugreifen will oder nicht. Im ersten Modus könnten DRM-Anwendungen einfach die Kooperation verweigern - dann wüsste der Nutzer aber zumindest, woran er ist. Bislang zeigt sich die TCPA in diesem Bereich aber nicht diskussionsbereit.

Der zweite Punkt des CCC fordert von der TCPA eine Art Garantie, dass die TPMs keine verborgenen Kanäle enthalten. Dieser Anspruch ist leicht verständlich: Wer mag schon seine geheimen Schlüssel einem Chip anvertrauen, der diese unbemerkt vom Anwender an Unbefugte verrät. Ein solches Leck kompromittiert nicht nur die Schlüssel, sondern auch alle mit ihnen gesicherten Dateien.

Bei „Covert Channels“ handelt es sich meist um Schnittstellen, die auf den ersten Blick nicht als Kommunikationskanäle erkennbar sind, sich aber zum Austausch von Informationen nutzen lassen. Entsprechend fällt auch die Reaktion von IBM aus.

An keiner Stelle sieht die Spezifikation vor, dass die im TCPA-Chip gespeicherten Schlüssel vom Anwender unbemerkt an Dritte übertragen werden. Dementsprechend enthalten TPMs auch keinen solchen Kanal - freilich könne man nicht komplett ausschließen, dass ein Hersteller einen von der Spezifikation abweichenden Chip baut.

Laut IBM ist dies unwahrscheinlich, da das TPM keine eigenen Ein- und Ausgabekanäle besitzt sowie nach den in IS15408 spezifizierten Common Criteria und dem Sicherheitsstandard FIPS 140-2 Level 2 zertifiziert werden muss. Es liege zudem nicht im Interesse der TPM-Hersteller, das Vertrauen in ihre Produkte durch solche Lücken zu unterwandern.

Diese Antwort wirkt deutlich ehrlicher als die zur ersten Forderung: Das Tückische an Covert Channels ist nun mal, dass diese zumeist nachträglich und häufig nur durch Zufall entdeckt werden. So kann die TCPA beziehungsweise TCG wenig mehr tun, als eine unabhängige Zertifizierung der Komponenten zu fördern - auch wenn sich die Frage stellt, ob eine relativ niedrige Zertifizierung nach EAL3 den Ansprüchen der TCPA gerecht wird.

In ihren ersten TCPA-Rechnern haben HP und IBM die TCPA-Chips auf Zusatzplatinen untergebracht, die auf das Mainboard gesteckt werden. Künftige TPMs werden vermutlich fest auf der Hauptplatine verlötet sein - schon allein aus Kostengründen.

Doch mit dem TPM werden dann auch die Schlüssel auf dem Mainboard fixiert, was deren Übertragung auf andere Rechner erschwert. Daher will der CCC im dritten Punkt seiner Forderungen darauf hinwirken, dass sich die Schlüssel in jedem Fall exportieren lassen.

Dies soll beispielsweise verhindern, dass ein Anwender im Fall eines Hardware-Defekts die Rechte an der Nutzung seiner speziell für seinen Rechner freigeschalteten Software verliert, nur weil er auf ein anderes System migrieren muss.

IBMs Antwort zu diesem Punkt wirkt zumindest bedingt beruhigend: Alle im TPM gespeicherten Schlüssel lassen sich jederzeit mit Wissen des Nutzers und/oder Administrators auf andere Rechner übertragen. Davon ausgenommen sind nur Schlüssel, die mit Einwilligung des Benutzers als „nicht übertragbar“ deklariert wurden oder deren Übertragung mit einem Passwort geschützt ist.

Auch von passwortgeschützten oder als nicht übertragbar markierten Schlüsseln lassen sich allerdings Backups anfertigen; die Beschränkung stellt lediglich sicher, dass stets nur eine Kopie aktiv ist. Allerdings räumt IBM auch ein, dass der Re-Import der Sicherheitskopie eines Schlüssels in ein neues TPM nur mit Hilfe des TPM-Herstellers funktioniere. Ein weiterer Schönheitsfehler in IBMs Antwort ist die Erklärung, dass es für eine Übertragung oder Sicherung des Endorsement Key keinen Grund gebe - daher sei dies auch nicht möglich.

Tatsächlich hat die TCPA mit Mechanismen zur Schlüsselübertragung die Forderungen des CCC bereits weitgehend umgesetzt. Jeder als „migratable“ definierte Schlüssel kann vom Besitzer der Plattform auf einen Rechner übertragen werden. Auch der Storage Root Key (SRK) kann gesichert werden, damit die Daten eines defekten TPM-Moduls nicht verloren gehen können.

Offen bleibt, wie viel eine Übertragung der Schlüssel von einem TPM auf ein neues Mainboard durch den TPM-Produzenten kosten wird. Bei einem defekten TPM ist der Benutzer dem Hersteller nämlich gänzlich ausgeliefert.

Mit der vierten Forderung begibt sich der CCC aufs Glatteis. Darin behaupten die Autoren unter anderem, dass ein grundlegender Mechanismus von TCPA auf Zertifikaten beruhe: Software solle durch kryptographische Zertifikate signiert werden, um von TCPA-Rechnern als vertrauenswürdig eingestuft zu werden. Der CCC stellt die Frage nach den Bedingungen dieser Zertifizierung, da deren Instanzen ihre Macht durch eine Verweigerung oder überhöhte Preise verweigern könnten.

Hier fragt man sich, ob der CCC die TCPA-Spezifikation gründlich genug gelesen hat. Der Standard sieht nämlich keinerlei Zertifizierung vor oder gar eine mit dieser Aufgabe bedachte Instanz.

Dementsprechend fällt auch IBMs Antwort aus: Da die TCPA-Spezifikation keine Zertifizierung von Software vorsehe, werde sie auch ihre Lauffähigkeit nicht einschränken. Zertifiziert werden nur das TPM und die Plattform - und dies nicht von der TCPA/TCG selbst, sondern von unabhängigen Institutionen. Deren Sicherheitstests sollen überprüfen, ob die kryptographischen Protokolle sauber implementiert sind.

Die Erwiderung überrascht wenig, da die Zertifizierung von Software-Komponenten nur im Rahmen eines Betriebssystems sinnvoll ist. Somit wären die Hersteller der Betriebssysteme für diese Forderung des CCC eine bessere Adresse gewesen - gut gemeint, aber schlecht gezielt.

Grundsätzlich ist ein konstruktiver Dialog zwischen dem Chaos Computer Club und der Trusted Computing Group durchaus positiv zu bewerten. Schade nur, dass beide Parteien die Chance verpasst haben, sich auf dem gemeinsamen Ziel zu sichereren und vertrauenswürdigen PCs näher zu kommen.

So lässt der CCC wesentliche Bereiche unberührt, wie etwa eine sichere Authentifizierung des Systems gegenüber dem Benutzer oder eine Option, die DRM-tauglichen Komponenten des TPM zu deaktivieren.

Ebenfalls unangesprochen bleibt das zentrale DRM-Problem [[#lit04 4]]: Solange DRM-Mechanismen, das Urheberschutzgesetz und die Privatsphäre des Anwenders nicht auf eine für alle Beteiligten akzeptable Weise unter einen Hut gebracht werden, wird Trusted Computing weiterhin mit Akzeptanzproblemen zu kämpfen haben. (ghi)

[1] Die Forderungen des CCC: https://www.ccc.de/digital-rights/forderungen

[2] Christian Stüble, Ahmad-Reza Sadeghi, Vertrauen ist gut, Sinn und Unsinn von TCPA und Palladium, c't 13/03, S. 232

[3] Gerald Himmelein, Erste Palladium-Vorführung auf der WinHEC 2003, c't 11/03, S. 18

[4] A.-R. Sadeghi, C. Stüble: Improving End-user Security and Trustworthiness of TCPA Platforms, Version 1.1

[#anfang Seitenanfang]


Die TCPA-Initiative hat sich der Verbesserung der PC-Sicherheit verschrieben. Dazu entwickelt die Organisation einen passiven Chip, der die Integrität eines Systems garantieren soll. Dieses Trusted Platform Module (TPM) dokumentiert die Systemkonfiguration in speziellen Registern als Hash-Werte (eine Art Prüfsummen). Anhand dieser Werte lassen sich Daten verschlüsseln und signieren, um sie vor unberechtigten Zugriffen zu schützen. Weiterhin speichert das TPM auch Schlüssel des Anwenders und generiert Zufallszahlen.

Der Weg eines TCPA-PC
Vergrößern
Der Weg eines TCPA-PC vom Chip bis zum einsatzfähigen System

Der Fokus der TCPA liegt auf der Authentifizierung einer Plattform - sei dies ein PC, ein Smartphone oder ein PDA (Personal Digital Assistant). Diese Authentifizierung findet in erster Linie gegenüber Dritten statt - etwa zur Remote Administration. Der Aufbau des TCPA-Chips unterscheidet sich prinzipiell nicht wesentlich von dem einer SmartCard, doch im Unterschied zu dieser ist das TPM fest an ein System gebunden und nicht an einen Anwender.

Die Mitgliederliste der TCPA umfasst mittlerweile 200 Mitglieder, die alle ein Vetorecht haben. Um den Standard schneller voranzutreiben, gründeten fünf TCPA-Mitglieder im April 2003 die Trusted Computing Group (TCG): AMD, Hewlett-Packard, IBM, Intel und Microsoft. Die TCG ist straffer organisiert und will noch in diesem Jahr den TCPA-Standard 1.2 verabschieden. Das TPM 1.2 legt den Grundstein für Microsofts Betriebssystemerweiterung Palladium. Das auch als NGSCB (Next Generation Secure Computing Base) bekannte Subsystem soll Bestandteil der nächsten Windows-Version werden (Codename „Longhorn“).

Kommentare