Trusted Computing. Peter Gerstbach, Andreas Tomek, 1 Einleitung 2

Transkript

1 Trusted Computing Peter Gerstbach, Andreas Tomek, Inhaltsverzeichnis 1 Einleitung 2 2 TCPA-TCG Motivation und Ziele Zukunftsaussichten Trusted Computing Architecture Basis-Komponenten TPM Integritätssicherung Identitätssicherung Sichere Speicherung Anwendungen und Szenarien IBM Integrierter Sicherheitschip und Sicherheitschiplibrary User-Verifizierungs-Manager (UVM) Public Key Infrastruktur (PKI) Administrations-Tool Datei und Ordnersicherheit VPN-Authentifizierung Zusammenfassung Palladium Aufbau Einsatz Ausblick Intel - La Grande Szenarien Bösartiger Code Diebstahl Mail Kritik DRM Black-/Whitelists Zertifizierung von Code Wahrheiten und Gerüchte Zusammenfassung 20 7 Glossar 21

2 Abstract Ziel dieser Arbeit ist es, einen grundlegenden Überblick über Trusted Computing zu bieten. Dazu wird zuerst auf die Organisationen eingegangen, welche sich um die Entwicklung und Einführung einer solchen Architektur bemühen. Danach werden die Spezifikationen der TCPA detailiert beschrieben und Umsetzungsstrategien dargestellt. Zu guter Letzt wird ein kritischer Blick in punkto Datenschutz auf diese Technologien geworfen. 1 Einleitung Sicherheit und Computer - das klingt für die meisten Menschen wie ein Paradoxon. In einer Zeit, in dem unsere Gesellschaft auf der einen Seite technologisch immer abhängiger und auf der Anderen Datenschutz und Integrität immer schwieriger wird, in einer Zeit wo mobile Anwender und E-Business enorme Probleme mit Datensicherheit und geschützter Übertragung von Informationen haben, wird der Ruf nach vertrauenswürdigen Technologien laut. Technologien, welche es einfach und doch effizient ermöglichen, Daten zu schützen und Personen zu identifizieren und damit das Vertrauen in die Technologie wiederherzustellen und zu festigen. Diese Arbeit beschäftigt sich genau mit diesem Thema, nämlich Trusted Computing und gibt einen Überblick über Ansätze und vorhandene Technologien, welche es bewerkstelligen (sollen) sichere Geschäfte im Internet abzuwickeln oder die Ausbreitung von Viren und Trojanern zu unterbinden. Wie bei jeder Zukunftsvision geht damit die Angst vor dem Unbekannten einher, die Angst vor der Überwachung und Kontrolle seitens des Staates oder multinationaler Konzerne. Deshalb muss ein besonderes Augenmerk auf diese Belange gerichtet werden und auch wenn nicht jede Kritik angebracht ist, so ist diese doch nötig um die Freiheit jedes Einzelnen zu wahren. Die folgende Arbeit soll dieses Für und Wider objektiv und kritisch beleuchten, Ansätze und Lösungen präsentieren und erklären und einen Überblick geben, welche Möglichkeiten sich in Zukunft bieten werden. Sollte eine Lösung möglich sein, welche es auch in Bezug auf Datenschutz schafft, die Anwender zu überzeugen, so wird die gesamte Branche, vor allem im Bereich des E-Commerce und E-Business, mit einem Wachstumsschub davon profitieren. Noch ein Wort zur Begriffsdefinition innerhalb der Arbeit. Die IT-Branche strotzt ja nur so von Akronymen und englischem Fachvokabular. Da eine Übersetzung bei den meisten Fachbegriffen nicht sinnvoll oder unmöglich ist, wird aber großteils darauf verzichtet. Die wichtigsten Begriffe sind im Glossar auf Seite 21 kurz auf Deutsch erklärt. 2

3 2 TCPA-TCG Am 11. Oktober 1999 wurde die Trusted Computing Platform Alliance (TCPA) durch die 5 Unternehmen Compaq, Hewlett-Packard, IBM, Intel und Microsoft gegründet. In der Pressemitteilung sprechen die Gründungsmitglieder von einer Industrie-Vereinigung, die das Vertrauen in Computer-Plattformen bei e-business Transaktionen erhöhen soll, indem Spezifikationen für sichere Technologien entwickelt werden sollen [13]. Weiters laden die Gründungsmitglieder andere Unternehmen ein, der TCPA beizutreten und an der Entwicklung neuer Spezifikationen mitzuwirken. Bis April 2003 sind knapp über 200 Unternehmen diesem Aufruf gefolgt. Abbildung 1: Logo der TCPA Am 8. April 2003 wurde neuerlich eine Pressemitteilung der 5 Gründungsmitglieder der TCPA herausgeben, indem die Gründung der Trusted Computing Group (TCG) bekanntgegeben wurde [11]. Die TCG soll die existierenden Spezifikationen der TCPA adaptieren und weiterentwickeln. Abbildung 2: Logo der TCG Es gibt Vermutungen, dass aufgrund der schwierigen Konsensfindung in der TCPA die neue Vereinigung TCG geschaffen wurde. In der TCPA mussten alle Entscheidungen über Spezifikationen einstimmig fallen, was bei über 200 Mitgliedern natürlich ein langwieriger Prozess sein kann. In der TCG reicht schon eine 2/3-Mehrheit, weiters gibt es drei verschiedene Levels von Mitgliedern mit unterschiedlichen Mitgliedszahlungen, Stimm- und Einsichtsrechten [3]. Der neuen Vereinigung sind schon zum Zeitpunkt der Presseerklärung, neben den 5 Gründungsmitgliedern, weitere 10 Mitglieder (Atmel, Infineon, National Semiconductor, Nokia, Philips, Phoenix Technologies, Sony, ST Microelectronics, VeriSign and Wave Systems) beigetreten. Momentan hat die Vereinigung 24 Mitglieder (Stand 9. Juni 2003). 2.1 Motivation und Ziele Die TCPA wurde gegründet, um besser sicherheitstechnische Aspekte in Computerplattformen und - geräten integrieren zu können. Die Anzahl und das Volumen von B2B Transaktionen im Internet werden in Zukunft weiterhin stark steigen. Die Spezifikationen der TCPA sollen das Vertrauen in e-business erhöhen und neue, bisher nicht dagewesene Möglichkeiten für Geschäfte im Internet erschließen. Besonders Unternehmen haben einen hohen Sicherheitsanspruch, die zugrunde liegende Technologie muss entwickelt werden, die Änderungen müssen durchgeführt und kontrolliert werden. Schon bisherige Standards wie IPSec, VPN, Smart Cards, S/MIME oder SSL haben die Sicherheit im Internet erhöht, allerdings gibt es noch keine Technologie und keine Spezifikation, wie man von Grund auf Sicherheit und Vertrauenswürdigkeit ermöglicht. Die Spezifikationen der TCPA sollen dieses Sicherheits-Fundament bilden, das aber auch vorhandene Technologien verwendet und zusätzlich auf Hardware-Ebene, beim BIOS und beim Betriebssystem die Sicherheit erhöht. Am 30. Jänner 2001 wurde die TCPA Spezifikation 1.0 veröffentlicht. Etwas mehr als ein Jahr später, im Mai 2002, wurde nach der Version 1.1a die momentan aktuelle Version 1.1b veröffentlicht, die auch erstmals im Betrieb eingesetzt wird (bei IBM, siehe Kapitel 4.1 auf Seite 11). 3

4 Seit der Gründung der TCG sind nun auch neue inhaltliche Ziele hinzugekommen. Neben dem Hauptziel der TCG, die letzte Spezifikation der TCPA 1.1b weiterzuführen, um möglichst bald die nächste Version (vermutlich 1.2) abschließen zu können, wird zusätzlich das Spektrum der Anwendungen auf Geräte wie Server, PDAs, digitale Telefone erweitert. Weiters soll die Gruppe als Industrie-Resource fungieren. Plattformspezifische Richtlinien sollen genauso entwickelt werden wie ein Logo Program, das ein gemeinsames Marketing ermöglichen soll und mit dem die Identifikation von Unternehmen und Kunden mit der Sicherheitsinitiative verbessern werden soll. 2.2 Zukunftsaussichten Derzeit ist die TCG gerade dabei, die existierenden Spezifikationen der TCPA zu adaptieren. Eine TSS- Spezifikation (TCG Software Stack) und eine erweiterte TPM-Spezifikation werden Ende des Jahres 2003 erwartet. Weiters wurde damit begonnen, Arbeitgruppen zu den Themen Server, PDA und Digitale Telefone zu bilden, die neue Spezifikationen entwickeln sollen. Noch ist aber kein genauer Zeitplan verfügbar [10]. Alle kommenden Spezifikationen der TCG werden offene Industrie-Standards, die unter der sogenannten RAND-Lizenz (reasonable and non-discriminatory) adaptiert werden können. 4

5 3 Trusted Computing Architecture In diesem Abschnitt wird die grundlegende Architektur einer Trusted Computing Archichtecture (TCA) anhand der Spezifikationen der TCPA[12] dargestellt. Ziel ist, einen Überblick über die grundlegenden Bestandteile und deren Anwendungsmöglichkeiten zu geben. 3.1 Basis-Komponenten Abbildung 3: Basis-Komponenten Die Basis jeder Architektur, die auf Sicherheit abzielt, ist es eine Vertrauensstellung zwischen zwei Partnern zu schaffen. Dabei spielen CA und Zertifikate eine entscheidende Rolle. Innerhalb der TCPA kommen folgende Zertifikate zum Einsatz[15]: Endorsement Cert. Dieses Zertifikat sichert zu, dass die Kernkomponente der TCPA, das TPM, echt ist und von einem geprüften Hersteller bereitgestellt wurde. Für die Signierung dieses Zertifikates wird das Endorsement-Key(EK)-Paar verwendet. Dieses hat eine Größe von 2048 Bits und wird entweder erst im Chip über ein Kommando gebildet, oder bei der Herstellung des TPM-Chips vom Hersteller importiert. In beiden Fällen wird der Private-Key niemals das TPM verlassen. Platform Cert. Das Plattform-Zertifikat wird vom Hersteller der Plattform ausgestellt und garantiert, dass alle Komponenten der TCPA-Spezifikation genügen und dass die Plattform ein TPM enthält. Somit ist durch dieses Zertifikat garantiert, dass die aktuelle Maschine eine Instanz von einer Trusted Platform ist. Conformance Cert. Hier wird versichert, dass das TPM-Design in dieser Plattform der TCPA- Spezifikation genügt und das TPM korrekt implementiert. Validation Cert. Hiermit wird sichergestellt, dass eine oder mehrere Teilkomponenten der TCPA- Spezifikation genügen. Weiters gibt es die sogenannten Roots of Trust. Diese untersten Komponenten der Plattform bilden das Fundament jeder Trusted Platform (TP). Zum Ersten wäre hier die Root of trust for measuring 5

6 integrity metrics (RTM), welche sich um das Messen und Aufzeichnen von bestimmten sicherheitsrelevanten Zuständen kümmert und diese dann im TPM ablegt. Das Trusted Platform Module bildet die beiden anderen Roots of Trust ab, nämlich jene, die sich um das Speichern (RTS) und das Wiedergeben (RTR) von sicherheitsrelevanten Informationen kümmern. Natürlich handelt es sich bei all diesen Roots um eine Art von Prozessor, da ja Befehle ausgeführt und Werte berechnet werden müssen. Auf die PC-Plattform bezogen sind die RTR und die RTS im TPM integriert, jedoch wird die RTM auf der normalen PC-Hardware abgebildet um Kosten zu sparen. Dabei wird der Bios Code modifiziert und über digitale Signaturen vor böswilligen Änderungen geschützt. Besonders beachtenswert dabei ist aber, und das sollte man vor allem bei der Kritik nicht vergessen, dass es sich bei TCPA ausdrücklich um eine Opt-In Technologie handelt, die erst vom Anwender aktiviert werden muss. Ohne die Aktivierung werden zwar bestimmte sicherheitskritische Applikationen vielleicht nicht funktionieren, jedoch behält der Anwender die Kontrolle über diese Entscheidung. 3.2 TPM Abbildung 4: Logische Architektur des TPM[14] Um die Manipulation von Soft- und Hardware zu entdecken, muss ein System geschaffen werden, welches selber weder physisch noch softwaretechnisch manipulierbar ist, und so auf eine sichere Weise Refernzwerte des Hauptsystems speichern und verarbeiten kann. Diese Funktionalität wird im TPM vereinigt. Das TPM bildet, wie bereits erwähnt, das Herzstück jeder Implementierung einer TP und ist gleichzeitig die RTS und RTR. Es wird fest auf der Hardware verlötet und würde bei physichem Austausch sämtliche enthaltene Daten zerstören. Softwareseitig werden darin sowohl der Endorsement Key und die Attestion ID Keys(AIK) gespeichert, als auch andere Werte, auf die später eingegangen wird (siehe Abbildung 3). Wichtig für eine weite Verbreitung dieses Chips ist die Minimierung seiner Kosten. Das TPM bildet folgende Funktionen ab: Sichere, persistente Speicherung, des Endorsement Keys, welcher statistisch einzigartig für jedes TPM ist, sowie Speicherung einiger TPM relevanten Flags. Erstellung von RSA-Keys, mit einer Standardgrösse von 2048 Bits, jedoch sind auch andere Größen möglich. Diese Schlüssel können entweder für Signierung und Authentifizierung benutzt werden, oder für die Ver-/Ent-Schlüsselung von Daten, jedoch muss der Zweck des Keys bei seiner Erstellung angegeben werden. Es ist nicht spezifiziert wie lange die Erstellung eines Keys dauern darf/muss. Anonyme Identitäten, welche benutzt werden, um Daten mit anderen Plattformen auszutauschen. Die genauere Funktionsweise wird im Kapitel 3.4 beschrieben, wichtig dabei ist, dass ein AIK nur aussagt, dass die Daten von einer TP kommen, jedoch nicht von welcher. 6

7 Zufallszahlengenerierung, welche in jeder TPM vorhanden sein muss, jedoch herstellerspezisch implementiert werden kann. Dazu zählt auch die Freiheit, die Zufallszahlen nach einer FIPSzertifizierten Methode zu erstellen, was ausdrücklich gewünscht jedoch nicht verpflichtend ist. Die Erstellung von Zufallszahlen wird sowohl intern verwendet, kann aber auch von aussen angesprochen werden. PCRs. Grundsätzlich dienen PCR s um die aktuelle Konfiguration von Soft- und Hardware festzuhalten. Jedes TPM muss ein Minimum von 16 Platform Configuration Registers (PCR) haben, wobei circa die Hälfte davon von Hardwarewerten belegt werden. Ein PCR dient dazu eine Summe von Integritätstests zu speichern. Da jedoch sowohl die Grundkonfiguration, als auch jedes Update getrennt gespeichert werden müssen und dies bei beschränktem Speicher im TPM bald ein Ende finden würde, bedient man sich einer anderen Methode. Die TCPA-Lösung speichert nicht die einzelnen Werte, sondern die Sequenz von Werten. Dazu wird für jede Sequenz eine Repräsentation mit einer fixen Größe gewählt, welche sich bei jeder Modifikation ändert. In der aktuellen Version wird dies über eine sichere Hash Funktion (SHA) über die verketteten Werte (Alter Wert und neuer Wert) erzielt. (De)Codierung von RSA-Keys. Analog zu Erstellung von RSA-Keys müssen natürlich auch die Ver- und Entschlüsselung von Daten, sowie die Signierung möglich sein, wozu das TPM diese Funktionen bereitstellen muss. 3.3 Integritätssicherung Abbildung 5: Integritäts-Sicherung[14] Wie schon zuvor beschrieben misst die RTM Werte von bestimmten Zuständen der Plattform und speichert diese über einen PCR in der TPM. Jedoch bedient sich die RTM dazu nicht nur ihrer eigenen Messmethoden, sondern baut viel mehr eine Kette auf, indem es mit Software-Agents zusammenarbeit, deren Werte Sie vorher überprüft. Diese übernehmen dann die Aufgabe des Analysierens und Speicherns. 7

8 Gleichzeitig wird ein Log-File mit den Werten und der Reihenfolge, in der die Plattform überprüft wurde, gespeichert, welches dann herangezogen werden kann, vordefinierte Zustände zu überprüfen. Jeder Eintrag in diesem Log-File beinhaltet eine Beschreibung des Systemzustands, der überprüft wurde, und das dazugehörige PCR. Wenn die Werte im Log-File und in den PCRs des TCMs übereinstimmen, weiss man, dass das Log-File nicht verändert wurde. Nun kann man das Log-File für weitere Überprüfungen benutzen. Abbildung 5 zeigt den Ablauf eines authentifizierten Boot-Vorgangs auf einer TCPA konformen PC- Plattform. In diesem Fall ist die RTM der BIOS Boot Block (BBB), welcher sowohl seine eigene Integrität als auch die des restlichen BIOS kontrolliert. Dies wird dadurch erreicht, dass er die Werte überprüft und sie danach sowohl in ein Log-File schreibt, als auch einen Hash Wert davon im ersten PCR des TPMs ablegt. Der BBB übergibt dann die Kontrolle ans BIOS, welches optionale Werte überprüft und analog zum oben beschriebenen Vorgang einen Hash-Wert im zweiten PCR ablegt. Danach wird die Kontrolle an den Bootloader übergeben, welcher seine normale Funktionalität ausführt und nebenbei wieder seinen Zustand in Log-File und PCR #3 dokumentiert. Zu guter Letzt analysiert das Betriebssystem seinen Zustand und den Zustand system- und sicherheitsrelevanter Applikationen und speichert diese Werte in PCR #4. Auf diese Art und Weise wird eine Kette aufgebaut, in der ein Modul auf die Authentizität des Vorherigen aufbaut, wobei die Anzahl der Übergänge in diesem Beispiel rein exemplarisch ist. Die zentrale Idee wird jedoch wiedergegeben, nämlich, dass eine Komponente die Nächste überprüft, wodurch der Wert gespeichert wird, bevor z.b. bösartiger Code in der nächsten Komponente diesen Wert verändern kann. Dadurch kann eine sichere Entdeckung von nichtgewollten Ereignissen garantiert werden. 3.4 Identitätssicherung Ein wichtiger Bereich ist natürlich das Überprüfen einer Identität in Bezug auf eine TP. Um zu gewährleisten, dass die Daten eines Users nicht direkt in Bezug zu einer bestimmten TP gebracht werden können, wählt sich der User eine öffentliche Zertifizierungsbehörde, der er vertraut. Diese ist die einzige Instanz die Userdaten in direkte Korrelation zu Plattformdaten bringen kann. Für alle anderen Kommunikationen wird nicht der Endorsement Key verwendet sondern ein AIK. Die Herstellung eines solchen wird in Abbildung 6 näher erläutert. Nachdem dieser Key nun zertifiziert wurde und im TPM gespeichert ist, kann er für den Austausch von Daten zwischen dem User und einer anderen Plattform herangezogen werden. Jemand, der nun zwecks Vertrauensstellung nähere Informationen zu der Plattform erlangen möchte, kann eine Anfrage an die Plattform senden. Wenn der User diese Anfrage beantworten will, beginnt ein Trusted Platform Agent (TPA) die benötigten Schritte einzuleiten. Zuerst schickt der TPA diese Aufforderung an das TPM und fordert die Signierung der Aufforderung und der aktuellen PCRs mit dem AIK. Als nächstes holt der TPA das Log-File und die relevanten Zertifikate und bündelt alles zusammen in einem Response, welchen er zurückschickt. Nun muss der Anfragesteller diese Antwort analysieren und wird dabei Folgendes untersuchen: Das Zertifikat der Privacy-CA, welches die Authentizität des AIK garantiert und so auch garantiert, dass diese Plattform eine Instanz einer TP ist. Die signierte Anfrage, darauf ob diese die tatsächliche Anfrage war oder nur eine Replikation einer Anderen ist. Die signierten PCRs, um zu erfahren, ob das System in dem gewünschten Zustand ist. Die Logs und die PCR-Zertifikate, um festzustellen, ob die Log-Files den aktuellen Zustand des Systems widerspiegeln und ob z.b. die Hardware tatsächlich diese ist, für die sie sich ausgibt und nicht modifiziert wurde. Nun hat der Anfragesteller genügend Informationen gesammelt um entscheiden zu können, ob er eine Transaktion mit der Plattform eingeht. In der Praxis werden wohl oft Betriebssystemversionen und Updates sowie Virendefinitionen relevant sein. Wichtig ist auch, dass sowohl vor, als auch nach der Transaktion, diese Prozedur durchgeführt werden muss, um alle Eventualitäten eines Angriffs abzudecken. 8

9 Abbildung 6: Erstellung eines AIK[15] 3.5 Sichere Speicherung Das TPM wurde so spezifiziert, dass es eine unbegrenzte Zahl von Geheimnissen, wie zum Beispiel Schlüssel oder andere Daten, schützen kann. Jedoch bietet es keine Funktionen diese Geheimnisse gegen Löschen zu schützen, oder sie zu benutzen, ausgenommen der Signierung von Daten innerhalb des TPM. Alle anderen Schlüssel müssen aus dem TPM exportiert werden und direkt auf der Plattform verarbeitet werden, um z.b. Dateien zu verschlüsseln und s zu signieren. Dafür, dass das TPM diese Funktionen nicht zur Verfügung stellt, gibt es folgende Gründe: Minimierung der Komplexität, welche mit einer Minimierung der Kosten einhergeht. Flexibilität, in Bezug auf z.b. Verschlüsselung, wobei Schlüssellängen an verschiedene Märkte angepasst werden, um den In- und Export von TCPA-Produkten zu ermöglichen. Schnelligkeit, da, nachdem die Plattform durch das TPM als sicher eingestuft wurde, der Hauptprozessor, welcher eine wesentlich bessere Performanz bei wesentlich geringeren Kosten bietet, für die Ver-/Entschlüsselung eingesetzt werden kann. Die Datenobjekte werden natürlich nicht im TPM gespeichert, sondern auf einem externen Medium, wo sie verschlüsselt abgelegt werden. Das TPM hat einen Storage Root Key (SRK), welcher asymmetrisch verschlüsselt ist und die Wurzel aller anderen Keys bildet, welche dann z.b. Daten signieren oder andere Schlüssel, wie z.b. symmetrische Schlüssel, schützen können. Grundsätzlich wird zwischen migrierbaren und nicht-migrierbaren Schlüsseln unterschieden. Bei migrierbaren Schlüsseln hat ein Dritter keine Möglichkeit zu überprüfen, wer auf die Daten zugegriffen hat und ob diese Zugriffe innerhalb eines TPMs erfolgten. Im Gegensatz dazu kann jeder einem nichtmigrierbaren Key vertrauen, da dieser nur innerhalb eines bestimmten TPMs gültig ist. Typische Daten, welche mit nicht-migrierbaren Schlüsseln versehen werden, sind z.b. Daten die nicht ausserhalb eines PC s zugänglich sein sollen, wie z.b. eine Patientendatenbank. Ein anderes Feature dieser Speichermethode ist, dass zusammen mit der Speicherung von Daten der Zustand einer Maschine, also ihre aktuellen PCRs, mitgespeichert werden kann. Damit kann sicherge- 9

10 Abbildung 7: Entschlüsselung einer Datei[14] stellt werden, dass eine Datei nur dann geöffnet werden kann, wenn sich die Plattform in einem vordefinierten Zustand befindet, der die Datensicherheit garantiert. Ein kurzes Beispiel dazu: 1. Der Schlüssel, mit dem die Daten verschlüsselt wurden, wird von einem normalen Speichermedium, wo er durch den TCPA-Speichermechanismus mit einem Storage-Key versehen gespeichert wurde, in das TPM geladen. 2. Das TPM überprüft, ob alle Parameter korrekt sind, d.h. ob eine korrekte Authorisierung gegeben ist und eventuelle PCRs mit den Gespeicherten übereinstimmen und sich das System damit in einem vertrauenswürdigen Zustand befindet. 3. Wenn all diese Parameter zutreffen, wird der verschlüsselte Datensatz, in diesem Fall ein symmetrischer Schlüssel, vom TCM freigegeben und an die aufrufende Applikation gesendet. 4. Mit diesem symmetrischen Key werden die eigentlichen Daten, welche separat oder vom selben Medium geholt wurden, entschlüsselt und können nun verwendet werden. Somit bietet dieser Ansatz auch eine Möglichkeit, symmetrische Schlüssel mit geringeren Schlüssellängen als ihre asymmetrischen Pendants besser zu schützen und die Weitergabe von Daten zu kontrollieren. 10

11 4 Anwendungen und Szenarien 4.1 IBM Die Firma IBM liefert als bisher einziges Unternehmen ihre Systeme der NetVista TM und Thinkpad TM Serie optional mit dem IBM Embedded Security SubSystem (ESS) aus, welches seit der Version 2.0 der TCPA- Spezifikation genügt. Das ESS ist eine Kombination aus TCPA-konformer Hardware und IBM-spezifischer Software, welches besonders dem kommerziellen Benutzer ein Plus an Sicherheit bieten soll. Hardwareseitiges Herzstück des Systems ist der ESS-Chip(TPM), welcher über ein integriertes EEPROM verfügt und über den System Management Bus (SMB), eine Untereinheit des Phillips-I2C-Interfaces, angesprochen wird. Softwareseitig kommt eine Fülle von Tools zum Einsatz, welche im folgenden Teil dargestellt werden. Diese Software ist beim Kauf der Plattform noch nicht installiert und muss gesondert, jedoch ohne Mehrkosten, über die IBM-Homepage bezogen werden, um das Ausspionieren oder Abändern der Schlüssel und Passwörter durch unauthorisierte Dritte zu verhindern. Die Kernkomponenten des ESS setzen sich aus folgenden Bestandteilen zusammen. Abbildung 8: IBM-ESS-Struktur Integrierter Sicherheitschip und Sicherheitschiplibrary Die Library greift über ein Interface auf den Sicherheitschip zu und kümmert sich vollständig um die Generierung, Speicherung und um alle anderen Management Operationen von Schlüsseln. So kann die Library alle im ESS Chip implementierten Funktionen höheren Applikationen transparent zur Verfügung stellen. Die Library ist eine statische Library, was bedingt, dass aufrufende Applikationen die Library direkt im Sourcecode verlinken müssen. Um dies zu umgehen werden Applikationen eher auf höhere Interfaces wie z.b.: CAPI oder PKCS#11 zugreifen User-Verifizierungs-Manager (UVM) Der UVM arbeitet als Middleware zwischen Applikationen, welche dadurch keine genaue Kenntnis des ESS brauchen, und den Authentifizierungsgeräten. Über ein Top-Level-Interface können Applikationen 11

12 auf den UVM zugreifen und ihn dazu veranlassen, Informationen sicher zu speichern und die damit verbundenen Sicherheitsabfragen durchzuführen. Auf der anderen Seite bietet ein Bottom-Level-Interface Hardwareherstellern die Möglichkeit ihre Authentifizierungsgeräte, wie z.b. einen Fingerabdruckscanner, über Treiber in den UVM einzubinden. Sollte kein Gerät angeschlossen sein, so bietet der UVM zumindest immer noch die Authentifizierung über Passwörter. Applikationen, die das Top-Level-Interface benutzen, sind zum Beispiel CAPI und PKCS#11, oder das Windows-Logon bzw. der ScreenSaver. Alle diese Applikationen profitieren von der starken Verschlüsselung und der Authentifizierung des Benutzers, welche durch einen der folgenden Mechanismen, oder einer beliebigen Kombination mehrerer, sichergestellt werden kann: Passwörter. Tokens, also Hardwarekomponenten, welche man mitnehmen kann, wie z.b. Sender, welche nur in einem gewissen Umkreis funktionieren, oder USB-Schlüssel. Biometrische Merkmale wie z.b.: Fingerabdrücke oder Retina-Scans. Diese Mechanismen erlauben auf einfache und doch sichere Weise ein Single-Logon für alle Applikationen über den UVM. Der UVM kann lokal oder über ein ganzes Netzwerk von einem Administrator so eingestellt werden, dass für verschiedene Operationen verschiedene Mechanismen angewendet werden müssen, z.b.: für das Einloggen im Intranet werden nur Passwörter verlangt. Für digitale Signierung von Dokumenten jedoch ist ein zusätzlicher Retinascan erforderlich Public Key Infrastruktur (PKI) Im Gegensatz zur Software-Basierten Implementierung einer PKI, bei der Schlüssel auf der Festplatte gespeichert werden und alle Ver- und Entschlüsselungsoperationen im Systemspeicher durchgeführt werden, wo sie von Hacker, Trojanern und Viren angegriffen und abgeändert werden können, werden im ESS all diese Operationen im TPM Chip erledigt. Um auf diese Funktionen zugreifen zu können, gibt es zwei beliebte Interfaces: CAPI, ist von Microsoft definiert und wird als der Standardverschlüsselungsservice für Microsoft Betriebssysteme und Applikationen verwendet. PKCS#11 wurde von der Firma RSA Data Security Inc. definiert und wird als Service für Netscape, Entrust und andere Produkte verwendet. Damit können Standard Applikationen wie MS Outlook, Internet Explorer, Mozilla usw. auf einfache Weise über das Interface, welches die Daten dann über UVM, Chip Support Library, TPM leitet, auf das TCM des ESS zugreifen und Operationen wie das Verschlüsseln einer durchführen Administrations-Tool Diese zentrale Anlaufstelle für alle Administrationsaufgaben in Bezug auf das ESS wird durch die Eingabe des ESS-Chip-Hardware-Passworts aktiviert und dient zu folgenden Aufgaben: Erstellung des Hardware-Key Paares, welches verwendet wird, um alle anderen Keys innerhalb des Systems zu kreieren. Auf den Hardware-Private-Key wird durch ein Admin-Passwort oder einen anderen Mechanismus zugegriffen (siehe UVM). Zurückstellen der fehlgeschlagenen Hardware-Private-Key Logons Erstellung des Plattform-Key Paares, welches mit dem private Key des Admins signiert wird um Authentizität zu wahren. Erstellung eines Key-Archives. Hierbei werden bestehende Plattform und User Keys mit dem Admin-Public-Key verschlüsselt und können so exportiert werden, jedoch nur mit dem Admin- Private-Key wieder entschlüsselt werden und können so nicht ausserhalb des Ursprungssystems in entschlüsselter Form vorliegen. 12

13 Wiederherstellung von Key-Archiven, welche durch Hardwaredefekte verloren gehen. Folgende Szenarien wären denkbar: Datenverlust einer Festplatte. In diesem Fall wären nur Plattform Keys und alle darüberliegenden Keys betroffen, welche dann bequem über ein Archiv importiert und wiederhergestellt werden können. Motherboarddefekt, wodurch natürlich auch der TPM Chip betroffen ist und nicht einfach ausgetauscht werden kann, da ein physischer Austausch des TPM Chips alle gespeicherten Daten zerstört. Da das Plattformschlüsselpaar ja zuvor mit dem Hardwareschlüsselpaar verschlüsselt wurde, muss es jetzt zu einem neuen Hardwarekeypaar migriert werden. Dazu muss das Plattformschlüsselpaar zuvor mit einem Recovery-Schlüsselpaar verschlüsselt worden sein, von dem üblicherweise der Administrator den privaten Key besitzt. Dieser entschlüsselt nun damit das Plattformschlüsselpaar und migriert es auf die neue Hardware. Alle anderen Schlüsselpaare bleiben dadurch gültig, da sie ja mit dem Plattformschlüsselpar verschlüsselt wurden. Erstellen von Usern. Der Administrator kann hier User erstellen, es wird ein Key-Paar erstellt und mit einem Default-Passwort verschlüsselt, welches der User beim ersten Logon ändern muss Datei und Ordnersicherheit Durch diese können Dateien und Ordner auf Basis des ESS mit einem symmetrischen 256-bit AES Schlüssel codiert werden. Dieses Feature ist besonders bei öffentlich zugänglichen, vernetzten, oder gestohlenen Plattformen von Nutzen, um sensible Daten zu sichern. Hinzu kommt, dass der Mechanismus leicht über ein Kontextmenü zu bedienen ist, welches auch verhindert, dass systemkritsche Daten verschlüsselt werden. Das System stützt sich dabei in Sachen Authentifizierung voll auf den Funkionsumfang des UVM VPN-Authentifizierung Die Implementierung des ESS erlaubt die Authentifizierung und Verschlüsselung von VPNs via RSA s SecurID Software und eliminiert so die Kosten und Risiken, die ein Hardwarezugang, wie z.b. ein USB Key, mit sich bringt. Die VPN Verschlüsselung wird wieder durch den UVM mit Benutzerdaten gespeist Zusammenfassung IBM bietet auf Basis von TCPA-konformer Hardware schon heute eine Plattform, welche viele Business- Anforderungen in punkto Sicherheit erfüllt und vereinfacht. Weiters hat sie den Vorteil moderne Authentifizierungsmechanismen zu unterstützen, welche vor allem mobile User und deren Daten gut und kostengünstig schützen können und nicht gleich ins Betriebssystem integriert werden muss. Dies eliminiert die Sorge der permanenten Kontrolle des Benutzers durch den Softwarekonzern in Verbindung mit DRM, da IBM den Funktionsumfang der Software klar definiert und abgrenzt. 4.2 Palladium Die Next-Generation Secure Computing Base (NGSCB) beschreibt die Technologie und die damit verbundenen Entwicklungen von Microsoft, eine vertrauenswürdige Computer-Umgebung zu erstellen. Durch NGSCB kann der Computer in eine Plattform umgewandelt werden, mit der sichere und vertrauenswürdige und mehrere Computer umspannende Operationen durchgeführt werden können, die auf einer Trust- Policy basieren und deren Integrität jederzeit überprüft werden kann. Die Technologie beinhaltet neue Soft- und Hardware und wird erstmals sichere Verarbeitung auf Windows Plattformen ermöglichen. Ursprünglich hieß die Technologie bei Microsoft Palladium. Dieser Name wurde allerdings Ende Jänner 2003 in Next-Generation Secure Computing Base (NGSCB) umbenannt, vermutlich weil der Name durch die Kontroverse um einige Teile des Sicherheitsprogramms befleckt worden ist [9]. Microsoftintern - und in dieser Arbeit - wird der Name Palladium aber weiterhin verwendet. 13

14 Weiters stellt sich die Frage wie Palladium/NGSCB mit der Sicherheitsarchitektur der TCPA zusammenhängt. Microsoft versucht klarzustellen, dass NGSCB keine Implementierung der TCPA Spezifikation ist, allerdings teilen beide Architekturen das gleiche Ziel und zwar sicherere und vetrauenswürdigere Computerplattformen zu schaffen. Das aktuelle Trusted Platform Module (TPM) 1.1b der TCPA erfüllt noch nicht alle für Microsoft erwünschten Funktionen, aber zukünftige Versionen des TPMs werden vermutlich die Hardware-Basis für NGSCB sein [6] Aufbau Die Palladium-Architektur erfordert sowohl neue Hardware als auch Software. Ein neues Betriebssystem- Modul, das Microsoft Nexus nennt, ermöglicht die sichere Kommunikation mit Anwendungen, Peripherie, primärem und sekundärem Speicher. Vier Kategorien von Sicherheitsmerkmalen werden dadurch geschaffen [7]: Geschützer Speicher. Die Speicher werden voneinander getrennt, sodass jede Nexus-unterstützende Anwendung sichergehen kann, dass der eigene Speicher nicht von einem anderen Programm oder Betriebbssystem geändert oder ausgelesen werden kann. Dies schützt vor Attacken wie einem Virus oder einem Trojanischen Pferd. Sichere Speicherung. Dies ermöglicht, dass Informationen verschlüsselt aufbewahrt werden können und eine Nexus-unterstützende Anwendung sichergehen kann, dass diese Informationen nur durch das Programm selbst oder durch andere vertrauenswürdige Programme gelesen werden können. Digitale Signatur. Die Möglichkeit Programmcode oder Daten digital zu signieren um dem Empfänger der Daten den Ursprung und die Authentizität beweisen zu können. Sichere Ein- und Ausgabe. Sichere Datenübertragung zwischen Keyboard und Maus zu Applikationen und sichere Übertragung von der Applikation zum Bildschirm. Die Plattform besteht weiters aus zwei Software-Elementen: Nexus. Das Betriebssystem-Modul in Microsoft Windows verwaltet die Funktionalität für die vertrauenswürdigen Operationen, wie Prozesserzeugung, Signatur-Handling, sowie Ver- und Entschlüsselung. Trusted Agents. Ein trusted Agent ist ein Programm oder Teil eines Programms oder eines Services, das im geschützten Speicher läuft. Dieser Agent ruft den Nexus für die sicherheitsrelevanten Operationen auf und kann somit die sicheren Funktionen nutzen. Besonders hervorzuheben ist, dass Einheiten wie User oder (EDV-)Abteilungen diese Trusted Agents unterschiedlich stark vertrauen können und somit jeder Trusted Agent bzw jede Einheit im System einen eigenen Bereich des Vertrauens hat. Der Nexus und die Prozesse, die den Nexus verwenden (Nexus Computing Agents, NCAs), laufen in einer eigenen Ausführungsumgebung, parallel zu den traditionellen Ausführungsumgebungen wie Kernel- und User-mode-Stacks. NGSCB erzeugt somit eine Umgebung, die neben dem Betriebssystem läuft, nicht unter ihm Einsatz Auf der Windows Hardware Engineering Conference (WinHEC) im Mai 2003 beschrieb Microsoft erstmals die konkreten Anforderungen und Vorteile der Sicherheitsinitiative Palladium. Auch ein erster Blick auf die Umsetzung in der Praxis fehlte nicht. In einer Live-Vorführung spielten drei Microsoft-Entwickler auf einer simulierten Palladium-Umgebung ein Szenario mit naivem Anwender, bösem Hacker und sicherheitsbewusstem Anwender durch [4]. 14

15 Abbildung 9: Die vier Quadranten bei NGSCB Zunächst fing sich der normale Anwender über ein Outlook-Attachment ein trojanisches Pferd ein. Daraufhin startete der Anwender ein Online-Banking-Programm. Dieses Programm speicherte zwar die Daten verschlüsselt, allerdings konnte der Hacker den Schlüssel im Arbeitsspeicher der Maschine finden und somit die Daten auslesen. Der nächste Angriff bestand darin, das Programm durch eine manipulierte Version zu ersetzen. Der sicherheitsbewusste Anwender startete auf derselben kompromittierten Plattform eine NGSCB-Variante des Banking-Programms die der Hacker aber nicht mehr auslesen konnte, da es sich im geschützen Speicherbereich des PCs befand. Beim zweiten Angriff überwachte der Hacker alle Eingaben des Anwenders in einem Chat-Programm mit einem Keylogger, sobald jedoch eine Tastatur mit gesicherter USB-Schnittstelle zum Einsatz kam, konnte der Trojaner an keine Daten mehr herankommen. Um die Konversation trotzdem mithören zu können, erstetzte der Hacker das Chat-Programm mit einer eigenen Version, das alle Verbindungen auf den eigenen Server umleitete. Durch Änderung am Code stimmte jedoch die gespeicherte Signatur nicht mehr überein und die Manipulation flog auf Ausblick Durch die Abschottung aller kritischen Applikationen in einem geschützen Speicherbereich wird Microsoft Windows gleichzeitig sicherer und bleibt jedoch auch abwärtskompatibel, was durch eine komplette Umstellung nicht mehr gegeben wäre: Bestehende Anwendungen können auch auf der neuen Plattform ohne jegliche Anpassung ausgeführt werden, was eine erfolgreiche Markteinführung sicher erleichtert. Laut Microsoft-Roadmap soll die kommende Windows-Version Longhorn inklusive NGSCB 2005 auf den Markt kommen. Bis dahin ist noch viel Überzeugungsarbeit zu leisten, dass die neuen Funktionen der Plattform die Kosten rechtfertigen. Weiters sind auch noch einige technische Probleme zu lösen [4]: Fernwartung. Sichere Ein- und Ausgabe gehört zu den Grundzielen von Palladium, wie damit Fernwartung ermöglicht werden soll, ist bis jetzt noch unklar. Behindertengerechte Nutzung. Auch hier entstehen Probleme durch die sichere Ein- und Ausgabe. Wie soll etwa Sprachausgabe für Sehbehinderte ermöglicht werden? Löschen von Daten. Palladium kann zwar die Manipulation von Daten aufdecken, allerdings ist noch unbekannt, ob das System auch das Löschen von Daten durch Viren verhindern kann. 15

16 Auslagerung des sicheren Speichers. Noch ist nicht entschieden, ob die erste Version von Palladium auch die Auslagerung von gesichertem Speicher unterstützen wird. Zertifizierung. Microsoft will auf keinen Fall eine Zertifizierungsstelle für Palladium-Anwendungen einrichten, nennt aber auch keine Alternativen. Spätestens bei flächendeckendem Einsatz wird Palladium nicht ohne Trust Center auskommen. 4.3 Intel - La Grande Neben Microsoft ist auch Intel eines der fünf Gründungsmitglieder der Trusted Computing Platform Alliance. Auf dem Intel Developer Forum im Herbst 2002 wurde erstmals Intels Umsetzung der Trusted Computing Architecture öffentlich gemacht. Unter dem Namen LaGrande Technologie (LT) soll mit Hilfe eines TPM-Chips eine vertrauenswürdige Computerumgebung ermöglicht werden [1]. Da Intel im Bereich Security schon einmal, durch die Einrichtung einer eindeutigen CPU-Seriennummer, ziemlich Schiffbruch erlitten hat, ist die neue Vorgehensweise deutlich vorsichtiger. Erst beim Intel Developer Forum im Frühjahr 2003 sind genauere Details der seit 1999 geplanten Strategie an die Öffentlichkeit gekommen [2]. Die erste Verwendung der LaGrande Technologie soll demnach in Intels zukünftigem Pentium-Flaggschiff Prescott eingebaut werden. Eine Seriennummer wird allerdings nicht mehr notwendig sein, dafür ist nämlich das Trusted Platform Module TPM zuständig. Da dieser Chip nicht in der CPU eingebaut sein wird, kann der Käufer durch die Wahl des Mainboards entscheiden, ob er das Sicherheits-Konzept von Intel verwenden möchte oder nicht. Weiters ist auch die De-/Aktivierung des TPMs per Jumper am Mainboard möglich. Intel sagt von sich aus, dass mit der LaGrande-Technologie weiter unten, nämlich direkt auf der Hardware-Ebene (durch Erweiterungen am Prozessor und am Chipsatz), die Sicherheit der Plattform verstärkt wird. Ähnlich wie bei Microsofts Palladium gibt es auch bei La Grande einen geschützten Bereich im Hauptspeicher (curtained memory). Auf diesen kann der CPU nur im Trusted Mode, unter Aufsicht des TPM zugreifen. Somit sind von außen keine Attacken, wie durch Viren, Trojaner oder durch den Busmaster (manipulierte Treiber) möglich. Die Speicherzugriffe selbst werden allerdings nicht verschlüsselt, das Sicherheitskonzept ist also nicht zur Abwehr von Hardware-Spähern gedacht, die physischen Zugriff auf das System haben. Im langfristigen Konzept von Intel gehören auch geschützte Zugriffe auf I/O- Geräte wie Tastatur, Maus und Grafikcontroller, wie dies auch schon Microsoft beschrieben hat. 4.4 Szenarien Bösartiger Code Es hat sich gezeigt, dass bösartiger Code (malicious code), wie Viren, Trojaner und Würmer die weit verbreitetste Ursache von Sicherheitsproblemen ist. Schon heute gibt es Lösungsansätze, die die Verbreitung von malicios Code unterbinden sollen. Beim Signatur-Ansatz wird ein Hash-Wert berechnet und signiert, mit dem das Programm verglichen werden kann; das Prinzip der Sandbox führt den Code in eigens geschützen Umgebungen (z.b. Java) aus, Compiler mit Bounded-Memory-Unterstützung überprüfen bei jedem Speicherzugriff, ob der Zugriff nicht außerhalb der für das Programm vorgesehenen Adressen stattfindet, während bei der Typ-Überprüfung sichergestellt wird, dass Daten nur in Variable geladen werden kann, wenn der Typ übereinstimmt. Die TCPA-Sezifikation kann einige der Probleme lösen: durch den curtained Memory wird der Speicher in 2 Teile geteilt, für sichere und normale Applikationen. Code Signierung kann direkt im TPM- Chip stattfinden und ist somit auch sicher vor Manipulationen, da alle Schlüssel im sicheren Speicher des TPMs liegen. Probleme wie die Löschung von Daten und die Erfordernis von Third Parties, die die Zertizifierung übernehmen, bleiben aber trotzdem vorhanden Diebstahl Ein weiteres Problem ist der Diebstahl von Hardware, wie Laptops, Festplatten oder Medien. Heutzutage kann dies durch Verschlüsselung mit Passwörtern verhindert werden, was allerdings die Handhabung verkompliziert und Brute-Force-Attacken ermöglicht. In größeren Unternehmen können die Schlüssel 16

17 auch auf einem Key-Server ausgelagert werden. Durch die TCPA-Plattform wird der Schlüssel, mit dem verkryptet wird, sicher im TPM aufbewahrt, d.h. Diebstahl von Medien können die Daten nicht mehr gefährden. Gelangt allerdings der gesamte Computer in fremde Hände sind die Daten nach wie vor in Gefahr Mail Eine Anwendungsmöglichkeit des TPM-Chips ist die sichere Kommunikation via . Beispielsweise könnte ein Mail-Client so konfiguriert werden, dass es ein -zertifikat von einer Trusted Third Party (TTP) anfordert, um Signierung und Verschlüsselung durchführen zu können. 1. Der Mail-Client fordert z.b. bei Verisign eine Digitale ID an 2. Verisign verwendet die CSP des TPM-Chips um mit der TPM-Hardware zu kommunizieren 3. Das TPM generiert ein neues Schlüsselpaar zum Signieren 4. Das TPM sendet den öffentlichen Schlüsselteil an Verisign 5. Verisign signiert den öffentlichen Schlüssel und gibt ihn an den Mail-Client zurück Die sichere Kommunikation läuft dann über folgende Schritte ab: 1. Der -Client sendet den Hash-Wert der Nachricht zum TPM 2. Das TPM signiert den Hash-Wert mittels RSA unter Verwendung des geheimen Privaten Schlüssels 3. Das TPM liefert die Signatur an Outlook zurück 17

18 5 Kritik Schon kurz nach der Gründung der TCPA konnte man in vielen Communities steigendes Unbehagen über das Sicherheitskonzept von Microsoft und Co bemerken. Crypto- und Datenschutz-Experten, OpenSource- Organisationen und viele eigens dafür ins Leben gerufene Vereinigungen haben sich dem Kampf gegen TCPA und Palladium verschrieben. Mittlerweile gibt es auch schon mehr Information von Gegnern der Architektur als von den Entwicklern selbst. Beim Studium dieser Anti-Seiten ist aber Vorsicht angebracht, weil neben viel interessanter Information, die die offiziellen Stellen lieber verschweigen, auch viel Unwahrheit verbreitet wird und Angst geschürt wird. Die Hauptkritikpunkte werden im folgenden Abschnitt erläutert und hier kurz zusammengefasst: als Hauptanwendungszweck wird DRM vermutet Black- und Whitelists Zertifizierung von Software (Nachteile für kleine Unternehmen + OpenSource) 5.1 DRM Digital Rights Management (DRM) ist der Versuch, das Anzeigen und Verbreiten von digitalen Inhalten, wie Musik, Videos, Bücher oder Dienstleistungen zu kontrollieren. Existierende DRM-Systeme, wie z.b. der Microsoft Media Player in Verbindung mit Windows Media Audio (.wma), arbeiten auf Applikations-Ebene [5]. In den TCPA/Palladium-FAQs [8] spekuliert Ross Anderson, dass TCPA und Palladium verwendet werden könnte, um DRM in Betriebssystemen besser einsetzen zu können. DRM ist ein notwendiges Instrument, um das geistige Eigentum zu sichern, allerdings ist es auch nicht überall wünschenswert, da es, falsch eingesetzt, Konsumentenrechte untergräbt, Zensur ermöglicht und Fortschritt hemmt. NGSCB oder andere Umsetzung der Architektur sollen die sicherheitsrelevanten Erweiterungen für die gesamte PC-Plattform ermöglichen und sind deswegen nicht von vorn herein mit DRM gleichzusetzen. Allerdings gibt Microsoft zu, dass DRM-Anwendungen unter der NGSCB-Architektur entwickelt werden können und auch Vorteile der Plattform verwendet werden können um die Umgehung von DRM-Regeln zu unterbinden [6]. Doch sollte durch die Ablehnung von DRM-Systemen nicht auch gleichzeitig die gesamte Trusted Computing Architektur abgelehnt werden. 5.2 Black-/Whitelists Eine Whitelist könnte z.b. eine Liste von Hardwarekomponenten sein, die im PC vorhanden sein muss, damit TCPA-Anwendungen überhaupt gestartet werden können. Eine Blacklist könnte z.b. eine Liste von gesperrten Seriennummern beinhalten, die laufend aktualisiert wird und das Starten von raubkopierter Software verhindert. Aber diese Funktionen sind in der TCPA-Spezifikation nicht enthalten und werden angeblich auch nicht kommen. Einzige Ausnahme ist die Zertifizierung der Hardware, denn ein vertrauenswürdiges System kann nur durch Zertifizierungen sichergestellt werden. Damit sich eine TCPA-Plattform in einem sicheren Zustand befindet, müssen alle Schlüsselkomponenten der Hardware die Sicherheitsfunktionen unterstützen, dies kann der TPM durch die Zertifizierung überprüfen. Ein nachträgliches Downloaden von solchen Listen ist aber nicht vorgesehen, könnte aber in einem TCPA-Betriebssystem leicht implementiert werden. 5.3 Zertifizierung von Code Ein weiterer großer Kritikpunkt betrifft die Zertifizierung von Code. Damit auf einer NGSCB-Plattform eine Applikation mit einem Trusted-Agent auf Nexus-Funktionen zugreifen kann, muss der Code zertifiziert sein. Noch ist unklar, wer diese Zertifizierung übernehmen soll. Dass diese Zertifizierung etwas kosten wird ist aber ziemlich sicher und gerade daraus ergibt sich ein Problem. Ross Anderson befürchtet, dass diese Zertifizierung einen großen Aufwand bedeutet und gerade teuer genug sein wird, um die Gemeinschaft freier Softwareentwickler davon abzuhalten, aber noch billig genug für die Anbieter der 18

19 meisten kommerziellen Softwarehersteller sein wird. Zusätzlich ergibt sich das Problem der Patches. Eine Änderung an zertifiziertem Code ist ohne erneute Zertifizierung nicht möglich. Das hindert zwar einen Virus daran, eine Anwendung zu untergraben, allerdings wird dadurch auch eine laufenden Erneuerung eines Systems, wie es in OpenSource-Betriebssystemen aufgrund der laufende Weiterentwicklung üblich ist, nicht mehr ohne zusätzliche Kosten möglich sein. In einem späteren Szenario ist auch geplant, dass der TPM-Chip das BIOS und das Betriebssystem auf Gültigkeit und Unverändertheit prüft. Das würde wiederum ein Selbstkompilieren des Kernels, wie unter Linux üblich, nicht mehr ermöglichen. Allerdings sind laut [5] gar keine externen Zertifikate notwendig, um alle Funktionen eines TPM- Chips verwenden zu können. Demnach ist es zwar möglich DRM-Applikation zu schreiben, die externe Zertifikate benötigen, aber Funktionen wie zum Beispiel sicherer Speicher ist auch ohne diese Zertifikate möglich. In Palladium werden aller Wahrscheinlichkeit nach zwar Zertifikate eine größere Rolle spielen, laut Microsoft [6] muss aber ein Programm nicht unbedingt zertifiziert sein, um mit dem Nexus in Verbindung treten zu können. Inwieweit dies wirklich zutrifft oder ob es vielleicht in zukünftigen Versionen zutrifft ist noch nicht abzusehen. 5.4 Wahrheiten und Gerüchte Gerade bei so kontroversen Themen wie IT-Security, Privacy und DRM ist die Diskussion oft sehr unsachlich und strotzt vor Unwahrheiten. Falsche Behauptungen werden ungefiltert zitiert und weiterverbreitet. Unternehmen wie Microsoft eilt der Ruf voraus, was die Informationspolitik betrifft, nicht gerade ehrlich zu sein. Das schürt wiederum Vermutungen und Gerüchte, da die meisten offiziellen Statements und Papiere von blumigen Marketing-Formulierungen durchzogen sind und nur schlecht auf den Wahrheitsgehalt geprüft werden können. In der Ausgabe 9 der c t [3] hat der Heise-Verlag versucht eine Liste aller Behauptungen aufzustellen und sie auf Wahrheitsgehalt zu prüfen. Folgende häufig kursierende Behauptungen konnten als unwahr entlarvt werden: TCPA-Chips sollen in den USA Pflicht werden. Es gibt zwar Bemühungen ein derartiges Gesetz zu Wege zu bringen, allerdings ist dies sehr unwahrscheinlich. Teure Zertifizierung nötig. Eine Zertifizierung von Anwendungen wird zwar sicherlich nicht billig sein (zumindest auf lange Sicht nicht), allerdings auch nicht notwendig, um die Funktionen des TPM nutzen zu können. Weltweite Black-/Whitelist. Eine weltweite Liste mit geprüfter Hard- und Software, gesperrten Dokumenten und Seriennummern wird es bei der TCPA nicht geben. In einem TCPA-Betriebssystem wie Palladium könnte dies allerdings umgesetzt werden, dies ist aber angeblich nicht geplant. Linux inkompatibel. Sowohl IBM als auch Hewlett-Packard arbeiten bereits an einem TCPAkonformen Linux, erste Treiber sind bereits verfügbar. Nicht deaktivierbar. Laut Spezifikation muss der Chip deaktivierbar sein und zwar am besten über einen Jumper, auf keinen Fall aber per Software fernsteuerbar. Auslieferungsmodi wären Opt-In (standardmäßig deaktiviert, Benutzer kann Chip aktivieren) und Opt-Out (standardmäßig aktiviert, Benutzer kann Chip deaktivieren) Steuert Boot-Vorgang. Falsch, der Chip bleibt durchgehend passiv. Einige Behauptungen sind aber wahr und könnten auch Komplikationen für die Zukunft bringen: Integration des TPM im Hauptprozessor. Ist technisch möglich, Intel bestreitet allerdings, dies vorzuhaben. TCPA-Anwendungen funktionieren nur bei aktiviertem Chip. Sichere Funktionen funktionieren natürlich nur, wenn der Chip aktiviert ist, bei entsprechender Programmierung könnte man allerdings auf andere Sicherheitsmaßnahmen zurückgreifen 19

20 Eindeutige ID. Der Endorsement-Key ist einmalig und würde eine Zuordnung ermöglichen, allerdings wird der öffentliche Schlüsselteil nur einer CA mitgeteilt, die dem Benutzer dann einen AIK ausstellt, der wiederum keine Rückschlüsse auf die verwendete Plattform ermöglicht (siehe auch 3.4 auf Seite 8 DRM. Digital Rights Management war z.b. ein ursprüngliches Ziel von Palladium, mittlerweile hat sich dies zwar geändert, die technische Umsetzung von DRM ist aber auf einer TCPA-Plattform leicht möglich. 6 Zusammenfassung In dieser Seminararbeit wurde, aufbauend auf den technischen Spezifikationen der Trusted Computing Platform Alliance, eine Bewertung der Technologie sowie der möglichen und bereits nutzbaren Anwendungen vorgenommen. Die TCPA bzw. die neu gegründete TCG haben sich das Ziel gesetzt, eine offene Spezifikation für Trusted Computing zu entwickeln. Auf die aktuelle Version 1.1b dieser Spezifikation wurde genauer eingegangen, die Bedeutung von Zertifikaten und die Funktionen und Arbeitsabläufe des TPM-Chips geklärt. Ein weiterer Teil der Arbeit beschäftigt sich mit Anwendungsmöglichkeiten der Architektur und bietet einige Szenarien für die Abwendung von Bedrohungen durch Manipulation. Es wurde bewiesen, dass es mit den Systemen der Firma IBM schon heute eine TCPA-konforme Plattform gibt, die schon viele wichtige Sicherheitsfunktionen der Business-Anforderungen unterstützt und vereinfacht. Es zeigte sich, dass Microsoft mit Palladium/NGSCB noch viel Größeres vor hat und von Applikationen, die auf sicheren Speicher zugreifen bis zu verschlüsselter Übertragung zwischen Ein-/Ausgabegeräten und Computer ein ganzes Sicherheits-Portfolio anbieten wird. Die Hardware-Basis dazu wird eventuell mit LaGrande von Intel kommen, die damit begonnen haben ihrerseits TCPA-Spezifikationen in Hardware, wie Prozessor und Chipsatz, abzubilden. Obwohl die genaue Spezifikation kritischer Passagen deutlich macht, dass die Entwickler vorsichtig vorgegangen sind, zeigt die aktuelle Diskussion um die Architektur, dass große Ängste bestehen, dass DRM-Systeme Rechte des Konsumenten einschränken könnten; Erfordernisse wie Zertifikate könnten die OpenSource-Entwicklungen der letzten Jahre bremsen und Datenschützer befürchten, dass die Macht über die Daten durch große Unternehmen kontrolliert werden könnten. In einem kritischen Abschnitt wurden diese Probleme dargestellt, welche die neue Plattform mit sich bringt. Richtig eingesetzt, ermöglicht die neue Technologie Datenverarbeitung auf viele neue Bereiche auszuweiten und bis jetzt, aus Sicherheitsgründen getrennte Systeme, zusammenwachsen zu lassen und bessere Interaktion zu ermöglichen. E-Business kann nur weiterhin an Bedeutung gewinnen und wachsen, wenn die Implementierung von sicheren Applikationen einfacher wird und alle involvierten Personen, vom einfachen Anwender über den IT-Profi bis zum Geschäftsführer von der Sicherheit der Technologie vollkommen überzeugt sind. Bessere Datensicherheit, größere Vertraulichkeit und stärkere Integrität von System wäre die Folge und könnte allen Beteiligten nutzen. 20