DRM und Trusted Computing

Inhaltliche Beschreibung

Grundbestandteile der TC-Architektur sind
Memory Curtaining
Secure Input and Output
Sealed Storage
Remote Attestation – ermöglicht Dienste-Anbietern anzufragen, was gerade auf dem jeweiligen Computer läuft.

Microsoft wird TCG-Spezifikation 1.2 für Longhorn (das nächste Betriebssystem) nutzen. MS kontrolliert 90% des OS-Marktes. TCG and Palladium sollten daher nicht getrennt diskutiert werden. Auch, weil TCG zu Problemen für Freie und Open Source Software führt.
MS will eine automatische Updatefunktion für das nächste Windows (Heise Newsticker, 19.8.2003). Dazu: Weis / Stefan Lucks – all your keybit are belong to us – the truth about blackbox cryptography, Vortrag auf der SANE 2002, Maastricht (der Titel ist als Postscript-Datei erhältlich unter www.nluug.nl/events/sane2002/papers/ WeisLucksAllYourKeybit.ps).
Die Gefahren bei TC sind unter anderem, dass es natürlich nicht völlig auszuschließen ist, dass ein Chip-Hersteller vom Standard abweicht. Das müsse irgendwie kontrolliert werden. Aber auch die Schlüssel werden außerhalb des Geräts erzeugt (aus Kostengründen) – dabei könnten sie kopiert werden, d.h. Hardware-Überwachung allein reicht nicht aus.
Wie sieht es aus mit einer Back Door? (Heise Newsticker, 9.8.2003: „NSA will gegen Hintertüren vorgehen“) Es stellt sich das Problem der „untrustworthy hardware“. MS habe dazu gesagt, die Firma werde „never voluntary“ („niemals freiwillig“) eine Hintertür einbauen. Wie aber sieht es aus, wenn der US-Gesetzgeber sie dazu zwingt? Auf der TC-Konferenz des BSI könne man sich unter www.webpk.de/bmwa/willkommen.php die eine Minute Schweigen ansehen/hören, die folgte, als einer der Industrievertreter gefragt wurde, wie es mit Hintertüren aussieht.
Wenn man sich das „real world key management“ von MS ansieht, stellt man fest, dass im Jahr 2001 ein MS server certificate ausgelaufen war (für MSN und Passport), außerdem MS immer noch auf der Suche sei nach einem „verlorenen“ Zertifikat, mit dem nun Unbefugte Hardware zertifizieren können. Eine Fehlerfreiheit kann nicht garantiert werden. Außerdem ist die Patentlage nicht geklärt – das ergibt Probleme für offene Software.
Daher wird die volle Kontrolle der Computerbesitzer über die Schlüssel gefordert. Als Lösung biete sich ein „Owner Override“ an. Dabei kann der Besitzer des Rechners (der nicht unbedingt gleichzusetzen ist mit dem Nutzer – etwa in Firmen – bei einer remote attestation „falsche“ Angaben über den Status des Computers und der darauf laufenden Programme machen.
TC ermöglicht DRM, Lock-in, Migration and backup restrictions, forced upgrades, application specific spyware und kann reverse engineering verhindern helfen.

Eine Art Fazit:
Third party uncertainty about your software environment is normally a feature, not a bug (Beispiel: Samba).
Stefan Bechtold erwidert, dass eine Owner Override-Funktion die Funktionalität einer TC-Architektur einengt. Z. B. sei das Versenden von Dokumenten über einen sicheren Pfad mit Owner Override nicht mehr sicher. In allen Umgebungen, in denen ich dem Nutzer nicht trauen kann, würden TC dann nicht mehr funktionieren, etwa bei verteilten Applikationen.
Aus der juristischen Perspektive sei eine Regulierung wünschenswert, die dafür sorgt, dass MS solche Kontrolle nicht ausüben darf – etwa aus wettbewerbsrechtlichen Gründen.
Weis erwidert, dass bei verteilten Anwendungen die Ergebnisse ohnehin verifiziert werden müssen, TC würde keinen relevanten Vorteil bringen.