Trusted Computing: Ein Weg zu neuen IT-Sicherheitsarchitekturen

Norbert Pohlmann Helmut Reimer (Hrsg.)

!n h a Itsverzei

Trusted Computing

c h n is

Einleitung Trusted Computing- eine E i n f 0 h r u n g Norbert Pohlmann 9Helmut Reimer

Grundlagen

13

Die Trusted Computing Group

15

Thomas Rosteck

Trusted Computing Grundlagen

21

Hans Brandl

TPM Virtualization" Building a General Framework

43

Vincent Scarlata. Carlos Rozas 9Monty Wiseman. David Grawrock. Claire Vishik

Trusted Computing und die U m s e t z u n g in h e u t i g e n B e t r i e b s s y s t e m e n

57

Sebastian Rohr

Sicherheitsbausteine

fiir Anwendungen

M e h r V e r t r a u e n s w ~ i r d i g k e i t fLir A n w e n d u n g e n d u r c h eine S i c h e r h e i t s p l a t t f o r m

71

73

Markus Linnemann 9Niklas Heibel 9Norbert Pohlmann Die S i c h e r h e i t s p l a t t f o r m

Turaya

86

Ammar Alkassar. Christian St0ble

Trusted Network Connect- Vertrauensw0rdige Netzwerkverbindungen

97

Marian Jungbauer. Norbert Pohlmann

Interaktionen TPM und Smart Card Florian Gawlas 9Gisela Meister. Axel Heider 9Sebastian Wallner

110

VIII

Inhaltsverzeichnis

Aus dem Bereich IT erfolgreich gestalten Anwendungsszenarien Enterprise S e c u r i t y - I n f o r m a t i o n s s c h u t z im Unternehmen

123 125

Michael Hartmann. Gunter Bitz Unternehmensweites TPM Key Management Mehr IT-Sicherheit durch Pen-Tests Bernhard Weiss von Enno Rey, Michael Thumann und Dominick Baier

140

IT-Sicherheit kompakt verständlich Trusted C o m p u t i n g imund Hochsicherheitsbereich vonPeter Bernhard C. Witt Kraaibeek 9Hans Marcus Kr0ger 9Kai Martius

156

Praxis des IT-Rechts vonTrusted Horst Speichert C o m p u t i n g for automobile IT-Systeme

170

Andrey Bogdanov 9Thomas Eisenbarth 9Christof Paar. Marko Wolf

Der IT Security Manager von Heinrich Kersten und Gerhard Klett

Trusted C o m p u t i n g in mobiler A n w e n d u n g : Von Z u g a n g s k o n t r o l l e

IT-Sicherheitsmanagement nach ISO 27001 zu Identit~iten und Grundschutz Andreas U. Schmidt 9Nicolai Kuntze von Heinrich Kersten, Jürgen Reuter und Klaus-Werner Schröder

Datenschutz- und r e c h t l i c h e A s p e k t e IT-Sicherheit – Make or Buy vonAMarco Müller und Köhler u s w i r kKleiner, u n g e n Lucas von Trusted C o Mario mputin g auf die Privatsph~ire

187

207 209

Markus Hansen 9Marit Hansen

IT-Sicherheit mit System von Klaus-Rainer Müller

Rechtliche Chancen und Risiken des ,,Trusted C o m p u t i n g " Andreas Neumann Trusted Computing von Norbert Pohlmann und Biographien der A u t o r e n Helmut Reimer (Hrsg.)

221

237

Glossar

243

Stichwortverzeichnis

249

www.vieweg.de

Norbert Pohlmann Helmut Reimer (Hrsg.)

Trusted Computing Einleitung Ein Weg zu neuen IT-Sicherheitsarchitekturen Mit 49 Abbildungen

Trusted C o m p u t i n g - eine Ein fLi hrung

Bibliografische Information Der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über abrufbar.

N o r b e r t P o h l m a n n ~. H e l m u t R e i m e r ~llnstitut far Internet Sicherheit, FH Gelsenkirchen [email protected] 2TeleTrusT Deutschland e. V. Chamissostrage 11,keiner 99096Verpflichtung Erfurt Das in diesem Werk enthaltene Programm-Material ist mit oder Garantie [email protected] einer Art verbunden. Der Autor übernimmt infolgedessen keine Verantwortung und wird keine daraus

folgende oder sonstige Haftung übernehmen, die auf irgendeine Art aus der Benutzung dieses Programm-Materials oder Teilen davon entsteht.

Zusammenfassung

Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen usw. in diesem Werk berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Angesichts der Tatsache, dass sich die Vertrauensw~rdigkeit des Internets trotz grof3erAnstrengungen der SicherSinne von Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher heitsexperten tendenziell nicht verbessert, verdient ein neues Konzept- wie Trusted Computing- besondere Aufvon jedermannZum benutzt werden merksamkeit. ersten MaI indürfen. der Geschichte der Informationstechnologie haben sich die grogen IT-Systemanbieter im Rahmen der Trusted Computing Group (TCG) entschlossen, gemeinsam Verantwortung f~r wirksame

Höchste und technische Qualität unserer Produkte unser Ziel. Bei der und Abhilfe inhaltliche zu t~bernehmen. Die Implementierung der Ergebnisse derist TCG ist im Gange und Produktion erste Anwendungen sind Auslieferung Bücher wollen wir diewollen Umwelt Dieses Buch ist auf säurefreiem und zeigen, nutzbar. Die unserer Herausgeber dieser Publikation mitschonen: den in diesem Buch zusammengestellten Beitr~igen dass dasgebleichtem Trusted Computing eineDie neue )i,ra ffir die Gestaltung er6ffnet. In chlorfrei PapierKonzept gedruckt. Einschweißfolie bestehtvertrauenswfirdiger aus Polyäthylen IT-LOsungen und damit aus diesem Einfahrungsbeitrag erl~iutert, sich das innovative Potential dieser Technologie grtlndet. Er soll organischen Grundstoffen, wird die weder beiworauf der Herstellung noch bei der Verbrennung Schadstoffe dazu anregen, die Vorteile der bereits standardisierten Hardwaremodule und offenen Schnittstellen auszusch6pfen freisetzen. sowie die neuen Ansfitze in Anwendungsentwicklungen und Infrastrukturservices zu implementieren.

Der TeleTrusT-Verein wird sich im Bereich Trusted Computing engagieren und m6chte helfen, die bestehenden Ans~itze des Zusammenwirkens der Sicherheitsplattform mit den notwendigen Sicherheitsinfrastrukturen und den nt~tzlichen Sicherheitstoken der Nutzer pragmatisch weiter zu entwickeln [TTT07]. Er sieht sich auch in der Rolle des Vermittlers zwischen den Technologieanbietern und-anwendern, um so die Erschlief3ung des Potentials dieser Sicherheitstechnologie Nr eine vertrauensw~rdige IT-Zukunft zu f6rderno 1.innovativen Auflage 2008

Alle Rechte vorbehalten Grunds IT-Sicherheitsl6sungen ©1Friedr. Vieweg & Sohnitzliches Verlag | GWV zu Fachverlage GmbH, Wiesbaden 2008 Lektorat: Günterund Schulz / Andrea Broßler InformationsKommunikationssicherheit sind Themen, die jede Diskussion fber nfitzliche Anwendungen des Internets begleiten. Stets von ist von Chancen, Risiken und Gefahren Der Vieweg Verlag ist ein Unternehmen Springer Science+Business Media. die Rede. Angesichts der fiber eine Milliarde PCs, die 2008 weltweit im Netz sein werden, und noch weit mehr mobiler Endger~ite www.vieweg.de ist sachlich festzustellen: Die Chancen werden genutzt. Einzig und allein dadurch sind die Voraussetzungen ffr das Erkennen bestehender Risiken undseiner Angriffspotentiale sowie die heute m6gliche Das Werk einschließlich aller Teile ist urheberrechtlich geschützt. Jede Bewertung der Wirkung von Gegenmal3nahmen Verwertung außerhalbgegeben. der engen Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlags unzulässig und strafbar. Das gilt insbesondere Die Nutzer des Internets auf der einen SeiteÜbersetzungen, verhalten sich gegenfber den bestehenden sehr für Vervielfältigungen, Mikroverfilmungen und dieRisiken Eindifferenziert. Im Allgemeinen wird das Ziel, einen deutlich erkennbaren Vorteil zu erreichen, zurzeit mit speicherung und Verarbeitung in elektronischen Systemen. einem nutzerseitigen Vertrauensbonus, nach dem Motto: ,,Es wird schon nichts passieren", verbunden. Die Sensibilit~it ffirUlrike Sicherheitslfcken oder fitr Angriffe entsteht eher durch negative Erfahrungen als Umschlaggestaltung: Weigel, www.CorporateDesignGroup.de durch Wissen oderIlmenau Pr~ivention. Satz: Oliver Reimer, Druck und buchbinderische Verarbeitung: MercedesDruck, Berlin Auf der auf anderen Seite betonen die IT-Sicherheitsexperten Gedruckt säurefreiem und chlorfrei gebleichtem Papier. das weit gef'~icherte Spektrum der potentiellen Bedrohungen. Aus dieser Bedrohungssicht ist eine grof3e Vielfalt von hochwertigen IT-SicherheitslOPrinted in Germany N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 3-12 ISBN 978-3-8348-0309-2

Vorwort

Die Informationstechnik (IT) hat in den letzten zwei Jahrzehnten alle wichtigen Lebensbereiche durchdrungen. In Privatleben, Wirtschaft, Verwaltung und selbst bei kritischen Infrastrukturen ist die funktionierende und sichere IT der Grundpfeiler moderner GescMftsprozesse und Kommunikationsverbindungen. Sichere Verfahren des EGovernment und des E-Commerce sind ebenso nur mit Hilfe sicherer IT realisierbar. Damit wird die Informationstechnik zunehmend selbst zu einer kritischen Infrastruktur, deren Ausfall oder missbr~iuchliche Nutzung ernste Folgen far die gesamte Gesellschaft begrtinden kann. Dies geht einher mit einer qualitativ und quantitativ steigenden Zahl von IT-Sicherheitsvorf'~illen, wie der Bericht zur Lage der IT-Sicherheit in Deutschland 2007 des Bundesamtes far Sicherheit in der Informationstechnik zeigt. Der Trend zur Kommerzialisierung und Professionalisierung der Internetkriminalit~it scheint bei einem zum Teil nur geringen Schutzniveau vieler IT-Systeme ungebrochen.

Dr. Markus DOrig, Bundesministerium des Innern

Konventionelle Ansfitze zur Verbesserung der IT-Sicherheit versuchen oft, potenziell unsichere Systemkerne mit einer Vielzahl von Schutzschichten nach augen hin sicherer zu macheno Die Trusted Computing-Technologie etabliert die Sicherheitsfi.mktionalit~it dagegen direkt in den Systemkern. Das Bundesministerium des Innern h~ilt diesen Ansatz f'th"vielversprechend und begNgt grunds~itzlich jede Magnahme, die dem Ziel eines besseren Schutzes der Informationstechnik dient. Allerdings mfissen die Mal3nahmen derart gestaltet sein, dass alle Bestandteile gesetzeskonform sind. Insbesondere die Aspekte des Datenschutzes mfissen berficksichtigt werden. Denn es k6nnen nur Mal3nahmen unterstfitzt werden, die dazu geeignet sind, das Vertrauen der Nutzer in die Informationstechnik zu erh6hen. Voraussetzungen sind eine transparente Informationspolitik in Bezug auf die Schutzkonzepte und Schutzmaf3nahmen, sowie die Einbeziehung aller Interessengruppen bei der Planung, Entwicklung und Vermarktung von Schutzmechanismen. Schutzmagnahmen im IT-Bereich dfirfen keinesfalls dazu missbraucht werden, Marktzugangsschranken zu schaffen. Der Grundidee ,,vertrauenswfirdiger Informationstechnik" folgend, sieht das Bundesministerium des Innern mit grogem Interesse auf die Standardisierungen innerhalb der Trusted Computing Group (TCG), insbesondere der Spezifikationen zum Trusted Platform Module (TPM). Bereits im Jahre 2004 suchte die Bundesregierung das Gesprfich mit der TCG, indem in Form eines Anforderungskataloges zu den

VI damaligen Entwicklungen Stellung genommen wurde. Die seinerzeitigen Forderungen gelten in ihrem Grundsatz bis heute fort und lassen sich wie folgt zusammenfassen: 9 Offenheit, Transparenz und freie VerfiJgbarkeit der Standards ~ Entscheidungsfreiheit f'tir einen Einsatz TPM-basierter Systeme 9 Nachvollziehbare und transparente Zertifizierung 9 Gew~ihrleismng der Interoperabilit~it mit alternativen L6sungen 9 Volle Kontrolle tiber Inbetriebnahme, Konfiguration, Anwendung und Stilllegung von TC-L6sungen 9 Einhaltung der Bestimmungen des Datenschutzes. Werden Trusted Computing-L6sungen, diesenAnforderungen gerecht, so k6nnen Sie einen wesentlichen Beitrag zur Erh6hung der IT-Grundsicherheit eines jeden Nutzers darstellen. Dabei ist es unwesentlich, ob sie auf den Spezifikationen der TCG basieren oder altemativen Ans~itzen folgen~ Gleichzeitig ergeben sich neue Chancen und M6glichkeiten, die Sicherheitsmechanismen auch anderen IT-Anwendungen zur Verffigung zu stellen und ein h6heres Vertrauen in E-Government und E-Commerce zu begrtinden.

!n h a Itsverzei

c h n is

Einleitung Trusted Computing- eine E i n f 0 h r u n g Norbert Pohlmann 9Helmut Reimer

Grundlagen

13

Die Trusted Computing Group

15

Thomas Rosteck

Trusted Computing Grundlagen

21

Hans Brandl

TPM Virtualization" Building a General Framework

43

Vincent Scarlata. Carlos Rozas 9Monty Wiseman. David Grawrock. Claire Vishik

Trusted Computing und die U m s e t z u n g in h e u t i g e n B e t r i e b s s y s t e m e n

57

Sebastian Rohr

Sicherheitsbausteine

fiir Anwendungen

M e h r V e r t r a u e n s w ~ i r d i g k e i t fLir A n w e n d u n g e n d u r c h eine S i c h e r h e i t s p l a t t f o r m

71

73

Markus Linnemann 9Niklas Heibel 9Norbert Pohlmann Die S i c h e r h e i t s p l a t t f o r m

Turaya

86

Ammar Alkassar. Christian St0ble

Trusted Network Connect- Vertrauensw0rdige Netzwerkverbindungen

97

Marian Jungbauer. Norbert Pohlmann

Interaktionen TPM und Smart Card Florian Gawlas 9Gisela Meister. Axel Heider 9Sebastian Wallner

110

VIII

Inhaltsverzeichnis

Anwendungsszenarien

123

Enterprise S e c u r i t y - I n f o r m a t i o n s s c h u t z im Unternehmen

125

Michael Hartmann. Gunter Bitz Unternehmensweites

TPM Key Management

140

Bernhard Weiss Trusted C o m p u t i n g im Hochsicherheitsbereich

156

Peter Kraaibeek 9Hans Marcus Kr0ger 9Kai Martius Trusted C o m p u t i n g for automobile

IT-Systeme

170

Andrey Bogdanov 9Thomas Eisenbarth 9Christof Paar. Marko Wolf Trusted C o m p u t i n g in mobiler A n w e n d u n g : Von Z u g a n g s k o n t r o l l e zu Identit~iten

187

Andreas U. Schmidt 9Nicolai Kuntze

Datenschutz- und r e c h t l i c h e A s p e k t e A u s w i r k u n g e n von Trusted C o m p u t i n g auf die Privatsph~ire

207 209

Markus Hansen 9Marit Hansen Rechtliche Chancen und Risiken des ,,Trusted C o m p u t i n g "

221

Andreas Neumann

Biographien der A u t o r e n

237

Glossar

243

Stichwortverzeichnis

249

Einleitung

Trusted C o m p u t i n g - eine Ein fLi hrung N o r b e r t P o h l m a n n ~. H e l m u t R e i m e r ~llnstitut far Internet Sicherheit, FH Gelsenkirchen [email protected] 2TeleTrusT Deutschland e. V. Chamissostrage 11, 99096 Erfurt [email protected]

Zusammenfassung Angesichts der Tatsache, dass sich die Vertrauensw~rdigkeit des Internets trotz grof3erAnstrengungen der Sicherheitsexperten tendenziell nicht verbessert, verdient ein neues Konzept- wie Trusted Computing- besondere Aufmerksamkeit. Zum ersten MaI in der Geschichte der Informationstechnologie haben sich die grogen IT-Systemanbieter im Rahmen der Trusted Computing Group (TCG) entschlossen, gemeinsam Verantwortung f~r wirksame Abhilfe zu t~bernehmen. Die Implementierung der Ergebnisse der TCG ist im Gange und erste Anwendungen sind nutzbar. Die Herausgeber dieser Publikation wollen mit den in diesem Buch zusammengestellten Beitr~igen zeigen, dass das Trusted Computing Konzept eine neue )i,ra ffir die Gestaltung vertrauenswfirdiger IT-LOsungen er6ffnet. In diesem Einfahrungsbeitrag wird erl~iutert, worauf sich das innovative Potential dieser Technologie grtlndet. Er soll dazu anregen, die Vorteile der bereits standardisierten Hardwaremodule und offenen Schnittstellen auszusch6pfen sowie die neuen Ansfitze in Anwendungsentwicklungen und Infrastrukturservices zu implementieren. Der TeleTrusT-Verein wird sich im Bereich Trusted Computing engagieren und m6chte helfen, die bestehenden Ans~itze des Zusammenwirkens der Sicherheitsplattform mit den notwendigen Sicherheitsinfrastrukturen und den nt~tzlichen Sicherheitstoken der Nutzer pragmatisch weiter zu entwickeln [TTT07]. Er sieht sich auch in der Rolle des Vermittlers zwischen den Technologieanbietern und-anwendern, um so die Erschlief3ung des Potentials dieser innovativen Sicherheitstechnologie Nr eine vertrauensw~rdige IT-Zukunft zu f6rderno

1 Grunds

itzliches zu IT-Sicherheitsl6sungen

Informations- und Kommunikationssicherheit sind Themen, die jede Diskussion fber nfitzliche Anwendungen des Internets begleiten. Stets ist von Chancen, Risiken und Gefahren die Rede. Angesichts der fiber eine Milliarde PCs, die 2008 weltweit im Netz sein werden, und noch weit mehr mobiler Endger~ite ist sachlich festzustellen: Die Chancen werden genutzt. Einzig und allein dadurch sind die Voraussetzungen ffr das Erkennen bestehender Risiken und Angriffspotentiale sowie die heute m6gliche Bewertung der Wirkung von Gegenmal3nahmen gegeben. Die Nutzer des Internets auf der einen Seite verhalten sich gegenfber den bestehenden Risiken sehr differenziert. Im Allgemeinen wird das Ziel, einen deutlich erkennbaren Vorteil zu erreichen, zurzeit mit einem nutzerseitigen Vertrauensbonus, nach dem Motto: ,,Es wird schon nichts passieren", verbunden. Die Sensibilit~it ffir Sicherheitslfcken oder fitr Angriffe entsteht eher durch negative Erfahrungen als durch Wissen oder Pr~ivention. Auf der anderen Seite betonen die IT-Sicherheitsexperten das weit gef'~icherte Spektrum der potentiellen Bedrohungen. Aus dieser Bedrohungssicht ist eine grof3e Vielfalt von hochwertigen IT-SicherheitslON. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 3-12

4

Trusted Computing- eine Einfahrung

sungen entstanden, deren Komplexit~it oft fiber das Fassungsverm6gen des durchschnittlichen Nutzers hinausgeht und die deshalb eher in geschlossenen Nutzergruppen (wie in Untemehmen oder besonders sensiblen Anwendungsbereichen, z.B. im Gesundheitswesen) mit entsprechenden Infrastrukmrinvestitionen Anwendung finden. Es ist im Interesse einer kontinuierlichen Verbesserung der Sicherheitslage im gesamten Intemet dringend erforderlich, Wege zu finden, mit denen die bestehende Diskrepanz zwischen dem blinden Vertrauen vieler Nutzer und den realen Schgden abgebaut werden kann. Die Entwicklung des Intemets und die Verbreitung von kompatiblen und interoperablen Endgergten ist durch entsprechende Industriestandards entscheidend mitbestimmt worden. Nur deren pragmatische Implementierung in Hard- und Software fahrte zu der heute erreichten weltweiten Interoperabilit~it von Intemetdiensten und-anwendungen. Gleichzeitig ist auf diesem Wege auch die Grundlage far den riesigen Markt mit relativ kostengt~nstigen Angeboten far die technische Basis entstanden. fi~hnliches gilt auch far wichtige Internet Sicherheitsstandards und -protokolle, wie SSL (TLS), S/ MIME, IPSec usw., die praktisch in alle verfagbaren Betriebssysteme und viele Anwendunge implementiert sind. Auch Kryptoverfahren stehen mit quasistandardisierten Parametem allgemein zur Verfagung. Obwohl diese Werkzeuge fiber ein hohes Potential im Hinblick auf die Verbesserung der Informations- und Kommunikationssicherheit verfagen, ist ihre Anwendungsbreite weit hinter den Erwartungen zurfickgeblieben. Drei wesentliche Grfinde k/Snnen- neben der oben genannten Risikobereitschaft- fitr die Anwendungszm'fickhalmng genannt werden: 9 Das Handling von Anwendungen mit Sicherheitsfunktionen wird komplizierter, oft sinkt die Performance. Eine unmittelbare Wirkung von Sicherheitsmagnahmen ist far den Nutzer hfiufig nicht erkennbar. 9 Ffir den Anwender ist es - in Anbetracht der Komplexitgt der fiblichen Intemetanwendungen und der far ihn ungberschaubaren Angriffsziele- nicht m6glich zu beurteilen, welches Gewicht eine von ihm implementierte Sicherheitsmal3nahme auf die Sicherheitsqualit~it der Anwendung besitzt. 9 Kryptographieanwendungen erfordern Infrastrukmren und-dienste. Der Nutzer sieht sich hierbei vor neue Herausforderungen gestellt: Neben der Qualit~it der Services und den mit ihrer Inanspruchnahme verbundenen Kosten, ist h~iufig ungekl~irt, wie die Vertrauenskette zum Diensteanbieter gerechtfertigt werden kann. Aus Sicht der Sicherheitsexperten gibt es darfiber hinaus zwei entscheidende und permanente Risikofaktoren: 9 Die Einbettung der Sicherheitsfunktionalit~ten als Software in eine offene System- und Netzumgebung und 9 das Nutzerverhalteno Allgemeine Bedrohungsanalysen far IT-Systeme und -Anwendungen haben bereits Anfang der 1990er Jahre zu der Erkenntnis gefahrt, dass in Software implementierte kryptographische IT-Sicherheitsl6sungen durch Hardwaremodule wirkungsvoll erg~inzt und gegen Angriffe besser geschtitzt werden k6nneno Ft~r geschlossene Benutzergruppen sind dies komplexe Hardware Security Module (HSM); ein klassisches Beispiel ist der im Bankenbereich verbreitete Kryptoprozessor IBM 4758. Ft~r den Einzelnutzer wurde das Konzept der Kryptoprozessor SmartCard entwickelt. Inzwischen ist dieser Ansatz - durch ein umfangreiches ISO-Normenwerk begleitet- Grundlage far SmartCard basierte Token als ein entscheidendes Sicherheitsinstrument in der Hand des Nutzers. Allerdings steigen die

Trusted Computing- eine E i n t ' t ~ n g

5

Infrastrukturanforderungen und-aufwendungen, bedingt durch die erforderliche Personalisierung und Verwaltung des Lebenszyklus von SmartCards, erheblich an. Zudem hat sich herausgestellt, dass der Sicherheitsanker ,,personalisiertes Token" im Hinblick auf Anwendungsumgebungen zu schwach ist. Alle Angriffe auf die t~brigen IT-Systemkomponenten bleiben wirksam. Deshalb werden zusammen mit der SmartCard zahlreiche zus~itzliche Sicherheitskomponenten (sichere Kartenterminals, sichere I/O-Kan~ile, sicherer Viewer, virenfreie Anwendungsumgebung usw.) empfohlen, die kostentr~ichtig sind und die Anwendungsflexibilit~it reduzieren. Bisher ist die Verbreitung dieser LOsung mit niedriger Performance, komplexem Handling und nur wenigen Akzeptanzstellen gering. Ihre konsequente Umsetzung als Grundlage fiir sichere IT-Anwendungen erfolgt zungchst nur propriet~ir und Ftir geschlossene Anwendergruppen. Das Risiko des Nutzerverhaltens zeigt sich insbesondere dadurch, dass die Nutzer auf Links in E-Mails von unbekannten Absendem und mysteri6sen Webseiten klicken, und sich so Schadsoftware auf ihren Rechnersystemen laden. Dabei nutzen sie oft keine Virenscanner und Personal Firewalls und sind aus diesem Grund far Angreifer leichte Opfer. Zudem tragen sie zur Verbreitung von Schad- und Angriffsprogrammen bei. Als ein Fazit ergibt sich: V611ige Sicherheit ist als Vertrauensgrundlage nicht erreichbar! Die Verantwortung aller Partner in der Netzwelt (Anwender, Anbieter von L6sungen oder GescMftsprozessen, Dienstleister, Infrastrukturbetreiber usw.) f'~ einen vertrauenswtirdigen Systemzustand kann von Technologie zwar unterstf~tzt, aber durch sie nicht abgel6st werden.

2 Die Alternative zu heutigen Sicherheitsl6sungen Vor dem Hintergrund der bisher zusammengefassten Erfahrungen wird deutlich, dass die bisher verfolgten Konzepte zur IT-Sicherheit erg~tnzungsbedfirftig sin& Erfolgversprechende Bemfihungen in diese Richtung sollten vor allem folgende Ziele verfolgen: 9 Reduzierung der Kosten ftir Sicherheits-Hardwaremodule und ffir Infrastrukturdienste; 9 Integration standardisierter Sicherheits-Hardwaremodule in Ger~ite und Systemkomponenten zur Verwaltung von Ger~iteidentit~iten sowie zur Prfifung der Vertrauenswfirdigkeit und Integritfit ihrer Konfiguration; ~ Vereinfachung des Handlings der Sicherheitsl6sungen und Verbesserung ihrer Performance; ~ Durchsetzung einer betriebssystemunabh~ingigen Standardisierung der Sicherheitsfunktionen und ihrer Anwendbarkeit; ~ Standardisierung von Schnittstellen f-fir sichere Anwendungen, weitere Kryptoger~ite (SmartCards, USB-Token, intelligente Speicherkarten usw.), Infrastrukturen und Management. Letztendlich k6nnen nur auf diesem Wege hochwertige Sicherheitsfunktionen in die allgemein verfagbaren Anwendungen und Systemarchitekmren eingebracht werden.

2.1 Das Trusted Computing Konzept Das Trusted Computing Konzept greift diese Ziele auf, indem zun~ichst konsequent ein SicherheitsHardwaremodul (Trusted Platform Module - TPM) definiert und spezifiziert worden ist, das in prozessorgestfitzte Gergteplattformen fest integriert werden kann. Seine standardisierten Grundfunktionen und Schnittstellen unterstfitzen die lokale Anwendung von Kryptoverfahren auf einem Sicherheitsniveau,

6

Trusted Computing- eine Einfahrung

wie es auch von SmartCards geboten wird. Darfiber hinaus er6ffnet das Konzept zahlreiche weitere Ans~tze far innovative L6sungen, mit denen die Vertrauenswttrdigkeit und die Sicherheit von IT-Systemen erh6ht werden k6nnen. Die Darstellung dieser M6glichkeiten ist ein Grundanliegen dieser Publikation. Da die IT-Systeme tendenziell komplexer und heterogener werden, entscheidet die Bewertbarkeit des Sicherheitszustandes von Systemkomponenten (PCs, aber auch andere computergestt~tzte Ger~ite im Netz wie Mobiltelefone, Speicherger~tte, Drucker usw.) zunehmend tiber die Vertrauenswfirdigkeit von Anwendungen. Diese Anforderung stand bei der Formulierung des Trusted Computing Konzeptes Pate. Das Trusted Platform Module (TPM) kann mittels kryptographischer Verfahren die Integrit~it der Soft- und Hardware-Konfiguration eines Ger~ites messen und deren Hashwerte (Prafwerte) sicher im TPM speichern. Diese Messwerte k6nnen remote t~berprfift werden und machen Anderungen der Soft- oder Hardware-Konfiguration erkennbar. Trusted Computing ben6tigt dazu als Voraussetzung und Infrastrukturkomponente eine Sicherheitsplattform (eigenst~indiges, sicheres kleines Betriebssystem), welche diese Integrit~its(iberprfifungen anst6f3t und auch auswertet. W~ihrend die beteiligten Hardwaremodule und die entsprechenden Software-Schnittstellen standardisiert sind, wird die ben6tigte Sicherheitsplattform propriet~ir sowohl vonder Software-Industrie als auch von Open Source Teams entwickelt. Bedeutsam ist, dass mit dem Trusted Computing Konzept die entscheidenden Marktplayer Verantworrang far die Gestaltung und Umsetzung der genannten Ziele fibernommen haben. So besteht die reale Chance, entsprechende L6sungen von unterschiedlichen Anbietem wettbewerbsneutral u n d - was die Hardwareerg~tnzung betrifft- zu geringstm6glichen Zusatzkosten bereit zu stellen. Der Erfolg wird wesentlich durch die Nutzerakzeptanz bestimmt werdeno Hier spielt die Transparenz der angebotenen Sicherheitsfunktionen eine entscheidende Rolle. Sie sollte far die Vertrauensbildung als ebenso bedeutend angesehen werden wie die Befolgung der Kerkhoff-Prinzipien 1 far die verwendete Kryptographie.

2.2 TPM Verbreitung Spezifikationskonforme TPM 1.2 Module werden von mehreren fahrenden Chip-Produzenten angeboten und inzwischen in die Motherboards von Servern, Desktops und Laptops verbreiteter Marken integriert. Die renommierte Marktforschungsorganisation IDC hat dazu eine Analyse und Vorschau geliefert (siehe Abbildung 1). Es wird erwartet, dass im Jahr 2010 bereits mehr als 250 Millionen TPM Module ausgeliefert werden.

1 Die Sicherheitdes Kryptosystemsdarfnicht von der Geheimhaltungdes Algorithmusabh~ingen.Sie darfsich nur auf die Geheimhaltungdes Schlfisselsgrfinden.

Trusted C o m p u t i n g - eine Einfahrung

7

ii !

84iii!iiii

....

....,,......

~@! I D C

(in mi![ions of un;~s shipped)

300 250 200 150 100 50 0 ~0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 0

0 --~

Source: IEC

Abbildung 1" TPM Module Forecast (IDC- Oct. 2005) In 2010 k6nnen dann nahezu 100 Prozent der ausgelieferten Laptops und ca. 90 Prozent der ausgelieferten Desktop Systeme mit einem TPM Modul ausgestattet sein (Abbildung 2). Geht man von einer Erneuerungsrate von 10-20 Prozent pro Jahr far die PC-Ausstatmng im privaten Bereich und in Unternehmen aus, k6nnte in fanf bis zehn Jahren mehr als 80 Prozent der PC-ClientBasis des Intemet mit TPM-Modulen ausgestattet sein. Desktop vs. Notebook [] Desktop [] Notebooks 160 r

c

.2 .=_

140 120

c 100 (1} G}

.c

e,_ BJ

m

80 60

40 20 0 2002

2003

2004

2005

2006

2007

2008

2009

2010

Jahr

Abbildung 2: TPM Module in Desktops vs. Notebooks (Roger L. Kay, Endpoint Technologies Associates)

8

Trusted Computing- eine Einfahrung

Diese Entwicklung ist durchaus vergleichbar mit der Einfahrung der USB-Schnittstelle. Vom Abschluss der ersten Spezifikation bis zur ihrer allgemeinen Verfagbarkeit sind ebenfalls etwa zehn Jahre ben6tigt women.

3 Neue V e r t r a u e n s m o d e l l e etablieren Nun ist es das Ziel von Trusted Computing Computing die Sicherheit von und das Vertrauen in die ITSysteme zu erh6hen. Aber das Thema Vertrauen und Sicherheit ist heute in unserer vernetzten Wissensund Informationsgesellschaft ein komplexes und vielschichtiges Thema. Das Internet ist sehr schnell zu einem ~iugerst grogen und komplexen Kommunikations- und Informationssystem herangewachsen, das fiber alle geographischen, politischen, kulturellen und administrativen Grenzen hinausgeht. Es stellt somit eine ungewohnte Herausforderung far die internationale Gesellschaft dar. Dabei ist jedoch festzustellen, dass in den letzten Jahren die Auswirkungen von Sicherheitsproblemen nicht kleiner, sondern sehr viel gr613er geworden sind und dass das Vertrauen in die angebotenen Dienste zwangsl~iufig durch negative Erfahrungen immer kleiner wird. Diesen Herausforderungen muss mit entsprechenden L6sungen angemessen begegnet werden. Aber was heil3t eigentlich Vertrauen und Sicherheit far eine vernetzte Wissens- und Informationsgesellschaft?

3.1 IT-Sicherheit und deren Bedeutung Die IT-Sicherheit hilft, die Risiken bei der Nutzung von IT-Produkten und IT-Angeboten zu minimieren. Bis heute nutzen die Angreifer jede Systemschwachstelle, um durch den Diebstahl von Identitfitsdaten, das Passwort-Fishing sowie Viren, Wtirmer und Trojanische Pferde u.a. die IT-Anwendungen negativ zu beeinflussen und den Nutzer zu verunsichern. Es ist leider festzustellen, dass auch die von uns allt~iglich genutzten Dienste, wie z. B. E-Mail-Dienste oder Online-Banking, immer wieder Schwachstellen offenbaren, die ihre Anwendbarkeit far kritische Gesch~iftsprozesse aus einer Risikobetrachtung heraus in Frage stellen. Die privaten Benutzer sind mit diesen Sicherheitsproblemen fiberfordert. Sie haben oft keine Chancen und M6glichkeiten damit umzugehen, weil sie nicht genau wissen, wie sie sich verhalten mfissen und wie sie sich angemessen scht~tzen k6nnen. Selbst Experten f~illt das zuweilen schwer. Aus diesem Grund sollen passende IT-Sicherheitmal3nahmen helfen, das Risiko eines Schadens angemessen zu reduzieren. Trusted Computing ist ein Sicherheitskonzept, das helfen wird, dieses Ziel nachhaltig zu erreichen.

3.2 Was ist und wie entsteht Vertrauen? Hundertprozentige Sicherheit kann es nicht geben. Risiken lassen sich durch geeignete Mal3nahmen minimieren, Restrisiken verbleiben jedoch immer. Der konkrete Anwendungskontext bestimmt das Mal3 an Restrisiken, das toleriert werden kann. Wird dieses Mag regelm~igig nicht fiberschritten, stellt sich Vertrauen ein. Mit der stetigen Weiterentwicklung der Angriffsverfahren erh6hen sich die Risiken. Damit das zul~issige Restrisiko nicht fiberschritten wird, ist die kontinuierliche Weiterentwicklung der Schutzmagnahmen eine Notwendigkeit. Vertrauen ist ein individuelles Gefahl und eine Vorbedingung far die Aufnahme von Gesch~iftsbeziehungen. Es erg~inzt bei wenigen sachkundigen Nutzern vorhandenes und bei vielen unkundigen Nutzern fehlendes Wissen um differenzierte Sicherheitsmechanismen. Vertrauen kann bei positiven Anwendungserfahrungen wachsen und bleibt solange erhalten, bis es ersch(ittert wird. Zerst6rtes Vertrauen ist

Trusted Computing- eine Einfiihmng

9

schwer wieder aufzubauen. Gerade deshalb tragen die Anbieter von elektronischen Gesch~iftsprozessen, von Sicherheitsl6sungen und Infrastrukturdiensten eine hohe Verantwortung. In unserer vernetzten Wissens- und Informationsgesellschaft k6nnen verschiedene Aspekte der Bildung und des Erhalts von Vertrauen betrachtet und diskutiert werden: 9 Vertrauen heil3t auch Zutrauen Zutrauen, dass die Anbieter von IT-Produkten und-Leistungen in der Lage sind, Technologie verl~isslich und ausreichend sicher umzusetzen. Angebotene Produkte und Dienste m%sen ordnungsgem~if3 und ggf. hinreichend transparent arbeiten, um Vertrauen nicht zu gef'~ihrden. 9 Zuverl~issigkeit erh~ilt Vertrauen Mit Zuverl~issigkeit ist gemeint, dass IT-Produkte und L6sungen genau die Dinge tun, die gew~nscht s i n d - nicht weniger, aber auch nicht m e h r - und das immer. 9 Haftung stCttzt Vertrauen Wenn sich die Anbieter in der IT-Branche ihrer Verantwortung in dem gleichen Mar3 stellen, wie wir das beispielsweise aus der Automobil-Branche kennen, und Produkthafmng bieten, kann dies Vertrauen stfitzen. 9 Vertrauen impliziert Gewissheit Gewissheit, dass sich jemand kompetent um die Angelegenheiten kftmmert, die ausreichende Sicherheit herstellen. 9 Glaubwfirdigkeit tr~igt Vertrauen Glaubwfirdigkeit der Aussagen, die zur Informationssicherheit gemacht werden, gemessen an den darauf folgenden Aktivit~iten. Die Beachtung dieser Vertrauensaspekte untersttitzt die Herausbildung einer neuen Intemetkultur der Nutzer, mit der sie risikoarm mit dem Internet und den angebotenen Diensten umgehen k6nnen. Erst dann sind sie in der Lage, sein Potential voll auszuschOpfen. Sie mt~ssen mit Regeln und richtigen Verhaltensweisen vertraut gemacht werden, um Risiken und Gefahren erkennen und abschfitzen zu k6nnen. Wichtig sind aul3erdem konkrete Hilfestellungen bei Fragen zu Anwendungen im Internet, wie Online-Banking, Intemet-Telefonie, Kaufen und Bezahlen im Internet, Informationsbeschaffung und deren Bewertung, Chatten, Spiele im Intemet und bezfiglich Raubkopien. Um Problemen vorzubeugen oder ihnen angemessen begegnen zu k6nnen, ist es wichtig zu wissen: Was darf ich und was darf ich nicht? Ein klares, t~bersichtliches und verinnerlichtes Regelwerk kann beim Intemet-Nutzer Vertrauen aufbauen. Zu all den genannten Aspekten des Vertrauens kann das Trusted Computing Konzept wirkungsvolle Beitr~ige liefem. IT Konzepte und L6sungen unterliegen einer schnellen Entwicklung. Es werden also Sicherheitsl6sungen ben6tigt, die flexible und passende Sicherheitsmechanismen beinhalten, welche entsprechend anpassungsf'~ihig sein mt~ssen, damit die Sicherheit als Basis des Vertrauens stabil bleiben kann.

4 Neue IT-Konzepte werden wirksam Zukt~nftig werden die Teilnehmer im ,,Netz" mit intelligenten Endger~iten jederzeit, von fiberall, auf allen Wegen, mit jeder Kapazit~it und in der gewfinschten Dienstqualit~it ihre gesch~iftlichen und ihre pers6nlichen Anliegen mit jeglichem Partner abwickeln.

10

Trusted Computing - eine Ein~hrung

Gesch/iftsmodelle und IT-Strukturen werden sich in Zukunft deutlich rascher ver/indern und stellen den einzelnen Teilnehmer mit seinem Equipment in den Mittelpunkt. Von der zunehmenden Ausstattung der privaten Haushalte und der einzelnen Personen mit immer intelligenteren IT-Systemen gehen inzwischen massive Rt~ckkoppelungen auf die Geschgftsmodelle, das Verh/iltnis zwischen Arbeitgeber und Arbeitnehmer und auch auf die IT-Infrastruktur der Unternehmen aus. Die gr6fJten Umw/ilzungen stogen derzeit das Web 2.0, die Technologien der Consumer Electronic und die virtuellen Communities an (z.B. Xing/openBC). Die Haupttrends sind zum Einen der Wandel von Produkten zu Services und zum Anderen die Ver~inderung des Umgangs mit der IT und deren Diensten. Der Nutzer der Zukunft empf~ingt seine Informationen von verschiedenen multimedialen Quellen und ist in der Lage, Aufgaben parallel zu verarbeiten. Des Weiteren wird der Nutzer der Zukunft in vielen FNlen zuerst Bilder, Ton, Video und dann erst Text bearbeiten. Er interagiert gleichzeitig mit vielen anderen, dabei lemt und agiert er ,,Just-in-Time". Die im Web 2.0 vernetzte Generation organisiert sich selbst, baut Gemeinschaften aufJerhalb der Unternehmen aufund zwingt Unternehmen, ihre IT-Infrastruktur und Produktwelten sowie Servicestrukturen den Wfinschen der Arbeitnehmer anzupassen. Es wird in Zukunft ffir Unternehmen immer schwieriger werden, ihre interne und externe IT-Umgebung zu kontrollieren. Ein heute tibliches Business Netz mit der ,traditionellen' Perimeter-Sicherheit und einer unflexiblen IT-Sicherheitspolicy reicht nicht mehr aus. Die neuen IT-Konzepte bedeuten, dass Informationen weltweit fiber fremde IT-Systeme und Netzstrukturen fibertragen und verarbeitet werden. Dennoch mtissen diese Informationen auf fremden ITSystemen entsprechend ihres Schutzbedarfs behandelt werden. Es werden pragmatische sowie innovative Sicherheitsans~itze und-konzepte ben6tigt, die in verteilten und komplexen Systemen einen notwendigen Sicherheits- und Vertrauenslevel schaffen k6nnen. Hier ist die Trusted Computing Technologie mit ihren M6glichkeiten ein richtungweisender Ansatz.

5 Vision Das Trusted Computing Konzept definiert 25 Jahre nach der Markteinftihrung des PCs sehr pragmatisch eine neue Qualit~it von Sicherheit und Vertrauen durch die Verbindung von allgemein verffigbaren ITSicherheitsmechanismen. Es ftihrt sowohl zu Innovationen bei Rechnerarchitekturen als auch zu neuen Umsetzungsstrategien bei Betriebssystemen oder Software-Sicherheitskomponenten. Das zugrunde liegende, strenge Standardisierungsprinzip, das von den marktentscheidenden Anbietern von Hard- und Software auch umgesetzt wird, erm6glicht nun eine kostengtinstige und investitionssichere Vorbereitung von Anwendungen, die dann von gestiegener Sicherheitsqualit~it profitieren. Die zunehmende Verbreitung von Prozessoren in Ger~iten ffir fast alle Lebensbereiche (Ubiquitous Computing) und ihre gegenseitige Vernetzung stellen dabei Sicherheits-Herausforderungen dar, denen nun auf dem beschrittenen Wege entsprochen werden kann. Sicherheitsplattformen auf der Basis von Trusted Computing bewirken bereits einen Quantensprung in der IT-Sicherheit. Mit einem geringen Mehraufwand an Hardwarekosten und einem intelligenten Ansatz an Sicherheitstechnologien k6nnen ger~itefibergreifend neue Gesch~iftsmodelle umgesetzt werden, die ein notwendiges h6heres Mal3 an VertrauenswiJrdigkeit bieten und damit unsere Zukunft sichern. Insbesondere in Deutschland, einer mittelstandsorientierten Softwarelandschaft mit mehr als 10.000 SoftwareMusern oder software-orientierten Unternehmen und einem Land, in dem die Werte Vertrauen und Sicherheit eine tiberproportionale Rolle spielen, ist die neue Sicherheitstechnologie von hohem Wert.

Trusted Computing - eine Einffihrung

11

Die Trusted Computing Technologie kann die IT-Sicherheit der eigenen Anwendungen verbessern und wird helfen, neue und wichtige Differenzierungsmerkmale far die internationale Wettbewerbsfiihigkeit aufzubauen und positiv zu nutzen. Es muss konsequent darauf geachtet werden, dass die Spezifikationen zum Trusted Computing Konzept far alle often und anwendbar bleiben und dass Anwendungsstandards entwickelt werden, mit denen sich die Unternehmen international sehr gut positionieren k6nnen. Gleichfalls muss die Nutzerakzeptanz ein vorrangiges Ziel bleiben. Bei allgemeiner Verfagbarkeit von Trusted Computing L6sungen, die ein Nutzer verwendet, weil er ihnen vertraut, wird er kfinftig auch dazu bereit sein, eigene Mitverantwortung far die allgemeine Sicherheit zu fibernehmen.

6 Zu den Beitr igen in diesem Buch Ffir das Trusted Computing Konzept sind durch die Trusted Computing Group Grundlagen und Erg~inzungen far wichtige Anwendungsbereiche spezifiziert worden. Die dabei entstandenen Industriestandards fahren zu neuen M6glichkeiten, die Informations- und Kommunikationssicherheit in der vernetzten Wissens- und Informationsgesellschaft zu verbessem. Die Herausgeber des Buches Trusted Computing wollen mit dieser Publikation fiber diese M6glichkeiten aufld/~ren und zu ihrer Anwendung ermutigen. Sie sind davon fiberzeugt, dass Trusted Computing in der Zukunfl eine ganz besondere und wichtige Rolle spielen wird. Die allgemeine Verfagbarkeit von standardisierten Hardwaresicherheitsmodulen ist abzusehen. Damit wird ein Wendepunkt im Bezug auf die Integration von Sicherheitsl6sungen in Sicherheitsarchitekturen, Betriebssystementwicklungen und Anwendungs- und Administrationswerkzeuge markiert. Sicherheitsplattformen auf der Basis von Trusted Computing sind innovativ. Sie verbinden die Erfahrungen bei der Entwicklung und Anwendung von IT-Sicherheitsl6sungen und bieten die derzeit besten Voraussetzungen, um zukfinftig Rechnersysteme sicherer und vertrauenswtirdiger zu machen. Das Spektrum der Sicherheitsqualit/~ten reicht dabei vom Grundschutz far die Anwenderumgebung oder Unternehmensnetze bis zur Unterstfitzung von L6sungen im Hochsicherheitsbereich. Mit dem Trusted Computing Konzept werden far einige Anwendungen auch neue Gesch/fftsmodelle z.B. far ein Digital Rights Management- erschlossen, die hinsichtlich der Akzeptanz durch die potentiellen Nutzer und des erforderlichen Datenschutzes sorgfNtig beobachtet werden mfissen. Im Kapitel ,,Grundlagen" wird das Basiswissen fiber die Trusted Computing Technologie und die dazugeh6rigen Sicherheitsfunktionen vermittelt, und es werden die Ziele und Arbeitsmethoden der Trusted Computing Group erl/~utert. Ausfahrlich werden die grundlegenden Funktionen des Sicherheitsmoduls (TPM) dargestellt. Ebenso behandelt wird die Weiterentwicklung und Anpassung von Betriebssystemen an die standardisierten Schnittstellen und Funktionalit/~ten des TPM, wie die Vision eines virtuellen TPM als ein flexibel in Systemumgebungen integrierbares Sicherheitskonzept. Im Kapitel ,,Sicherheitsbausteine far Anwendungen" werden weitere Sicherheitsbausteine beschrieben, die far die Einbindung der Sicherheitsfunktionen in die Anwendung wichtig sind. Es wird die Idee und Umsetzung einer Sicherheitsplattform sowie deren Sicherheitsnutzen dargestellt. Zus~itzlich werden Anwendungsfelder aufgezeigt, in denen Sicherheitsplattformen auf der Basis von Trusted Computing aus heutiger Sicht eine besondere Rolle spielen. Augerdem wird das Trusted Network ConnectionKonzept (TNC-Konzept) erl~iutert, das den Zugriff von nicht einsch/~tzbaren Rechnersystemen auf vertrauenswfirdige Netze erm6glicht. Das Kapitel endet mit der Beschreibung, wie die SmartCard in das Trusted Computing Konzept sinnvoll eingebunden werden kann.

12

Trusted Computing- eine Ein~hrung

Im Kapitel ,,Anwendungsszenarien" werden unterschiedliche Anwendungsbereiche des Trusted Computing Konzeptes und die jeweiligen Anforderungen an die Sicherheitsl6sungen behandelt. Zuerst werden Umsetzungsideen zum Enterprise Rights Management beschrieben. Anschliegend wird aufgezeigt, welche Aspekte beim Key-Management der Trusted Computing-Funktionalit~it berficksichtigt werden mfissen. Dann wird geschildert, welche weiteren Aspekte von Trusted Computing bei Hochsicherheitsanwendungen zu berticksichtigen sin& Das breite Wirkungsspektrum des Trusted Computing Konzeptes wird anhand erreichbarer neuerer Sicherheitsqualit~iten bei mobilen Anwendungen und embedded Systems im Automotiv-Bereich dargestellto Im Kapitel ,,Datenschutz und rechtliche Aspekte" sind grundsgtzliche Positionen zum Verh~iltnis zwischen datenschutzrechtlichen Maximen und den Ausgestaltungsm6glichkeiten der Trusted Computing L6sungen sowie eine Bewermng der rechtlichen Chancen und Risiken zu finden.

Literatur [TTT07]

Trusted Computing Whitepaper: http://www.teletrust.de/fileadmin/files/publikationen/Whitepaper/ TTT-TC_070330.pdf

Grundlagen

Die Trusted Computing Group Thomas Rosteck Infineon Technologies AG, Am Campeon 1-12, Neubiberg [email protected]

Zusammenfassung Trusted Computing ist nicht nur ein technologischer Begriff. Um die Technologie zu definieren und umsetzbar zu machen, wurde die Trusted Computing Group gegr~ndet. Diese Organisation und die wichtigsten Ziele zu erkl~iren, ist Aufgabe dieses Artikels. Dabei sollen auch die aktuellen Hauptfokusgebiete der TCG erl~iutert werden. Tiefere technische Einblicke in die Standards der TCG kann der Leser dann im folgenden Artikel finden.

1 Trusted Computing 1.1 Was ist Trusted Computing? Die Forderung nach Trusted Computing (Vertrauenswfirdige Datenverarbeitung) ist nicht wirklich neu~ Schon zu Beginn der Datenverarbeitung wurden sensitive und geheime Informationen genutzt, gespeichert und weitergeleitet. Die milit~irische Nutza.mg war einer der wesentlichen Treiber ~ die Weiterentwicklung der Kryptographie, deren Methoden die Basis Dr das heutige Trusted Computing sind~ Und schon immer war der Schutz der Daten und Systeme (oder umgekehrt der Angriff darauf) einer der wichtigen Ziele. Seit dieser Zeit haben sich einige Dinge ge~indert. Die Rechenleistung der Computer, die Verfagbarkeit von Informationen und insbesondere der Zugriff auf Daten und Systeme. W~ihrend fraher ,,Datentransfer" das Liefern von Lochkarten war, kann man heute riesige Datenmengen online verschicken oder anfordem. Natfirlich steigen damit auch die M6glichkeiten, gespeicherte Daten und verbundene Computer anzugreifen. Interessanterweise beinhaltet der Begriff ,,Trusted Computing" den Begriff ,,Vertrauen". Vertrauen in Zusammenhang mit Maschinen scheint zun~ichst einmal ungew6hnlich, da man Vertrauen in der Regel in Personen und ihre Handlungsweisen hat (oder auch nicht). Aber das ist eine passende Analogie, denn bei der Datenverarbeitung geht um das Vertrauen in ein vernfmftige und sichere Implementierung der Prozesse, Softwareprogramme und Hardwareplattfomen. Die Definition der TCG zu Vertrauen ist daher: ,,Man kann jemanden oder etwas vertrauen, wenn es sich f'tir einen bestimmten Zweck jedes Mal erwartungsgemN3 verMlt. ''1

1 An entity can be trusted if it alwaysbehavesin the expectedmannerfort the intendedpurpose. N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 15-20

I6

Die Trusted Computing Group

1.2 Der Anfang" Trusted Computing Platform Alliance Die Trusted Computing Platform Alliance (TCPA) wurde im Jahr 1999 von Compaq, HP, IBM, Intel und Microsoft gegrfindeto Innerhalb k{irzester Zeit stieg die Anzahl der Mitglieder auf fiber 200. Klarer Fokus der Aktivit~iten waren PC's und Notebooks, obwohl bereits damals auch fiber andere Plattformen nachgedacht wurde. Das Ziel der TCPA war die Schaffung vertrauenswth'diger Komponenten fttr alle Computersysteme. W~ihrend und besonders am Ende der ersten Standardisierungsaktivit~iten stellte sich dann jedoch heraus, dass die alte TCPA-Organisationsstruktur, die z.B. Einstimmigkeit bei den Beschltissen und Standards forderte, bei dieser Gr613e nicht mehr effizient genug war. In einer Organisation dieser Gr613e eine neue Satzung umzusetzen, erwies sich ebenfalls als schwierig, da auch hier alle Mitglieder h~ttten zustimmen mfissen. Im Jahre 2003 wurde deshalb eine Nachfolgeorganisation, die Trusted Computing Group (TCG) [TCG03] mit einer reformierten und angepassten Satzung (z.B. nur noch 2/3 Mehrheit ffir BeschlCtsse) geschaffen und auf diese die Ziele und das Wirken der TCPA fibertragen.

1.3 Die Trusted Computing Group 1.40rganisation Mit der Trusted Computing Group wurde auch eine neue Struktur aufgesetzt, die eine effiziente Standardisierungsarbeit erlaubt. So wird die TCG von einem Board of Directors (BOD) gesteuert, das die endgfiltigen Entscheidungen flir die TCG trifft. Unterstt~tzt wird das BOD vom Technical Committee, dem h6chsten technischen Gremium der TCG. Alle Spezifikationen mfissen das Technical Committee passieren, bevor das BOD sie zur Ver6ffentlichung freigibt. Die eigentliche technische Standardisierung findet in den Arbeitsgruppen statt. Zus~ttzlich hat die TCG noch eine Marketing-Arbeitsgruppe, die die Zusammenarbeit mit der Presse, die Messeaktivit~tten der TCG und die Planung der Marketingaktivit~iten im Rahmen der Ver6ffentlichung yon Spezifikationen verantwortet. Neu bei der TCG im Gegensatz zur TCPA sind auch die unterschiedlichen Mitgliedslevel: ~ Promotoren sind der h/Jchste Level der TCG und werden nur auf Einladung des BOD ernannt. Sie erhalten einen Sitz im BOD und im Technical Committee. ~ Contributoren sind Mitglieder, die aktiv in Arbeitsgruppen mitarbeiten und vollen Einblick in den Arbeitsstand der Spezifikationen haben. ~ Adaptoren sind Mitglieder, die frfihzeitig Zugriff auf neue Spezifikationen erhalten, die aber nicht in Arbeitsgruppen mitarbeiten wollen. Der Mitgliedsbeitrag der TCG richtet sich nach dem Level der Mitgliedschaft. Um auch kleinen Firmen die M6glichkeit der Teilnahme zu er6ffnen, wurde die Small-Adaptor-Mitgliedschaft fftr kleinere mittelst~tndische Betriebe eingeffihrt, Dr die ein geringerer Mitgliedsbeitrag berechnet wird. Zus~itzlich hat die TCG nach umfangreichen Diskussionen mit verschiedenen Regierungen und anderen Organisationen noch weitere Programme ins Leben gerufen, die die Kommunikation mit diesen Institutionen erm6glichen sollen.

Die Trusted Computing Group

17

Das Liaison-Programm erm6glicht die Zusammenarbeit mit Regierungsorganisationen sowie Universitgten und anderen Instituten. Diese Organisationen k6nnen aktiv in den Arbeitsgruppen mitwirken. Beim Mentor-Programm, das sich haupts/~chlich an Forschung und Lehre richtet, erh/~lt diese Institution einen freiwilligen Mentor einer der TCG-Mitgliedsfirmen, der Fragen beantwortet und bei Projekten unterstfitzen kann. Neben diesen Programmen wurde noch ein Advisory-Board etabliert, in dem bekannte Personen aus der IT-Sicherheitsbranche die TCG beraten.

2 Das Ziel" Hardware-basierte Sicherheit Die TCG definiert ihr Ziel wie folgt: "Trusted Computing Group members develop and promote open, vendor-neutral, industry standard specifications for trusted computing building blocks and software interfaces across multiple platforms." (www.trustedcomputinggroup.org/home) Dabei fokussiert sich die TCG aufhardware-basierte Sicherheit. Das bedeutet, dass die angebotenen Sicherheitsfunktionen sich auf Hardware-Komponenten zurfickf'thhren lassen, die bestimmte Sicherheitseigenschaften haben mtissen. So m~ssen diese z.B. gegen logische Angriffe von Viren und Trojanern resistent sein und auch Gegenmal3nahmen gegen die sogenannten Dictonary-Attacks (WOrterbuchangriffe) auf die Passworte der Sicherheitskomponenten implementiert haben. Zusgtzlich sind aber auch Gegenmaf3nahmen gegen bestimmte physikalische Angriffe notwendig, bei denen die Sicherheitskomponente mit physikalischen Methoden, z.B. mit l~erspannungen attackiert wird. Diese Widerstandsf'ghigkeit gegen Angriffe ist eine der wesentlichen Unterschiede, die die Trusted Computing Group in ihren Standards gegent~ber konventionellen Sicherheitsimplementierungen bietet. Wesentlich bei allen Umsetzungen von Sicherheitsfunktionen in diesen Komponenten ist, dass die Implementierung nachvollziehbar und durch vertrauenswttrdige Dritte fiberprfifbar sein muss. Die TCG hat sich entschlossen, die Sicherheitsevaluierungen z.B. ffir die Trusted Platform Module (TPM) nach dem international zwischen Regierungsorganisationen definierten Common Criteria Schema [CC01] durchzuffihren. Mit der Evaluierung durch unabMngige Sicherheitslabore und der Zertifizierung dieser Untersuchung durch Sicherheitsbeh6rden, wie z.Bo in Deutschland dem Bundesamt ffir Sicherheit in der Informationstechnik (BSI), erhalten Kunden und Anwender eine transparente Best~itigung der Sicherheitsqualit~tt der von ihnen eingesetzten Komponenten.

3 Das Spektrum der TCG Inzwischen besch~iftigt sich die TCG nicht mehr nur mit PCs und Notebooks, auch wenn diese am weitesten fortgeschrittenen Spezifikationen immer noch die Vorreiterrolle bei der Umsetzung der Spezifikationen in Produkte haben. Viele der Mitglieder haben inzwischen den Vorteil der TCG ,,building blocks" ffir ihre spezielle Branche erkannt und so haben sich eine Reihe von Arbeitsgruppen gebildet, die der Adaptierung der TrustedComputing-Komponenten in einem speziellen Plattformtyp Rechnung tragen. So sind die Architekturen, die Leistungsanforderungen und auch die Aufgabenbereiche, die solche Komponenten erfallen sollen, durchaus unterschiedlich, wenn es sich um einen PC, einen Server, ein Mobiltelefon oder um ein

18

Die Trusted Computing Group

Speichermedium handelt. Dies sind dann auch die im Moment aktiven Arbeitsgruppen, die im Folgenden kurz betrachtet werden sollen. Dabei kommt es weniger auf die einzelnen Arbeitsgruppen an, als vielmehr auf die Bedeutung, die Trusted Computing in diesen Bereichen erreicht hat. Das zeigt auch das ,,Big Picture" der TCG, mit dem die TCG ihre heutigen Fokusbereiche definiert.

Abb. 1: Hauptfokusgebiete der TCG (Quelle: TCG) In den folgenden drei Kapiteln sind beispielhaft Plattformen erl~iutert, wobei im Wesentlichen kurz auf die Verwendungsm6glichkeiten (die ,,Use Cases") eingegangen werden soll.

3.1 Die Computerwelt PCs und Notebooks sind seit 1999 die Vorreiter in der Arbeiter der TCG (bzw. vor 2003 der TCPA). Hier wurde das sogenannte TPM (Trusted Platform Module) standardisiert, d a s - fest mit dem Mainboard des Computers verbunden- folgende wesentliche Aufgaben hat: ~ Prfifen der Systemintegrit~tt 9 Authentisierung und attestieren des Sicherheitsstatus des PCs ~ Sicherer Speicher Dabei wurde sichergestellt, dass der Benutzer bzw. der Eigen~mer des PCs die ultimative Kontrolle fiber das TPM hat.

Die Trusted Computing Group

19

Das TPM ist Bestandteil der Root of Trust des PCs, an denen sich andere Komponenten, z.B. das Betriebssystem, sicherheitstechnisch verankem k6nnen. Die Funktion, bestimmte Geheimnisse (z.B. Schl~ssel) sicher und unver~inderbar aufbewahren zu kOnnen, bietet die Grundlage auf der auch Applikationen ihre Sicherheit aufbauen k6nnen. Eine genauere Beschreibung der Aufgaben des TPMs findet sich im n~ichsten Artikel dieses Buches.

3.2 Mobiltelefone Mobiltelefone entwickeln sich immer weiter. In einigen Bereichen ist es schwierig zu definieren, wo die Grenze zwischen Mobiltelefon und Notebook genau liegt. Leistungsf'~thige Gergte haben inzwischen viele der PC-Applikationen integriert und werden mit PCs synchronisiert bzw. greifen auf dieselben Daten in Netzwerken zu. Damit wird die Bedrohung f'~ Mobiltelefone denen far PCs immer ~ihnlicher. Aber auch far Ger~ite, die ,,nur" zum Telefonieren da sind, gibt es Sicherheitsanforderungen, die teilweise sogar gesetzlich vorgeschrieben sind. So muss ein Telefon fiber seine eindeutige Seriennummer (IMEI) jederzeit identifizierbar sein. Die Notruffunktion muss in jedem Land unabhgngig vom aktuellen Provider funktionieren, was Anforderungen an die Systemintegrit~it stellt. Somit gibt es viele Grfinde far die gesamte Bandbreite der Mobiltelefone, Komponenten des Trusted Computing zu verwenden. Die Use Cases, die der Mobiltelefonspezifikation der TCG zugrunde liegen, beschreiben unter anderem folgende Aufgaben: [TCG04] 9 Schutz der Plattform-Integrit~it 9 Unterstfttzung der Plattform-Authentisierung 9 Unterstfitzung einer robusten Digital Rights Management (DRM) Implementierung, um neue Gesch~iftsprozesse zu erm6glichen 9 Schutz einer sicheren Software-Download-Funktion 9 Mobile Bezahlfunktionen und mobile Tickets 9 Schutz der Benutzerdaten auf dem Gergt sowie der Privatsph~ire des Benutzers

3.3 Speichermedien Bei Speichermedien stehen im Moment Festplatten im Vordergrund. Wesentlich far die Besch~iftigung mit diesen Speichern ist, dass insbesondere beim PC die CPU und die zugeh6rige Peripherie selbst nur beschr~inkt far den Schutz der Daten auf Festplatten sorgen kann. In vielen FNlen k6nnen alle Sicherheitsmal3nahmen der Plattform durch das Ausbauen der Festplatte und Einbauen in ein anderes System umgangen werden. Aber auch weitere, zusgtzliche Use Cases pr~igen die Arbeit der StorageArbeitsgruppe: [TCG05] 9 Vertrauenswfirdige Verbindung zwischen Speichermedium und Plattform 9 Unaufl6sbare Verbindung zwischen Speichermedium und Plattform 9 Gescht~tzter Speicher far sensitiver Daten 9 Integrit~it der Festplatte und sicheres Update der Firmware

20

Die Trusted Computing Group

4 Fazit" Zukunft des Trusted Computing Die Diskussion fiber Trusted Computing geht im Moment fiber die Aktivit~iten der TCG hinaus. Weiter Applikationen beginnen sich mit dem Konzept und den Vorteilen zu besch~iftigen. Schutz der Integrit~it von Daten und Gergten sowie starke Authentisierung- um nur einige der Vorteile zu n e n n e n - sind in fast allen vernetzten Systemen notwendig. Obwohl die TCG bisher noch keine Spezifikation hierffir definiert hat, gibt es bereits Trusted Computing Komponenten z.B. in Routern und anderen Netzwerkkomponenten. Wesentlich dabei ist die hardware-basierte Sicherheit, die eine neue Qualit~it von ,,Schutz" zur Verffigung stellen kann. Auch viele Artikel diese Buches demonstrieren, dass sich unterschiedlichste Organisationen mit sehr unterschiedlichen Anforderungen und Blickwinkeln intensive mit dem Thema auseinandersetzen. Daher ist zu erwarten, dass die Konzepte des Trusted Computing in vielen unterschiedlichen Applikationsbereichen Anwendung finden werden. Die Trusted Computing Group muss dabei nicht zwangsl~tufig die einzige Standardisierungsinstitution darstellen, bietet aber eine gute Grundlage fiir weitere Aktivit~iten.

Literatur [TCG03] https://www.trustedcomputinggroup.org/about/, Webseite der TCG [CC01 ] http://www.bsi.de/cc/index.htm, Gemeinsame Kriterien far die Prtifung und Bewertung der Sicherheit von Informationstechnik [TCG04] Mobile Phone Working Group, Use Case Scenarios, v2.7, Trusted Computing Group [TCG05] Storage Work Group, Use Case Whitepaper-vl,0, Trusted Computing Group

Trusted Computing Grundlagen Hans Brandl Infineon Technologies AG, Am Campeon 1-12, Neubiberg hans.brandl@infineon, com

Zusammenfassung Der Mangel an Sicherheit und Verl~isslichkeit in den heutigen vernetzten IT-Systemen hat in den letzten 20 Jahren zu immer intensiveren und komplexeren Angriffen auf die Sicherheit der Computer-Infrastruktur gefahrt. Besonders in der PC-Welt mit ihrer tiefen Vemetzung und dem Einsatz von SW, die auf diese stark zunehmenden Angriffe nicht vorbereitet war, hat dies zu erheblichen Sch~iden im Gesch~ifts- aber auch im privaten und 6ffentlichen Bereich gefahrt, die zudem auch Auswirkungen auf die gesamte volkswirtschaftliche Infrastruktur mit sich brachten. Wghrend man jahrelang mit hohem Forschungs- und Entwicklungsaufwand vergeblich versuchte durch den punktuellen Einsatz von verschiedenen kryptographischen und anderen Sicherheitsverfahren diese Systeme zu schatzen entwickelten sich neue Angriffsverfahren vor allem gegen die Integrit~it der einzelnen Computer-Plattformen. Hinzu kam, dass durch die zunehmende Komplexit~it moderner Computersysteme (OS und SW-Umfiinge im Gigabyte Bereich) es nicht mehr m6glich war, die Korrektheit solch grof3er Systeme bereits bei der Entwicklung zu verifizieren. Prinzipiell ungewollte Entwicklungs-Fehler wirkten sich deshalb in der gleichen Weise sch~idlich aus, wie von augen in das System eingebrachte Angriffe. Mit der Trusted Computing Technologie wurde auf diese ausufernde Bedrohungssituation reagiert und Methoden und Werkzeuge geschaffen, mit denen die Uberpriifung der Integritfit eines Systems m6glich wird. Damit kann dann festgestellt werden, ob ein System ungewollt ver~indert wurde (gleich ob durch einen externen Angreifer oder durch einen internen Fehler), ob dem System noch Vertrauen entgegengebracht werden kann oder ob es far bestimmte (sicherheitskritische) Anwendungen nicht mehr einsetzbar ist. Prinzipiell werden dabei bekannte kryptographische Methoden und Prozeduren verwendet, allerdings mit einer vollkommen neuen Ausrichtung hin zur Integrit~its-Uberp~fung. Die Weiterentwicklung der Trusted Computing Technologie l~isst zudem erwarten, dass nicht nur die Integrit~it eines Systems verifizierbar ist, sondern dass mit ~ihnlichen Methoden auch Safety (Eigensicherheit) und Ausfallsicherheit verbessert werden kann. Dies l~isst im weiteren auch auf die weitere Verbesserung der Eigenschaften, Stabilit~it und Funktionalit~it, von komplexen Systemen z.B. im Verkehrswesen ( Automobiltechnik ) und bei industriellen Anlagen hoffen. Das Trusted Computing Kernelement ist das Trusted Plattform Module (TPM), ein Sicherheits-Chip auf der Prozessorbaugruppe (fihnlich einem sicheren Chipkartenprozessor), der sowohl die Integritfit der SW messen kann als auch eine sichere, geschiitzte Umgebung f~r kritische Variablen und Schlt~ssel bereitstellt. Dieses TPM ist aber lediglich ein passives Element das wiederum von einem sicheren Betriebssystem gesteuert werden muss. FOr die Erfallung aller Erwarmngen ist zudem eine neue Generation von Prozessoren und Peripherie-Baueinen notwendig die zusfitzliche Schutz-Mechanismen enthalten. Dazu geh6ren z.B. sichere Tastatur-Encoder, die die Eingabedaten bereits an der Tastatur verschlt~sseln und sicher zum Zentralprozessor leiten, eine Graphikeinheit die verhindert, dass eine Bildschirmausgabe eines Programms nicht durch ein anderes Programm iiberschreiben werden kann und na~rlich auch sichere Speicher- und Kommunikationsmedien. Erst das Zusammenwirken vieler Teile die sich auch gegenseitig scht~tzen, erm6glicht die Entwicklung wirklich sicherer, vertrauenswardiger Computerplattformen.

1 Einleitung Bisherige konventionelle Ans~itze zur Entwicklung von sicheren Computersystemen beruhten darauf, dass vorhandene, unsicherere System-Keme mit einer zunehmenden Zahl von Schutzschichten ummantelt wurden (Firewall, Virenscanner, Verschl~sselung usw.). Diese Systeme befinden sich stgndig N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 21-42

22

Trusted Computing Grundlagen

in einem nicht zu gewinnenden Wettlauf mit immer neuen Angriffsarten: Der Kern ist ja immer noch prinzipiell unsicher und damit ein lohnendes Ziel. Die Schutzschichten sind zudem auf der gleichen gef~ihrdeten Umgebung mit den gleichen Methoden wie der zu schfitzende Kern realisiert. Gelingt es einem Angreifer durch eine Vergnderung des Codes oder der Daten diese Schutzschichten oder aber den Kern selber gezielt zu ver~indern, so ist ein solcher Angriff in der Regel erfolgreich. Dabei hilft auch nicht dass z.B. durch den Einsatz von hochsicheren Chipkarten kryptographische Schlftssel oder Zertifikate sicher abgespeichert werden k6nnen und besonders kritische Operationen nur im Inneren solcher sicherer Chipkartenprozessoren ausgeftthrt wurden: Der Angreifer geht eben nicht gegen das hochgescht~tzte Chipkartensystem vor, sondern vergndert mit wesentlich einfacheren Mitteln die Computerplattform auf der ein solches System realisiert wurde, sodass z.B. der Chipkarte vollkommen andere Daten zum Signieren vorgelegt wurden. Typische, ver6ffentlichte Beispiele sind die bereits vor einigen Jahren vorgeffihrten Attacken gegen das HBCI-Homebanking System oder auch die in [Cre01 ] beschriebene, m6gliche Attacke gegen eine Digitale Signamrapplikation, die sogar gemN3 deutschem Signaturgesetz zertifiziert war~ Generell muss dabei festgestellt werden, dass auch heute immer noch typische Anwendungen nach dem Signaturgesetz lediglich einen Gesamt-Sicherheitslevel besitzen, der dem schwgchsten Glied in der Kette, eben der Standard-Computerplattform entspricht. Der mit Trusted Computing (TC) m6gliche, neue Sicherheitsansatz integriert hingegen die ben6tigten Sicherheitsfunktionen (wie Integrit~itsfiberprfifung von SW und Hardware, digitale Signatur und 12Jberprfifung von Datenkomponenten, sicheres Generieren und Verwalten von Schl~isseln und digitalen Zertifikaten, sicheres Booten, Virmalisierungs-Kompartments) in den Systemkern und sorgt ftir Sicherheit von innen heraus. Durch die Universalit~it des TC-Konzepts wird es zudem m6glich, von den bisherigen deprimierenden Sicherheits-Erfahrungen aus der PC-Welt zu lernen und mit dieser neuen Technologie vollkommen neue Konzepte auch f'ttr die sonstigen Rechnernetze und-Systeme zu entwickeln. Damit k6nnen ~ihnliche Fehler wie bei PCs vermieden und vertrauenswfirdige Plattformen entwickelt werden, die ffir die Weiterentwicklung der Computer- und Netzwerktechnologie dringend erforderlich sind. TC-Systeme k6nnten theoretisch nach vielerlei Grunds~itzen und Prinzipien aufgebaut werden. Grundsgtzliche Bedeutung hat allerdings bisher nur die Standardisierungsarbeit der Trusted Computing Group (TCG) [TCG01] erreicht. Mittlerweile etwa 170 Firmen und Organisationen als Mitglieder (darunter alle Nhrenden Firmen) und deren Spezialisten arbeiten gemeinsam an der Schaffung des Standards. Bei Drucklegung diese Buchs war auf der often zug~inglichen Webseite der TCG [TCG02] etwa 2000 Seiten Standardisierungstext zug~inglich. Da zudem der TCG Standard anders als sonstige Standards nicht mit Lizenzen belegt und frei verfagbar ist, erm6glicht diese freie Verbreitung eine entsprechende Akzeptanz und damit den Einsatz von TC in einem breiten Umfeld von Computer-Plattformen und Systemen. Dieser Beitrag beschreibt demzufolge auch im Wesentlichen die TC-Implementierung nach dem TCG-Standard: Der unter diesen Prgmissen geschaffene Standard impliziert eine sichere Hardwarestruktur, dessen Hauptkomponente, das Trusted Plattform Module (TPM) [TCG04], als hochintegrierter Sicherheitschip spezifiziert ist. Er beruht zu einem wesentlichen Teil auf den Erfahrungen der letzten Jahre fiber hochsichere Chipkarten und ihren Anwendungen, von denen folgerichtig wesentliche Teile der Architektur und Sicherheitseigenschaften t~bemommen wurden~ Mmlich wie wir mit dem kryptographischen Mechanismen der Chipkarte die sensitiven und geheimen personenrelevanten Daten sowie kritische Prozesse in einer Sicherheitsumgebung schfttzen, k6nnen im TPM mit diesen Funktionen auch die Integrit~it, aber auch der Schutz von Benutzerdaten einer Plattform abgesichert werden. Nochmals prgzisiert:

Trusted Computing Grundlagen

23

Der TCG-Standard bietet Integrit~itsprafung, Authentifizierung und Beglaubigung der Plattform, nicht des Anwenderso Zus~itzlich erlaubt der Standard die sichere Speicherung yon kritischen Geheimnissen wie z.B. Schlfisseln. Ft~ die Authentisierung des Anwenders ist die Interaktion mit Chipkarten und ~ihnlichen kryptographischen Token vorgesehen. Das EinNgen eines sicheren TPMs in eine Computer Plattform die andererseits noch mit unsicheren Standard-Bausteinen aufgebaut ist verhindert allerdings keinen intelligenten Angriff mit Hardware-Debugging und Analyse-Tools. Zwar erh6ht das TPM die Widerstandf'~higkeit und das Sicherheitsniveau einer solchen Plattform (vom TPM geschfitzte Daten sind quasi unangreifbar), trotzdem muss einkalkuliert werden, dass auch eine solche konventionell aufgebaute Plattform keine 100%ige Sicherheit gegen einen direkten physikalischen Angriff vor Ort erreicht wird. Das derzeitige Schutzziel will Computerplattformen gegen logische Angriffe von augen und Fehler des eigenen Systems schfitzen, nicht aber gegen physikalische Angriffe des eigenen Besitzers. Einen wesentliche Verbesserung und H~irtung auch gegen solche fortgeschrittenen und komplexen Angriffsverfahren wird erst die n~ichste Generation der ebenfalls nach TC-Prinzipien entworfenen Prozessoren und Peripherie-Bausteine bringen.

2 Trusted Computing Systeme" Hardware und Software m issen zusammenwirken Trusted Computing Systeme bestehen aus drei wesentlichen Grundbestandteilen, die sich gegenseitig erg~inzen mf~ssen um wirksam zu werden:

2.1 Trusted Plattform (definiert durch die TCG) Eine Trusted Plattform ist eine sichere Rechnerplattform (PC-Prozessorbaugruppe aber auch andere Computer wie zB. Embedded Systeme), die in der Lage ist, die elementaren Geheimnisse, Zertifikate und Schlt~ssel sowie kritische (vor allem Krypto-) Operationen sicher in einer geschtitzten HardwareUmgebung zu halten bzw. auszuffihren sowie ihre Integrit~it zu messen. Als wesentliches Element dafar wurde von der TCG dazu das Trusted Plattform Module (TPM) definiert. Diese damit geschaffene Trusted Plattform soll betriebs-systemunabh~ingig sein und mit standardisierte Funktionen und Sicherheitsschnittstellen (als Applikation Programm Interface, API) dem jeweiligen Betriebssystem und den Applikationen vertrauenswfirdige Sicherheitsfunktionen za~rVerfagung stellen. Die TCG hat mit einer sehr pr~izisen und granularen Definition und Spezifikation der TPM-Funktionalit~it und vor allem des zugeh6rigen TPM Software Stacks (TSS) die Voraussetzungen geschaffen, dass solche Baugruppen auch aus verschiedenen Quellen verffigbar werdeno

2.2 Sichere Prozessorarchitektur (definiert durch die

Prozessorhersteller)

Die meisten aus der PC-Welt bekannten Sicherheitsprobleme lassen sich auf die Universalit~it der heutigen Prozessoren zurfickf'tihren mit der Anwendung und Ausnutzung von komfortablen Befehls- und Addressierfunktionen. Eigenschaften wie die sehr flexible Nutzung yon Pointer-Registern geben einerseits dem Programmierer alle M6glichkeiten seine Daten zwischen Data-, Code- und Stack-Segmenten beliebig hin und her zu bewegen und zus~itzlich erlauben die DMA-Funktionen der Peripherie den Transfer von grogen Datenbl6cken, ohne dass die CPU dabei fiberhaupt diese Daten zu Gesicht be= kommt. Andererseits sind genau dies die Funktionen, die Angriffe (gleich ob lesend oder ver~indernd) erst erm6glichen oder erleichtern. Nach nicht besonders erfolgreichen Zwischenl6sungen, haben mitt-

24

Trusted Computing Grundlagen

lerweile die beiden grogen Prozessorhersteller Intel und AMD jeweils eine neue Generation mit zusgtzlichen Sicherheitsfunktionen geschaffen, die diese Architekturschw~ichen konsequent beschr~inken. Die Firma ARM stellt ~ihnliche, sichere Prozessoren far den Einsatz in Embedded Systemen (Steuerungen far Mobiltelefone, Unterhaltungselektronik, Industrie und Autos) her, deren neueste Varianten ebenfalls nach Sicherheitskriterien entworfen sind und far TC geeignet sind. All diese Hersteller untersttitzen mit Ihren Prozessoren die definierten Sicherheitsfunktionen der TCG Trusted Plattform (TP), sind aber nicht Objekte der TCG-Standardisierungsarbeit.

2.3 Sichere und vertrauensw0rdige Betriebssysteme Sichere Betriebssysteme sind die Voraussetzung um die Sicherheits-Funktionen der sicheren Prozessoren als auch der TP ftberhaupt nutzen zu k6nnen und diese Dienste dem Anwender zur Verfagung zu stellen. Entgegen der optimistischen Annahmen der letzten Jahre ist gerade dieser wesentlichste Bestandteil einer sicheren Trust-Architektur das am schwersten zu realisierende, langwierigste und meist unterscMtzte Element geworden. Zu Beginn der Trusted Computing Architektur Aufbruchsphase wurde von Betriebssystemherstellem noch voller Optimismus angenommen, dass sich eine spezielle Sicherheitsumgebung, ~ihnlich wie die bekannte DOS-Box, einfach als vertrauenswtirdige Umgebung in ein normales Betriebssystem integrieren lassen wtirde. Erst die Beschfiftigung mit den vielen, vielen kleinen, aber grunds~itzlichen Realisierungsproblemen (wie denn z.B. ein sicherer IO-Kanal parallel zu einem traditionellen IO-Kanal auf die gleiche Peripherie zugreifen k6nne, trotzdem aber keine verborgenen KanNe zwischen Normal- und Trust-Betriebssystem existieren sollten) und viele weitere Interoperabilit~its-Probleme zeigten, dass man sich pl6tzlich mit einer bisher str~iflich vernachl~issigten, besonderen SW-Technologie bescMftigen musste. W~ihrend man z.B. aus der Chipkartentechnologie durchaus wusste, wie man kleine hochsichere, genau spezifizierte Sicherheits-Betriebssysteme far alle m6glichen Anwendungen (wie sicheres Banking, Identifikationssysteme und vieles mehr, die noch dazu bis CC EAL5 zertifizierbar waren) konstruieren konnte, erkannte man, dass die H~irtung von KomfortBetriebssystemen doch eine deutlich andere Gr613enklasse dieses Problems war. Derzeit arbeiten alle wichtigen OS- und Prozessorhersteller, aber auch OpenSource Gruppen an der Schaffung einer geeigneten Systemarchitektur, die sowohl HW als auch SW-Komponenten miteinander verbindet. Gerade bei dem jetzt pl6tzlich aufgetretenen Bedarf nach entsprechendem Trusted OS-KnowHow r~ichen sich die mittlerweile eingetretene Gew6hnung bzw. die Tolerierung bekannter Schwachstellen von Betriebssystemen und ghnlichen SW-Entwicklungen, sowie die Vernachl~issigung von Sicherheitsansprfichen. Sicherheit, Vertrauen und Verfagbarkeit waren bisher nicht unbedingt die Produktmerkmale, die eine Investitionsentscheidung der potentiellen Anwender wesentlich beeinftusste.

3 Grundlegende Sicherheitsfunktionen im TCG Standard Eine Trusted Plattform gem~ig der TCG besteht aus vertrauenswtirdiger Hard- und Software auf der Plattform, der sicheren Kommunikation zwischen Plattformen, sowie der An- und Einbindung von externen Trustcentern (Certification Authorities (CA), bereits bekannt aus den ,,konventionellen" Chipkarten-Signaturl/3sungen) um die Identit~it und Integrit~it einer Plattform auch gegent~ber der Aul3enwelt sicher bestimmen zu k6nnen.

Trusted Computing Grundlagen

25

3.1 Das Trusted Platform Modul (TPM) Gem~il3 der TCG-Architekmr erbringt das TPM die besonders zu schfttzenden Sicherheitskernfunktionen, die deshalb auch in einer sicheren Chip-Hardware-Umgebung implementiert werden. Um die Datenschutz-Anfordemngen zu erffillen ist das TPM als passives Teil ausgelegt. Es besitzt keine M6glichkeiten den Programmablauf des Zentralprozessors oder den Boot- Vorgang aktiv zu beeinflussen oder gar zu unterbrechen. Es empf'~ingt lediglich Steuer- und Zustandsmessdaten vom Zentralprozessor, verarbeitet, speichert und liest sie wieder aus seiner sicheren Struktur aus und gibt diese Ergebnisse an den Zentralprozessor wieder zurack. Erst dort wird mit Hilfe dieser Ergebnisdaten der weitere Ablauf der S icherheitsprozeduren gesteuert. Lediglich der Zugriff zu besonderen Daten (wie z.B. Schl~sselmaterial) wird vom TPM selbst vonder Vorlage entsprechender Authentifizierungsmuster abh~ingig gemacht. Der innere Aufbau eines TPMs entspricht im Wesentlichen einem sicheren Chipkartenchip da er auch ~ihnliche Sicherheitsfunktionen ausRihrt: Schutz von Schliisselmaterial Die verschiedenen Schltisselklassen werden geschOtzt im nichtflt~chtigen Speicher des TPM abgelegt. Je nach SchlOsseltyp (TPM-gebunden, migrierbar, Signatur, Identit~it (AIK), Binding Keys) wird das Zugriffsverfahren gew~ihlt. Authentifizierung des Systems Authentifizierung und Validierung der Plattform gegent~ber Dritteno Kommunikation des Sieherheitsstatus des Systems (Attestation) Vertrauenswtirdige Kommunikation der sicherheitsrelevanten (yore Plattform-Besitzer definierten) Konfigurationo Zufallsgenerator Hardware Zufallszahlengenerator zur Erzeugung sicheren Schlfissel

26

Trusted Computing Grundlagen

AktiverSchild zur Erkennung physikalischerAngriffe

Memory Controller +C:.Pll ~tJf dem Motherboard

I 9 .. I " 9

LPC(Low Pin Count) Interface

I I I

RSA 2048Rechenwerk

SicherheitsController

Ang riffs-Sensoren (U,f,T,Schild)

Hash SHA-1

Programm 128KB

m

Daten 8KB

m

Asym. SchKisselGenerator

N ichtfKichtige Daten 32KB

L_J

Host-Prozessor auf d e m Motherboard

....

HW-RauschGenerator

.J . . . . . . . . . . . . . . . . . . . Trusted Plattform Modul (TPM)

North-Bridge ( S p e i c h e r und IOSteuerung )

-"

South-Bridge IO-Steuerung

LPC-Bus

Abb. 1" Blockschaltbild Trusted Plattform Modul (TPM) Versiegelung von Dateien (Sealing) Bindung von Daten an die Systemkonfiguration und Signierung der Daten beim Speichern mit dem Hash-Wert der Konfiguration. Der Zugriff auf solche Daten (zB. Schliissel) ist dann nur noch bei der gleichen Konfiguration m6glich. Sicheres Abspeichern der System Konfiguration zur Erkennung von ~,nderungen Die Konfiguration der Host-SW wird mit dem eingebauten Hash-Algorithmus gemessen (Bildung eines Hashwerts tiber einen Datenblock) und in den Plattform Configuration Registem (PCR) sicher abgelegt. Diese Zustandswerte k6nnen entweder signiert mit einer anderen Plattform ausgetauscht werden (Information tiber die Konfiguration der Plattform) oder aber zur Verschliisselung und Entschltisselung vorzugsweise von Schltisseln verwendet werden mit denen der Zugang zu besonderen Diensten nur bei einer vorher eingestellten Systemkonfiguration m6glich ist.

Die Durchfiihrung sowohi dieser Integrit~itsmessungen als auch yon Sealing oder anderen Funktionen muss aufjeden Fall vom Betriebssystem her angestoBen werden. Der TPM verh~ilt sich rein passiv Lind dient nur als Sicherheitserweiterung. Zur Verhinderung von Angriffen auf den TPM wurde yon der TCG noch Wert auf einige allgemeine, aber mindestens ebenso wichtige Eigenschaften gelegt: 9 Schutz gegen Angriffe auf die Integrit~it des TPM, insbesondere gegen physikalische Angriffe 9 Preisgiinstige Implementierung, um eine weite Verbreitung zu erm6glichen. 9 Erfallung der weltweiten Exportkontrollvorschriften um den intemationalen Handel mit TCPlattformen (PCs) nicht zu behindern. 9 Und als wichtigstes eine Realisierung seiner Funktionen, die den Schutz der Privatsphiire und die Selbstbestimmung fiber die Daten des Nutzers unterstiitzt.

Trusted Computing Grundlagen

27

Ein geschickter Entwurf dieses Systems erm6glicht ffir die Realisierung einen minimalen und damit preisgt~nstigen Umfang an kryptographischer und Sicherheits-Hardware im TPM: 9 Spezialisiertes Kryptorechenwerk zur schnellen Berechnung von RSA-Kryptographie bis zu 2048 Bits; 9 Schlftsselerzeugung mr RSA-Schlfissel bis 2048 Bits; 9 Hardware-Hash-Rechenwerk ffir den SHA-1 Algorithmus; 9 Echter Hardware Rauschgenerator als Input zur SchlCtsselerzeugung; 9 Interner Prozessor mit der entsprechenden Firmware um die kritischen Funktionen (z.B. RSA mit dem geheimen SchlCtsselteil) in einer sicheren Umgebung vertrauenswttrdig berechnen zu k/Snnen; 9 Monotone, geschfttzter Ereignis- und Zeit-Zghler um Reply-Attacken zu erkennen; 9 Nichtflfichtiger Speicher (EEPROM) zum Erhalten der TPM-(Schlfissel)-Daten auch beim Ausschalten der Betriebsspannung; 9 Sensoren und interne Sicherheitsstrukturen (z.B. aktiver Schirm t~ber der obersten Verdrahtungslage des Chips) um physikalische Angriffe zu erkennen und diesen zu begegnen; 9 Low-Pin-Count (LPC)-Interface zur Verbindung mit dem Prozessor des Mainboards; 9 TPM Selbsttest Funktion. Eine umfangreiche, interne Firmware realisiert das vom Standard vorgegebene Schnittstellenprotokoll zu den darfiber liegenden Schichten der Host-SW (TSS) und bentitzt dazu die genannten HardwareFunktionen. Daneben fiberprfift und verwaltet diese Firmware auch die verschiedenen Sicherheits-Sensoren und reagiert entsprechend auf erkannte physikalische Manipulationen oder Ver~inderungen am Chip oder seiner Umgebung. Die Korrektheit der Implementierung wird dabei durch ein komplexes Zertifizierungsverfahren (siehe 3.3) von einem unabMngigen P~finstitut kontrolliert und best~itigt.

3.2 Grundlegende Funktionen des TPM f~ir Trusted

Computing

3.2.1 Core Root of Trust Der generische TCG Ansatz ergibt neue Systemstrukturen: W~ihrend bisher Sicherheit durch zus~itzliche Ebenen von Verschlt~sselung oder Anti-Virus Software erreicht werden sollte, beginnt TC bereits auf der untersten Ebene der Plattform und dort bereits zu Beginn des Bootvorgangs eines solchen Systems mit der Messung der Integrit~it der SW- und gegebenenfalls der HW-Integrit~it der Plattform. Dem TPM als zertifiziertem HW-Sicherheitsbaustein wird dabei a priori vertraut. Wie diese Messung genau abl~iuft wird wiederum vom BIOS und dem zu startenden Betriebssystem vorgegeben. Dabei wird in der Regel abwechselnd ein Code- oder Datenblock vom TPM gemessen (mit der Hashfunktion) und anschliel3end vom Zentralprozessor ausgefahrt. Von dieser untersten Schicht wird beim Systemstart eine ununterbrochene Sicherheitskette (,,Chain of Trust") bis zu den Applikationen hochgezogen. Sobald jeweils die untere Ebene t~ber eine stabile Sicherheitsreferenz verfggt, kann sich die ngchste Ebene darauf absttitzen. Jede dieser Dom~inen baut auf der vorhergehenden auf und erwartet damit, dass jede Transaktion, interne Verbindung und Ger~iteanbindung vertrauenswttrdig, zuverl~issig, sicher und gescht~tzt ist.

28

Trusted Computing Grundlagen ExecutionFlow

MeasurementFlow Applikations--Code (BIOS)

5

OS-Code 3 OS-Loader Code

I "

"1

1

CRTM-Code (BIOS) Trusted Building Blocks + Root of Trust

Abb. 2: Aufbau der ,,Chain of Trust" Das TPM als Hardware-Sicherheits-Referenz stellt dabei zusammen mit den ersten Bytes des BIOS die Wurzel (,,Root of Trust") der gesamten Sicherheitskette dar. Diese Startsequenz des BIOS (die gegen Ver~inderungen gesch~tzt sein muss) aktiviert t~ber einen speziellen (memory absent) Treiber den TPM und gibt ihm die Anweisung den ersten Bootblock zu messen. Daran schlieBt sich dann Block far Block die Messung der weiteren Bootsequenz an. Ahnliche lJberprfifungsmechanismen mit Hilfe des TPM verifizieren dann nacheinander z.B. die Korrektheit des BIOS, des Bootblocks, des Laders und des Betriebssystems selbsto Durch die Auswertung der Messwerte kann dann sp~iter fiberpraft werden ob sich die Signatur (und damit die Konstellation) der Plattformkomponenten ver~indert hat, doh. ob die SW oder eine der HWKomponenten (Plattenspeicher, LAN-Anschluss usw.) ver/~ndert wurde oder gar entfemt oder ersetzt wurde. W~ihrend des ganzen Startvorgangs, aber auch noch spgter, ist damit der Sicherheits- und Vertrauenszustand des Systems - allerdings nur mit Einwilligung des Plattform-Besitzers - t~ber den TPM abfragbar. Damit kann dann auch eine kompromittierte Plattform sicher von anderen erkannt werden.

3.2.2 Zertifikats-Verwaltung und sicherer Datenspeicher Da die Spezifikation des TPM gemN3 den Vertrauensanforderungen der TCG vollkommen 6ffentlich und ffir jedermann zug~inglich ist, k6nnte man nach dieser Spezifikation seinen eigenen TPM auf einem Prozessor nachbauen. Werden dann z.B. sichere e-commerce Prozesse abgewickelt, so k6nnte der Besitzer dieses ,,speziellen" TPM problemlos die intemen Daten zu seinem Vorteil ver~indern: Ein solches Modul wfirde sicher das volle Vertrauen seines eigenen Besitzers geniegen, aber fftr den Austausch vertrauenswfirdiger Prozesse vollkommen ungeeignet sein. Man hat deshalb eine Vertrauens-Struktur implementiert, die bereits von hochsicheren Bankenkarten (siehe MULTOS-Betriebssystem [MULT01 ]) her bekannt ist: Die kritischen Daten und Schlfissel und auch die Chipidentit/~t werden von einem Chip individuellen Schlfisselpaar (dem Endorsement Key (EK)) signiert und es werden weitere Schlfissel aus dem EK abgeleitet um damit auch die Integrit/it der internen Datenstruktur des TPM nachweisen zu k6nnen.

Endorsement Key Am Ende der Fertigung des TPM-Chips (nach dem Endtest) erzeugt der Hersteller im TPM ein Private/ Public Key Paar mit 2048 Bits, den so genannten Endorsement Key. Dieser ist so abgespeichert, dass der Private Key (PK) nicht mehr auslesbar ist, sondern nur noch intern im TPM verwendet werden kann. Zudem wird der EK noch vom Hersteller durch ein Hersteller-Zertifikat signiert. Damit wird vom

Trusted Computing Grundlagen

29

Hersteller elektronisch best~itigt, dass dieser TPM in einem vertrauenswiirdigen Prozess von einem kontrollierten Hersteller erzeugt wurde und den Anforderungen der Spezifikation gent~gto Auf diesem Prozess und der Einzigartigkeit des EK beruht zum gr6f3ten Teil die Vertrauenswiirdigkeit des kompletten TPM-Systems. Der Anwender muss dabei dem Hersteller vertrauen, dass der private Teil des Schlfissels nirgendwo sonst noch gespeichert und auch niemand anderem zuggnglich ist. Im Rahmen der Sicherheitsevaluierung wird auch dieser Aspekt intensiv gepdift. Bei qualifizierten Herstellem wird dieser gmndlegende Prozess wie bei Chipkarten im gleichen, zertifizierten Hochsicherheitsbereich durchgeNhrt. TPM

Key Cache Manager

I

/ [] StorageKey A AIKKey

~ O

SignatureKey AIIg. Daten

I

Abb. 3: Interne Organisation von Daten und Zertifikaten Ein zus~itzliches, externes Abspeichem des EK beim Hersteller w~ire allerdings auch schon deshalb sinnlos, da die TPMs in einem anonymen Prozess gefertigt, sp~iter rein zufNlig verteilt in die Motherboards montiert und dann die PCs als Massenware ebenso an die Kunden verteilt werden. Ein Verfolgen eines bestimmten TPM mit seinem EK ist damit praktisch unm6glich.

Storage Root Key (SRK) Der SRK bildet die Wurzel einer Schlfisselhierachie, in der die Daten (Blobs) und Schlfissel des TPMEigentttmers aber auch der weiteren Nutzer sicher abgelegt sind. Deren Vertrauenswfirdigkeit h~ingt damit vom SRK ab. Der SRK wird bei der Inbesitznahme des TPM (,,Take Ownership") durch den Eigentfimer in einem speziellen Protokoll erzeugt. Alle weiteren Nutzer Zertifikate mtissen bei der Erstellung vom SRK signiert werden und h~ingen damit auch von der G~ltigkeit des SRK ab. Falls der Besitzer eines TPMs diese Ownership aufgibt, wird damit auch der SRK gel6scht, die Zertifikatshierarchie ist unterbrochen und damit sind auch alle unter dem SRK angeordneten Schliissel nicht mehr gfiltig und nutzbar.

Attestation Identity Key (AIK) Der Begriff Attestation enthNt sowohl die Bedeutung von Authentifizierung und Integrit~it. Mit Hilfe von AIK's und externen Trustcentem k6nnen (auch anonyme) Identit~iten gebildet werden. AIKs werden vom SRK abgeleitet und k6nnen auf Grund Ihrer Verwendung auch nachtrgglich noch gebildet oder gel6scht werden. Es sind mehrere AIKs pro Plattform und pro User m6glich. Dieses Attestationkonzept ist neu und weicht von bisherigen X.509 Zertifikatskonzepten deutlich ab. Typische Anwendungen hierfgr sind:

30

Trusted Computing Grundlagen 9

S erver-Authentifizierung

~ Plattformgebundene digitale Inhalte (DRM) ~ Anonyme Identit~iten in Beschaffimgs- und Vergabeplattformen Daneben ist nattMich auch nach wie vor die Unterstfitzung bekannter X.509 Zertifikatsstrukmren m6glich.

Plattform Zertifikat Das Plattform Zertifikat wird vom Motherboard/PC-Hersteller in den TPM eingebracht und best~itigt, dass ein gfiltiger TPM in eine korrekte Plattform montiert wurde. Der PC-Hersteller kann individuelle Hersteller-Daten in das Plattform-Zertifikat einbringen und damit sp~iter erm6glichen dass z.B. der PCTyp oder die Variante sicher erkannt wird~ Typische Anwendungen daRtr sind Third-Party oder ,,after buy" Business bei dem z.B. bestimmte Software oder andere Dienste auf ausgewfihlte Plattformen zu besonderen Konditionen automatisch tiber das Netz installiert werden kann.

Conformance Zertifikat Das Conformance Zertifikat wird von einem Prfiflabor ausgestellt und bestgtigt, dass die Sicherheitsfunktionen des TPM und des Motherboards positiv ftberpriift wurden und dem Protection Profile der TCG entsprechen. Die Verkettung dieser verschiedenen Zertifikate, Credentials und Keys, die es erlauben daraus diverse Sicherheitsaussagen abzuleiten, stellt ein durchaus interessantes und anspruchsvolles logisches System dar. Der interessierte Leser sei auf [TCG03] verwiesen.

Direct Anonymous Attestation Um Bedenken der Datensch(itzer tiber die Sicherheit von und das Vertrauen in externe oder 6ffentlichen Trustcenter (Certification Authority: CA) Rechnung zu tragen wurde noch zus~itzlich ein auf ZeroKnowledge Verfahren (Direct Proof) beruhendes Attestation-Verfahren definiert. Damit k6nnen sich zwei Plattformen ohne externe CA gegenseitig attestieren und durch den Wegfall eines extemen Dritten kann eine verbesserte Anonymit~it erreicht werden [TCG03].

3.2.3 Externe Zertifikats-Integrit~its- und Identit~itskette Gem~iB der TCG-Philosophie sind alle relevanten Standards often und allgemein verffigbar. Es w~ire also ein leichtes per SW-Emulation einen TPM nachzubauen und diesen auch entsprechend einzusetzen. Um aber sicher zu stellen dass auf der anderen Seite der Kommunikationsbeziehung auch ein sicherer Hardware-TPM aus einer vertrauenswfirdigen Produktion beteiligt ist, benutzt man daher ein bereits von hochsicheren Chipkarten her bekanntes Verfahren: Die korrekte Implementierung des TPMs wird durch den Hersteller mit einer digitalen Signatur best~itigt. Wie aus dem vorhergehenden Kapitel bekannt, enth~iltjeder TPM ein individuelles RSA-Schlfisselpaar (den sogenannten Endorsement-Key (EK)) bei dem der 6ffentliche Schlfissel durch ein Zertifikat des Herstellers signiert werden kann. Der TPM-Hersteller erzeugt dazu am Ende des Produktionsprozesses ffir jeden einzelnen TPM ein individuelles EK-Paar, signiert dieses und l~idt es in den TPM. Der geheime Teil des EK ist danach nur mehr f'~ interne Verschlt~sselungsoperationen zug~tnglich, der 6ffentliche Teil des EK kann aber ausgelesen und far die Verifikation benutzt werden. Ffir die Uberprtffung

Trusted Computing Grundlagen

31

der TPM-Signatur wird der 6ffentliche SchliJsselteil des Hersteller-Zertifikats benutzt (mit dem die EK-Signatur auch erstellt wurde). Das Hersteller-Zertifikat ist sinnvollerweise z.B. auf der Webseite des Herstellers 6ffentlich verfOgbar [IFX02], so dass die 0berprtifung eines TPMs durch jedermann erfolgen kann.

Erstellung der dig. Signaturkette Root CA Verisign

Hersteller

0berprefung der dig. Signatu rkette

Public KeyVp

VerfQgbar im Internet

Public }/Signed Public Key Ip Key Vs(Ip)


~!~i~i~i~i~Jii:~i i!i~i~i!G!~i i! i !~!!i!i~i!i !i!!~i~i~i!i!!iiIi~;ii!
TPM

Public Key

Signed Public Key Is(Tp)

I Abb. 4: l]berprtifung des TPMs tiber die Hersteller Signamrkette Um diese Signatur-Verifizierung besonders vertrauenswfirdig zu gestalten (die Webseite des Herstellers k6nnte ja gef'Nscht sein), bietet es sich an, das Hersteller-Zertifikat nochmals durch ein anerkanntes und allgemein verfOgbares Root-Zertifikat wie zB. von Verisign zu signieren. Wie man leicht feststellen kann, ben6tigt man fOr die Verifizierung lediglich die 6ffentlichen Schltissel der beteiligten Public Keys, sodass die Oberprtifung ohne weitere Sicherheitsinformationen vonder Allgemeinheit (z.B. User- oder Maschinen-Zertifikate, e-Business-Partner, Conformance Labs, BackupServer, Netzwerkmanagement) durchgefOhrt werden kann.

3.2.4 SchlLisselverwaltung, SchlLisseltransport Schltisselarten Schliisselmigration Da fiber das TPM sowohl plattformbezogene Schltissel, wie auch personenbezogene Schltissel (User-

32

Trusted Computing Grundlagen

keys) gesichert werden kOnnen, ergibt sich das Bedfirfnis, die Userkeys sicher auf andere Plattformen zu transferieren. Die TCG hat dazu unter dem Begriff Migration ein Regelwerk definiert:

Non-migratable Keys (an die Plattform gebunden) Beispiele: 9 EK: Endorsement Key des TPM-Herstellers 9 SRK: Storage Root Key Diese Schlgssel sind prinzipiell nicht auf andere TPMs fibertragbar, da sie plattformspezifisch sind. Backup (Maintenance) ist unter bestinumen Regeln mOglich. In der neuesten Spezifikationsversion 1.2 ist jetzt der EK in einem bestimmten Prozess 1Oschbar. Mit der Prozedur ,,RevokeTmst" wird der komplette EK invalid und gel6scht und damit alle davon abh~tngenden Zertifikate und Schlt~ssel ebenfalls. Mit einer ebenfalls speziellen Prozedur kann dann ein neues EK-Schl~sselpaar erzeugt werden und die Zertifikatskette von neuem aufgesetzt werden. Dieses Verfahren stellt allerdings die Ausnahme dar und ist nur Dr geschlossene Infrastrukturen denkbar. Der Aufbau einer neuen Zertifikatskette ffir eine solch allgemeine Nutzung wird mit sehr hohen Kosten einhergehen.

Migratable Keys (auf andere Plattform iibertragbar) Beispiel: alle vom Anwender benutzten, unter dem Storage Key gespeicherten Schlfissel (sofem sie migratable generiert wurden) und Dateno S c h I t i s s e It ra n s po rt

Migration (Ubertragung auf andere TPMs) Ft~r die Migration wird ein besonderer Authorisierungsprozess verwendet und das Datenmaterial wird zu Sicherungszwecken in einem kennwortgescht~tzten Container transportiert~ Praktisch kann dies durch einen speziellen Migration-Server erfolgen Maintenance

(Sichern und Wiederherstellung von Schlfisselmaterial) Dieses Feature dient zur Daten-/Schlt~ssel-Sicherung im Falle eines Hardware-Defekts (nur Empfehlung)o Realisierung durch Backup-Server oder z.B. Chipkarten

3.3 Conformance, Compliance" Sicherheitszertifizierung des TPM und von SW-Implementierungen Um die Qualit~it und das Vertrauen in ein TPM Modul und auch sonstige Implementierungen des Standards, zB. auch als SW-Modul, sicher zu stellen und dies auch dem Anwender zu versichern, ffihrt die TCG derzeit einen Zertifizierungsprozess ein. Anbieter von Produkten oder SW-Implementierungen nach dem TCG-Standard k6nnen sich die l)bereinstimmung mit dem TCG-Standard (Compliance: Funktionstest gegen eine Referenzimplementierung) sowie die Sicherheit der Implementierung (Conformance: offizieller Zertifizierungsprozess gem~ig ISO 15408 [CommonCriteria, CC] durch eine vertrauenswfirdige Third Party) durch geeignete Testverfahren best~itigen lassen. Ffir die Conformance-

Trusted Computing Grundlagen

33

Evaluierung ist dazu ein Protection Profile (PP) far eine Zertifizierung gem~ig CC EAL4+ verfagbar. Wie alle anderen relevanten TCG-Standards auch, werden auch diese Test= und Evaluierungs-Szenarien und Testvektoren often zuggnglich sein~Der Anwender erhNt damit auf einfache Weise die Best~itigung, dass die Voraussetzung far ein vertrauenswttrdiges System durch die bestandene Evaluierung und das Vorliegen eines gfiltigen Zertifikats fttr Hard- und Software erffillt ist.

4 Trusted Software Komponenten und Betriebssysteme Das grundlegende Problem der Trusted Betriebssysteme besteht dabei darin, dass generell bei SW (und na~rlich auch bei Betriebssystemen) ab einer bestimmten Gr613e und Komplexitgt es kaum mehr m6glich ist, Fehlerfreiheit und ein korrektes Funktionieren zu gew~ihrleisten. Derzeit konzentriert sich die internationale Forschung und Entwicklung auf zwei erfolgversprechende Ans~itze:

4.3.1 Microkernel Ein Microkernel (oder auch Mikrokern) bezeichnet einen Betriebssystemkern mit einem deutlich reduzierten Funktionsumfang wie z~ Funktionen zur Speicher- und Prozess-Verwaltung, sowie Grundfunktionen zur Synchronisation und Kommunikation. Der dazu notwendige vertrauenswfirdige Code ist im Vergleich zu konventionellen monolithischen Betriebssystemen relativ klein und somit einfacher zu verifizieren. Man arbeitet derzeit in verschiedenen Forschungsprojekten durchaus erfolgreich daran, die TC-Funktionen in solche Kerne zu integrieren um damit einen Trusted Mikrokern auf einer Trusted Hardware zu realisieren.

4.3.2 Virtualisierung, Hypervisor Virtualisierung (auch Hypervisor genannt, die Steigerung von Supervisor) bezeichnet Methoden und Prozeduren, die es erlauben, Hardware-Ressourcen eines Computers fiber eine dfinne VirtualisierungsSW-Schicht auf mehrer Betriebssystem oder Applikationen aufzuteilen. W~ihrend fibliche Betriebssysteme den Ablauf von einzelnen Tasks oder Prozessoren auf einer Hardware verwalten, verteilen Virtualisierungssysteme die Prozessor-Ressourcen (und das k6nnen durchaus auch Multi-Core Prozessoren sein) auf einzelne Compartments in denen unterschiedliche Betriebssysteme vollkommen getrennt voneinander ausgefahrt werden. Dabei entsteht far jedes Compartment der Eindruck, dass es der alleinige Nutzer einer Ressource sei. Die far den Anwender unsichtbare bzw. transparente Verwaltung der Ressource ist dabei in der Regel die Aufgabe des Virtualisierungs-Betriebssystems (VOS). Bei derzeit realisierten Konzepten steht dem VOS der TPM f'ar die Kontrolle der Integritgt zur Verfagung. Das VOS andererseits realisiert dann in jedem Compartment einen eigenen virtuellen TPM, der die lokalen Anforderungen erfallt und der seine Root of Trust wiedermn auf den zentralen physikalischen TPM des VOS abstfitzt.

34

Trusted Computing Grundlagen

cmp#n: Standard OS

Multicore Prozessoren mit Virtualisierungsu nterstOtzung zB. Intel Vanderpool, AMD Pacific& ARM

!

z2;

I

Abb. 5- Trusted Virtualisierungs-Betriebssystem Der Vorteil eines solchen Systems besteht darin, (vorausgesetzt die Virtualisierungsschicht ist fehlerfrei implementiert) dass auftretende Fehler in einem Compartment in einen abgeschlossenen Bereich begrenzt werden und nicht die anderen Compartments infizieren k6nnen. Werden die einzelnen Gast-Betriebssysteme (z.B. Microkemel) sowie die Applikationen in einer fiberschaubaren Gr613e gehalten, so h~ilt sich die Wahrscheinlichkeit dass sich Fehler katastrophal ffir das Gesamtsystem auswirken durchaus in einem sehr kleinen Rahmen. Die M6glichkeit, dass aul3erdem beim Starten eines Compartments und des zugehOrigen Gast-OS jedes Mal neu die Integrit~it mit Hilfe des TPM fiberprfift wird, verbessert so zus~itzlich das erwartete Gesamt-Sicherheits-Niveau. Moderne Prozessor-Chips~itze wie z. B. Intels Vanderpool oder AMDs Pacifica unterstfitzen bereits mit Ihrer optimierten Hardware-Struktur solche Virtualisierungs-L6sungen und den Einsatz yon TPMs [WIN01 ], [WIN02].

4.1 Trusted Plattformen und konventionelle Betriebssysteme W~ihrend sich der volle Nutzen und die entsprechenden Vorteile bezfiglich der Integrit~it von Computersystemen erst bei vollst~indigen Trusted Systemen ergeben, die auch auf Trusted Betriebssystemen basieren, ist auch bereits beim Einsatz von TPMs in derzeitigen konventionellen Computern mit Standard-Betriebssystemen ein deutlicher Sicherheits-Vorteil zu erkennen. Standard-Sicherheitsapplikationen ben6tigen in der Regel einen gescht~tzten Bereich ffir eigenes Schlt~sselmaterial der in der Regel nicht vorhanden ist. So werden ~iblicherweise diese Schlfissel in einem geheim gehaltenen Bereich des Speichers abgelegt. Ftir einen Angreifer ist es aber problemlos m6glich, gegebenenfalls unter Zuhilfenahme eines anderen Betriebssystems, die gesamten Datenstrukturen (und natfirlich auch diejenigen die durch Sicherheitsmechanismen des Original-Betriebssystems gescht~tzt werden) nach solchen Sicherheits-Speicherbereichen und -Daten zu durchsuchen. Ein TPM bietet hier die M6glichkeit solche kritische Daten und Schlfissel sicher im gescht~tzten TPM-Chip abzulegen und

Trusted Computing Grundlagen

35

auch die Authentifizierungsmechanismen um Zugang zu diesen Daten zu erlangen, sicher im TPM abzuwickeln ohne dass Kopien von Passw6rtern oder dgl. often im System gehalten werden m~sseno

Sicherer und Trusted Boot-Prozess Eine der zunehmenden Sicherheitsprobleme insbesondere bei Laptops ist der Verlust (z.B. Vergessen im Taxi) oder Diebstahl der Ger~iteo Dabei ist weniger der Schaden durch den materiellen Wert von Bedeutung, sondern die Preisgabe von meist hochsensiblen Daten. Der Schutz lediglich durch z.B. die Betriebssystem-Authentisierung ist hier sicher nicht ausreichend, da ein Angreifer beliebig viel Zeit und Mittel zur Verfagung hat. Microsoft hat deshalb als eine der ersten Sicherheitsfunktionen auf der Basis des TPM im neuen VISTA| OS ein kombiniertes sicheres Booten zusammen mit einer Verschlfisselung der Platte integriert [WIN03]. Dabei wird der Plattenspeicher erst dann freigegeben und entschl(isselt wenn sowohl die Boot-Authentifizierung und auch die nachfolgende 121berprfifung der Integrit~t der Startprozeduren erfolgreich waren. Eine ~ihnliche Funktion steht auch als Open Source ft~r Linux unter dem Namen TrustedGRUB zur Verfftgung [RUB01 ]. Ffir einen ,,Finder" bzw. Angreifer ist damit ein Zugriff auf die derart gesicherten Datenbest~inde kaum mehr m6glich. Das sichere Booten als einer der grundlegenden Funktionen der ,,Chain of Trust" gem~ig der TCG-Spezifikation ist damit ffir beide konkurrierende Betriebssystemfamilien der Einstieg in die n~ichste Generation der vertrauenswttrdigen Betriebssystem geworden.

4.1.1 Software-/Hardware-Sch nittstellen Um die Nutzung von TPM-Funktionen von Anfang an deutlich zu erleichtern, hat die TCG eine spezielle API (den TPM Software Stack, TSS) definiert der die TPM Funktionen auf einer h6heren abstrakten Ebene als standardisierte Krypto-Applikations-Schnittstelle zur Verffigung stellt. Ahnliche Funktionsumfiinge existieren auch in bereits bekannten Anwender-Bibliotheken und erlauben somit dem Entwickler ein schnelles Vertrautwerden mit dieser neuen Technik.

TPM Software Stack (TSS) Das TPM ben6tigt wie jedes andere Hardware-Element auch, eine spezielle Treiber- und Service-Provider-Schnittstelle um vom Betriebssystem und den Applikationen aus angesprochen werden zu k6nnen. Dieser Trusted Plattform Support Service stellt eine Sicherheits-API dar, die dem jeweiligen Betriebssystem die Funktionen des TPM auf einer hohen abstrakten Ebene bereitstellt. Der TSS nach dem TCG-Standard besteht auf der untersten Ebene aus dem hardwarenahen Device Driver (implementiert im Kernel-Mode), der fiber den LPC-Bus mit dem TPM die Schnittstellen initialisiert und Daten austauscht. Die n~ichst h6heren Ebene besteht aus dem System Service mit: 9 TPM Device Driver Library 9 TSS Core Services 9 TSS Service Provider die folgenden Funktionen abarbeiten: 9 Koordinierung und Management von Vielfach-Zugriffen auf den TPM 9 Umsetzen der abstrakten API-Kommandos auf den Datenstrom und die Basisfunktionen flir den TPM 9 Bereitschaft des System Service (auch wenn kein Nutzer aktiv ist) fttr Remote Zugriff z.B. durch den System Administrator

36 VI

Trusted Computing Grundlagen

Ein Cache Entwicklungen Manager legt dabei die Daten, die den Speicherbereich des TPM-Bausteins fiberschreiten damaligen Stellung genommen wurde. Die seinerzeitigen Forderungen gelten in ihrem sicher auf dem externen ab. Damit besteht ein nur durch die Gr613e des Plattenspeichers Grundsatz bis heute fortMassenspeicher und lassen sich wie folgt zusammenfassen: begrenztes Fassungsverm6gen for Schlt~ssel und Sicherheitsdaten. Zusfitzlich ist ein ~ihnlich funktionie9 Offenheit, Transparenz und freie VerfiJgbarkeit der Standards render Authentifizierungs-Cache Manager vorhanden. ~ Entscheidungsfreiheit f'tir einen Einsatz TPM-basierter Systeme 9 Nachvollziehbare und transparente Zertifizierung AppliI Applikation 9 Gew~ihrleismng der Interoperabilit~it mit alternativen L6sungen kation

9 Volle Kontrolle tiber Inbetriebnahme, Konfiguration, Anwendung und Stilllegung von TC-L6CSP-Interface sungen Service Provider 9 Einhaltung der Bestimmungen des Datenschutzes. Sicheres

TSS Service Provider Booten Werden Trusted Computing-L6sungen, diesenAnforderungen gerecht, so k6nnen Sie einen wesentlichen Beitrag zur Erh6hung der IT-Grundsicherheit eines jeden Nutzers darstellen. Dabei ist es unwesentlich, TPM -Driver ob sie auf den Spezifikationen der TCG basieren oder altemativen Ans~itzen folgen~ Gleichzeitig ergeben sich neue Chancen und M6glichkeiten, die Sicherheitsmechanismen auch anderen IT-Anwendungen zur TPM-Fi rmware (TPM-OS unind Sicherheitsfunktionen) Verffigung zu stellen und ein h6heres Vertrauen E-Government und E-Commerce TPM- zu begrtinden. TPM-Prozessor + Krypto-Rechenwerk + Sch utzmechanismen

Chip

Abb. 6: TPM Software Stack mit den Trusted Plattform Support Services (TSS) Die Funktion und Aufrufe des TSS sind natOrlich vom TCG-Standard exakt vorgegeben, da nur durch eine pr~izise und vertrauenswfirdige Implementierung die Sicherheitskette zwischen Betriebssystem und Hardware-TPM stabil bleibt. Die Implementierung des TSS ist bei den m6glichen Betriebssystemen nattirlich verschieden. Da einige der Teilfunktionen (z.B. unterste Treiberebene) mit Systemrechten ausgestattet sein muss und auch sonst die jeweiligen OS-Eigenschaften zu berficksichtigen sind, bestehen hier erhebliche Kompetenzanforderungen an die Entwickler und Anbieter. Oblicherweise liefert der Hersteller des TPM auch den fOr das jeweilige Betriebssystem ben6tigten TSS mit.

Kryptographische Anwender-Schnittstelle des TSS Da der TSS als API seine Sicherheitsfunktionen dem Betriebssystem zur Verfogung stellt, liegt es nahe, diese Schnittstelle t~ber ein Anpassungsmodul auch anderen Sicherheitsapplikationen anzubieten. Damit k6nnen vor allem sichere Speicher- und Signatur-Services des TPM den normalen Applikationen verfogbar gemacht werden und der Sicherheitslevel dieser Standardanwendungen deutlich angehoben werden. Diese Funktionalit~it ist nicht direkt vom Standard gefordert, verbessert aber die Nutzbarkeit der Plattform erheblich. Derzeit existieren zwei verbreitete Implementierungen: Microsoft Cryptographic Service Provider (CSP) Verschiedene Anwendungs-Programme unter Windows| (wie Outlook| Explorer, Word ...) enthalten Sicherheitsfunktionen, wie Verschlt~sseln und Signieren und wickeln diese Funktionen t~ber das so genannte MS-CAPI| (Microsoft Cryptographic Application Programming Interface) als propriet/~re Krypto-Schnittstelle ab. MS-CAPI| kann durch Zugriff auf verschiedene Sicherheitsprovider wie SW-Module, kryptographische Token (Chipkarten usw.) oder eben auch fiber den TSS auf das TPM gelenkt werden. Damit ist es relativ einfach, bestehende Sicherheitsanwendungen, die MS-CAPI| bereits nutzen, lediglich durch Auswahl eines anderen CSP auf das h6here Sicherheitsniveaus des TPM zu portieren.

Trusted Computing Grundlagen

37

Offene Kryptographische Schnittstelle PKCS#11 PKCS#11 ist der yon der RSA entwickelte, am weitesten verbreitete, universelle Krypto-Schnittstellenstandard. Er wird z.B. vom Netscape Browser benutzt. Auch hier erleichtert die Umsetzung der PKCS#11-Sicherheitsauffufe auf die TSS-API die Adaption yon bereits existierenden Standardanwen= dungen ganz wesentlich. So kann dutch das sichere Speichem yon Zertifikaten fOr Browser (Nutzung der bereits vorhandenen PKCS#11-Schnittstelle) im TPM mit geringstem Implementiemngsaufwand hochsichere L6sungen erreicht werden

5 Verwaltungsfunktionen Um Plattformen mit TC-Funktionen auch verwalten und konfigurieren zu k6nnen, sind besondere Bedien-Funktionen for die TC-Komponenten und insbesondere das TPM erforderlicho W~ihrend bisher for die Handhabung von Standard PCs nur die allgemeinen logistischen Anforderungen angelegt wurden, treten bei Trusted Plattformen mit der darin enthaltenen eindeutiger Identit~it und daraus abgeleiteten Sicherheitselementen neue Bedfirfnisse auf. Insbesondere das erste Aktivieren des TPM (das aus Datenschutzgrfinden durch den Nutzer erfolgen muss), das Anlegen einer entsprechenden Zertifikats- und Schlfisselhierarchie, die Portierung und das Backup von Rechten, Schlfisseln und Identit~tten bedingen neue Bedienungs- und Verwaltungsfunktionen bei der Nutzung im Feld. Bei Defekten im TPM, aber auch bei Ausfall eines Motherboards muss es dabei z.B. m6glich sein, den Schlftsselbestand eines TPMs soweit n6tig und m6glich (die sogenannten migrierbaren Schlfissel) auf einen anderen TPM z.B. auf einem neuen Motherboard zu t~bertragen. Erstellen von Sicherungskopien und auch das Wiedereinspielen sind auch hier for den Betrieb absolut notwendige Standardprozeduren. Eine besondere Herausfordemng entsteht beim Management grol3er PC-Flotten und damit der zentralen Verwaltung vieler TPMs durch zentrale Administratoren. W~ihrend einzelne Ger~ite z.B. bei der privaten Nutzung noch per Hand konfiguriert werden k6nnen sind mittlerweile far grol3e Installationen dazu auch entsprechende Administrationsprogramme verfogbar, mit denen als ,,Silent Installation" das komplette Management (vom Aktivieren t~ber Backup und Schl~sselmanagement) aller TPMs in einer Organisation zentral vom Administrator durchgefohrt werden kanno Erst solche Hilfsmittel erlauben den breiten Masseneinsatz von TC in grogen Organisationen.

5.1 Aktivieren des TPM, ,,Take Ownership" Der TPM in einem PC wird gem~il3 des Vertrauensprinzips der TCG deaktiviert ausgeliefert. Es ist Sache des Administrators (in Organisationen) bzw. des einzelnen Nutzers (bei der privaten Verwendung eines TPM) ihn in Betrieb zu nehmen (Opt-In Strategie for Privacy Control). Dies geschieht durch Aufrufe der daf'ttr vorgesehenen TCG-Prozeduren fiber ein TPM-Management Programm: 9 Initialisierung TPM-Selbsttest, Rftcksetzen der PCR Register und aller Flags, Messen des Plattform Zustandes 9 121bemehmen (Ownership) Das "Take Ownership"-Kommando nimmt den TPM for den Nutzer ,,in Besitz" und legt im wesentlichen einen neuen Storage Root Key (siehe 3.2.2~ als Wurzel for alle folgenden Zertifikate und Schlt~ssel der weiteren Nutzer an. 9 Verfogbarkeit (Enabling)/Aktivierung (Activated) erm6glichen den Zugriff auf den TPM.

38

Trusted Computing Grundlagen

Daneben gibt es weitere Kommandos far Funktionen bzw. Zustandfiberg~inge: ~ Das ForceClear-Kommando 16scht das TPM vollst~indig bis auf den EK und die Plattform-Zertifikate. Damit sind auch alle operationellen Schlt~ssel nicht mehr verfagbar und eventuell damit noch verschl%selte Daten nicht mehr zug~inglich! 9 Um den Zugriff auf diese Funktionen durch Unbefugte zu verhindem, werden bei all diesen Aktionen entweder Identifikationsmuster (im einfachsten Fall PINs ) erzeugt oder abgefragt. ~ Die ,,kritischen" Operationen ,,Aktivierung" und ,,Enable" ben6tigen zus~itzlich die physikalische Pr~isenz des Eigentfimers vor Ort (z.B. Eingabe tiber BIOS oder mittels Schalter). ~ Das Opt-In Verfahren des TPM (Privacy Control) mit seinen Kommandos erm6glicht die Kontrolle durch den Besitzer/Anwender unter den Gesichtspunkten des Datenschutzes mit granularer Abstufung: 9 Enable/Disable Ownership ~ Enable/Disable TPM 9 Activate/Disactivate TPM ~ Enable/Disable PUBEK-Read (Zugriff auf den Public Teil des EK)

5.2 Backup und Recovery von TPM-Schl0sseln Datenretmng und Wiedereinspielen ist bei allen Sicherheitsl6sungen, so auch bei TC eine der wichtigsten Voraussetzungen. Der TCG Standard definiert dabei far den TPM entsprechende ,,Maintenance"und Verwaltungsfunktionen, die es erlauben die migrierbaren Daten des TPM verschlfisselt und signiert auf ein extemes Speichermedium abzulegen. Dies kann far den Einzelnutzer z.B. eine Archivierungsmedium, far eine gr6f3ere Organisation aber ein komplettes Archivierungs-Server-System sein. In der Regel sind entsprechende Programme zur manuellen Datensicherung als TPM-Verwaltungsprogramm im PC-Lieferumfang enthalten. Ffir gr613ere Organisationen werden zus~itzlich Komplettsysteme angeboten, bei denen ein regelmN3iger Backup (z.B. bis herab zum Stundentakt oder auch bei entsprechenden TPM-Aktionen (bei impliziter Ver~inderung des Schlftsselbestands) nach Vorgabe automatisch erfolgen kann. In all diesen FNlen werden lediglich die sogenannten migrierbaren (transportierbaren) Schl~ssel gesichert, die z.B. aus extemen Quellen geladen werden oder aber far die externe Nutzung erzeugt wurden (zB. zur Verschlfisselung von Datenspeichem oder Zugriff zu Diensten). Das Schl%selmaterial das direkt auf die TPM Hardware bezogen ist, verbleibt aufjeden Fall im TPM, da es ja nur far einen bestimmten TPM und damit eine Hardwareplattform gfiltig ist. Ist ein Wiedereinspielen des gesicherten Schlflsselvorrats beim Ersatz der Hardware erforderlich, so existieren dafar standardisierte Funktionen, die ein Umschlfisseln der Daten aus dem sicheren BackupSpeicher auf die neue Speicherhierarchie (vom SRK bis zu den UserKeys) des neuen TPM unterstt~tzen.

5.3 SchlLissel Migration Da ein typischer PC-Anwender in der Regel an mehreren Maschinen arbeitet, entsteht nat~rlich auch die Forderung an allen diesen Anlagen auch den jeweils neuesten Daten- und Schlfisselbestand im jeweiligen TPM verfagbar zu haben. Auch spezielle Anwendungen, wie den Zugang zu bestimmten Diensten durch kryptographische Authentisierung (z.B. SW-Dongle) erfordem die Bereitstellung des Schlfisselmaterials auf wechselnden PCs. Auch hier helfen im Wesentlichen ~ihnliche Funktionen des TCG-Stan-

Trusted Computing Grundlagen

39

dards zur Schlfisselmigration wie beim TPM-Backup. Durch verschlfisselte und signierte 12Ibertragung des Schlfisselmaterials und gegenseitige Quittung ist es sogar m6glich, dafttr zu sorgen, das bestimmte Schl~ssel nur einmal auf verschiedenen Plattformen existieren und damit z.B. Individuelle Zugriffsrechte gewahrt bleiben. Diese universelle und sichere Verffigbarkeit des individuellen Schlfisselmaterials auf den verschiedenen Anlagen eines Nutzers stellt eine wesentliche Verbesserung der Nutzungsm6glichkeiten und des Komforts in groBen Rechnemetzen dar. Da diese Prinzipien des TCG-Standards nicht nur aufPCs beschr~inkt sind, sondern zB. auch in Zusammenarbeit mit mobilen Systemen funktionieren, ergeben sich damit sehr elegante M6glichleiten Nutzungs- und Zugriffsrechte zu Daten und Diensten auf den verschiedensten Anlagen nach einheitlichen Regeln jederzeit zu erm6glichen. Zukfinftige Anwendungen wie persistente Datenhaltung oder ,,ubiquitous computing" setzen auf solchen Funktionen auf.

5.4 TPM-Management Server Eine wesentliche Voraussetzung zur einfachen und komfortablen, aber auch sicheren Nutzung dieser Dienste sind entsprechende TPM-Mangement Server. Sie stellen sichere und vertrauenswfirdige Hintergrundspeicher dar (wiederum abgesichert fiber TPM), auf denen die zugeh6rigen TPMs ihre Daten in verschlftsselter und signierter Weise ablegen k6nnen. Wesentliche Voraussetzungen fttr das Einhalten der entsprechenden Sicherheitsanforderungen ist dabei unter anderem die gegenseitige sichere Authentifizierung von TPM und Backup-Servem um zu verhindern dass z.B. Sicherungskopien oder migrierbare Schlfissel auf gef~ilschte TPM-Nachbildungen zurfickkopiert und damit missbraucht werden k6nnen. Zus~itzliche Roaming-Funktionen erm6glichen dann dem TPM= und Server- Nutzer dass er sich auf einer beliebigen Trusted Plattform (ob PC, Smartphone oder sogar Auto) einloggt und dann in sicherer Weise seine komplette vertrauenswfirdige Datenumgebung zur Verfagung hat.

6 Anwendungen auf der Basis yon Trust und Sicherheit Die vonder TCG vorgesehene Leitanwendung von TC Plattformen ist der Einsatz auf PCs zur Unterstfitzung sicherer Betriebssysteme. Derzeitige Hauptanwendung ist die Verwaltung der PC-Flotten in grogen Organisationen. Die sichere Versorgung der PCs mit Zertifikaten erm6glicht andererseits wieder die Durchsetzung von entsprechenden Rechten und Zugangsprofilen zu Netzen und Diensten im Untemehmen. Bis zur Verffigbarkeit erster sicherer OS k6nnen aber bereits die Sicherheitsfunktionen des TPMs auf konventionellen OS (wie Windows) genutzt werden. Die Sicherheits-HW des TPM erm6glicht dabei das zuverlgssige Speichem und Verwaltung von kritischen Daten, die in einer konventionellen Umgebung von Angriffs-SW jederzeit ver~indert werden k6nnten: Digitale Zertifikate far elektronische Signaturen k6nnen ebenso sicher im TPM abgelegt und verwaltet werdend. Sichere Implementierung von WLAN und Netzwerkzug~ingen: Die entsprechenden Schlfissel und Zertifikate werden sicher im TPM verwaltet Und viele weitere, ghnliche Funktionen ....

40

Trusted Computing Grundlagen

6.1 TC-Anwendungsklassen Kir Nicht-PC Plattformen Die TCG begann zwar Ihre Standardisierungs-T~itigkeit mit dem Ziel der PC-Sicherheit. Die Idee der sicheren Plattform ist aber auf viele andere Gergte und Anwendungen fibertragbar und bei steigender System-Komplexitgt auch notwendigo Im Rahmen der TCG existieren mittlerweile Arbeitsgruppen far die verschiedensten Anwendungsbereiche:

PDAs und Smartphones PDAs haben mittlerweile ~.hnliche Leistungsmerkmale und Funktionen wie PCs, werden durchgehend am Internet betrieben und sind bedingt durch ihre Beweglichkeit mit einem erheblichen Diebstahls- und Verlustrisiko behaftet. Die darin typischerweise verwendeten Betriebssysteme haben meistens keinerlei oder minimale Sicherheitsfunktionen. Ein Ger~ite-Verlust fahrt in der Regel zur Kompromittierung aller enthaltenen Daten. Die Sicherheitsfunktionen des TPM und seine Nutzung im OS k6nnen hier zu einer wesentlichen Verbesserung durch implizite Authentisierungs- und Verschlfisselungsverfahren fahreno

Mobilfunkapplikationen Moderne Ger~ite, wie z.B. UMTS, sind 24"7h in Betrieb und am Intemet, und das bisher ohne besondere Sicherheitsvorkehrungen. Mit TPM lassen sich nicht nur die Datensicherheit verbessern, sondern auch die m6glichen Anwendungen signifikant erweitern. Besonders die M6glichkeit Zertifikate sicher im Ger~it abzulegen, ermOglicht neue vertrauenswttrdige Anwendungen. Mit einem TPM-Sicherheitskern kann aus einem Handy ein Sicherheitsterminal far m-Commerce oder durch Nutzung der vorhandenen Tastatur und dem Display ein sicheres Klasse-3 Terminal zum Signieren von Dokumenten oder t'~ e-Banking entstehen. Auch der zunehmenden Gef'~ihrdung durch Schadsoftware (ein Virus/Wurm auf Handys der sich fiber das Internet verbreitet und der die Notrufnummer w~ihlt ist mittlerweile durchaus vorstellbar) kann mit einem TC gestfitzten Betriebssystem besser begegnet werden.

Kommunikation (WLAN-Sicherheit, Network Remote Access ...) Speziell in letzter Zeit wird das Thema Sicherheit far externe Netzwerkzugriffe immer wichtiger. Besonders interessant ist dabei der Schutz von WLAN-Systemen. Nachdem inzwischen die Systeme der ersten Generation von deutlich weitergehenden Schutzmechanismen abgel6st sind, taucht auch hier der Wunsch nach sicheren Speichern far Schlfisselmaterial als auch nach Speichern far Ger~ite-Zertifikate zur Identifizierung und Authentisierung von Accesspoints und Endger~iten auf. TPM bietet hier die M6glichkeit nicht nur Sicherheit far die WLAN-Luftschnittstelle sondern auch far Netzwerk-Zugriffe (RADIUS, DIAMETER) vertrauenswfirdig in die Ger~ite zu integrieren.

Geriitesicherheit und-Integritiit Ftir den Schutz yon hochwertigen Wirtschaftsgfttern gegen Angriffe auf deren Integrit~t oder aber unbefugte Ver~inderungen bietet sich ein breites Einsatzfeld. Es beginnt beim Schutz yon Produkteigenschaften yon Autos, wie der Motorsteuerung oder yon werthaltigen Parametern wie Km-Stiinden bis hin zum Schutz yon Anlagen-Steuerungen z.B. bei Chemieanlagen. Die Diskussionen sind hier erst am Anfang aber auch hier erOffnet die Plattformintegrit~it neue MOglichkeiten.

Digital Rights Management DRM ist eine Technik die sowohl ft~ das Management yon Firmendaten (Firmen-Unterlagen oder die sichere Gestalmng yon Dokument- und Workflow-Management Systemen) als auch far den so genannten Content (Musik, Videos, Spiele...) eingesetzt werden kann. Mit geringem Aufwand kOnnen damit auf den Terminals Sicherheitsbereiche entstehen, mit denen die Verbreitung und Verwaltung yon Nutzungsrechten fair und nachvollziehbar kontrollierbar sind.

Chipkarten-Interaktion Bei vielen der zuvor erw~ihnten Anwendungsklassen spielen Chipkarten als Tr~iger personenbezogener,

Trusted Computing Grundlagen

41

sicherheitskritischer Daten eine wichtige Rolle. Die vonder TCG definierten Sicherheitskomponenten, wie TPM oder TSS, sichem haupts~ichlich die Integrit~it einer Rechnerplattform ab und sind somit an dieses System statisch gebunden. Im Gegensatz dazu sind Chipkarten portabel, speichern personenbezogene Daten und k6nnen in verschiedenen Sicherheitsumgebungen und Infrastrukturen eingesetzt werden. Bei vielen sicherheitskritischen Anwendungen spielt deshalb ein Austausch von Daten zwischen der gesicherten Rechnerumgebung und einer Chipkarte eine wichtige Rolle. Die Chipkarte garantiert dabei die Authentisierung der beteiligten Personen, wghrend der TPM Chip auf der ,,Trusted Plattform" die Integrit~it der Plattform ~berprfifen kann und damit auch die korrekte Funktion nachgewiesen werden kann.

Chipkartentechnologie ben6tigt sichere Plattformen Ffir die Ausfahrung entsprechender Anwendungen mit Chipkarten (sicheres Banking, digitales Signieren von Daten, Authentisierung und Zugriffskontrolle u.~i.) sind PC-Plattformen notwendig, die sich auf einem ~ihnlich hohem Sicherheitsniveau befinden. Bei bekannt gewordenen Angriffen wird deshalb in der Regel die Plattform angegriffen und vergndert. Um dieses Aushebeln der Sicherheit von Chipkarten basierten Systemen zu verhindern ist auch hier der Einsatz von TC Technologie auf der AnwendungsPlattform dringend erforderlich.

7 Fazit Die Trusted Computing Technologie bietet die M6glichkeit, das Auftreten von ungewollten Zustandsver~inderungen (gleich ob durch externe Angriffe oder interne Fehler) in Computersystemen (wenn es schon aus prinzipiellen GNnden nicht m6glich ist diese zu verhindern) einigermagen sicher zu erkennen und dann entsprechend darauf zu reagieren. Besonders wichtig ist aber dabei, dass alle Teile eines solchen Systems (Hardware, Software und als wichtigster Teil das Betriebssystem) nach den TC Grunds~itzen konstruiert, realisiert und integriert werden. Weder einzelne Sicherheits-Chip oder isolierte SW-Applikationen oder gar umfangreiche SW-Zertifizierungsprogramme alleine erm6glichen Trusted Systeme die gegen externe und interne Angriffe weitgehend resistent sind. Nur wenn alle Teile sich erg~inzen, gegenseitig schfitzen und wohl~berlegt zusammenwirken, ist es m6glich Computersysteme zu entwickeln, die auch unter einer st~indigen Bedrohung durch Angriffe von augen (z.B. fiber unsichere Netze) oder durch eigene fehlerbehaftete Applikationen weiter Ihre Funktion korrekt ausfahren. Die beschriebenen Mechanismen nach dem TCG-Standard schaffen die Voraussetzungen um unter ingenieurmN3igen Randbedingungen vertrauenswfirdige Systeme zielorientiert entwickeln zu k6nnen und damit auch bei der Konstruktion von Datenverarbeitungssystemen Vertrauen und korrekte Funktionalit~it nicht nur ,,hineinzutesten" sondern mit systematischen Methoden und einem beschr~inkten Ressourcen-Aufwand sichere Systeme gezielt zu entwickeln. Trusted Computing wird wahrscheinlich die grundlegende Technologie sein, die es uns erlaubt bei der Systementwicklung die gegenw~irtigen Komplexitfitsschranken und Bedrohungen zu ~berwinden und somit zuverl~issige Ger~ite und Netze zu entwickeln die eine zukfinftige, immer st~irker vernetzte, industrielle Gesellschaft ben6tigt.

WeiterfLihrende Literatur 9 Die gesamte Spezifikation, Konzepte und Architektu~berlegungen der TCG finden sich often auf der TCGWebseite [TCG01]. Ft~rden Umfang der Spezifikations-Aufgabetypisch und andererseits auch notwendig, ist allerdings der erhebliche Umfang (insgesamt derzeit etwa 2000 Seiten mit steigender Tendenz) und die knochentrockene Darstellung, die durchaus abschreckend wirken kann. 9 Die grundlegenden Ziele und Prinzipien sind in ,,TCPA Design Principles" [TCG04] dargestelltoEs empfiehlt sich, zumindest dieses f]Ibersichtsdokumentder TCG direkt durchzuarbeiten.

42

Trusted Computing Grundlagen 9 Sicherheitsexperten von HP, die an der TCG-Spezifikation beteiligt waren, haben das Buch zu TC geschrieben [Pea01]: TCPA Design Philosophies and Concepts. Dieses Buch ist eine sehr empfehlenswerte technische Einffihrung und t~bersicht zur TCG-Philosophie und Technik, gut erklfirt und mit bestem Anwendungsbezug. 9 Auf die Fehlinformationen, Vermutungen und falschen Statements in der TC-Diskussion vor allem der letzten Jahren geht [IBM01 ] ein.

Literatur [Cre01]

Cremers, Spalka, Langweg: 7. Deutscher Sicherheitskongress 2001, Tagungsband: Vermeidung und Abwehr von Angriffen trojanischer Pferde auf digitale Signaturen

[IBM01]

IBM: Watson Research - Global Security Analysis Lab: TCPA Misinformation Rebuttal www.research.ibm.com/gsal/tcpa/tcparebuttalopdf

[INF01 ]

Infineon: TPM Produkt Information: http://www.infineon.com/TPM

[INF02]

Infineon: TPM Herstellerzertifikate: http://www.infineon.com/TPM/certificate

[INT01]

Intel| Trusted Execution Technology: http://www.inteI.com/technology/security

[McF01 ]

Tony Mc Fadden: TPM PC Anbieter 121bersicht: http://www.tonymcfadden.net/tpmvendors_arc.html

[MS01]

Microsoft: Bitlocker, Laufwerkverschl%selung : http://www.microsoft.com/germany/technet/prodtechnol/windowsvista/secprot/bitexec.mspx

[MUL01] MULTOS Betriebssystem: http://www.multos.com [Pea01]

Siani Pearson (ed.): Trusted Computing Platforms: TCPA Technology in Context, Prentice Hall PTR2003

[RUB01]

Ruhr Universit~tt Bochum: Trusted GRUB Bootloader ffir Linux: www.prosec~ html

[TCG01]

Trusted Computing Group Website: https://wwwotrustedcomputinggroupoorg/home

[TCG02]

Specifications: https://www.trustedcomputinggroup.org/specs/

[TCG03]

Trusted Computing bestpractices/

[TCG04]

Trusted Computing Group: Trusted Platform Module https://www.trustedcomputinggroup.org/specs/ TPM

[OTC01 ]

EU Forschungs- und Entwickhmgsprojekt: Open Trusted Computing: http://wwwoopentc.net

[WIN01]

WINHEC2005 Conference: Virmalization Technology for AMD Architecture http://download. microsoft.com/download/9/8/f/98f3 fe47-dfc3-4e74-92a3-088782200fe7/TWAR05014 WinHEC05. ppt

[WIN02]

WINHEC2005 Conference: Virtualization Technology for Intel Architecture http://download. microsoft.com/download/9/8/f/98f3fe47-dfc3-4e74-92a3-088782200fe7/TWAR05015 WinHEC05. ppt

Group:

Best

Practices

https://www.trustedcomputinggroup.org/specs/

TPM Virtualization: Building a General Framework Vincent Scarlata. Carlos Rozas 9 Monty Wiseman David Grawrock- Claire Vishik Intel Corporation {vincent.scarlata I carlos.rozas I monty.wiseman [ david.grawrock t claire.vishik} @intel.com

Abstract Trusted Computing has been widely recognized as a useful and necessary extension of more traditional security mechanisms. In today's complex multi-device environment, it is essential to be assured that devices participating in transactions can be trusted. The Trusted Computing Group (TCG) has created a set of specifications and accompanying infrastructure defining means of assurance necessary to build a trusted environment. Continuing interest in virmalization as a way to extend flexibility in diverse computing environments while addressing issues of underutilization of equipment and energy consumption brings additional complexities to current and future models of trusted computing~ This chapter is a research paper, rather than a discussion of issues for a practical implementation. We talk about today's trusted computing environment by briefly describing Intel| Trusted Execution Technology (formerly LaGrande Technology) as an example implementation of a trusted platform. We dedicate a few sections to the basics of Trusted Platform Modules (TPMs) as defined in TCG specifications, before moving to focus primarily on describing a generalized framework for TPM virmalization. A Virtual TPM (VTPM) framework provides a set of services for trustworthy Virtual TPMs (VTPM) or proprietary TPM-like software. This framework allows multiple mutually distrustful and unaware guests to share a TPM without requiring modifications to guest operating systems or applications that they are running. Additionally, the framework supports the custom cryptographic subsystems with enhanced proprietary functionality that can be adapted to multiple use models. The proposed framework leverages the TPM to ensure that the trustworthiness of the VTPM is rooted in hardware. The proposed framework can be used to design VTPMs with varying security and performance profiles. TPM features optimizing the performance or security in the framework are discussed at the end of the chapter followed by conclusions.

1 Virtualization and Trusted Computing" Background With the re-emergence of virtual machine monitors, the use of virtualization techniques for providing added system assurance has received increased attention. NSA's NetTop[ 14], VMWare's ACE[ 1], Xen at Cambridge and as part of the Open Trusted Computing Project [2][5], Terra at Stanford [6][7 ], and ReVirt at the University of Michigan [3] all make use of virtual machine technology to support a higher level of domain separation than found in traditional systems in order to build a more trustworthy platform providing a higher level of protection. Other systems, such as Parallels desktop for Mac, have become available as products. The Trusted Computing Group[8] (TCG) is working on a set of specifications aimed at augmenting the assurance on a platform by using a Trusted Platform Module[ 12] (TPM) and supporting protocols. The N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 43-56

44

TPM Virtualization: Building a General Framework

TPM can protect platform configuration and measurement data and provide attestation with regard to the state of the platform configuration[15]. There are several research projects focusing on architecting new security solutions for TPM-equipped platforms. In particular, IBM's Integrity Measurement Architecture[16] and Dartmouth College's Enforcer [13] demonstrate how a TPM can be used to measure an operating system, system services, and applications as they are launched. Terra project describes how a trusted virtual machine monitor (TVMM) operating on a platform similar to a TPM-equipped platform could provide "closed-box" VMs based systems. The Open Trusted Computing Project already mentioned above is engaged in building a secure operating system based on XEN for platforms with a TPM as well as TPM-rooted applications in a variety of areas [20], [23]. The EMSCB (European Multilaterally Secure Computing Base) project in Germany is working on architecting an L4 based kernel for TPM-enabled platform capable of supporting a variety of environments [24]. These efforts are complementary. Using the TPM-enhanced software in each virtual machine can provide data protection for the operating system and applications and facilitate attestation to remote entities. Direct work on TPM virtualization has also taken off the ground. It is important to mention here the impressive IBM report on TPM virtualization[27]. The paper describes full TPM specification implemented in software, with functions to create and destroy VTPM (Virtual TPM) instances. The software is integrated into hypervisor environment in order to make the functionality available to virtual machines. The implementation supports suspension and resumption of VTPM operations as well as migrations and covers four models of certificate chains linking software and hardware TPMs.

2 Trusted Computing Group and TPM TPM virtualization is based on hardware TPM specifications and uses protocols and interfaces defined by the Trusted Computing Group. TPM functionality is briefly described below to provide the background for further discussion.

2.1 Trusted Computing Group (TCG) The industry consortium TCG (Trusted Computing Group) has standardized the Trusted Platform Module (TPM) as a cryptographic subsystem providing a foundation for trust on a platform. The core of the TPM's functionality resides in its ability to store information about the platform's configuration and support attestation. The platform can provide information to a remote entity to enable the entity to make decisions about the trustworthiness of the platform. The platform can also instruct the TPM to ensure that keys or sensitive data are only released while the system is using a known "good" configuration, making them unavailable in "non-trustworthy" states. No entity can change the measurements made by the preceding component, and the chain of measurements is created, such that if the beginning of the chain (known as the Root of Trust for Measurement or RTM) and each link are trusted, the entire chain is trusted. Researchers are exploring modifications for the boot process[ 1] and operating systems[ 15] [ 18] to allow the TPM to store meaningful measurements of the state of the platform.

2.2 TPM Components TPMs, smartcards, IBM 475815], and other similar devices are self-contained computing environments, with some perimeter protections. These devices can be trusted to do certain computations without relying on external resources. A TPM comprises the following components. 9 Program Code Segment (PCS) --code segment of a TPM's logic circuits that are typically in ROM and read-only.

TPM Virtualization: Building a General Framework

45

9 Processor--small CPU that executes the PCS. 9 Non-Volatile Memory (NVM)-- storage within the TPM where persistent keys, secrets, and other artifacts of the TPM are stored, is protected against attacks from host software executing on the platform. 9 Active Memory-- volatile memory used to store non-persistent data lost on power off. The technical capabilities of devices built from these components are somewhat limited by available internal resources. With resource constraints, simpler scenarios are implemented in most environments. VTPM framework proposed here can alleviate the problem of limited resources by providing computational areas without resource constraints (but with a potential tradeoff of weaker assurance) that are inexpensive to develop and to deploy.

2.3 TPM Functions Attestation is an essential capability of a TPM and refers to a set of functions and protocols that enable the TPM to prove to a remote party that the platform is using a particular configuration. In order for this claim to be reliable, it must be made by a trustworthy source in an environment that is resistant to tampering. In the case of a TPM-equipped platform, the TPM hardware is implicitly trusted. During attestation, it uses an Attestation Identity Key (AIK) to quote[ 13], or sign, platform measurements it uses to store the platform state. In order to prove to a remote entity that the TPM that signed a quote is a genuine TPM, each TPM has a unique Endorsement Key (EK). In addition to the endorsement key pair, an Endorsement Credential is created asserting the validity of the EK and the TPM. This credential can be signed by the TPM manufacturer, the platform OEM, or the IT department that owns the platform, and the public portion of the EK is used along with the credential to convince the 3rd party (Privacy CA) of the validity and genuine nature of a TPM. Since the EK uniquely identifies the TPM, privacy considerations require that the EK should be used only to verify the validity of Attestation Identity Keys (AIKs) and never the configuration of a platform directly. AIKs, which are created and destroyed by TPM owners, are used for platform attestation. As a root of trust on the platform, a TPM needs to provide cryptographic support for platform attestation and authentication, but also ensure that the user's choice and his/her need for privacy are preserved at all times. In order to uphold privacy, the TPM specification designs the (cryptographic) key hierarchy so that a static identifier (EK) is substituted with domain-oriented keys (AIKs) in attestation protocols in order to reduce privacy issues of a trusted platform (Figure 1 below) and eliminate direct cryptographic associations between the EK and AIKs. In order to perform attestation without affecting privacy of the platform users[26], TCG has defined an infrastructure, allowing the TPM to prove to the Privacy CA that it is a genuine TPM. The Privacy CA creates Identity Credentials for AIKs that the TPM owns. If the Privacy CA trusts the manufacturer of the TPM and the root of trust for measurement *RTM), and a remote entity trusts the Privacy CA, a quote signed by an AIK accompanied by an Identity Credential constitutes a cryptographic proof of the current state of the platform.

46

TPM Virtualization: Building a General Framework

Figure 1oTPM Key Hierarchy The TPM also provides secure storage for data and keys. The TPM can generate RSA keys protected by password-based and platform configuration-based access controls. Platform-configuration bindings specify the set of values that indicate the platform state allowed to use the key. In addition to generating and storing keys, the TPM includes monotonic counters inside the TPM that can be incremented by their owner. The counter values can be embedded into encrypted data to indicate whether the data is the most recent set of values saved and not a replay of old data off disk

3 Intel | Trusted Execution Technology (TXT) TCG specifications are building blocks for creating real-life trusted platforms and environments. But what does it mean, in non-technical terms, to build a trusted computer? Users of personal computers are involved in very important transactions using their PCs and need to trust the device they are using and those platforms, with which their devices are communicating. The users would trust the platform more if the following pieces of information were available to them: ~ Platform provides hardware-based protection, and the existing software is taking advantage of this feature; ~ The system has the ability to recognize when something is wrong and provide a reasonable level of protection when a problem is detected; 9 There are mechanisms that verify configuration information reported by the platform [25]. Intel's Safer Computing Initiative focuses on creating a building block supporting the creation of a trusted computer, Intel| Trusted Execution Technology or TXT (formerly LaGrande Technology or LT)o TXT-enabled platform has the ability to provide information about the status of the computer in

TPM Virmalization: Building a General Framework

47

order to enable the users to make a decision if the platform is adequate (trustworthy) to perform the task at hand. A trusted computer possesses a number of attributes that are listed below: 9 Isolation of programs, to ensure that Program A is not able to access information for program B.

9 Separation of user and supervisor processes, to ensure, e.g., that user applications do not interfere with the operating system. 9 Long term protected storage, ensuring that a value or an artifact is protected across power cycles. 9 Identification of the current configuration, to make sure that identity of the platform and applications on the platform can be verified. ~ A verifiable report of the identity of the platform and current configuration, ensuring that an external observer has an attestation mechanism to confirm their validity. ~ Hardware basis for protection, ensuring that strong safeguards for values on the platform is provided. The first version of Intel| Trusted Execution Technology (or TXT, figure 2 below) is a set of software and hardware components on a platform and a Trusted Platform Module (TPM) setting a protection boundary attempting to mitigate vulnerabilities within this boundary. Combining virtualization with features supporting trust, such as measured launch, Intel| TXT is an important step towards building a trusted computer.

Intel| Trusted Execution Technology Components 9 VT extensions for domain isolation 9 Trusted Execution Tech nology extensions for measured launch & memory protection

3 ~ Party SW 9 VMM provider

3 rd P a r t y

9 Trusted Execution Technology extensions for memory protection and T P M v l . 2 interface

Memory

9 Opt-in for Trusted ExecuUoh~ Technology, VT t T P M v l . 2 9 Complete support of T P M v l . 2 9 BIOS AC Module (SCHECK / SCLEAN) inclusion and support

\

9 S I N I T AC Module 9 6IOS AC Module (SCLEAN/SCHECK)

[

~

9 TPMv:IL.2

3rd Party HW

Input Devices

Figure 2o Intel| Trusted Execution Technology Components With the first trusted platforms such as Intel| TXT already available, research in the area continues. Protections provided to the VMM (Virtual Machine Monitor) and the VTPM can come from various roots of trust. Establishing trust in the VMM and the VTPM using TXT can enhance assurance of the protections of the TPM's keys and bindings to the virtual and physical platforms. Intel| TXT provides assurance by creating a new root of trust measured within a dedicated set ofPCRs. TXT combined with virtualization provides strong and attestable domain separation that can increase assurance in VTPMs.

48

TPM Virtualization: Building a General Framework

4 TPM Virtualization Current TPM specifications envision predominantly a one to one relationship between the operating system and the trusted platform, and most (though not all) existing implementations and architectures are based on the same assumptions. However, today's platforms are beginning to include virtualization mechanisms with multiple partitions hosting operating systems~ These multiple virtual operating systems reside in virtual machines, which themselves are "virtual platforms" and are leading to indirect binding between the OS and the physical hardware. The degree of indirection is different depending on the virtualization model used. This decoupling of the OS from the physical platform is starting to support new usage models, such as migration of a virtual machine (VM) from one physical platform to another. It is important to understand the distinction between TPM virtualization and sharing a TPM. When virtual partitions (VMs or Virtual Machines) share one TPM, with each domain accessing a defined set of TPM resources allocated to that domain specifically, TPM virtualization is not part of the picture: the virtual partitions simply share a subset of the physical resources of a hardware TPM. It is when the two domains need access to the same set of resources in a "physical" TPM that TPM virtualization becomes necessary. Each VTPM (Virtual TPM) has its own EK and can replicate functions of a "real" TPM. A TPM is always a TPM, and a virtual TPM needs to provide an acceptable level of assurance and follow the principles of building a trusted environment that are defined in TCG specifications. Levels of assurance compatible with TCG specifications and requirements of an application, for real and virtual TPMs, may need to be defined in consequence. Using trusted computing techniques on a virtualized platform does not always imply a virtualized TPM. A single TPM can be partitioned to work with several operating systems and shared, as described above. In other models, it is necessary for the VTPM (Virtual TPM) to replicate the functionality of a physical TPM. It is also possible for the guest OS to share a single TPM that may be aware that it is operating in a virtual machine. Different implementations can be devised. It is possible to allocate a VM to serve as a TPM in one to many or in one to one relationships, with Virtual Machines using this type of TPM.

5 Generalized Virtual TPM Framework The VTPM framework illustrated in Figure 3 below contains several components designed to support functional and security properties of tamper resistant modules. The VTPM simulates the crypto coprocessor functionality, and the VTPM Protected Persistent Storage (PPS) is the central repository for each VTPM's NVM (Non Volatile Memory), while the CPU and RAM of the platform provide the processor and active memory resources. The framework imposes the requirement that the platform should isolate the use of the CPU and RAM to ensure the framework is protected from the rest of the platform. One way to meet the isolation requirement is to implement the components in a Trusted Virtual Machine Monitor (TVMM) or use a TVMM to isolate the VTPM in its own virtual machine. The VTPM Manager provides management functions for the VTPMs. VTPM Factory generates new VTPMs and creates the evidence of validity such as credentials. All components must be isolated from the rest of the system in order to ensure the security of the secrets stored in these components.

TPM Virtualization: Building a General Framework

~ .

.

.

49

Hardware .

.

.

Communication Channel

.

Virtual M a c h i n e

ii,ii~ ii~i ~i~,.~.,I Internal Component

Figure 3. Generalized Virtual TPM Framework

5.1 Generalized Virtual TPMs (VTPMs) The VTPM provides TPM or TPM-like functionality to the OS partitions. The protection perimeter of the VTPM is defined by the environment, in which it is executing, e.go the TVMM or the hardware boundary of the platform. By placing the perimeter around each VTPM component and each VTPM instance, VTPM instances maintain isolation in the event of another instance being compromised. The framework supports flexibility in VTPM design by allowing the instances to be implemented in a VM, in dedicated hardware or a combination of the two. This flexibility can support a variety of encryption algorithms, signature schemes, access control policies, and storage mechanisms. For virtual TPMs, each instance manages its own set of TPM resources, including its own Endorsement Key (EK), Storage Root Key (SRK), PCRs (Platform Configuration Registers), monotonic counter, and general purpose NVRAM. VTPM therefore can function identically to hardware TPMs, ensuring that applications can transparently use hardware or virtual TPMs. The framework also allows individual VTPMs to balance performance and security and adapt to a variety of regulatory and geographical environments. Some implementations can focus on supporting faster encryption operations or enhanced

50

TPM Virtualization: Building a General Framework

migration by implementing keys in software within the VTPM, while other environments may require that all keys always reside in the hardware TPM and that the VTPM acts as a portal to access them.

5.2 VTPM Manager The VTPM Manager provides communication channels between the instances and the OS partition and between VTPM instances and the Manager. The VTPM Manager collects information required to authenticate the VTPM instance, e.g., measurement of the code of that instance. The manager also enables the instance to access other VTPM components, including VTPM Factory, PPS, and serialized access to the physical TPM. The primary resources under management include the set of loaded keys and authorization sessions. Sharing techniques proposed in TCG TPM Core Services specification [ 10] can be used here. The only requirement for the VTPM Protected Storage framework is that all persistent data be copied from NVM to Active Memory on load, and then saved back to NVM when necessary. Thus, PPS is responsible for protecting the VTPM instance data while that instance is not in operation. After the instance loads, the TVMM provides isolation and protection of the data while the instance is executing. In protecting NVMs offline, the PPS must provide strong authentication and protection mechanisms rooted in the physical TPM. It is also critical for the TPM to ensure that the TVMM, VTPM, and any other code that can undermine component isolation has preserved integrity since the NVM was saved. If the hardware TPM detects unauthorized changes of a VTPM or the TCB, it prevents the release of secrets to the VTPM instance that appears to have lost integrity.

5.3 VTPM Credentials In the case of the hardware TPM, the manufacturer or trusted 3rd party create a credential supporting the EK in the TPM and certifying that the EK resides in a genuine TPM. This process was described above. The VTPM Factories are designed to perform a similar role, certifying that keys reside in a valid VTPM within a VTPM framework that the Factory represents. The VTPM Factory can create credentials based on two processes.

5.3.1 CA Generated Credentials The Factory can provide evidence of the legitimacy of the VTPM framework to a Certificate Authority (CA) and obtain the signed credentials. The evidence submitted to the CA must be from the physical TPMo This mechanism is effective for relatively static systems. When the system is initialized, a small fixed number of VTPMs are instantiated, and credentials are acquired for them. For highly dynamic platforms where new VTPM instances are created and destroyed frequently, it is desirable to allow the platform to create VTPMs without reliance on CAs. Credentials may contain either detailed information about the platform, or simply the proof of the identity of the maintainer of the platform, such as an IT department. Model fields in credentials can indicate both the hardware and software platform, on which this VTPM resides. For the Endorsement Credential, the model field may include TPM model and the version of the VTPM framework (including VTPM Manager, Factory, and Protected Storage). For the Platform Credential, the model field may include the hardware platform model and the TCB version. Upgrade capabilities may require an equivalency class style grouping for the software platform identification. However, at a minimum, the credentials must identify functionality (primarily support for migration and upgrade) that adds dynamic features to the trustworthiness of the VTPM. The details and capabilities of the VTPM may be either explicitly

TPM Virtualization: Building a General Framework

51

or implicitly stated in the credential. For example, while generating credentials, IT of an organization may include the fact that a system supports upgrade, and that IT is the upgrade authority. If all platforms with credentials signed by IT are upgradable only by IT, simple possession of an IT signed credential is sufficient for IT to determine these characteristics of the VTPM. However, all challengers must know the criteria for the issuance of credentials by the signer in order to trust that signer and know its implicit claims. The abstracted protocol for using an external CA to generate a credential is straightforward. During the creation of a new VTPM, the VTPM Factory instantiates the new VTPM with a Virtual Endorsement Key (VEK). Once the VEK is available, the evidence is collected on its attributes, statement of the properties of the VTPM where VEK is located, and evidence of the confidence of 3d parties tied to the identity of the VTPM Factory that has created the VTPM. This evidence is sent to the CA that evaluates the suitability of the framework to support a trustworthy VTPM. If the CA approves the configuration, it generates Endorsement and Platform Credentials~

5.3.2 Locally Generated Credentials The advantage of generating credentials locally is that environments requiring large numbers of VTPMs, such as servers in utility computing, do not need to contact a CA during every instance of creation of a new virtual machine with a VTPM. It is necessary to establish sufficient trust in the VTPM Factory, so that the Privacy CAs can trust it to "manufacture" VTPMs. When trust is established, it can inform the network of Privacy CAs to delegate TPM "manufacturing status" to the Factory. The Factory can sign a delegation certificate and transmit it to the Privacy CAs. In order to make the Factory's certification meaningful, it must also convince the certifying authority that the VTPM Factory's key is protected. Reliable protection requires the use of TPM keys with platform configuration bindings. Since software key is not likely to provide sufficient guarantees in most environments, the Factory creates a TPM signing key, bound to the configuration of the VTPM and the TCB. The key is then used to sign credentials without further interaction with the CA. The CA evaluates or delegates evaluation of whether the VTPM framework and TCB have been appropriately reviewed~ If the certifying authority trusts the configuration, it can trust the credentials created by the factory to be valid. Optionally, the validity period on Factory's credentials and credentials signed by the Factory can be in proportion to the security review that the VTPM and its TCB have received. The discovery of a vulnerability in the VTPM framework, or the TCB should result in removal of trust in its VTPMs. Under these circumstances, the CA that certified the VTPM Factory revokes its certification.

5.4 Establishing Trust in a V T P M In order to establish trust in a VTPM, trust must also be established for the underlying hardware platform, the TCB (including the VMM and related components), the VTPM framework, and the VTPM. Several kinds of evidence can be used for trust establishment.

5.4.1 Hardware Root of Trust In a TPM platform stack, the deepest level is the hardware TPM, and that also is the basis of trust. Each TPM includes an Endorsement Key and a signed Endorsement Credential. The TCG has defined the

52

TPM Virtualization: Building a General Framework

protocols to extend the trust from the EK to an AIK after a Privacy CA evaluates the evidence. After an identity credential is acquired, any AIK operation accompanied by that credential is an assertion of trust validated by the Privacy CA. The two AIK operations yielding the necessary evidence are TPM_quote (described above) and TPM_CertifyKey. TPM_CertifyKey produces evidence of the attributes of another key co-resident in the TPM where AIK resides.

5.4.2 Underlying Software Trust The next level up in the platform stack is the VMM along with the other components of the TCB and the VTPM framework. These combine to create the software platform hosting a VM and its VTPM. There are two different approaches to gaining assurance in the underlying software platform, which yield different levels of confidence. They are described below. One Time Evaluation assumes an assertion of simplicity or high confidence in platform software or in its maintainers. This approach is appropriate when the TCB and the VTPM framework will not need to change over time and lack the capability to be changed. A platform where the VTPM state is bound to a set of TPM PCRs is an example of such a system. This approach is also valuable where the upgrade authority is trusted and real time evidence and re-evaluation are not required~ An example VTPM creation protocol is referenced below. 1. The VTPM Factory generates the VEK as a TPM Legacy Key. 2. The VTPM Factory uses its AIK to quote the current configuration of the platform via the TPM PCRs, as well as a CertifyKey of the VEK. 3. The factory then uses its signing key to sign the concatenation of the [Quote, CertifyKey, Upgrade Authority's key] and transmits it to a CA. 4. The CA evaluates the evidence to ensure that the current quoted configuration meets all the requirements noted in this document including the security isolation of the VTPM. It ensures the framework will only apply upgrades signed with the enclosed Upgrade Authority key. It also ensures that the Upgrade Authority declared, is an Upgrade Authority trusted by the CA. 5. If the CA evaluation succeeds, it generates an Endorsement Credential for the VEK. In the case of a static TCB and VTPM framework, measurements or version numbers corresponding to measurements of the platform should be included in the credentials. However, in the dynamic system, these measurements will not remain accurate descriptions of the system over time. For this reason, the identity of the Upgrade Authority should be included in the credential. During use of the TPM, the existence of this credential signed by the trusted CA is sufficient evidence to provide assurance that the EK is housed within a trusted TPM and the virtual nature of the TPM is not an obstacle to trusting it. A key benefit of this approach is that the challenger does not need to know the difference between a platform with a TPM and a virtual platform with a VTPM. The shortcoming of One-Time Evaluation is that current evidence of the platform's state is stronger than the assurance that an Upgrade Authority has approved the configuration. Without attestation, a challenger doesn't know that the platform is current. To resolve this issue, the VTPM credentials can reference a mechanism for a challenger to query the underlying platform attestation of the underlying software configuration. This approach has problems: it requires that a VTPM user be able to create and use TPM AIKs in order to request a TPM quote from the TPM below, which presents difficulties. In virmalized environments, there is no standard for sending a command outside a VM: Xen VMM uses Hypercalls to contact the VMM; some other systems can use a network interface to support a query. As a result, several implementation issues arise.

TPM Virtualization: Building a General Framework

53

In a VTPM using Real-Time Deep Attestation, a challenger first requests an attestation from the VTPM. Upon examination of the accompanying credential, it discovers that the VTPM depends on a complex environment below it. The challenger then requests an attestation from the TPM below. The procedure can be repeated until hardware is reached.

5.5 Virtual TPM (VTPM) Designs Two models for VTPM design discussed in this section represent two ends of the spectrum, one ensuring the high level of security, and the other focusing on performance and flexibility. The first model, software-based VTPM, recognizes that after the VTPM is anchored in hardware TPM, software can provide complete TPM functionality to the virtual machine. All private keys are stored in the VTPM's memory, and all other data is stored in the virtual TPM. The second model, referred to as the hardwarebased VTPM, stores all keys in the hardware TPM. In the second model, when a key is used, the VTPM issues a request to the real TPM to use the key. In the first model, the VTPM is not hindered by the performance limitations of the TPM and can access the keys directly, while the second relies on the hardware TPM for most requests. The difference between the first and the second models in terms of assurance is minimal during normal operations. But the two designs display differences after a compromise has occurred. If the VTPM instance or the VMM of a platform are compromised, all data stored in the VTPM instance's memory is compromised as well. After a vulnerability has been corrected, hardware-based keys protected inside the TPM can no longer be accessed by the attacker. Software-based keys, whose private portions are exposed in memory can be copied off the platform by the attacker, in which case you cannot terminate the attacker's access to the key. In many environments, the software-based approach can achieve an adequate level of security, especially when revocation of the compromised keys is easy to carry out. When it is more difficult and expensive to revoke and regenerate compromised keys, the hardwarebased approach is more appropriate. The choice between hardware and software models is defined by the requirements and the necessary level of assurance and performance to be supported. The framework described here leaves the choice of the model to the implementers.

5.5.1 Software-based VTPM Software-based VTPM uses no hardware TPM resources for providing TPM functionality. Once the PPS and the hardware TPM have guaranteed that the VTPM and the TCB are the same as those reflected in the VTPM credentials, the VTPM can function independently of the hardware TPM. All virtual PCRs, monotonic counters, non-volatile storage, and other TPM resources are stored and managed in the memory of the VTPM. The benefit of this design is that the functionality exposed by the VTPM is not hampered by the level of performance defined by the hardware TPM. Stronger keys, larger numbers of key slots and more PCRs can be easily supported. Current hardware TPMs are somewhat resource constrained, in part by choice. Software TPMs do not have performance constraints imposed by small hardware devices with limited resources and can perform resource intensive functions directly.

5.5.2 Hardware-based VTPM The second VTPM design discussed here aims at maximizing the use of the protected processing within the hardware TPM rather than emphasizing performance. In the hardware TPM all keys are stored in the TPM, and private keys are never stored in main memory. Due to restrictions placed on the use of TPM keys, many VTPM keys can't be stored in the same way as TPM keys of the same type. For example, identity keys can only be used to sign platform configuration

54

TPM Virtualization: Building a General Framework

values. This means that the VAIKs, if implemented as real AIKs, would be unable to sign VPCRs, which are external data stored in VTPM memory rather than in the physical TPM. VAIKs within the TPM are then instantiated as TPM Signing keys. During their use, quote structures are constructed for the VPCRs in the VTPM and then signed with the VAIK. During the reception of Identity Credentials, the EK's public key is used to protect the credential in transit. The VTPM needs to decrypt this credential. The only key type that can do this is a TPM Legacy Key; therefore, VEK must be a legacy key. Due to complexities in migration, storage keys must be legacy keys, too, changing the structure of the key hierarchy in the TPM. Table 1 below shows mappings between hardware TPM and Virtual keys. Table 1" Virtual to Physical Key Type Mapping Virtual Key Type

Hardware TPM Key Type

Virtual Endorsement Key:

TPM LEGACY

Virtual Storage Key:

TPM LEGACY

Virtual Attestation Identity Key:

TPM_SIGNING

Virtual Signing Key:

TPM_SIGNING

Virtual Binding Key:

TPM_BINDING

Legacy keys cannot have children, and as a result, the virtual hierarchy cannot maintain its form in the TPM. Since the TPM does not support this structure, the hierarchy has to be flattened, and the VTPM enforces the logical hierarchy at run time.

5.5.3

Enforcing Virtual PCRs on TPM Keys

The hardware TPM and the virtual machine using the VTPM have different definitions of the current PCR values. Care must be taken to ensure that information flow between them remains consistent. When a virtual machine requests that a key be created in the VTPM, the request is accompanied by VPCR bindings, though the guest may not realize they are virtual. When this request is forwarded to the hardware TPM, the PCR field in the request must be translated into correct HWPCR bindings.

VTPM Wrapped Key I

I

PuNic Portion of Key Additional ~ P M Protected Portion Odgina! TPM Protect Potion of Key Figure 4. Wrapped Keys

TPM Virtualization: Building a General Framework

55

To address this issue, the wrapped key returned by the VTPM is a modified form of the wrapped key returned by the hardware TPM, shown in Figure 4 above; however, all public portions of the structure remain intact to ensure transparency.

5.5.4

!n h a Itsverzei

O t h e r V T P M Resources

c h n is

The VTPM cannot share some of the TPM resources. Monotonic counters cannot be shared without modifying to expect non-exclusive counter usage and therefore must either be permanently E i n l e i applications tung allocated to a specific VTPM instance or implemented in software. VTPM non-volatile storage can reside in the hardware TPM, is it does not exceed the storage size of the hardware TPM. The virtual maTrusted Computing- eine E i n f 0 h r u n g chine must be able to create authorization sessions to use many of the TPM functions; however, it canNorbertbetween Pohlmann 9Helmut Reimerby the VTPM directly and those passed on to the hardware not differentiate functions handled TPMo As a result, the VTPM must be able to transparently provide TPM functionality, from itself and Grundlagen the hardware TPM under the single user authorization session~ In order to accomplish this, the VTPM1 3 must maintain separate authorization sessions with both the virtual machine and the hardware TPM.

Die Trusted Computing Group

15

Thomas Rosteck

6 Conclusions Trusted ComputingTPM Grundlagen The framework for Generalized Virtualization proposed here uses a physical TPM to enable secure 21 virtual TPM operation Hans Brandl and facilitates the development of secure cryptographic subsystems, covering a range of uses, with emphasis either on assurance or on flexibility and performance. Virtual TPMs enable the combination of isolation created by virtual machine technology and TPM functionality, providing TPM Virtualization" Building a General Framework 43 hardware-based secure storage and attestation. The framework ensures transparency of the virtualized Vincent Scarlata. Carlos Rozas 9Monty Wiseman. David Grawrock. Claire Vishik environment, and applications do not need to treat TPM access from within virtual machines differently than TPM access on platforms without virtualization. With growing interest in virtualization combined Trusted Computing die applications U m s e t z u n gto in h evirtualized u t i g e n B eenvironment, triebssystem e nframework 57 with security mechanisms used tound enable trust the described Sebastian in this chapter Rohr provides a foundation for further study of technologies indispensable for the dynamic computing environments of the future. Sicherheitsbausteine fiir Anwendungen 71

References [1] [21

[3] [4]

IS] [6]

[7]

M e h r V e r t r a u e n s w ~ i r d i g k e i t fLir A n w e n d u n g e n d u r c h Trusted grub.html. eine S i cgrub. h e r hhttp://www.prosec.rub.de/trusted eitsplattform 73 Vmware reinvents enterprise desktop management and security with breakthrough new product, http:// Markus Linnemann 9Niklas Heibel 9Norbert Pohlmann www.itsecurity.com/tecsnews/sep2004/sep240.htm, September 2004.

B. Dragovic, K. Fraser, S. Hand, T. Harris, A. Ho, I. Pratt, A. Warfield, R Barham, andR. Neugebauer. Die i c hthe e r hart e iof tsp l a t t f o r m Turaya XenSand virmalization. In Proc. ofACM Sympo on Operating Sys.Principles, October 2003. 86 Ammar Alkassar. Christian St0ble G~ W. Dunlap, So T. King, S. Cinar, M. Basrai, and R M. Chen. Revirt: Enabling intrusion analysis through virtual-machine logging and replay. In Proc. of 2002 Symp. on Operating Sys.Design and Implementation, December 2002. Trusted Network Connect- Vertrauensw0rdige Netzwerkverbindungen 97 J. Dyer, M. Lindemann, Ro Perez, R. Sailer,L. van Doom, S. W. Smith, and S. Weingart. Building the Marian Jungbauer. Norbert Pohlmann ibm 4758 secure coprocessor. IEEE Computer, 34(10):57-66, 2001. K. Fraser, S. Hand, R. Neugebauer, I. Pratt, Ao Wareld, and M. Williamson. Safe hardware access with Interaktionen TPM und Smart Card 110 the xen virtual machine monitor. In Proc. of 1st Workshop on Operating Sys and Arch Support for the on demand IT InfraStructure, October 2004. Florian Gawlas 9Gisela Meister. Axel Heider 9Sebastian Wallner T. Garfinkel, B. Pfaff, J. Chow, M. Rosenblum, and D. Boneh. Terra: A virtual machine-basedplatform for trusted computing. In Proc. of 19th ACM Symp. on Operating Sys. Principles, pages193-206, 2003.

56

TPM Virtualization: Building a General Framework

[8]

T. Garfinkel and M. Rosenblum. A virtual machine introspection based architecture for intrusion detection. In Proc. of Net. and Distributed Sys. Sec. Symp, February 2003.

[9]

Trusted Computing Group. http://www.trustedcomputinggroupoorg.

[10]

Trusted Computing Group. TCG Software Stack Specification, version 1.2. Available at: https://www. trustedcomputinggroup.org/specs/TSS/TSS_Version_l.2_Level 1 FINAL.pdf

[11]

Trusted Computing Group. Trusted platform module main specification, part Design principles, version 1.2, revision 94. Available at: https://www.trustedcomputinggroup.org/specs/TPM/

[12]

Trusted Computing Group. Trusted platform module main specification, part 2: Tpm structures, version 1.2, revision 94. Available at: https://www.trustedcomputinggroup.org/specs/TPM/

[13]

Trusted Computing Group. Trusted platform module main specification, part 3: Commands, version 1.2, revision 94. Available at: https://www.trustedcomputinggroup.org/specs/TPM/

[14]

Trusted Computing Group. TCG Specification Architecture Overview, version 1.3, May 2007. Available at:https://www.trustedcomputinggroup.org/groups/TCG 1 3 Architecture_Overview.pdf John Marchesini, Sean W. Smith, Omen Wild, and Rich MacDonald. Experimenting with tcpa/tcg hardware, or: How i learned to stop worrying and love the bear. Technical Report TR2003-476, Department of Computer Science, Dartmouth College, December 2003.

[16]

R. Meushaw and D. Simard. Nettop: Commercial technology in high assurance applications, http:// www.vmware.com/pdf/TechTrendNotes.pdf, 2000.

[17]

D. Safford. The need for TCPA. http://www.research.ibm.com/gsal/tcpa/why tcpa.pdf, October 2002.

[18]

R. Sailer, X. Zhang, T. Jaeger, and L. van Doom. Design and implementation of a tcg-based integrity measurement architecture. In Proc. of 13th USENIX Security Symposium, pages 223-238, 2004.

[19]

M. Swift, B. Bershad, and H. M. Levy. Improving the reliability of commodity operating systems. In Proc. of 19th Symp. Operating Sys. Principles, October 2003.

[20]

Eimear Gallery and Chris Mitchell. Trusted Computing Technologies and Their Use in the Provision of High Assurance SDR Platforms. Available at: http://www.opentc.net/publications/OTC_SDR_Paper. pdf

[21]

Trusted Computing Group. TCG Credentials Profiles, version 1.1, May 2007. Available at: https:// www.trustedcomputinggroup.org/specs/IWG/Credential_Profiles_V I_R 1.14.pdf

[22]

HariGovind V. Ramasamy and Matthias Schunter. Architecting Dependable Systems Using Virmalization. Available at: http://www.opentc.net/publications/OTC_Architecting_Dependable_Systems.pdf

[23]

Shane Balfe and Eimear Gallery. Mobile Agents and the Deus Ex Machina. Available at: http://www. opentc.net/publications/OTC_TC_MobileAgents.pdf

[24]

EMSCB. Information at: http://www.emscb.com/content/pages/49241.htm

[25]

David Grawrock. The Intel Safer Computing Initiative: Building Blocks for Trusted Computing. Intel Press, 2006.

[26]

Claire Vishik, David Hoffman, and Karim Lesina. In Search of a Perfect Identifier. EU RFID Convocation, March 2007. Available at: http://www.rfidconvocation.eu/Papers%20presented/Technical/In%20 Search o~20of%20a o~20Perfect o~20Identifier.pdf

[27]

Stefan Berger, Ramdn Cficeres, Kenneth A. Goldman, Ronald Perez, Reiner Sailer, Leendert van Doom. vTPM: Virmalizing the Trusted Platform Module. IBM Research Report. Available at: http://domino. research.ibm.com/library/cyberdig.nsf/1 e4115aea78b6e7c85256b360066f0d4/a0163 fff5b 1a61 fe85257 178004eee39?OpenDocument&Highlight=0,RC23879

Trusted Computing und die Umsetzung in heutigen Betriebssystemen Sebastian Rohr Konrad-Zuse-Strasse 1,85716 Unterschleil3heim Microsoft Deutschland GmbH [email protected]

Zusammenfassung Die Historie des Trusted Computing ist eng verbunden mit der Trusted Computing Group (TCG) und deren Vorg~inger Organisation, der Trusted Computing Platform Alliance. Microsoft hat die Bestrebungen dieser Organisationen von Beginn an untersttitzt und maggeblich mitgestaltet, um deren Ziele - n/~mlich die Schaffung eines Industriestandards far eine sichere Rechnerumgebung - erfolgreich in neuen Betriebssystemen und Anwendungen umzusetzen. Dieses Kapitel befasst sich mit den Implikationen far die sichere Entwicklung von Software, die sich aus den Spezifikationen der TCG und den allgemeinen Grundlagen des Trusted Computing ergeben. Am Beispiel von Microsoft Windows Vista werden dann einige umgesetzte Technologien und deren Bedeutung far Anwender und Unternehmen kritisch beleuchtet sowie die Aussichten far zukanftige Weiterentwicklungen diskutiert.

1 Grundlagen und Uberblick Der Begriff des Trusted Computing (TC) an sich wird an verschiedenen Stellen unterschiedlich definiert - einig sind sich die meisten Quellen jedoch fiber den Ursprung bzw. die Treiber far die Entstehung und Etablierung des Trusted Computing: die immer gr6ger werdende Anzahl und Auswirkung von b6swilligen oder unabsichtlichen Manipulationen von Computern und IT- Systemen bei gleichzeitig immer st~irker werdender Abh~ingigkeit von deren reibungslosen Betrieb (Verfagbarkeit) und ihrer Integrit/~t (keine Ver/inderungen an abgesendeten Emails, Onlinebestellungen oder Buchungsvorg~ingen). FOr die Anwender dieser Systeme wurden viele Verbesserungen zur eindeutigen Identifikation, Authentifizierung und far den Datenschutz realisiert. FOr die dabei genutzten Computersysteme gab es jedoch kaum Sicherheitsmechanismen oder Vorkehrungen, die bei der Wahrung ihrer Integrit/it eingesetzt werden konnten. Die Idee hinter Trusted Computing zielt also auf die bessere Wahrung alt bekannter Sicherheitsziele wie Vertraulichkeit, Integritgt, Authentizit/~t und Verfagbarkeit, jedoch mit dem Fokus auf die Integrit~it des Computersystems. Die Ziele Revisionsf'~ihigkeit und Transparenz k6nnen im Rahmen dieses Beitrages nicht berficksichtigt werden, da diese eher die Applikationen als die Kombination Hardware/Betriebssystem betreffen. Zun/~chst wird in Abschnitt 1.1 auf die Anf~inge des TC eingegangen um dann in Abschnitt 1.2 den Zusammenhang zwischen TC und der Microsoft Strategie des Trustworthy Computing (TwC) zu erkl~iren. Der Hauptteil mit Abschnitt 2 ft. zeigt dann einzelne technische Mal3nahmen und deren Umsetzung im Betriebssystem Windows Vista im Detail, w~ihrend Abschnitt 3 einen Ausblick auf kfinftig zu erwartende Technologien bietet. Ein Fazit in Abschnitt 4 bildet dann den Abschluss der Betrachtung und geht kritisch auf die bisher erreichten Bestandteile des Trusted Computing in heutigen Betriebssystemen ein.

N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 57-70

58

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

Wie verhindert aber nun Trusted Computing, bzwo die Kombination aus den viel diskutierten Hardwarebausteinen, dem Trusted Computing Module - kurz TPM - und softwaretechnischen Magnahmen, eine Manipulation von entsprechend ausgerfisteten Computern bzw. scht~tzt diese vor einer Kompromitierung? Zur Beantwortung dieser Frage empfiehlt sich ein Blick zuNck ins Jahr 2002, in dem Bill Gates ffir Microsoft die ,,Trustworthy Computing" (TwC) Initiative ins Leben fief.

1.1 Trustworthy Computing- dieAnf~inge Nachdem durch konzentrierte Angriffe auf bestimmte Schwachstellen in Betriebssystem und Anwendungssoftware wie ,,Code Red" und ,,Nimda" weltweit massive finanzielle Sch/~den und Ausfallzeiten bei kritischen Anwendungen und Systemen zu verzeichnen waren (Vgl. [1] und [2]), wurde die komplette Ausrichtung des Konzems Microsoft auf das Trustworthy Computing umgestellt. Jegliche Entwicklungsarbeit, alle Softwareprojekte und Designprozesse wurden unterbrochen um die jeweiligen Teams und einzelne Entwickler durch intensive Schulung auf die Richtlinien ,,Secure by Design" und ,,Secure by Default" einzustimmen. Es werden seit dem umfangreiche Mal3nahmen zur Etablierung von Codereview Prozessen und Komponenten- wie Systemtests durchgeffihrt und jedem Entwicklungsteam wird ein dedizierter Sicherheitsverantwortlicher zur Seite gestellt, der ffir die Umsetzung der drei Treiber des Trustworthy Computing ,,Security, Privacy, Reliability" und der Teststeuerung verantwortlich ist. Diese Bestrebungen auf Seiten der Technologieentwicklung werden durch Hilfestellung und Beratung bei der Umsetzung neuer Dienste im Kundenumfeld flankiert- hierfar steht ,,Secure by Deployment". Dazu z/ihlen auch Handlungsanweisungen, Best Business Practices und auch Tools, die etwa f-fix die Sicherheitsfiberprfifung oder das Patch Management eingesetzt werden. Abschliegend bilden eine offene Kommunikation und ein mehrseitiger Austausch zwischen dem Anbieter und den Kunden und Anwendern sowie 6ffentliche Schulungsmagnahmen, Aufkl/~rungsinitiativen zum sicheren Umgang mit Informationstechnologien und universit/~re Kooperationen das notwendige Rahmenwerk, um die Trustworthy Computing Strategie mit Leben zu ffilleno Weitere Informationen zum Trustworthy Computing, der Entwicklung fiber die letzten ffinf Jahre und dem Ausblick ffir die Zukunft findet man unter: http ://www.microsoft.com/germany/sicherheit/twc/TwChomepage.mspx

1.2 Trusted und Trustworthy Computing der Zusammenhang Da Microsoft Grfmdungsmitglied der TCPA und der sp~iteren TCG ist, war es eine logische Schlussfolgerung das interne Paradigma Trustworthy Computing mit den Bestrebungen und Spezifikationen des Trusted Computing zu koordinieren. Die bereits genannten Schutzziele der IT-Sicherheit spielen bei der Interaktion der beiden Initiativen eine maggebliche Rolle und bilden zugleich den gr6gten Uberlappungsbereich, da TC eher technische Mal3nahmen an einem Hardwarekonzept beschreibt, wghrend Trustworthy Computing einen komplett neuen Ansatz verk6rpert Software und Computersysteme insgesamt wieder vertrauenswfirdig, stabil und verl/isslich zu konzipieren. TwC orientiert sich durch den Fokus auf die Gesch~iftspraktiken und die ,,Privacy", also den Datenschutz fftr Anwender, vielmehr auf die Personen und nicht unbedingt die Technologie, die bei TC im Mittelpunkt steht. Inhalt des TwC ist u.a. die Vermittlung von Handlungsanweisungen, Anleitung flit einen ,,sicheren" Softwareentwicklungsprozess, die lfickenlose Planung und Inbetriebnahme von komplexen IT Systemen sowie deren Pflege und Integrit~itssicherung. Das Trusted Computing hingegen konzentriert sich maggeblich auf die Kombination des TPM Hardwarebausteins mit grundlegenden Sicherheitsfunktionen des Betriebssys-

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

59

tems (Secure Startup - direkter Zugriff auf das TPM) bzw. dessen Interaktion mit genau spezifizierten Administrationstools und der Schlfisselverwaltung mittels der sogenannten TPM Base Services (TBS). Auch wenn die Ans~itze des TwC und des TC unterschiedlich erscheinen unters~tzen sie beide direkt die Sicherheitsziele Vertraulichkeit, Integrit~it, Authentizit~it und Verfagbarkeit- doch dazu spgter mehr in den Abschnitten 2.1.1 und 2.3.1. Ein besonders wichtiger Kritikpunkt begleitet die Historie des Trusted Computing von Anfang an, n~imlich der Vorwurf, den Nutzer eines Computers zum ,,gl~isernen" Anwender zu machen bzw. ihm letztlich die Kontrolle t~ber sein Ger~it zu entziehen. Dies stttnde im krassen Gegensatz zu einem Kerninhalt des Trustworthy Computing, n~imlich die Vertraulichkeit und Integrit~it der Plattform und der Anwenderdaten zu sichem und zu schfitzen. Auch hierauf soll im folgenden Abschnitt eingegangen werden.

2 Mal nahmen z u m S c h u t z der S i c h e r h e i t s z i e l e mittels TC Die in den vorigen Kapiteln beschriebenen Grundlagen des TC manifestieren sich in einem PC System heute vornehmlich durch einen Hardwarebaustein, das Trusted Platform Module oder TPM. Dieser Baustein wird zumeist als integraler Bestandteil des Mainboards oder Motherboards eines PCs, Servers oder Laptops von den Herstellern oder Systemlieferanten verbaut (Vgl. [3]). Gerade die feste Einbindung in die tiefsten Hardwareschichten, ein Bereich der selbst gestandenen IT-Fachleuten oft verschlossen bleibt, hat in der Vergangenheit far viel Unmut und Kritik gesorgt- diese kann aber heute weitgehend als entkr~iftet gewertet werdeno Schon frfih ~iul3erten sich Bedenken hinsichtlich des Kontrollverlustes (der Anwender oder der Konsument sei nicht mehr Herr t~ber sein eigenes System, (vgl. CCC: [4]). Die Bedenken richten sich meistens auf die M6glichkeiten der Verschlt~sselung mittels des TPM, der Schlfisselerstellung und ihrer Verwaltung. Da das einer Smartcard ~ihnliche TPM ein eigenes internes Schlfisselpaar (Endorsement Key, EK) besitzt, welches nicht vom Anwender manipuliert werden kann, bietet sich hier laut den Kritikern eine bisher so nicht m6gliche eindeutige pers6nliche Zuordnung von Inhalten. Auch die Idee, ein Digital Rights Management auf Basis der TPM-Bindung von z.B. digitalen Musik- oder Videoinhalten zu schaffen, bzw. die R~ickverfolgung von Dateien die auf einem solchen TPM ges~tzten System erzeugt wurden zu erm6glichen, sorgten far Angste und Bedenken unter den Datenscht~tzern. Da eine solche Zuordnung jedoch eine nahezal unermessliche Datensammlung und Korrelation voraussetzt und die Erhebung und vor allem Pflege und Aktualisierung dieses Datenbestandes Kosten in nicht abzuscMt= zender H6he verursachen wgrde, bleiben diese Anwendungen des TPM Fiktion. Doch wie kann ein TPM nutzbringend eingesetzt werden um die Sicherheit des Computersystems, die Vertraulichkeit der darauf gespeicherten Daten und die Abgrenzung verschiedener Anwender(-daten) auf einem Multiusersystem zu erreichen? Diese Ziele stehen in Einklang mit den Zielen des Trustworthy Computing und deren Umsetzung wird in den folgenden Abschnitten erlgutert.

2.1 Direkte Interaktion yon Vista mit dem TPM Eine der grN3ten Herausforderungen und Forderungen der Anwender w~ihrend der Designphase von Windows Vista war der Schutz der Vertraulichkeit von auf dem System gespeicherten Daten bei Verlust, Betriebsende oder Anwenderwechsel und/oder Verkauf. Eine Vielzahl von Laptops wird jghrlich ,,verloren", in Taxis vergessen oder aus Wohnungen und Automobilen gestohlen. Im Gegensatz zu relativ leicht abzuwehrenden Angriffen aus der Ferne, gilt ein im physischen Zugriff des Angreifers befindli-

60

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

ches Get,it heute als nahezu kompromittiert. Die BIOS- oder Betriebssystemmittel des Zugriffschutzes (wie Passw6rter) k6nnen durch die direkte Interaktion mit der Hardware (Festplatte) fast vollkommen vernachl~issigt werden. Genau hier setzt die Festplattenverschlfisselung BitLocker an, die im folgenden erkltirt wird~

2.1.1 Bitlocker und Secure Startup Der einfachste Ansatz einen PC bzw. seine Daten vor unerlaubtem Zugriff zu schfitzen, ist die Verwendung einer Nutzername/Passwort Kombination. Neben den damit verbundenen Problemen (St~irke der Passworte, regelmfigiger Passwortwechsel etc.) schfitzt selbst ein Boot- oder BIOS- Password das Computersystem nicht ausreichend, wenn der Angreifer fiber lgngere Zeit physikalischen Zugriff auf das System hat und ggf. mit einem fremden Betriebssystem oder fiber einem ,,Recovery Versuch" - mit z.B. einer Knoppix Boot CD - die Festplatte des System auszulesen versucht. Jede Art von Betriebssystemschutz muss hierbei versagen, da das Betriebssystem die ihm eigenen Schutzfunktionen nicht ausfiben kann, eine typische Bypass Situation. Der einzig hilfreiche Ansatz ffihrt fiber die Verschlfisselung des Dateisystems bzw. der gesamten Betriebssystem- oder Datenpartition eines Rechnersystems~ Bisher konnten solche Mal3nahmen nur fiber den Einsatz von Drittherstellertools erfolgreich umgesetzt werden, wobei ein immenser Teil des Aufwands auf die organisatorischen Aspekte der Schlfisselverwaltung und der Recovery Funktionen ffir das Untemehmen entfielen. In Windows Vista besteht nun die M6glichkeit, die Funktionen des TPM zur Verwalmng yon Schlfisselmaterial und zur Speicherung von Sicherheitsinformationen zu nutzen. Der Schlfissel f-fir den initialen Zugriff auf das Dateisystem w~ihrend des Bootvorganges liegt im TPM - d e r sogenannte Storage Root Key, S R K - und kann nicht manipuliert werdeno Wird die Festplatte ausgebaut und in einem anderen Rechner fiber ein anderes Betriebssystem ein Zugriff versucht, so scheitert dieser an der abwesenden/ unpassenden Schlfisselquelleo Vista gleicht in der PreBoot Phase ab, ob die im TPM hinterlegten Integrit~itsinformationen (Blueprint) der beim Startvorgang verwendeten Betriebssystemdateien mit den akmellen Daten fibereinstimmen. Dieser Vorgang wird als ,,Static Root of Trust for Measurement" (SRTM) bezeichnet, und sichert die Integrit~it des Bootstacks. Bei einer Manipulation des Dateisystems (vorheriger Zugriffsversuch durch ein anderes Betriebssystem) wird der Bootvorgang unterbrochen. Im Austausch zwischen TPM und BIOS (,,Core Root of Trust" genannt) wird dann der Start einer ersten kleinen Teil des Bootstraps angestogen. Sollten hier Manipulationen am BIOS oder der Hardware insgesamt festgestellt werden, w~ire ebenfalls ein Abbruch des Bootvorganges denkbar. Erst wenn dieser Schritt erfolgreich beendet werden konnte wird der n~ichste Schlassel der Kette, der Full Volume Encryption Key FVEK, aus dem mit dem SRK verschlfisselten Bereich des Dateisystems gelesen. Der symmetrische FVEK wird im Folgenden genutzt, um die Informationen des verschlt'tsselten Dateisystems bei Zugriff zu entschlfisseln bzw. neu zu schreibende Informationen verschlfisselt abzulegen.

2.1.2 Secure Startup ohne TPM Neben der unter 2.1.1 vorgestellten Transparent Operation Mode genannten Methode stehen noch zwei weitere Betriebsmodi zur Verfagung:

User Authentication Mode: Hierbei muss der Nutzer w~ihrend des Startvorgangs, ~ihnlich einem BIOS Passwort, ein Passwort eingeben, dass den FVEK entschlfisseln kann. Der TPM wird hierbei nicht genutzt, der Ablauf ist aber vergleichbar mit den oben beschriebenen.

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

61

USB Key Mode: Hierbei kommen USB Token eines L6sungsanbieters zum Einsatz, auf denen der entsprechende prim~ire Schlt~ssel abgelegt ist. Die Funktionalit~tt ist hier ~ihnlich zu den bereits far frfihere Versionen von Windows verfagbaren PreBoot Authentication und Verschlfisselungsl6sungen. Im Laufe des oben beschriebenen Bootvorganges wird jedoch nicht der TPM abgefragt sondern das USB Token. Der dort abgelegte Schl~ssel ist von Haus aus nicht weiter abgesichert und wird direkt abgefragt um den Bootvorgang einzuleiten. In diesem Modus w~ire die Sicherheit alleine vom Besitz des USB Sticks abh~ingig. Geht das Notebook zusammen mit dem USB Stick verloren, kann der Angreifer das System problemlos booten. Es ist also organisatorisch dafar zu sorgen, dass Token und Laptop nie gemeinsam gelagert, transportiert und zug~inglich gemacht werden.

2.1.3 Verschl~isselte Token Ein Ansatz f'tir die Optimierung des unter 2.1.2 dargestellten Ansatzes liefert eine zusgtzliche Verschlfisselung des USB Sticks mit dem Schlfisselmaterial. Dieser erweiterte Ansatz schfttzt auch den USB Stick und sieht vor, dass man s i c h - ghnlich einem BIOS Passwort- zun~tchst am USB Stick authentisieren muss (Two Factor Authentication, Besitz und Wissen). Vorteil hierbei ist die Nutzbarkeit jeglicher existierender USB Sticks in einem Unternehmen, da die L6sung auf einer Softwareerweiterung basiert. Nachteil in einem grogen Unternehmen wgre das schwierige Management, welches im TPM Ansatz durch den Einsatz von AD als zentrales Repository ffir die Recovery Keys gel6st wird. Eine ,,Sammelstelle" far Kopien der SRKs (um bei Verlust der USB Sticks kein Recovery fahren zu mfissen) fehlt bisher. Den Anwendern steht es frei, die von Vista und dem (deaktivierbaren) TPM bereit gestellten Funktionen zu nutzen oder sich far die Tools eines anderen Anbieters zu entscheiden.

2.2 Management der Schl~issel in Unternehmen Erh6hte Sicherheit muss sehr off mit h6herem Aufwand erkauft werden. Im Unternehmensumfeld muss sichergestellt werden, dass die sensiblen Daten auf den PC Systemen auch dann lesbar und zugreifbar bleiben wenn der Mitarbeiter ausf'~illt, wenn ein Hardwaredefekt (Laptop TFT oder Festplattencrash) vorliegt oder der TPM eine Fehlfunktion haben sollte. Da das TPM und die BitLocker Verschlfisselung logisch aneinander gebunden sind, ist ein einfaches ,,Umh~ingen" der Festplatte aus einem defekten Laptop in ein funktionierendes Ger~it so nicht m6glicho Der Prozess zur Reaktivierung lgufl wie folgt ab: lm Problemfall steht dem Administrator zun~ichst ein Recovery Key (RK) zur Verfagung, der automatisch bei der Initialisierung von BitLocker erstellt wird~ Der im TPM gespeicherte RK kann exportiert (siehe hierzu 2.3) und zur besseren Handhabung und Verwaltung in das Active Directory eingepflegt werden. Somit steht far jedes System der Recovery Key jederzeit zur Verfagung und es muss kein zus~itzlicher Aufwand zur Pflege der RK betrieben werden. Diese Methode schfitzt auch vor dem unwahrscheinlichen Schadenfall mit TPM-Verlust oder Beschfidigung.

2.3 Indirekte Interaktion mit dem TPM 0ber TBS und TSS Da der weitl~iufige Zugriff auf das TPM erheblich Probleme bei der Wahrung der Integrit~it des Bausteins mit sich bringen wfirde, sieht die Spezifikation der TCG einen direkten Zugriff auf die TPM Treiber- wie unter 2.1.1 beschrieben - nur far die Realisierung eines Secure Startup Prozesses vor. Alle weiteren Zugriffe werden fiber genauestens spezifizierte Schnittstellen und restriktive Vorgaben mittels der sogenannten Trusted Base Services (TBS) geregelt, die einen Zugriff durch Admin Tools und den

VIII 62

Trusted Computing und die Umsetzung in heutigenInhaltsverzeichnis Betriebssystemen

Key Storage Provider erm6glichen sowie die Schnittstellen fOr den TCG Software Stack (TSS) bereit stellen (siehe Abb. 1).

Anwendungsszenarien

123

Enterprise S e c u r i t y - I n f o r m a t i o n s s c h u t z im Unternehmen

125

Michael Hartmann. Gunter Bitz Unternehmensweites

TPM Key Management

k25J

140

Bernhard Weiss Trusted C o m p u t i n g im Hochsicherheitsbereich

156

Peter Kraaibeek 9Hans Marcus Kr0ger 9Kai Martius Trusted C o m p u t i n g for automobile

IT-Systeme

Der TPM und sein Software Stack

170

Andrey Bogdanov 9Abb. Thomas Eisenbarth 9Christof Marko Wolf 1: Das TPM Modul und die Paar. hardwarenahe Software m p u t i n und g in mobiler Anwendu n g : Von Z u g a n g s k o n t r o l l e 2.3.1 Trusted AdminC oTools Key Storage Provider zu Identit~iten

187

Um zum Beispiel spezielles, exportierbares Andreas U. Schmidt 9Nicolai Kuntze Schlfsselmaterial (wie den RK) aus dem TPM zu exportieren, stehen die Admin Tools bzw. der Key Storage Provider zur VerfOgung. Diese greifen fiber spezifizierte Calls auf dieund TPM rTreiber Datenschutze c h t lzu i cund h e erm6glichen A s p e k t edas Schlfisselmanagement, die Aktivierung/ 207 Deaktivierung des TPM und werden auch fOr die prim~ire Initialisierung genutzt (acquire ownership - d a s Opt-In bei der Nutzung von TPMs). Gerade in einem Unternehmensumfeld mit tausenden von A u s w i r k u n g e n von Trusted C o m p u t i n g auf die Privatsph~ire 209 TPM-Rechnern bieten diese beiden Module, erg~inzt um den TCG Software Stack (TSS), die notwenMarkus Hansen 9Marit Hansen dige Managementschnittstellen fOr eine solche Infrastruktur. Insgesamt muss hier klar der Vergleich zu einer Public Key Infrastructure gezogen werden, da die zentrale und einfache Verwaltung von Sicherheitsschlgsseln fOr Maschinen (TMPRisiken RKs etc.) den,,Trusted gleichen C Prinzipien 221 Rechtliche Chancen und des o m p u t i nund g " Sicherheitsvorkehrungen nachkommen wie die Verwaltung von auf Nutzer bezogenen Schlt~sseln, Zertifikaten oder ~ihnliAndreassollte Neumann chem Datenmaterial wie es in einer PKI verwaltet wird.

Biographien der A u t o r e n

237

Diverse Anbieter von TPMs bieten in Kooperation mit den OEM und Mainboard Herstellern Management Tools an, die genau diese Skalierbarkeit und einfache Nutzung abbilden. Eine Integration Glossar 2 4mit, 3 bzw. die Spiegelung von Daten in ein existierendes Active Directory bilden hier aus Gesichtspunkten da keine parallele Infrastruktur aufgebaut und betrieben werden Sdes t i cTCO h wden o r tanzustrebenden v e r z e i c h n iZustand, s 249 muss. Als einer der ersten Anbieter ist Infineon in der Lage, ein auf Vista abgestimmtes Enterprise Management fOr TPM anzubieten. Ober dieses Management ist z.B. auch der Import von personenbezogenen Zertifikaten/Schltisseln in das TPM hinein m6glich, so dass dem Anwender des Systems Applikationen wie Signatur und Verschlfisselung von Emails/Code, Mehrfaktor Authentisierung, sichere Speicherung von Browserzertifikaten, geschftzte Ablage von Schlfsselmaterial zur Datei- oder Verzeichnisverschl~isselung zur VerfOgung stehen. Darfiber hinaus sind die bereits unter 2.2 genannten Aufgaben der Administration bequem gber eine einheitliche GUI m6glich. Die Integration mit anderen Tools zur Erweiterung der Funktionalit~it kann fiber die genau definierten und frei verffgbaren Spezifikationen der TCG erfolgen und zukfnftig vielf'~ltige Erweiterungen der TPM Nutzung erm6glichen.

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

63

2.3.2 NX Funktionen - Data Execution Protection (DEP) Eine nicht direkt mit dem TPM interagierende aber dennoch dem TC Ansatz zuzurechnende Funktion ist ,,NX" - oder No Execute, bzw~ die Softwarekomponente DEE N X ~ E P ist eine Kombination aus Softwareunterstt~tzung und Hardwarefunktionalit~it und wird yon den beiden grof3en CPU Herstellern AMD und Intel seit der Einfahrung von LaGrande (Intel) bzw. der AMD FX64 Prozessoren implementiert. Mit NX/DEP ausgestattete Systeme k6nnen das Ausffthren von Daten verhindern, wenn diese mit einem ,,No Execute" Bit markiert wurden. Eine Schwachstelle in einem Bildbetrachtungstool mittels einer ver~inderten *.JPG Dateien w~ire dann nicht ausnutzbar, da die Applikation den in der manipulierten Datei enthaltenen Code nicht ausffihren wfirde.

2.3.3 Adress-Verschleierung - ASLR Viele Systemprozesse und Services unter XP und Windows 2000 wurden nach strenger Regel in immer gleicher Folge geladen und an immer gleicher Stelle im Speicher abgelegto Diese Information- wenngleich far den Programmierer sehr komfortabel- stellte eine einfach ausnutzbare Grundlage far viele Angriffskonzepte der vergangenen Jahre dar. Sowohl Programmierer als auch Hacker mussten sich nicht erst ,,orientieren", wo in einem bestimmten Fall an welcher Stelle welcher Puffer lag, sondern konnten diese wohlbekannten Adressen direkt ansteuern. War eine Schwachstelle gefunden, so konnte relativ einfach fiber den wiederholten Angriff auf eben diese statische Adressierung eine ganze Population an Rechnern kompromittiert werden. Um den Angreifem diesen Vorteil zu nehmen wurde in Vista die Address Space Layout Randomization (ASLR) eingefahrt, mit der nun die diversen DLL und EXE Dateien nicht mehr fest an einem Ort, sondern zuf'~illig an einem von 256 Stellen im Speicher liegen k6nnen. Ein Angreifer hat es in Zukunft schwerer eine bestimme Funktion aufzurufen, da ihre genaue Adresse nicht von vornherein bekannt ist~ Komplett auszuschliel3en sind Angriffe auf diesem Wege nicht, da Prozesse immer noch den Systemstatus abfragen k6nnen und somit die ,,aktuelle" Adresse einer DLL finden k6nnen. Die schnelle und nahezu blinde Ausnutzung einer Schwachstelle fiber einen statischen Angriff kann jedoch ausgeschaltet werden.

2.4 D e r S e c u r e K e r n e l und das T r u s t e d C o m p u t i n g Am Anfang war das Trusted Computing yon der Idee gepr~igt, die angestrebte ,,Trusted Computing Platform" auch mit einem vertrauenswfirdigen sicheren Kernel auszustatten. Diese Bestrebungen der Softwareentwicklung wurden bei Microsoft unter dem Begriff der NGSCB, Next Generation Secure Computing Base, zusammengefasst. Im Gegensatz zu den relativ einfach zu implementierenden weil fiber sehr beschr~inkte Funktionalit~it verfagenden sicheren Betriebssystemen flu Smartcards, gestaltete sich die Entwicklung eines solchen sicheren Betriebssystem Kerns vor dem Hintergrund der immer st~irker werdenden Diversifizierung der Aufgaben (DTP, Grafikanwendungen, Musikwiedergabe, Office Anwendungen) far Computer als nicht zu bew~iltigeno Als deutlich wurde, dass ein ,,sicherer Kernel" so nicht realisierbar war, wurde begonnen andere M6glichkeiten der Absicherung einer Computerplattform zu untersuchen. Diese Ans~itze werden im Folgenden n~iher erl~iuterto ==

2.4.1 Uberprivilegierte Prozesse Eine besondere Schwachstelle der bisherigen etablierten Betriebssysteme war das Berechtigungssystem far die laufenden Systemprozesse oder Services, d i e - wie der Name schon impliziert- mit Systemberechtigungen liefen. Viele Anwendungsprozesse wurden ebenfalls mit erheblichen Rechten ausgestattet, da sie in einem bestimmten Umfeld einen Zugriffmit hohen Rechten ben6tigten, den Rest ihrer Aufgaben j edoch ,,fiberprivilegiert" erledigteno Dies lag an einem viel zu grob gerasterten Berechtigungskonzept und

64

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

ffthrte dazu, dass diese System- oderAnwendungsprozesse immer wieder das ZieI vonAngreifern wurden. (Vgl. LSASS: [5])

2.4.2 Der,,least privilege mode" Um die potentielle Gef~ihrdung des Systems zu verringern wurden in Windows Vista die Prozesse einzeln re-evaluiert und ihre Berechtigungen den tats~ichlichen Anforderungen angepasst. Dies ffihrte dazu, dass Vista viele frtther im ,,Local System" Kontext laufende Prozesse nur noch in den weniger privilegierten ,,Local Network" oder ,,Local Service" Kontext ausfahrt. Dies ist vergleichbar mit dem Ansatz des User Account Control (UAC), der im Abschnitt 2.5 n~iher behandelt wird. Sollten Angreifer in der Lage sein einen der ,,Systemprozesse" zu kompromittieren, so erreichen sie dadurch keine ,,Systemlevel Berechtigung" mehr. Hinzu kommt, dass ~ihnlich wie in den Sicherheitsklassen bei Zugriffsberechtigungen kein so genannter ,,write up" erfolgen kann. Das heisst es wird aktiv unterbunden, dass ein Prozess mit geringen Privilegien auf Ressourcen zugreift, die h6here Privilegien voraussetzen bzw. von einer Ressource h6herer Integrit~it gestartet wurdeno

2.4.3 Kapselung von Prozessen / Prozess-Hardening Um das Missbrauchspotential von kompromittierten Prozessen weiter einzuschr~inken, wurde im Rahmen der unter 2.4.2 beschriebenen Re-Evaluierung auch der Kontext eines jeden Systemdienstes genauestens geprfift und seine Interaktion mit der Umgebung analysiert. Daran anschliegend wurde ein als Prozess-Hardening bezeichneter Vorgang angestogen, indem differenziert festgelegt wurde mit welchen Komponenten der Service unter normalen Bedingungen interagiert. Jegliche darfiber hinaus gehende Interaktion wird daraufhin mittels einer dedizierten Access Control List (ACL) unterbunden. Um diese ACL auch gezielt einen Dienst oder Service zuordnen zu k6nnen, wurde das System um einen ffir jeden Dienst spezifischen Security Identifier (SID) erg~inzt, der es erm6glicht den Prozess eindeutig zu identifizieren. Die ACLs sind somit exklusiv ffir jeden Service einzeln bestimmt und k6nnen nicht nachtr~iglich vom System oder dem Anwender manipuliert werden. Im Falle eines Service Prozesses, dernur auf (eine) bestimmte (Anzahl) Objekte zugreifen darf, k6nnen mit Hilfe eines Access Tokens die Zugriffe auf bestimmte Ressourcen begrenzt werden. Wird versucht auf andere Ressourcen zuzugreifen, wird dies fiber die Access Tokens bzw. die ACL unterbunden. Die Access Tokens leiten sich aus dem Kontext ab, in dem der Prozess gestartet wurde. Ein Standarduser startet solche Prozesse im Integrit~itslevel Medium (siehe hierzu 2.5.2), ein vom Administrator gestarteter Prozess kann sich hingegen auch im Integrit~itslevel High befinden.

2.4.4 Kapselung von Prozessen / Firewalling Viele Systemprozesse wurden nach einer 121bernahme missbraucht um fiber die Kommunikationsschnittstellen andere Systeme zu kontaktieren und diese ebenfalls zu kompromittieren. Vielfach waren diese Prozesse gar nicht ffir die Inter-System Kommunikation vorgesehen, ein Sachverhalt der durch die unter 2.4.3 dargestellte Abgrenzung teilweise schon behoben werden konnte. Um nun auch Prozesse zu schfitzen, die regelm~tgig mit anderen Prozessen oder Systemen kommunizieren, sind weitere Magnahmen erforderlich. Durch die eindeutige Zuordnung einer SID zu jedem Prozess k6nnen auch Netzwerkfirewall Regeln far jeden Prozess oder Dienst erstellt werden, anhand derer die Interaktion mit anderen Systemen fiber jegliche Schnittstelle kontrolliert werden kann. Somit ist es m6glich, ungewollten oder unvorhergesehenen Netzwerkverkehr zu unterbinden, bevor m6gliche Angreifer weitere Zielsysteme angreifen k6nnen. Die Angriffsplattform far Netzwerkattacken wie ,,SQL Slammer" kann hierdurch massiv verkleinert bzw. sogar g~inzlich ausgeschaltet werden.

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

65

2.4.5 Virtualisierung von Systemkomponenten Da viele Programme und Anwendungen aus der Historie heraus nur mit vollen Systemrechten oder unter dem Administrator Account zu betreiben sind -zum Beispiel solche, die Ver~inderungen an der Registry in HKEY_LOCAL_MACHINE oder etwa in C:\WINDOWS vornehmen- stellt dies eine hohe Anforderung an die zu gew~ihrleistende Abw~ihrtskompatibilit~it. Unter dem von User Account Control (UAC) angewendeten Prinzip der ,,least privileges" wfirden solche Programme nur mit geringen Rechten ausgefahrt und k6nnten ihren Dienst verweigern. Um die damit einhergehende Sicherheitsproblematik zu berficksichtigen und dennoch ausf'Ohrbare Programme zu erhalten, ftthrt Vista eine kontextabhfingige Virtualisierung und ein Redirect von Schreibanforderungen auf solche ,,verbotenen Ressourcen" aus. Somit k6nnen eigentlich auf die ganze Maschine anzuwendende Einstelhmgen in einen Anwender- bzw. Anwendungsbezogenen Kontext gebracht werden. Die Anwendung erMlt in einem virtualisierten Umfeld volle Rechte und kann Anderungen an Systemkomponenten vornehmen, der eigentliche Betriebssystemkern wird hierdurch jedoch nicht ver~indert.

2.5 User A c c o u n t Control (UAC) Ahnlich den unter 2.4.1 angesprochenen, oft t~berprivilegierten Prozessen, ist es durchaus t~blich ffir allt~igliche Arbeiten einen Nutzeraccount zu verwenden, der der Administratorgruppe angeh6rt - also volle administrative Rechte hat und diese zu jeder Zeit anwenden kann. Damit einhergehend 6ffnen sich jedoch viele Sicherheitsprobleme, Managementprobleme und Helpdeskprobleme. Dem Anwender ist allzu oft unklar, dass er gerade im Begriff ist massive Ver~inderungen am Betriebssystem vorzunehmen, nur weil er ein ,,kleines Tool" installiert. Da er als Administrator arbeitet, ist far ihn schwer zu differenzieren, wie gravierend dieses ,,Tool" nun in das System eingreift. Ebenso schwer wiegend sind die m6glichen Angriffe fiber Phishing und Social Engineering, die den Anwender zum Beispiel verleiten einen Email Dateianhang sofort zu 6ffnen, bzw. auszufahren. Die harmlos erscheinende Grafikdatei entpuppt sich dann schnell als ausft~rbare Datei, die zudem im Administratorkontext aktiviert wurde. Die Folgen sind far jeden Sicherheitsfachmann deutlich absehbar, ihre Auswirkung nahezu unfibersehbar. Von Helpdesk Calls aufgrund von Fehlfunktionen oder langsamen Rechnern bis hin zu groben Sicherheitsproblemen mit kompromittierten Zugfingen und manipulierten Serversystemen reichen die bisherigen Beobachtungen- verbunden mit den dadurch verursachten Kosten sicher ein Anreiz zu handeln! In groBen Unternehmen bietet User Account Control nun die M6glichkeit, vormals im ,,Administratormodus" betriebene Rechnerpopulationen auf einfache Standarduser zurfick zu fahren.

2.5.1 Least Privilege auch fLir Administratoren Es bedarf sicher einer Gew6hnungszeit und l]berzeugungsarbeit far die Administratoren, um sich an die neue Arbeitsweise im Umgang mit der Rechneradministration anzupassen. Von jeher ist bekannt, dass technische Mal3nahmen alleine niemals eine volle Wirksamkeit entwickeln k6nnen, wenn sie nicht durch organisatorische und psychologische Mal3nahmen unterstfitzt werden! Im Falle des User Account Controls (UAC) bei Windows Vista bedeutet dies, sich an eine Anzahl an Warnhinweisen zu gew6hnen, die beim Ausftthren von kritischen administrativen Aufgaben auf genau diese Kritikalit~it hinweisen. Um die o.g. Sicherheitsproblematik abzufangen wird generell und vor allem dem Administrator eines Vista Systems empfohlen, im Kontext eines normalen Anwenders zu arbeiten. Sobald eine administrative Aufgabe anfiillt die erh6hte Rechte erfordert, musste hierbei bislang mit dem Befehl ,,run as..." gearbeitet werden. Dies entf'~tllt nun, da das System den Anwender einfach bei Aufruf der kritischen Funktion nach den entsprechenden Angaben (fiblicherweise Nutzername Passwort) fragt. Als Administrator (oder Mitglied der Administratorengruppe) ist man jedoch in der Lage das Verhalten des Prompts zu ver~indern, so dass z.B. nur noch ein best~itigender Mausklick erforderlich ist (nur far Mitglieder

66

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

der Admin-Gruppe). Hat man sich als Administrator angemeldet, so bekommt auch weiterhin keine Prompts - ist man jedoch als Nutzer angemeldet, der der Gruppe Administratoren angeh6rt, so arbeitet man standardm~il3ig mit niedrigen Rechten und bekommt die Prompts. Als Einstieg fiir UAC zeigt sich ein besonderer Unterschied: bei der Erzeugung des ersten neuen Anwenders nach der Installation von Windows 2000 oder XP wurde dieser Anwender automatisch in der Gruppe Administratoren angelegt. Vista legt neue Anwender als Standardnutzer an, denen die M6glichkeit zur ,,Account Elevation", also dem ,,Aufsteigen" zum Administrator durch den UAC Prompt erm6glicht wird. Diese Anderungen gehen tiefer und wirken sich direkt auf die bereits diskutierte Sicherheit der Prozesse aus, wie in den folgenden Abschnitten erkl~irt wird.

2.5.2

Integrit~it f o r P r o z e s s e - UlPI

User Interface Privilege Isolation (UIPI) hilft dabei, die von/mit gering privilegierten Accounts gestarteten Programme auf ihr eigenes Level zu beschr~inken und den Austausch von Windows Messages mit Prozessen h6herer Einstufung zu unterbinden. Dieser Ansatz stuft die Prozesse in eines der vier Integrity Level 9 Low 9 Medium 9 High 9 System eino Neben den Prozessen (Subjekten) k6nnen auch jedem Objekt, also auch Dateien, Ordnern oder einem Registry Key, solche Integrity Level (IL) zugeordnet werden. Somit kann ein Browser, der in einem niedrigen Integrit~itskontext (etwa Low oder Medium) gestartet wird, nicht mehr schreibend auf Systemressourcen h6herer Integritgt zuzugreifen. UAC verwendet diese Integrity Level um den Kontext zu bestimmen, in denen Anwendungen gestartet w e r d e n - ein vom Administrator gestarteter Prozess bekommt also ein Integrity Level ,,High". Startet man als normaler Anwender einen Intemet Explorer, so wird dieser als ,,Medium IL" (siehe Abb.2) eingeteilt, ein vom Administrator gestarteter IE genauso hier wird keine ,,Elevation" des gestarteten Programms betrieben, da der Inter Explorer eine entsprechende IL Vorgabe mitbringt! Um dem hohen Gef'~ihrdungspotenzial eines Browsers zu entsprechen kann man durch einfache Kommandozeileneingabe Browser in einem ,,Low IL" starten, siehe hierzu Joanna Rutkowska's Beschreibung in ihrem Blog auf http://theinvisiblethings.blogspot.com/2007/02/ running-vista-every-day.html -

Das Prinzip dem UIPI zu Grunde liegende Konzept zur Kommunikation beschr~inkt sich auf ein Unterbinden des ,,write up", ein ,,read up" ist aus Grfinden des Systemdesigns dennoch m6glich. Um den unerwfinschten Zugriff auf zu scht~tzende Dateien zu unterbinden werden flankierende Magnahmen wie Verschlt'~sselung und erweitertes Zugriffsrechtemanagement empfohlen.

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

67

AdmiNstrator in Ad.min

Apprc~JNNode ~,ogon

~~~~~'I~;Full a

c

c

e

S~andard user access token

s

administrator token

s

t

"- i EXPiorer, exe i ~-~-~<~~

.................. ~ ~ : ~

Standard user Iogon

S~ndard user access token

Der IL Kontext eines Exploreraufrufes Abb. 2" UIPI in der Anwendung

2.5.3 Erh6hte Integrity Level fLir administrative Tasks Da es ~iugerst l~istig w~ire als Standardnutzer dauemd ,,Elevation Prompts" best~itigen zu mf~ssen wenn man einen administrativen Task ausftihren will, kann man fiber den Application Information Service (AIS) eine einfache Alternative nutzen. Der AIS erm6glicht es, ffir einen bestimmten Task einen Prozess unter Nutzung des Administrator Access Tokens mit hohem Integrity Level zu starten. Dieser mit hohem IL ausgestattete Prozess bietet dann den notwendigen Kontext um die gewfinschten administrativen Tasks auszuflihren. Eine Darstellung des AIS Ablaufes findet sich in Abbildung 3.

E3 ~ mini~rat~ve

appiication attempts ~:o rvn,

~ ].AIS initiates the e~eva~ion p~omp[,

~ioNn~ [ prom;tsthe

[ user~ Elevate? Yes

C

Application not laun~,

does

Appli caUon launches as

administrator,

App!ic~.[io n is

closed and elevated process

exits~ Ablauf eines Applikationsstarts mit AIS Abb. 3" AIS Regelung beim Start administrativer Tasks

2.5.4 Eigene Ma6nahmen - Nutzersegregation Die von Vista angebotenen Ma6nahmen zur Absicherung des Systems gegen kompromittierte Prozesse und Services l~isst sich auf Seiten des Anwenders mit ein wenig Aufwand abrunden. Die Idee der UIPI

68

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

und der UAC erm/Sglicht far den erh6hten Schutzbedarf oder besonders experimentierfreudige Anwender die Erstellung von dedizierten Accounts far bestimmte Aufgaben. Ziel dieser weiteren Gewaltentrennung ist es, Anwendungen mit hohem Gef'~ihrdungspotenzial wie Webbrowser und Mailclients in einem niedrigen Integrity Level ausfahren zu lassen, um den m6glichen Schaden far das System bei einer Kompromitierung so gering wie m6glich zu halten. Hierfar sollte man zungchst einen Standarduser als prim~iren Account verwenden. Zusgtzlich erstellt man dann z. B~ e i n e n - jeweils gezielt mit Low IL ausgestatteten - Email und Webbrowser Account, welche jeweils nur auf eine definierte Region des Dateisystems zugreifen dflrfen (dies wird ftber ,,normale" ACLs etabliert!). Der Start der entsprechenden Applikationen muss dann fiber eine Zeile Skript erfolgen, um auch tats~ichlich ein Low IL f'ttr Browser und Mailclient zu erhalten.

Einleitung

2.5.5 Management von Identit~iten

Neben den internen Ansfitzen zur Verbesserung der Systemsicherheit spielt die Verwaltung der digitalen Identit~it eines Users eine immer gewichtigere Rolle. Durch die Zunahme an schutzbed~rftigen Applikationen im Unternehmensumfeld sowie den immer lmafassender werdenden Angeboten an WebDiensten, sind die Anwender mit einer stetig steigenden Anzahl an Nutzeridentit~iten und dazu geh6renden Passworten konfrontiert. Neben der bereits diskutierten impliziten Unsicherheit des Nutzername/Passwort Schemas bedeutet die Durchsetzung von strengen Richtlinien zur Passwortsicherheit eine erhebliche Last far den Anwender. Seit geraumer Zeit werden massive Anstrengungen zur Verbesserung der Situation untemommen, die sich unter dem Kflrzel I A M - Identity & Access Management- zusammenfassen lassen. Im Unternehmensumfeld ist der Ansatz einer Zentralisierung der Erfassung, der Zuordnung und der L6schung von Identitgten in einem Identity Lifecycle Management System State-of-the-Art. Dies wird oftmals durch flankierende Magnahmen wie Enterprise Single-SignOn und/oder den Einsatz von Smartcards/Tokens zur Mehrfaktor Authentisierung unterstfitzt. Hierbei ist besonderes Augenmerk auf die Ausgewogenheit von Datenzentralisierung und der informativen Selbstbestimmung bzw. dem Schutz der Privatsph~ire sowie des Datenschutzes zu legen, da oftmals die Personalabteilung mit ihren detaillierten Informationen zur realen Identit~it des Anwenders ein Stakeholder des IAM Programms ist. Eine strenge Abgrenzung des wirklich ben6tigten (need to know) vom ggf. komfortabel zur Verfagung stehenden (nice to know) ist zwingend erforderlich.

2.5.6 F6deration im privaten Umfeld- CardSpace Ahnlich verhNt es sich f-fir den Anwender in seinem privaten Umfeld - eine Vielzahl an Nutzeraccounts und Zug~ingen zu diversen, voneinander getrennten Systemen. Da hier kein zentraler Interessenvertreter f'fir die Koordination der Daten existiert, werden diverse Ans~itze zur L6sung des Problems diskutiert. Zun~ichst nutzt der Anwender die Dienste eines Serviceproviders, z.B. eines Freemail Anbieters oder eines Webshops und muss sich hierfar mit einer digitalen Identit~it registrieren. Der Anwender meldet sich an der Seite des Anbieters an, ist somit identifiziert und authentisiert. Will der Anwender nun andere Dienste nutzen, mfisste er sich jedes Mal neu registrieren und jeweils teilweise ~ihnliche teilweise unterschiedlichen Informationen von sich Preis geben. Hier kommt theoretisch der Identity Provider ins Spiel, der diese pers6nlichen Informationen des Anwenders in kontrolliertem Umfeld vorhfilt und selektiv den Service Providern die ben6tigte Auswahl an Informationen des Anwenders fibermittelt. Dieses ganze Konstrukt basiert auf Vertrauen - zwischen dem Anwender und dem Identity Provider sowie zwischen dem Identity Provider und den jeweiligen Service Providern. Diese Identity Provider zentrische Struktur wird teilweise sehr kritisch gesehen, da erstens die Vertrauensbeziehungen etabliert

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

69

sein mt~ssen und zweitens der Anwender sehr viel sensible Information an den Identity Provider fibermitteln muss. Ein gegens~itzliches Modell ist Anwender zentriert, und stellt dem Anwender frei, seine Informationen auf einer Anbieter spezifischen ,,Karte" zusammen zu stellen welche dem Service Provider fbermittelt wird. Ein Rahmenwerk ffir eine solche Strategie bieten unter anderem Microsoft mit seinen CardSpace Ansatz (frtther InfoCard) sowie SXIP Identitys ,,SXIPPER".

2.5.7 F6deration im betrieblichen U m f e l d - ADFS Der unter 2.5 angesprochene Ansatz der zentralisierten Verwaltung von Identit~itsinformationen ist nur solange valide, wie sich die juristischen und datenschutzrechtlichen Bestimmungen einwandfrei einhalten lassen. Da Unternehmen immer 6fter dazu tendieren in weiten Teilen mit anderen Untemehmen zu kooperieren, sei es im Rahmen einer Projektarbeit oder einer langfristigen Einbindung eines Zulieferers, mfssen auch immer h~iufiger Daten ausgetauscht werden. Dies wird zunehmend durch einen direkten Zugriff auf die ERP oder Produktionsplanungstools realisiert, was eine gegenseitige Pflege von Nutzeridentit~iten notwendig macht um eine Nachvollziehbarkeit der Transaktionen zu gew~ihrleisten. Der Ansatz der Identit~its-F6deration eignet sich hier besonders, da die ,,doppelte" Pflege von Identit~iten entfallen kann. lJber den Einsatz eines Active Directory Federation Service (ADFS) k6nnen die Mitglieder der einen Organisation sich wie gewohnt an ihrem System anmelden und arbeiten. Sobald ein Zugriff auf Systeme der fdderierten Organisation erfolgt, werden die t~ber ADFS regulierten und standardisierten Anfragen zur Nutzeridentifikation und Authentisierung sowie die anschliel3ende Authorisierung ftir den Nutzer unsichtbar abgewickelt. Ohne wiederholte Eingabe von Nutzername/Passwort oder sonstiger Legitimation kann hier ein entferntes System sicher genutzt werden, was zudem die Anwender entlastet. Neben einer grunds~,ttzlich etablierten Vertrauensbeziehung setzt solch eine F6deration ein vertragliches Rahmenwerk voraus, in dem Art und Umfang der gegenseitigen Zugriffe genau geregelt werden! Das komplexe und weite Feld des Identity & Access Managements und insbesondere der FOderation von Identitgten kann und soll im Rahmen diese Beitrages nicht weiter gehend diskutiert werden, da es sich zwar um eine Kernthema des TwC aber nur ein Randthema des TC handelto

3 Ausblick auf k inftige Entwicklungen Die bisher in Vista abgebildeten Mal3nahmen und M6glichkeiten aus dem Umfeld des Trusted Computing zeigen einen Einstieg in die M6glichkeiten und Vorteile, die eine Kombination von vertrauenswfirdig konzipierter und sicher implementierter Hardware und ebenso sorgf~ltig entwickelter und umgesetzter Betriebssystem Software schaffen kann. Die kommende Version des Windows Server Betriebssystems ,,Longhorn" wird diesen Weg weiter beschreiten und die S~iulen des Trustworthy Computing weiter st~irken. Funktionalit~iten wie eine BitLocker Verschlfisselung ffir den gesamten Plattenplatz eines Servers, Integration der TPM Management und Recovery Funktionalit~it in das Identity Lifecycle Management (ILM) und das Active Directory sowie noch weiter voranschreitende Virtualisierung von Betriebssystem Komponenten zur Absicherung kritischer Prozesse kennzeichnen diesen Fortschritt.

70

Trusted Computing und die Umsetzung in heutigen Betriebssystemen

4 Fazit Viele sicherheitstechnische Probleme und harte Anforderungen im Hinblick auf die Sicherheit und Integrit~it von Computersystemen konnten mit Vista und den aus TC und TwC abgeleiteten Mal3nahmen gel6st werden. Die Interaktion und Interoperabilit~it solcher Systeme mit Vertretern der OpenSource Bewegung (vgl. [6] und die Bestrebung der EU) wird in Zukunft t~ber den gemeinsamen wirtschafllichen und ideellen Erfolg des Ansatzes entscheiden. Eine Vielzahl an offenen Schnittstellen und deren gemeinsam getragene Weiterentwicklung wird fOr das notwendige Rahmenwerk sorgen, in dem zulainftig von Trusted Computing geschfitzte Systeme neben herk6mmlichen Systemen koexistieren und diese gemeinsam eine vertrauenswfirdige Abwicklung der IT gestfitzten Geschfiftsprozesse erm6glichen.

Literatur [1] [2] [3] [4] [5] [6]

http://www.cert.org/advisories/CA-2001-26.html http ://www.cert.org/advisori es/CA- 2001 - 19.html http ://www.tonymcfadden.net/tpmvendors.html http ://www.datenre ise.de/de/tc/kritik, p hp http ://www.microsoft.com/technet/security/bulletin/MS 04-011 .mspx http ://www.opentc.net/

Si c h e rh e i t s b a u s t e i ne for Anwendungen

Mehr VertrauenswLirdigkeit fLir Anwendungen durch eine S i c he rhe its p Iattfo rm Markus Linnemann- Niklas Heibel. Norbert Pohlmann Institut ffir Intemet Sicherheit, FH Gelsenkirchen www.intemet-sicherheit.de {markus.linnemann I niklas.heibel I pohlmann} @intemet-sicherheit.de

Zusammenfassung Moderne Trusted Computing Technologien erm6glichen es bereits, Rechnersysteme auf Integrit~it und Authentizit~it zu p~fen. Kombiniert mit einer Sicherheitsplattform, die diese Funktionen kontrollieren und durchsetzen kann, werden viele sicherheitskritische Anwendungen erst in der Praxis vertrauenswardig nutzbar. Das Isolieren sicherheitsrelevanter Vorg~ingeund eine definierte Kontrolle t~berdas Rechnersystem gew~ihrleisten da~ber hinaus eine vertrauensw~rdige Verarbeimng von digitalen Inhalten. Die Anwendungsbereiche einer solchen auf Trusted Computing basierenden Sicherheitsplattform werden in diesem ArtikeI beispielhaft beleuchtet und sollen zur Erschlief3ung weiterer Gebiete animieren.

1 Einleitung Die Entwicklung zur vemetzten Wissens- und Informationsgesellschaft und die multimediale Vernetzung vieler Bereiche des t~iglichen Lebens ffihren zu einer starken Erh6hung des schfitzenswerten Datenbestandes. Der Zugriff auf Daten von jedem Ort der Welt aus offenbart neben der hohen Flexibilitfit vor allem eine sehr grol3e Angriffsfl~iche. Fehler in Betriebsystemen und Anwendungen, die fttr Angriffe ausgenutzt werden k6nnen, multiplizieren sich oftmals durch die globale Vemetzung der Rechnersysteme. Aus diesem Grund erstrecken sich die Angriffsm6glichkeiten von privaten Rechnersystemen fiber den Service Provider bis fiber das gesamte Intemet. Um digitale Inhalte in diesem Umfeld sinnvoll schfitzen zu k6nnen, ist es notwendig, die Kommunikationspartner und die genutzte Hard- und Software auf Integrit~it und Authentizit~it vertrauenswfirdig prfifen zu k6nnen. Bei sensiblen Daten ist es augerdem notwendig, den Umgang mit den Daten auf entfemten Rechnersystemen dem Schutzbedfirfnis entsprechend reglementieren zu k6nnen. Der sorglose Umgang mit sensiblen Daten, die nur mangelhaft vor unbefugtem Zugriff geschtitzt sind, fOrdert die Entwicklung von organisierter Kriminalit~it im digitalen Umfeld. Angriffe sind nicht mehr ausschliel31ich das Werk von Computer-affinen Anwendem, die lediglich beweisen wollen, dass sie einen Angriff durchfahren k6nnen. Vielmehr steht die illegale Bereicherung auf Kosten anderer im Vordergrund, die mittlerweile immer h~iufiger bis zur Schwerstkriminalit~it reicht [McAf06]. Hierffir sind entsprechende innovative Schutzmal3nahmen dringend erforderlich. Im Zuge der globalen Vemetzung werden besonders im Businessumfeld zunehmend Arbeitsvorg~inge automatisiert- ein entscheidender Vorteil der digitalen Welt. Diese neuen Funktionen beinhalten abet auch das selbstst~indige Durchft~hren von vertrauensw~rdigen Aktionen durch Maschinen. Somit ist N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 73-85

74

Mehr Vertrauenswfirdigkeit fOrAnwendungen durch eine Sicherheitsplattform

die Uberprfifbarkeit der Vertrauenswiirdigkeit von Rechnersystemen ohne menschliche Interaktion eine notwendige Forderung innovativer IT-Konzepte. Wir brauchen eine vertrauenswfirdige IT, realisierbar durch eine Sicherheitsplattform, die Sicherheitsprobleme existierender Rechnersysteme 16st, bzw. die sch~idlichen Auswirkungen von Malware und Fehlbedienungen stark einschr~inkt. Dazu geh6ren zum Beispiel die ScMden, die durch Viren, Wttrmer, Trojaner, Phishing, Rootkits, Exploits und Software-Updates hervorgerufen werden k6nnen. Die garantiert vertrauenswttrdige Verarbeitung von Informationen auf dem eigenen und auf fremden Rechnersystemen, die Unterstt~tzung existierender Betriebssysteme, sowie transparente Sicherheit (Vertrauenswttrdigkeit) sind Grundanforderungen an eine solche Sicherheitsplattformo Trusted Computing in Kombination mit einer Sicherheitsplattform, wie Turaya, erm6glicht einen vertrauenswflrdigen Umgang mit sicherheitskritischen Daten. Doch welche Anwendungsfelder k6nnen konkret von einer solchen Sicherheitsplattform abgedeckt werden?

2 Einsatzfelder f ir Sicherheitsplattformen Eine Sicherheitsplattform ist auch ohne einen Sicherheitschip, sprich ohne neue Hardware, einsetzbar, erreicht aber bei weitem nicht dasselbe Sicherheitsniveau. Bei den beschriebenen Anwendungsszenarien wird davon ausgegangen, dass die Sicherheitsplattform auf der Basis von Trusted Computing Hardware (TPM) arbeiteto Der Einsatz von Sicherheitsarchitekturen muss f'tir Privatanwender und Businessanwender separat betrachtet werden. Der Privatanwender hat t~blicherweise Inhalte von geringerer Brisanz und Wichtigkeit im VerhNtnis zum Businessanwender und ist zumeist in der Lage sicherheitskritische Vorg~inge, die mit Geldwerten zu tun haben auch ohne die Nutzung des Mediums Internet durchzuffihren~ Nichtsdestotrotz bringt diese Technologie auch einen Mehrwert ftir den Privatanwender, was anhand eines OnlineBanking-Beispiels konkretisiert wird. Das vorrangige Einsatzfeld einer Sicherheitsplattform auf Basis der Trusted Computing Technologie ist im Enterprise-Bereich zu sehen. Die Absicherung und die l]~oertragung von Daten sind Bestandteil der t~iglichen Gesch~iftspraxis. Ein besonderes Risikopotenzial entsteht durch die Anbindung von externen Mitarbeitern oder Filialen an eine Zentrale. Es gilt sensible Daten zu sch~tzen, die Kommunikation abzusichern und die Nutzung der sicherheitsrelevanten Daten auf entfernten Rechnersystemen zu kontrollieren. Selbiges gilt auch f'~ den internen Datenverkehr in Unternehmen, da innerhalb der Unternehmensstruktur for gew6hnlich unterschiedliche personen- oder abteilungsbezogene Berechtigungen vergeben werden. Sicherheitsplattformen sind in Zeiten globaler Vernetzung unumg~inglich und erm6glichen durch Ihre Eigenschaften ganz neue Geschfiftsfelder.

2.1 Einsatzszenarien Grunds~itzlich besteht der Wunsch, sicherheitsrelevante und pers6nliche Daten vor unbefugtem Zugriff zu schtitzen. Durch Trusted Computing Funktionen, wie Sealing und Binding ist es m6glich, Daten an vertrauensw~irdige Systemzust~inde, bzw. an bestimmte Rechnersysteme zu binden und den Zugriff nur unter bestimmten Umst~inden zuzulassen. Diese Funktionen sind nur im Zusammenspiel mit einer Sicherheitsplattform vertrauenswfirdig nutzbar und generieren so ein h6heres Mal3 an Sicherheit und Vertrauenswftrdigkeit f'tir Daten und Inhalte.

Mehr VertrauenswardigkeitffirAnwendungen durch eine Sicherheitsplattform

75

Kommunikation findet heutzutage fiber das Internet statt. Im Businessumfeld sind hierfar traditionelle Client-Server Beziehungen installiert, die ein potenzielles Bet~itigungsfeld flu" Angreifer darstellen, da diese Konstellation viele Angriffspunkte liefert. Eine Sicherheitsplattform wie Turaya schliel3t bereits eine Vielzahl von Angriffen aus, da die Integrit~it eines von aul3en zugreifenden Rechnersystems t~berprfifbar wird. Das Rechnersystem selbst kann nicht unerkannt ver~indert werden und ein Missbrauch durch eine ,,Man-in-the-middle"-Attacke lfisst sich ausschlief3en, da sich die Rechnersysteme far eine Kommunikation in Abh~ingigkeit ihrer Konfiguration gegenseitig authentifizieren mt~ssen, was fiber die Trusted Computing Funktion Attestation realisiert wird. In diesem Szenario kommt die sichere Authentifizierung des Benutzers hinzu, die ebenfalls in der Sicherheitsplattform abgeschirmt stattfindet. Gerade im Business-Umfeld stellen die Daten einer Firma deren Kapital da und dieses gilt es ad~iquat zu schfitzen. Das kann durch eine Sicherheitsplattform erm6glicht werden~ Firmen k6nnen mobile Gergte, wie zum Beispiel Notebooks, PDAs oder Smartphones, die mit einer Sicherheitsplattform bestfickt sind, an Ihre Mitarbeiter ausgeben. Die Konsequenz die sich daraus ergibt ist, dass Daten auf einem mobilen Ger~it mit einem viel h6heren Sicherheitsniveau verarbeitet werden. Selbst wenn private Daten oder Programme des Mitarbeiters auf das mobile Ger~it gespielt werden bleibt der hohe Sicherheitslevel erhalten. Eine Kompromittierung der Daten wird durch die Sicherheitsplattform verhindert. Aul3erdem kann der mobile Zugriff auf das Firmennetzwerk von einem mobilen Ger~it aus, in einer isolierten, sicheren Umgebung erm6glicht werden. Sicherheit wird transparent far den Anwender garantiert, so dass far den Mitarbeiter kein Mehraufwand entsteht. Der Einsatz von Vimtal Private Networks (VPNs), zur Anbindung von Filialen oder Aul3endienstmitarbeitern an das Firmennetz, hat sich gr613tenteils durchgesetzt. Es hat sich gezeigt, dass der Umgang mit diesem Werkzeug technisch sehr anspruchsvoll ist und zuweilen hgufig Fehler auftreten~ Durch eine Sicherheitsplattform kann der Einsatz optimiert und abgesichert werdeno Die Einstellungen k6nnen aus der Ferne vertrauenswttrdig gewartet und konfiguriert werden. Das spart nicht nut Kosten, sondern erh6ht auch das Mal3 an Sicherheit. Dieses Szenario bietet auch Anwendungen far den Privatnutzer. Server wichtiger Institutionen kOnnen vom Anwender auf Ihre Integrit~it und Authentizit~it fiberpNft werden. Dies bekommt eine Relevanz bei Online-Banking Aktivit~iten, sowie bei beh6rdlichen Aktionen im Umfeld von eGovernment. Ein weiteres Szenario bezieht sich insbesondere auf den Schutz der Inhalte. Viele Fehler entstehen durch die Unachtsamkeit und Unwissenheit von ungeschultem Personal~ Bereits durch kleine Fehler k6nnen Daten unverschlfisselt ~bertragen werden oder es gelangen Informationen in Bereiche, in denen sie nicht zu finden sein sollten. Die Sicherheitsplattform kontrolliert die sicherheitskritischen Anwendungen in einer Form, die es erm6glicht, Anwenderfehler konzeptionell zu verhindern. Beispielsweise kann t~ber eine vorher definierte Regel dafar gesorgt werden, dass E-Mails nur verschlfisselt oder sensible Daten nur an bestimmte Empf~inger versendet werden k6nnen. Diese Regeln beschreiben, wie ein Umgang mit den Daten zu erfolgen hat~ Die Inhalte lassen sich beispielsweise nur bei einer vertrauenswfirdigen Konfiguration eines Rechnersystems verarbeiten~ Sie k6nnen aber auch Einschr~inkungen unterliegen, die aus Sicherheitsgrfinden beispielsweise das Drucken oder die Weitergabe eines Dokumentes untersagen. Die Architektur in Kombination mit der Durchsetzung von Regeln erm6glicht den Entwurf von eigenstgndigen vertrauensw~digen Diensten, die in der Sicherheitsplattform angeboten werden k6nnen. Dadurch wird verhindert, dass Unwissenheit und Unachtsamkeit zu schwerwiegenden Problemen fiihren. Durch den modularen Aufbau und die offenen Schnittstellen k6nnen Plug-Ins (modulare Erweiterungen) und Dienste vertrauenswt~rdig und sicher in eine Sicherheitsplattform integriert werden.

76

Mehr Vertrauenswt~rdigkeitfOrAnwendungen durch eine Sicherheitsplattform

What you see is what you get Um sicherheitskritische und vertrauenswOrdige Aktionen durchfiihren zu kOnnen, ist eine sichere Anzeige von Inhalten unabdingbar, damit ein "What you see is what you get"-Prinzip realisiert werden kann. Das Signieren yon Inhalten beispielsweise muss unter der Gew~ihrleistung stattfinden, dass Inhalte nicht w~ihrend des Signatur-Vorgangs ver~indert werden k6nnen. Ein manipuliertes Betriebssystem kann dem Anwender ein Dokument anzeigen, das signiert werden soil, aber bei der DurchfOhrung im Hintergrund ein anderes Dokument signieren. Um Manipulationen dieser Art zu umgehen, werden Signaturvorg~inge aus dem System ausgelagert aufbeispielsweise Kartenleser, die ein Display besitzen, damit die Signatur eindeutig einem Datensatz zugeordnet werden kann. Doch bei ganzen Dokumenten ist dieses Vorgehen aufgrund der Platzbeschr~inkung der Displays kaum praktikabel. Der Anwender muss dem System beim Signaturvorgang vertrauen k6nnen. Es wird eine vertrauenswfirdige Middleware ben6tigt, dessen Funktionen von einer Sicherheitsplattform abgedeckt werden. Die Signamr findet in diesem Beispiel nicht im herk6mmlichen Betriebssystem statt, sondern innerhalb einer parallel ausgefohrten Applikation, die yon dem Arbeitssystem vollst~indig isoliert nur auf Basis einer Sicherheitsplattform arbeitet. Die voneinander isolierten, parallel arbeitenden Funktionsbl6cke werden Compartments genannt. Das Compartment in dem die Signamr durchgefohrt wird kann auf Authentizit~it und Integrit~it t~berprfift werden~ Diese Architektur erweitert das Einsatzfeld yon Sicherheitsplattformen erheblich. Das dargestellte Beispiel wird bereits prototypisch umgesetzt. Trusted Network Connect

Eine Schwachstelle in einem Netzwerk bilden Netzwerkkomponenten die auf Grund ihrer aktuellen Konfiguration unsicher sind. Das Schlagwort heil3t TNC (Trusted Network Connect). Mit Hilfe von TNC und einer Sicherheitsplattform k6nnen Netzwerkkomponenten die beispielsweise nur fiber einen veralteten Virenscanner verfOgen vom Netzwerk ausgeschlossen werden bis der Virenscanner aktualisiert wurde. Dieser Ausschluss wird yon intelligenten Netzwerkkomponenten (Router, Bridge, Gateway, usw.) erledigt, die mit einem vertrauenswfirdigen Dienst innerhalb der Sicherheitsplattform kommunizieren. Ein wichtiger Aspekt dieser Technologie ist die transparente Sicherheit die im Netzwerk geschaffen wird. Nachdem die Sicherheitsplattform im Hintergrund fOr die Aktualisierung des Virenscanners gesorgt hat und somit wieder ein vertrauenswiirdiger Zustand hergestellt wurde, sorgt das intelligente Netzwerk dafOr, dass die Netzwerkkomponente wieder an der Kommunikation teilnehmen kann. Mulitlevel-Sicherheitsstruktur

Eine Sicherheitsplattform kann auf einem Endanwender System eine Mulitlevel-Sicherheitsstruktur erzeugen, die eine Verarbeitung hochsensibler Daten zusammen mit privaten Daten auf einem Rechnersystem zul~isst. Ein Beispiel fOr den Einsatz einer solchen Multilevel-Sicherheitsstruktur ist im Gesundheitswesen zu finden. )krzte mfissen bislang dafor Sorge tragen, dass das Netzwerk in dem die Patientendaten zugreifbar sind keinen Zugang zum Internet erhNt, um die Patientendaten zu schfitzen. Allerdings kann es auch n6tig sein, dass der behandelnde Arzt im Internet recherchieren muss~ Bisher mussten fOr solche Szenarien zwei Netzwerke aufgebaut werden. Mit Hilfe der Multilevel-Sicherheit einer Sicherheitsplattform wie Turaya k6nnen nicht nur Kosten und Zeit gespart, sondern auch Fehler dutch Fehlbedienung ausgeschlossen werden.

2.2 Definierte Branchen und Zielgruppen Der Einsatz einer Sicherheitsplattform ist in allen Bereichen sinnvoll und teilweise sogar unerl~isslich, um ein notwendiges Mal3 an Vertrauenswfirdigkeit und Sicherheit zu erreichen. Jedes System das fiber sensible Daten verfogt, die es Wert sind geschfitzt zu werden, geh6rt zur potenziellen Zielgruppe fOr eine Sicherheitsplattform. Einige Branchen konnten bereits identifiziert und Pilotprojekte initiiert

Mehr Vertrauenswfirdigkeit far Anwendungen durch eine Sicherheitsplattform

77

werden, die zeigen, dass eine Sicherheitsplattform das Sicherheitsniveau deutlich steigert~ Durch den besonders hohen Sicherheitsanspruch bietet die Finanzbranche zweierlei Anwendungsfeldero Einerseits helfen Sicherheitsplattformen, wie Turaya bei der intemen Absicherung der Firmennetze des Finanzwesens, andererseits bei der Optimierung von Online-Transaktionen im Rahmen von eBanking. Aufgrund der F~ihigkeit, Server auf Vertrauenswfirdigkeit ~berprfifen zu k6nnen, finden Sicherheitsplattformen aul3erdem ein Anwendungsfeld in den Bereichen eHealth, eGovernment, eBusiness und eCommerce. Beispielsweise k6nnen ,,Supply-Chains" zwischen verschiedenen Firmen abgesichert werden. Hinzu kommen die Anwendungen im Bereich Inhalteschutz. Hierzu z~ihlen sowohl die Content-Anbieter, wie beispielsweise die Musikindustrie, als auch Firmen mit Enterprise-L6sungen wie SAR Umgebungen in Firmennetzwerken bieten ein weiteres Anwendungsgebiet mit Bezug auf die MultilevelF~ihigkeit einer Sicherheitsplattform.. Im eHealth-Umfeld ist eine gesteigerte Sicherheit nicht nur notwendig sondem durch den Gesetzgeber gefordert [LIDI99]. Die Patientendaten mftssen geschfitzte werden und dt~rfen nicht in die H~inde Dritter gelangen. Der Einsatz einer Sicherheitsplattform in dieser Branche spart Kosten ein und erm6glicht vereinfachte Vorg~inge im Bereich der Datent~bertragung und Datenhalmng von Patientendaten~ Die Vielf~iltigkeit der Einsatzm6glichkeiten ist hier bei weitem noch nicht ersch6pft. Es werden weitere Anwendungsfelder gesucht, um diese Technologie gewinnbringend einsetzen zu k6nnen.

3 Perspektiven der Turaya Pilotanwendungen Ffir die Technologie Turaya, die im EMSCB-Konsortium entwickelt wird, wurden fin- den Projektzeitraum 5 Pilotanwendungen definiert, die so gew~ihlt sind, dass sie die vielf~tltigen Nutzungsm6glichkeiten der Turaya Sicherheitsplattform aufzeigen. Bei der Auswahl wurde darauf geachtet, dass die Piloten das Potenzial besitzen, zu einem sp~iteren Zeitpunkt in echte Produkte und L6sungen fibergehen zu k6nnen. Dies wird durch die direkten Projektpartner SAP und Bosch/Blaupunkt, mit denen jeweils ein Pilot entwickelt wird, unterstrichen.

Turaya.Crypt Der erste Pilot ,,Turaya.Crypt" bietet eine Festplattenverschltisselung, die optional aufBasis von Trusted Computing l~iuft. Dass dies eine sinnvolle Anwendung im Sicherheitsbereich ist, wird dutch die Tatsache gestOtzt, dass Microsoft im aktuellen Vista Betriebssystem ebenfalls eine Festplattenverschltisselung auf Basis von TC mit Namen BitLocker [MICR07] anbietet. Die Microsoft-L6sung bietet nicht das Sicherheitsniveau, welches die Sicherheitsplattform Turaya durch die klein gehaltene Codebasis und die Isolation bietet. Betriebssysteme, wie Microsoft Vista bringen viele Sicherheits-Tools bereits als Bordmittel mit. Dies engt den Markt fftr alternative Produkte, wie die Festplattenverschltisselung, selbstverst~indlich ein. Aber mit der Sicherheitsplattform Turaya kann allein durch die Offenheit des Quellcodes, die es erm6glicht evenmelle Hinterttiren oder Fehler zu erkennen, eine h~here Vertrauenswfirdigkeit erreicht werden. Diese Festplattenverschl~isselung stellt exemplarisch die M6glichkeiten vor, die durch Funktionen, wie Sealing umgesetzt werden k6nnen. Daten k6nnen direkt mit einer vertrauenswgrdigen Systemkonfiguration verbunden werden, um somit nur bei einem per Definition vertrauenswfirdigen Rech_nersystem verwendet werden zu k6nnen. Diese Pilotanwendung wurde im Januar 2006 fertig gestellt. Ziel von Turaya.Crypt ist der Schutz des geheimen Schlflssels, der ben6tigt wird um eine verschlfisselte Festplatte wieder entschltisseln zu k6nnen.

78

Mehr Vertrauensw~rdigkeit for Anwendungen durch eine Sicherheitsplattform

Im Linux Compartment wird durch Benutzerinteraktion die Entschlfisselung einer verschlfisselten Festplatte angestogen. Hierzu wird ein spezielles Kernel Module geladen, das die Kommunikation fiber den Sicherheitskern zur Turaya-Festplattenverschlfisselung herstellt. Durch die Nutzung der TrustedGUI, einer vertrauenswfirdigen Oberfl/~che aufBasis der Sicherheitsplattform, erfolgt eine vertrauenswfirdige Benutzerauthentifikation. Das eingegebene Passwort ist geschfitzt, da es nur innerhalb der Sicherheitsplattform verarbeitet wird, sodass die Informationen nicht in das Linux Compartment gelangen k6nnen (vgl. Abb. 1). Nach einer erfolgreichen Authentifizierung des Benutzers wird der geheime Schlfissel freigegeben, um die verschlfisselte Festplatte entschlfisseln zu k6nnen. Durch die strenge Isolation der einzelnen Compartments bedeutet eine Kompromittierung des Linux Compartments keine Gefahr far den geheimen Schlftssel. Dies gilt nicht f-fir die Inhalte der Daten, da diese nach der Entschlfisselung im Linux Compartment verfagbar sind. Um den Schutz auf die Daten auszuweiten, w/~re es m6glich diese Pilotanwendung dahingehend zu erweitem, dass ein weiteres Compartment gestartet wird, welches ausschlieBlich die entschlftsselten Daten erh~ilt. Dort werden die Daten vertrauenswfirdig und integer angezeigt, beziehungsweise bearbeitet. Ein solches Compartment wfirde dann als TrustedViewer oder TrustedEditor bezeichnet. Als verschlfisseltes Ger/~t kommen Festplatten/Partitionen, USB-Speicher, CDR/DVD-Medien oder Dateicontainer in Frage.

I KommunikatiOns~odul~ '..,, . .

"]i

Abb. 1: Architekmrbild Turaya.Crypt Turaya.VPN Die zweite Pilotanwendung ,,Turaya.VPN" bietet die M6glichkeit, Netzwerkaktivit/~ten zu steuem, Zertifikate die hiermit verbunden sind zu schfitzen und Automatismen fftr transparente Sicherheit anzubieten. Das Client-Server Szenario wird in Ans~itzen in dieser Pilotanwendung umgesetzt. Um eine vertrauenswfirdige Kommunikation herzustellen, muss der Netzwerkverkehr kontrolliert und sicherheitsrelevante Daten, wie Zertifikate, oder Verbindungsdaten vom herk6mmlichen Betriebssystem ge-

Mehr Vertrauenswiirdigkeit fOrAnwendungen durch eine Sicherheitsplattform

79

trennt werden. Die hier verwendete Technologie bietet grol3e Vorteile far sichere Netzwerkverbindungen. Diese Pilotanwendung ist im M~irz 2006 fertig gestellt worden. Auf technischer Seite wird diese Pilotanwendung folgendermagen realisiert: Ziel von Turaya.VPN ist, wie bei Turaya.Crypt, der Schutz des geheimen Schlfissels in einer unsicheren Rechnerumgebung. Der Unterschied zu Turaya.Crypt ist aber, dass der geheime Schlfissel verwendet wird, um einen VPN-Tunnel flu" die gesicherte Kommunikation aufzubauen. Eine weitere Eigenschaft von Turaya.VPN ist die Kontrolle des gesamten Netzwerkverkehrs (vgl~ Abb. 2). Im Folgenden wird das EMSCB VPN/Firewall Compartment als Turaya.VPN bezeichnet. Turaya~ stellt die physikalische Verbindung zur Netzwerkkarte her und verwaltet sie. Jedes Compartment, das fiber einen Netzwerkzugang verfagen soll, muss sich fiber Turaya~ far diesen Dienst anmelden und autorisieren. Der gesamte Netzwerkverkehr l~iuft dabei, transparent far die Benutzer, fiber Turaya.VPN. Hier k6nnen zentral Dienste ausgefahrt werden: unter anderem eine Anonymisierung des Datentransfers, eine Firewall oder ein Virenscanner. Hauptaufgabe von Turaya.VPN ist der far den Benutzer transparente Aufbau eines VPN-Tunnels, sobald der Benutzer ein spezielles Ziel aufruft. Die Authentifizierung des Benutzers wird durch die TrustedGUI vom herk6mmlichen Betriebssystem isoliert. Durch den TrustedPath, einer abgesicherten Kommunikation zwischen Nutzer und Turaya, wird sichergestellt, dass die Eingabe der Authentifizierungsdaten nur an die dafar zust~indige Instanz gelangt.

Abb. 2: Architekturbild Turaya.VPN

Turaya.FairDRM Die ersten Pilotanwendungen zeigen, wie Daten auf einem Rechnersystem vertrauenswfirdig gespeichert werden k6nnen und wie eine Kommunikation zwischen Rechnersystemen vertrauenswfirdig geschfitzt werden kann. Die Pilotanwendungen 3-5 stellen vor allem den Schutz yon Inhalten sicher. Die dritte Pilotanwendung ,,Turaya.FairDRM" legt die Grundlage far den Umgang mit Daten, denen Regeln und Rechte zugewiesen werden k6nnen. Es werden Audiodaten mit Regeln versehen, die den Inhalt an eine Rechnerplattform b i n d e n - unter Berficksichtigung der Interessen aller beteiligten Parteien. Auch klassische Mankos von Digital Rights Manangement Systemen werden berficksichtigt. So ist der Trans-

80

Mehr Vertrauensw~rdigkeitfOrAnwendungen durch eine Sicherheitsplattform

Trusted C o m p u t i n g - eine Ein fLi hrung

fer einer Lizenz ftir ein anderes Rechnersystem m6glich. Diese Pilotanwendung wurde im Mgrz 2007 fertig gestellt.

N o r b e r t P o h l m a n n ~. H e l m u t R e i m e r ~-

Auf technischer Seite wird diese Pilotanwendung folgendermagen realisiert:

llnstitut far Internetbesteht Sicherheit, FH Gelsenkirchen Die dritte Pilotanwendung ,,Turaya.FairDRM" aus insgesamt zwei Compartments: Das Policy [email protected] Entforcer Compartment bildet die vertrauenswfirdige Instanz, die in der Lage ist, das verschlfisselte DRM Objekt zu entschlfisseln und die entsprechenden Regeln durchzusetzeno Entsprechen die Regeln 2TeleTrusT Deutschland e. V. der aktuellen Situation, so werden die entschlfisselten Daten an den TrustedViewer fibertragen, der diese Chamissostrage 11, 99096 Erfurt darstellt. [email protected] Der Ablauf des Turaya.FairDRM Piloten sieht wie folgt aus:

9 Der Informationsanbieter sendet eine Auswahl an Medien-Daten an den Anwender. In dem Piloten geschieht dies fiber eine HTML-Seite.

Zusammenfassung

9 Der Anwender w~ihlt ein Lizenzmodell und eine Medien-Datei aus. Dieser Vorgang wird als Lizenzverhandlung bezeichnet und ist in der aktuellen Version der Pilotanwendung nur rudiment~ir Angesichts der Tatsache, dass sich die Vertrauensw~rdigkeit des Internets trotz grof3erAnstrengungen der Sicherbereitgestellt. heitsexperten tendenziell nicht verbessert, verdient ein neues Konzept- wie Trusted Computing- besondere Aufmerksamkeit. Zum ersten MaI ein in der Geschichte Informationstechnologie haben die grogen 9 Der Anwender erstellt Zertifikat, dasderden 6ffentlichen Schltissel dessich TPMs und dieIT-Systemanaktuelle bieterKonfiguration im Rahmen derder Trusted Computing GroupTuraya (TCG)zertifiziert. entschlossen, gemeinsam Verantwortung f~r wirksame Sicherheitsplattform Abhilfe zu t~bernehmen. Die Implementierung der Ergebnisse der TCG ist im Gange und erste Anwendungen sind 9 Zertifikat und ausgew~ihltes Lizenzmodell werden zusammen mit der Anforderung der Mediennutzbar. Die Herausgeber dieser Publikation wollen mit den in diesem Buch zusammengestellten Beitr~igen zeigen, Datei an den Informationsanbieter gesendet. dass das Trusted Computing Konzept eine neue )i,ra ffir die Gestaltung vertrauenswfirdiger IT-LOsungen er6ffnet. In 9 Der Informationsanbieter prfift das Zertifikat. derPotential Informationsanbieter demgrtlndet. Zertifikat diesem Einfahrungsbeitrag wird erl~iutert, worauf sich dasVertraut innovative dieser Technologie Er soll dazu und anregen, die Vorteile bereits standardisierten Hardwaremodule offenen Schnittstellen stimmt er dem der ausgew~ihlten Lizenzmodell zu, wird dieund Medien-Datei ftir den auszusch6pfen Anwender sowieverschlfisselt die neuen Ansfitze in Anwendungsentwicklungen und Infrastrukturservices zu implementieren. und an ihn gesendet.

Die Sicherheitsplattform Turaya nimmt die Computing verschlfisselte Media-Datei in Empfang ~ e rbestehenden E-Mail Der9 TeleTrusT-Verein wird sich im Bereich Trusted engagieren und m6chte helfen, die oderdesDownload). Solangedersich die Konfiguration Turaya nicht ~indert, Ans~itze Zusammenwirkens Sicherheitsplattform mitder den Sicherheitsplattform notwendigen Sicherheitsinfrastrukturen und den nt~tzlichen Nutzer pragmatisch weiter zu entwickeln [TTT07]. Er sieht sich auch in der Rolle ist es Sicherheitstoken nun m6glich dieder Media-Datei fiber den Trusted Viewer darzustellen. des Vermittlers zwischen den Technologieanbietern und-anwendern, um so die Erschlief3ung des Potentials dieser innovativen Sicherheitstechnologie Nr eine vertrauensw~rdige IT-Zukunft zu f6rderno

1 Grunds [

itzliches zu IT-Sicherheitsl6sungen

~ ~ 9 Informations- und Kommunikationssicherheit sind Themen, die jede Diskussion fber nfitzliche Anwendungen des Internets begleiten. Stets ist von Chancen, Risiken und Gefahren die Rede. Angesichts der fiber eine Milliarde PCs, die 2008 weltweit im Netz sein werden, und noch weit mehr mobiler Endger~ite ist sachlich festzustellen: Die Chancen werden genutzt. Einzig und allein dadurch sind die Voraussetzungen ffr das Erkennen bestehender Risiken und Angriffspotentiale sowie die heute m6gliche Bewertung der Wirkung von Gegenmal3nahmen gegeben.

Die Nutzer des Internets auf der einen Seite verhalten sich gegenfber den bestehenden Risiken sehr differenziert. Im Allgemeinen wird das Ziel, einen deutlich erkennbaren Vorteil zu erreichen, zurzeit mit einem nutzerseitigen Vertrauensbonus, nach dem Motto: ,,Es wird schon nichts passieren", verbunden. Abb. 3: Architekmrbild Turaya.FairDRM Die Sensibilit~it ffir Sicherheitslfcken oder fitr Angriffe entsteht eher durch negative Erfahrungen als durch Wissen oder Pr~ivention. Turaya.ERM Auf der anderen Seite Piloten betonenwird die IT-Sicherheitsexperten das weit gef'~icherte SpektrumSystem der potentiellen Aufbauend auf diesem im 4. Piloten ein Enterprise-Rights-Management aufgeBedrohungen. Aus dieser Bedrohungssicht ist eine grof3e Vielfalt von hochwertigen IT-SicherheitslOsetzt, das den Umgang mit Inhalten innerhalb eines Firmenumfeldes absichern soll. Das Vorhaben, das im Zusammenwirken mit SAP erarbeitet wird, bietet somit die M6glichkeit Dokumente nur fitr N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 3-12

Mehr Vertrauenswiirdigkeit for Anwendungen durch eine Sicherheitsplattform

81

bestimmte Personen, bzw. Rechnersysteme lesbar und verwertbar zu macheno Beispielsweise k6nnte ein Dokument auf einem anderen Rechner angezeigt, aber nicht gedruckt werden, da das System nicht die erforderliche Vertrauenswfirdigkeit besitzt oder kein privilegierter Nutzer an dem System gemeldet ist. Auch hier wird das multilaterale Konzept verfolgt, das beinhaltet, dass alle Beteiligten mit den Regeln und Rechten, die einem Vorgang zugeordnet sind, konform gehen mfissen. Als zus~itzliches Element ist in diesem Meilenstein ein Policy-Manager bzw. Policy-Enforcer notwendig, der die Rechte auf der einen Seite einem Dokument hinzufiigt und auf der anderen Seite die Rechte durchsetzt. Dieser Pilot findet vor allem eine grol3e Anwendung in der Unternehmenskommunikation, sowohl intern, als auch extern. Ein Beispiel hierft~r bieten ,,Supply Chains", wie sie beispielsweise in der Automobil- und Luftfahrtindustrie ~blich sind. Produktionsfirmen und Ihre Zulieferer arbeiten mit eng verzahnten Systemen beispielsweise im Bereich ERM (Enterprise Resource Management) und CRM (Customer Relationship Management). Die beteiligten Firmen haben jeweils Zugriff auf die Systeme des Partners. Die Zugriffe finden teilweise automatisiert und zwischen einer Vielzahl von Systemen statt~ Die Absicherung eines solchen Konstrukts ist nur durch die Integrit~itsprfifung der Ger~ite m6glich. Firmen tauschen Entwfirfe neuer Produkte aus, die im Falle eines Verlusts zu ScMden in Millionenh6he ffihren k6nnen. Die Sicherheitskonzepte in diesem Umfeld sind nicht in ausreichendem Mage vertrauenswfirdig. Mit einer Sicherheitsplattform kann die falsche Verwendung von Inhalten jedoch minimiert werden. Die Technologie erm6glicht eine sichere Kommunikation, eine sichere Anzeige und durch die Integritgtsprfifung aller beteiligten Systeme einen vertrauenswttrdigen Zustand. Zusammengefasst arbeitet die Turaya Sicherheitsplattform als vertrauenswttrdige Middleware. Zus~itzliche vertrauenswfirdige, teure Peripherie, wie beispielsweise Kartenleser der Klasse 2-3, sind durch einen Trusted Viewer und die vertrauensw~rdige Plattform nicht mehr zwingend notwendig. Ein Beispiel ist das Online-Banking per HBCI 1. Ft~r diese Technik wird grunds~itzlich ein solcher Kartenleser ben6tigt [FinT07], der durch die Turaya Technologie eingespart werden kann.

Turaya.Embedded Der ffmfte Pilot demonstriert die Plattformunabh~ingigkeit der Turaya Sicherheitsplattform, indem ein dem vierten Piloten ~ihnliches System auf ein eingebettetes System im Automobilbereich fibertragen wird. Zusammen mit Bosch~laupunkt wird eine multimediale Anwendung auf einem ARM-Prozessor ffir das Auto realisiert. In diesem Bereich wird ein besonders groges Potenzial der Technologie gesehen, da bereits heute in einigen Autos fiber 80 Prozessoren verbaut sind [Wol107], die teilweise schfttzenswerte Aufgaben t~bernehmen. In der Zukunft sollen Updates der Autoelektronik durchgeffihrt werden, indem lediglich mit dem Auto an der Werkstatt vorbeigefahren wird~ Sichere und vertrauenswfirdige Systeme fiir derartige Anwendungen sind absolut notwendig, damit das Auto einen Bremsbefehl auch nach einem Update zuverl~issig durchfthhrt. Angriffe auf solche Systeme k6nnten k6rperlich Verletzungen nach sich zieheno Der Meilenstein beschr~inkt sich nicht auf den Bereich Automotive. Er ist stellvertretend ffir jegliche eingebetteten Systeme zu sehen. Diese sind nicht nur in mobilen Ger~iten, wie Handys und PDAs zu finden, sondern vor allem in zukt~nftigen Technologien, wie der Haustechnik (Kt~hlschrank, Heizung, ...) oder maschinellen Produktionsstgtten~ Der vierte und fanfte Pilot werden Ende 2007 fertig gestellt.

1 HomeBanking ComputerInterface, ein nationaler Standarddes ZentralenKreditausschusses

82

Mehr Vertrauensw(irdigkeitfar Anwendungen durch eine Sicherheitsplattform

4 Das Anwendungsbeispiel Online-Banking Online Banking ist ein Einsatzgebiet der Turaya Sicherheitsplattform, anhand dessen die Technologie beschrieben werden soll. Im Beispiel kommen besonders Teile des zweiten Meilensteins zum Einsatz, wie sie in der Praxis genutzt werden k6nnten. Sicherheitskritische Prozesse werden durch Virtualisierung und Isolation von unsicheren Prozessen getrennt. Online Banking beispielsweise l~isst sich mit der Sicherheitsplattform Turaya sehr sicher betreiben. Um eine entsprechende Vertrauenswfirdigkeit zu erreichen, wird die Online Banking Applikation in einem eigenen Compartment ausgefiihrt. An dieser Stelle sind zwei unterschiedliche Szenarien denkbar. Zum Einen wgre es m6glich, ein Compartment mit einem Betriebssystem und einem Browser auszustatten - dazu sind keine Anpassungen an der Software notwendig, zum Anderen wfirde eine Banking-Software so modifiziert werden, dass sie direkt auf den Schnittstellen der Sicherheitsplattform aufsetzt. Im Folgenden wird das Beispiel der modifizierten Banking-Software weiterverfolgt. Sobald der Anwender seine Banking-Applikation startet, ,,springt" er in das entsprechende OnlineBanking-Compartment. Ftir den Anwender ist dieser Vorgang transparent. Er startet die Applikation, beispielsweise durch einen Klick auf das Icon seiner Anwendung im herk6mmlichen Betriebssystem. Dadurch wird ein Aufruf an die Turaya-Plattform gesandt. Diese startet die Banking Software in einem neuen Compartment (vglo Abb. 3). Daraufhin 6ffnet sich die Anwendung in einem Fenster. Dieses Fenster ist bereits das sichere Compartment. Der Bank-Server wird angew~ihlt und fiber die Attestierungsfunktion kann vertrauenswfirdig nachgewiesen werden, dass der Anwender wirklich mit dem Server seiner Bank verbunden ist und sich dieser Bankserver in einem vertrauenswt~rdigen Zustand befindet. Der Anwender gibt seine transaktionsrelevanten Daten ausschlieglich innerhalb des sicheren Compartments ein. Das herk6mmliche Betriebssystem hat in diesem Fall keinen Zugriff. Dadurch ist evtl. vorhandene Malware nicht in der Lage, die Eingaben des Anwenders zu missbrauchen, denn das Compartment wurde in einem unver~tnderten Zustand gemessen. Wenn ein Angriff auf dieses Rechnersystem erfolgt w~ire, der das Compartment beeinflusst Mtte, w~ire es aufgrund des beschriebenen sicheren Ladevorgangs, der durch TC angeboten wird, nicht gestartet worden, da die Messwerte nicht mehr fibereinstimmen warden und damit eine Vertrauenswt~rdigkeit nicht mehr gew~ihrleistet w~ire. Im Bereich Online Banking l~isst sich ein weiterer Vorteil der Sicherheitsplattform Turaya lokalisieren. Das Online Banking-Verfahren HBCI verlangt, wie bereits erwghnt, teure Kartenleser f-fir ein h6heres Sicherheitsniveau. Turaya hingegen stellt eine vertrauensw~dige Middleware und somit einen Trusted Path 2 zwischen Kartenleser und Banking-Applikation. Dadurch ist der Einsatz eines simplen kostengfinstigen Kartenlesers zusammen mit Turaya v611ig ausreichend fiir ein hohes Sicherheitsniveau. Dieses Szenario zeigt, wie die Technologien Trusted Computing und SmartCards, die den Sicherheitschips (TPM) sehr ~ihneln, zusammenspielen. Der TPM ist fest mit einem Rechnersystem verbunden, w~ihrend die SmartCard ffir mobile Anwendungen eingesetzt wird. Des Weiteren besteht die Aufgabe der SmartCard darin, einen Nutzer zu authentifizieren, w~ihrend die Hauptaufgabe des TPMs in der Authentifizierung des Rechnersystems liegt.

2 Als TrustedPath wird ein Mechanismusbeschrieben,der die direkteKommunikationzwischeneinerTrustedComputingBase, wie Turaya,und einemTerminaloderNutzerbeschreibt.Der Kommunikationswegist nicht manipulierbar.Er basiertdarauf,dass sich alle daran beteiligtenInstanzenals vertrauenswtirdigausweisenkonnten.

Mehr VertrauenswfirdigkeitfttrAnwendungendurch eine Sicherheitsplattform

83

...................................

,

i.... i

i

.....

Abb. 4" Architektur Online Banking mit Turaya Am Beispiel Online Banking zeigen sich auch Vorteile im Bereich der Benutzerfreundlichkeit. Die Eingabe der Bankdaten k6nnte einmalig stattfinden w~ihrend die Daten durch die Sicherheitsplattform in einem so genannten Wallet (vgl. Abb. 4) verwaltet werden. Beim Online Banking wird die Eingabe der Authentifiziemngsdaten automatisiert und damit transparent far den Nutzer stattfinden. Turaya t~berprffft augerdem die VertrauenswOrdigkeit des Servers und gibt dem Anwender eine visuelle ROckmeldung, sowohl im positiven, aber auch im negativen Sinne- je nachdem, ob alle Regeln far einen vertrauenswOrdigen Vorgang eingehalten wurden.

Unsicheres Betriebsystem k ~ ;

~:~::~ '~

~;;~;== ~

~:i

i

Sicherer Browser

T

secure

Bank-Server Abb. 5" Transparente Sicherheit beim Online-Banking

4 84

Trusted Computingeine Einfahrung Mehr VertrauenswfirdigkeitffirAnwendungen durch eine Sicherheitsplattform

sungen Komplexit~itdes oftAnwenders fiber das Fassungsverm6gen desdieses durchschnittlichen Nutzers Ein TPMentstanden, ist auf demderen Rechnersystem (Client-Rechner) far Anwendungsbeispiel hinausgeht und erforderlicho die deshalb eher in geschlossenen Nutzergruppen (wie und in Untemehmen oder besonders nicht zwingend Es erh6ht die Sicherheit aber betr~ichtlich vereinzelte Funktionen, wie sensiblen Anwendungsbereichen, z.B. imnicht Gesundheitswesen) mitunter entsprechenden Infrastrukmrinvestidas Messen der Compartments k6nnten vertrauenswfirdig Zuhilfenahme von Hardwaresitionen Anwendung finden. cherheit durchgefahrt werdeno Der Aspekt der Migration spielt in einem solchen Umfeld eine wichtige Rolle~ Es ist also m6glich, herk6mmliche Rechner far diese Art des Online Bankings zu nutzen, woEs ist die im Interesse kontinuierlichen Verbesserung der Sicherheitslage im gesamten Intemetbietet drindurch Sicherheiteiner nur geringfagig gegentiber herk6mmlichen Systemen erh6ht wird. Trotzdem gend Wege zu finden, mit denen die bestehende Diskrepanz dem blinden Vertraues sicherforderlich, an, diese geringfagige Erh6hung der Sicherheit vor dem Einsatz zwischen neuer Hardware zu nutzen, da en vieler undUmstieg den realen abgebautm6glich werdenist. kann. spgter einNutzer einfacher aufSchgden neue Hardware Die Entwicklung des Intemets und die Verbreitung von kompatiblen und interoperablen Endgergten ist durch entsprechende Industriestandards entscheidend mitbestimmt worden. Nur deren pragmatische 5Implementierung Notwendige Infrastrukturen zum Einsatz in Hard- und Software fahrte zu der heute erreichten weltweiten einer Interoperabilit~it von Intemetdiensten und-anwendungen. Gleichzeitig ist auf diesem Wege auch die Grundlage far den riesigen Markt mit relativ kostengt~nstigen Angeboten far die technische Basis entstanden. Die Trusted Computing Group, die sich far die momentan wichtigsten Spezifikationen im Bereich Trusfi~hnliches gilt verantwortlich auch far wichtige Internet und -protokolle, wie SSLohne (TLS), S/ ted Computing zeichnet, willSicherheitsstandards mehr Vertrauenswfirdigkeit in der IT etablieren grol3e MIME, IPSec usw., dieRechnersystemen praktisch in alle vornehmen verfagbarenzuBetriebssysteme unddass viele impleVergnderungen an den mfissen. Fakt ist, einAnwendunge Rechnersystem mit mentiert sind. Auch Kryptoverfahren stehen Parametem allgemein zur VerfaSicherheitschip die Grundvoraussetzung ist, mit um quasistandardisierten die TC Funktionen wie Sealing oder Attestation sinngung. Obwohl diese Werkzeuge fiber ein hohes Potential im Hinblick auf die Verbesserung der Informavoll nutzen zu k6nnen. W~ihrend die Erneuerung der Hardware automatisch stattfinden wird, da die Sitionsund Kommunikationssicherheit verfagen, verbaut ist ihre Anwendungsbreite hinter den Erwartungen cherheitschips aktuell fast auf allen Mainboards werden, sind andereweit Infrastrukturen notwendig, zurfickgeblieben. Drei wesentliche Grfinde k/Snnender oben genannten Risikobereitschaft- fitr um die Trusted Computing Funktionalit~iten einsetzenneben zu k6nnen. die Anwendungszm'fickhalmng genannt werden: Die Oberpr~ifung des sicheren Bootvorgangs beispielsweise mit einem m6glich. Hierfar 9 Das Handling von Anwendungen mitistSicherheitsfunktionen wirdToken komplizierter, oft sinktmt~sdie sen standardisierte Schnittstellen far die Tokenhersteller geschaffen werden, um optimale InteroperabiPerformance. Eine unmittelbare Wirkung von Sicherheitsmagnahmen ist far den Nutzer hfiufig lit~it zu nicht erzeugen. Gleiches gilt far die Schnittstelle zum Virmalisierungslayer, der frei austauschbar sein erkennbar. soil, und tar die Schnittstellen zu den aufTuraya laufenden Applikationen. 9 Ffir den Anwender ist es - in Anbetracht der Komplexitgt der fiblichen Intemetanwendungen und derwichtigste far ihn ungberschaubaren Angriffszielem6glich zu beurteilen, welches Gewicht Die vielleicht Funktion ist die Attestierung und nicht die damit verbundene M6glichkeit Inhalte mit von ihm implementierte Sicherheitsmal3nahme auf durchzusetzen. die Sicherheitsqualit~it derAuthentifizieAnwendung Policieseine zu versehen und diese auf fremden Rechnersystemen Wenn die besitzt. rung eines Client-Rechners gegent~ber einem Server stattfindet, ben0tigt der Server eine dritte Instanz, die ihm die (ibermittelten Attestierungsdaten Clients verifiziert. Ft~r diesen Punkt gibtsieht es bereits eine 9 Kryptographieanwendungen erforderndes Infrastrukmren und-dienste. Der Nutzer sich hierL6sung,bei dievor ohne eine dritte Instanz auskommt. PKI-Infrastrukturen in Untemehmen neue Herausforderungen gestellt: Vorhandene Neben der Qualit~it der Services und den mit ihrerbieten Inansich trotzdem dafar an, diese Funktion abzudecken~ Das gilt na~rlich auch far Trustcenter, die diese spruchnahme verbundenen Kosten, ist h~iufig ungekl~irt, wie die Vertrauenskette zum DiensteanFunktionen bieterunternehmenst~bergreifend gerechtfertigt werden kann.einnehmen k6nnten.

Sicherheitsplattform

Aus Sicht der Sicherheitsexperten gibt es darfiber hinaus zwei entscheidende und permanente Risikofaktoren: 6 Fazit

9 Die Einbettung der Sicherheitsfunktionalit~ten als Software in eine offene System- und NetzDas Ziel, mehr Vertrauenswfirdigkeit in der IT zu erreichen, kann mit einer Sicherheitsplattform, wie umgebung und Turaya in Kombination mit Trusted Computing erreicht werden. Erste Anwendungsfelder sind klar aus9 das Nutzerverhalteno zumachen und die Entwickhmg zu vernetzten Systemen, in denen sicherheitskritische Daten fibertragen werden, fordert eine h6here Sicherheit und Vertrauenswfirdigkeit. Beispiele for diese Entwicklungen Allgemeine Bedrohungsanalysen far IT-Systeme und -Anwendungen haben bereits Anfang der 1990er sind Web-Services oder auch GRID-Computing. Jahre zu der Erkenntnis gefahrt, dass in Software implementierte kryptographische IT-Sicherheitsl6sungen durch Hardwaremodule wirkungsvoll erg~inzt und gegen Angriffe besser geschtitzt werden k6nneno Daten k6nnen durch die Sicherheitsplattform Turaya w~ihrend der Kommunikation mit anderen RechFt~r geschlossene Benutzergruppen sind dies komplexe Hardware Security Module (HSM); ein klassinersystemen, aber auch w~ihrend der Verarbeitung auf dem eigenen Rechnersystem, vertrauensw0rdig sches Beispiel ist der im Bankenbereich verbreitete Kryptoprozessor IBM 4758. gesch~tzt werden. Welche weiteren Anwendungsfelder von der Sicherheitsplattform Turaya profitieren k6nnen noch nicht wurde vollstgndig abzusehen. IT-Systeme, die Vertrauenswfirdigkeit vorausFt~r den ist Einzelnutzer das Konzept der S~imtliche Kryptoprozessor SmartCard entwickelt. Inzwischen ist setzen, k6nnten durch die Sicherheitsplattform Turaya im Level der Vertrauensw~rdigkeit erh6ht werdieser Ansatz - durch ein umfangreiches ISO-Normenwerk begleitet- Grundlage far SmartCard basierden. Beispiele k6nnten Kiosksysteme oder Wahlrechner sein, auch andere Anwendungen, te Token als einhierfar entscheidendes Sicherheitsinstrument in der Hand desaber Nutzers. Allerdings steigen die die in Zukunft vor allem digital ausgefahrt werden.

Mehr Vertrauensw~irdigkeitffirAnwendungen durch eine Sicherheitsplattform

85

Doch far den Einsatz dieser Sicherheitsplattform ist es notwendig, eine kritische Masse an Anwendern far die Nutzung zu motivieren, um Standards und Infrastrukmren zu schaffen, die einen flexiblen, interoperablen Einsatz erm6glichen. Die Vorteile der Sicherheitsplattform Turaya liegen in der freien Verfagbarkeit der Plattform, der vertrauensw~irdigen, fairen und offenen Nutzung der Trusted Computing Technologie und der fahrenden Stellung innerhalb der Forschungslandschaft. Die Turaya Sicherheitsplattform macht es zudem m6glich, dass a11e sicherheitskritischen Komponenten und Anwendungen unabh~ingig von ,,klassischen" Betriebssystemen agieren k6nnen und damit far zukfinftige plattformfibergreifende verteilte Anwendungen optimal geeignet sind. Das EMSCB-Konsortium wfinscht sich, dass m6glichst viele Anwendungen auf die Sicherheitsplattform Turaya aufbauen, urn eine sichere und vertrauenswfirdige Zukunft von Rechnersystemen zu erm6glicheno

Literatur [McAf06] [LfDI99] [MICR07] [FinT07] [Wol107]

McAfee, MCAFEE VIRTUAL CRIMINOLOGY REPORT, www.mcafee.com, 2006 Landesbeauftragtefar Datenschutz und Informationsfreiheit NRW, Datenschutzrecht NRW, 1999 Microsoft, BitLocker, http://technet.microsoft.com/en-us/windowsvista/aa906018.aspx FinancialTransaction Services, http://wwwohbci-zka.de/, 2007 Wollinger,Thomas: Sicherer Software Download durch Trusted Computing im Automobil, Pr~isentation 2007

Die Sicherheitsplattform Turaya Ammar Alkassar 9 Christian S~ble Sirrix AG security technologies Im Stadtwald, Geb D3~ Saarbrficken {alkassar J smeble} @sirrixocom

Zusammenfassung Die Sicherheitsplattform Turaya 16st mit Hilfe von Trusted Computing Technologien essentielle Sicherheitsprobleme konventioneller IT-Systeme wie sie durch Viren, Trojaner und andere Schadsoftware verursacht werdeno Darfiber hinaus erm6glicht die Sicherheitsplattform die Durchsetzung von Sicherheitsregeln bei der Ausfahrung eigener Inhalte und Dokumente auf fremden Systemen und schafft damit die Grundlage far zahlreiche neue Gesch~iftsmodelle. In diesem Beitrag werden die Notwendigkeit far eine solche Sicherheitsplattform motiviert, die technische Architekmr skizziert und die gmndlegenden Eigenschaften der Turaya-Architektur dargelegt.

1 EinfLihrung Vernetzte Rechnerplattformen waren bisher nicht in der Lage die Anforderungen mehrseitiger Sicherheit (Multilateral Security) und damit die Interessen aller beteiligten Parteien eines IT-Systems zu erfallen. Insbesondere die divergierenden Interessen von Unternehmen, Endbenutzem und Inhalteanbietern (,,Content-Provider") fahren oftmals zu unbefriedigenden L6sungen, die zahlreiche innovative Gesch~iftsmodelle ausschliegen. Darfiber hinaus konnte die Sicherheit der bestehenden Rechnerplattformen in den vergangenen Jahren nicht substanzielI verbessert werden, wie die zahlreichen, immer wieder auftretenden Sicherheitslficken und deren breite Ausnutzung durch Viren, Trojanem und weiteren Schadprogrammen deutlich vor Augen fahrt. Die Ursachen hierfar sind die inhfirenten Schw~ichen bisheriger Systemarchitekturen mit monolithischer Struktur und hoher Komplexit~it. Diese Problematik umfasst alle etablierten Betriebssysteme von Windows fiber MacOS und Linux, bis hin zu mobilen Betriebssystemen wie Symbian~ Diese Erkenntnis ist nicht n e u - bisherige L6sungsans~itze scheiterten aber meist an der mangelnden Kompatibilit~it mit der auf dem Markt befindlichen Anwendungssoftware und w e r d e n - wie das Betriebssystem Trusted Solaris von S U N - heute nur in Nischenbereichen, beispielsweise bei milit~irischen Anwendungen, eingesetzt. Technisch gesehen fehlen den heutigen IT-Systemen elementare Sicherheitseigenschaften wie die F~ihigkeit zur Integrit~itsprfifung (,,Secure Booting") und dessen Beleg gegenfiber anderen Systemen (,,Remote Attestation") sowie wichtige Sicherheitsfunktionen, wie die verl~issliche Erzeugung von Zufallszahlen far kryptographische Schlfissel. Insbesondere die erstgenannten Sicherheitseigenschaften sind essentiell far den Aufbau vertrauenswfirdiger IT-Systeme, sowie ffir die Realisierung zahlreicher Gesch~iftsmodelle von fairem IP-Schutz und Enterprise Rights Management (ERM), fiber Freischaltsysteme und Bezahlfemsehen, bis hin zu effizienten Zugangskontrollen far Netzwerkger~tte zur Absicherung der firmenintemen IT-Infrastrukmr.

N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 86-96

Die Sicherheitsplattform Turaya

87

Die vonder Trusted Computing Group (TCG) spezifizierten Trusted Computing (TC) Hardwarekomponenten stellen grundlegende Sicherheitsfunktionen bereit, die zur Realisierung der genannten Sicherheitseigenschaften genutzt werden k6nnen. Allerdings werden durch diese Komponenten alleine weder die aktuellen Sicherheitsprobleme gel6st, noch neue Sicherheitseigenschaften bereitgestellt. Da das Betriebssystem diejenige Komponente eines IT-Systems ist, die den gesamten Informationsfluss oberhalb der Hardware kontrolliert und somit Zugriff auf alle System- und Anwendungsdaten hat, ist ffir die Realisierung neuer Sicherheitsfunktionen eine sichere und vertrauenswttrdige Basissoftware in Form eines sicheren Betriebssystems, eines Sicherheitskerns, oder eines sicheren Hypervisors, unumg/~nglich [SaSt03]. Zu einem sicheren und vertrauenswfirdigen IT-System geh6rt daher neben entsprechenden TC-Hardwarekomponenten eine Sicherheitsplattform, die Sicherheitseigenschaften zur Verft~gung stellt und den Anwendungen die TC-Funktionalit/~ten anbieteto Turaya ist eine der ersten offenen Sicherheitsplattformen, die mit ihrer TC-Unterstfitzung die Grundlage ffir die Bereitstellung mehrseitiger Sicherheit und neuer Sicherheitseigenschaften auf Basis von TCKomponenten wie dem Trusted Plattform Module (TPM) oder Intels TXT Technologie bietet.

2 Hintergrund und Probleme heutiger IT-Systeme In den letzten Jahrzehnten wurden zahlreiche technische, personelle und organisatorische Schutzmal3nahmen gegen die allseits bekannten Sicherheitsprobleme existierender IT-Systeme vorgeschlagen und entwickelt. Inzwischen besch/~ftigen sich viele Forschungs- und Industrieeinrichtungen mit den technischen, politischen und gesellschaftlichen Aspekten der IT-Sicherheit und Kryptographie und es existiert bereits eine Vielfalt von Sicherheitsl6sungen und Produkten auf den internationalen M/irkten. Zu den technischen Schutzmagnahmen geh6ren der Einsatz von Firewalls und Intrusion Detection Systemen, kryptographischen Primitiven (z.B. Verschl%selung, digitale Signamren) und Protokollen (z.B. Schlftsselaustausch, Authentifikation), sowie die Berficksichtigung von Benutzbarkeitsaspekten. Diese EinzellOsungen k6nnen jedoch nur bedingt gegen existierende und zuk~nftige Bedrohungen Abhilfe leisten, da sie nur Teilprobleme 16sen und insbesondere nur die bekannt gewordenen Sicherheitslficken zu schliegen versuchen. Beispielsweise k6nnen Firewalls durch Insider oder Tunneling von augen umgangen werden. Anti-Viren Software bietet nur Schutz vor bekannten Viren bzw. Virensignaturen. Letztlich k6nnen Intrusion Detection Systeme leicht dazu gebracht werden, falsche Diagnosen und Alarmmeldungen zu erzeugen. Weiterhin sind diese Einzell6sungen nahezu immer auf bzw. mittels Betriebssystemen realisiert, die, wie bereits diskutiert, keine Ausreichende Sicherheit bieten. Somit werden Angreifern M6glichkeiten er6ffnet, die o.g. L6sungen zu umgehen oder auszuhebeln. Mit anderen Worten: Sicherheitsl6sungen sind niemals sicherer als das zugrunde liegende Betriebssystem. Einige interessante und fttr die Praxis wichtige Problemstellungen im Zusammenhang mit existierenden Rechnerplattformen sind: 9 Existierende IT-Plattformen, speziell deren Betriebssysteme, bieten keinen ausreichenden Schutz gegen Viren, W~rmer, Trojaner und Konfigurationsfehlero ~ Es existiert bisher kein effizienter Mechanismus zur 12Iberpr~ifung der Integrit~it einer IT-Plattform, d.h. es ist bisher nicht m6glich zu verifizieren, ob eine Plattform eine gewt~nschte Eigenschaft besitzt. L6sungen wie VPN (Virtual Private Networks) zur Authentifikation mobiler Mitarbeiter bieten nur eingeschr/~nkte Sicherheit, da derartige Ans/itze auf der starken Annahme

88

Die Sicherheitsplattform Turaya beruhen, dass die zugrunde liegende Plattform eines Mitarbeiters keine Sicherheitslt~cken aufweist~ Die praktischen Erfahrungen zeigen jedoch, dass diese Annahme unrealistisch ist. 9 Die notwendige Sicherheitsgrundlage fftr eine vertrauliche, integere und authentische Kommunikation zwischen einem Benutzer und den auf der Rechnerplattform laufenden Anwendungen (Trusted Path) ist nicht gegeben. Insbesondere betrifft dieser Aspekt rechtsverbindliche Transaktionen, da eine eindeutige Darstellung von Dokumenten, sowie eine eindeutige Authentifizierung der Anwendungen, und damit ein sicherer Einsatz digitaler Signamren, mit heutigen IT-Plattformen nicht m6glich sin& Ist die zugrunde liegende Plattform kompromittiert (z.B. von einem Intemet-Wurm befallen), so kann ein zu signierendes Dokument von dem Trojaner ge~indert bzw. ersetzt werden, nachdem der Benutzer die Richtigkeit fiberprfift hat, aber bevor er das Dokument digital unterschreibt. Dieses Problem ist als Darstellungsproblem bekannt. Um derartige Angriffe zu verhindem, muss die Plattform Funktionen zur Verfiigung stellen, welche die Realisierung einer vertrauenswt~digen Darstellungseinheit (Trusted Viewer) erm6glichen. W~ihrend die oben beschriebene Angriffsart die Kommunikation zwischen Signamranwendungskomponente und Signaturerstellungseinheit manipuliert, setzt eine andere Angriffsmethode an der Kommunikation zwischen Benutzer und Signamrerstellungseinheit an: Hierbei wird das zur Benutzerauthentifikation gegenfiber der Signaturerstellungseinheit eingegebene Passwort von einer b6sartigen Komponente, z.B. einem Trojaner, mitgelesen und kann damit zur FNschung der Signaturen missbraucht werden. Um diese Angriffsmethoden zu verhindem, ist eine vertrauenswttrdige Benutzerschnittstelle, im Folgenden Trusted Graphical User Interface (TrustedGU1) genannt, erforderlich. 9 Sicherheitskritische Dokumente k6nnen nur eingeschr~nkt gehandhabt werden, da diese nicht an eine Plattform gebunden werden k6nnen und somit auf andere IT-Systeme fibertragbar sind. Beispielsweise ist es in vielen industriellen sowie staatlichen Betrieben gewfmscht, dass der Zugriff auf bestimmte Dokumente nach bestimmten Sicherheitsregeln gesteuert wird oder bestimmte Dokumente (z.B. Konstruktionspl~ine) einen bestimmten Rechner bzw. eine Abteilung nicht verlassen dfirfen. 9 Anwendungsanbieter haben nur eine beschr~inkte M6glichkeit zur Durchsetzung ihrer Sicherheitsregeln, da die entsprechenden Schutzmechanismen im Wesentlichen durch die Ausnutzung der Sicherheitsschw~ichen der zugrunde liegenden Plattform umgangen werden k6nnen. Beispielsweise sind heutige Rechnerplattformen nur in sehr begrenzter Form in der Lage, kopierergeschfitzte Daten (z.B. Bilder, Video, Audio) vor Verletzung der Urheberrechte zu schtitzeno

Weiterhin bieten die heutigen IT-Plattformen den Inhalte- und Anwendungsanbietem keine sichere M6glichkeit zur Durchsetzung extemer Sicherheitsregeln, da das Betriebssystem, und somit die Anwendungen selbst, vollstgndig unter Kontrolle ihrer Benutzer stehen. Ein wichtiger Anwendungsbereich in diesem Kontext ist unter dem Schlagwort Digital Rights Management (DRM) bekannt. Unter DRM verstehen wir Verarbeitungsmethoden von Rechteinformationen zur elektronischen Verwalmng von Rechten auf digitale Gfiter. Hgufig werden auch die Mal3nahmen zur Durchsetzung dieser Rechte (Digital Rights Enforcement) mit dem Begriff DRM bezeichnet. Aus unserer Sicht besteht das Ziel von DRM-Systemen jedoch darin, geeignete Umgebungen und Rahmenbedingungen fttr die Industrie zur Nutzung digitaler Werke zu schaffen, so dass die Interessen und Sicherheitsanforderungen aller beteiligter Parteien in sinnvoller Weise berficksichtigt werden. Somit sollen DRM-Methoden i.A. far einen Vertragsabschluss und dessen Einhaltung von den Beteiligten sorgen. ~ Diesem Bereich und den damit verbundenen Gesch~fftmodellen spricht man in der Zukunft, insbesondere ffir den deutschen IT-Markt, eine enorme Bedeutung zu. Eine der prominenten Anwendungen ffir DRM ist der Urheberschutz digi1 Beispielsweisesoll einerseitsder Endbenutzerdie von ihm in Anspruch genommenDiensteoder Inhalte nicht unerlaubtunautorisierten Parteienanbieten.Andererseitssoll der Vorgangzur Nutzung der entsprechendenDienstebzw. Inhalte den Anbietern nicht erm6glichen,auf die vom Endbenutzerals privat eingesmftenDaten zugreifenzu k6nnen.

Die Sicherheitsplattform Turaya

89

taler Inhalte. Die L6sungen der Vergangenheit waren jedoch nicht erfolgreich, da, wie bereits erw~ihnt, die entsprechenden Mechanismen zur Durchsetzung von externen Sicherheitsregeln auf heutigen Systemen durch den Endbenutzer umgangen werden k6nnen. Des Weiteren konzentrieren sich existierende DRM-Systeme und Produkte haupts~ichlich auf die Durchsetzung von Anforderungen der Dienste- und Inhalteanbieter und nicht auf die der Endnutzer, wie beispielsweise eine Garantie, dass die Nutzung der entsprechenden Anwendungen die Datenschutzaspekte des Endnutzers nicht verletzen.2

Trusted Computing Technologie, wie beispielsweise das von der Trusted Computing Group (TCG) vorgestellte Trusted Platform Module (TPM) und die darauf aufbauende Next-Generation Secure Computing Base (NGSCB) Architektur von Microsoft bieten hierzu geeignete Funktionen, die dem Betriebssystem erlauben, durch manipulationssichere Hardware dem Endbenutzer die Kontrolle fiber seine Rechnerplattform teilweise zu entzieheno Basierend auf diesem Hardwaremechanismus k6nnen weitere Softwaremechanismen zur Durchsetzung externer Sicherheitsregeln wirksam vor Angriffen gesch~tzt werden. Kritiker des Trusted Computing geben allerdings zu bedenken, dass gerade die eingeschr~inkte Kontrolle durch den Endbenutzer prinzipiell auch dazu genutzt werden kann Zensur auszut'lben, die PrivatspMre der Endbenutzer zu verletzten oder ihre Rechte einzuschr~inken. Dieser inh~irente Konflikt zwischen den Interessen/Sicherheitsanforderungen der Endnutzer und denen der Anwendungsanbieter kann nur durch ein mehrseitig vertrauenswt~rdiges Betriebssystem gel6st werden, welches im Sinne von multilateraler Sicherheit eine Ausgewogenheit zwischen den Interessen aller beteiligten Parteien garantiert. Technisch k6nnen diese Forderungen basierend auf TC-Technologien und einer Sicherheitsplattform erf'tillt werden, indem existierende Betriebssysteme um eine Kontrollschicht (Sicherheitsplattform) erweitert werden, der sowohl Endbenutzer, als auch die Industrie (Anwendungs-, Inhalte- und Diensteanbieter) vertrauen. Diese Kontrollschicht beschr~inkt den Zugriff aufTC-Hardware seitens der Softwareanbieter auf ein sinnvolles Mar3, verhindert aber gleichzeitig eine Umgehung von Sicherheitsvorgaben durch die Benutzer. Eine m6gliche L6sung dieses Konflikts ist die Verwendung eines sicheren und vertrauenswfirdigen Sicherheitskerns, erl~iutert in der folgenden Turaya Sicherheitsarchitektur.

3 Die Turaya-Architektur Ziel der Turaya-Architektur ist die Bereitstellung einer offenen, mehrseitig sicheren Rechnerplatform, basierend auf der Trusted Computing Technologie. Insbesondere umfasst dieser Ansatz die Fghigkeit die Sicherheitsanforderungen der verschiedenen beteiligten Parteien eines IT-Systems unter Ausschluss von Konflikten durchzusetzen. Die Turaya Sicherheitsplattform basiert auf dem PERSEUS3 Security Framework, dessen Entwicklung 1999 an der Universit~it des Saarlandes begann und das sich mittlerweile zur Referenzarchitekmr ffir viele offene Sicherheitsplattformen entwickelt hat. Das wichtigste Designziel der Turaya-Architektur ist die Realisierung eines stabilen, minimalisierten und dadurch einfach verwaltbaren Sicherheitskerns Nr herk6mmliche Hardwaresysteme wie Desktoprechner, Server, Embedded Systeme und mobilen Ger~iten wie PDAs und Smartphones. Die daraus resultierende Architektur ist in der Abbildung 1 dargestellt. 2 Es gibt auch gewisseDienste,bei denenKundenanforderungen(wie Gewghrleistungder Anonymit~it)wichtigeGescMftsbedingungen darstellen, da sonst die Kundennicht bereit sind, diese in Anspruchzu nehmen. 3 http://www.perseus-os.org

90

Die Sicherheitsplattform Turaya

~SE

Property.based Attestation Property-based Sealing Mutually Trusted Storage Policy Translation Secure Booting I

9

~ Device Drivem } ~ Process Isolation

~.~

Abb. 1: Turaya-Architektur Die Turaya Sicherheitsarchitektur basiert auf den folgenden Ebenen:

3.1 Hardware-Ebene Die Hardwareebene besteht aus der herk6mmlichen Hardware wie CPU, dem Arbeitsspeicher und anderen Hardwareteilen. Zusiitzlich stellt die Hardware Trusted Computing Technologie zur Verfigung, wie zum Beispiel das Trusted Platform Module (TPM) oder Prozessorerweiterungen wie Intel TXT.

3.2 Hypervisor-Ebene (Ressource Management Layer) Oberhalb der Hardwareschicht liegt die Hypervisor- oder Ressource Management Ebene. Die Hauptaufgabe dieser Ebene besteht in der Bereitstellung abstrakter Schnittstellen zu darunter liegenden Hard= wareressourcen wie Interrupts, Arbeitsspeicher und anderer Hardware. Sie ist einerseits verantwortlich fir die Verteilung der Hardwareressourcen und andererseits fir die Durchsetzung der obligatorischen Zugriffsrechte, welche auf den zur Verfigung stehenden Hardwareressourcen basiert. Da der Zugriff auf die Hardwareressourcen sicherheitskritisch ist, muss die Ebene fir das Ressourcen Management zwei wichtige Eigenschaften zur Verfigung stellen: Isolation und das ,,least privilege'"-Prinzip. Turaya unterstitzt als Ressource Management Layer unterschiedliche Realisierungen wie beispielsweise Virtual Machine Monitore (VMM) wie XEN mit einem monolithischen Aufbau oder Mikrokerne wie L4.. Im Gegensatz zu monolithischen Systemen werden bei Mikrokern-basierten L6sungen die einzelnen Bausteine des Security Kernels durch voneinander isolierte Komponenten realisiert. Um Hardwarekomponenten nutzen zu k6nnen, werden Hardwaretreiber ben6tigt, welche ebenfalls Teil der Ressourcen Management Ebene sind. Da gef'~ihrlicher Code mit Zugriff tiber DMA (direct memory access) jeden Sicherheitsmechanismus umgehen kann, muss die Ressourcen Management Ebene augerdem sicherstellen, dass entweder nur vertrauenswfirdige Komponenten DMA-Devices benutzen k6nnen, oder dass Hardwaremechanismen wie z.B. AMD's Pacifica oder Intel's LaGrande unauthorisierte Zugriffe verhindem.

Die Sicherheitsplattform Turaya

91

3.3 Vertrauensw~irdige Sicherheitsdienste (Trusted Software Layer) Durch die Verbindung und Erweiterung der Schnittstellen, die yon der darunter liegenden Ressource Management Ebene zur Verfagung gestellt werden, stellt die Trusted Software Ebene sicherheitskritische Dienste zur Verffigung, welche ffir eine Sicherheitsplattform ben6tigt werden: 9 Umsetzung von Zugriffsregeln: Die Sicherheitsregeln (Policies), die mit Hilfe eines sicheren Systems durchgesetzt werden sollen, bestehen aus einer Kombination verschiedener Unterregeln, welche von verschiedenen Parteien mit unterschiedlichen Interessen kommen. Eine Hauptaufgabe der Trusted Software Ebene besteht darin, diese unterschiedlichen Unterregeln in eine einheitliche Menge von Zugriffsregeln umzuwandeln und darin m6gliche Konflikte, zu identifizieren und zu beheben. Die resultierende Sicherheitsregel muss spgter wieder separiert, tibersetzt und verteilt werden, so dass sie von anderen Sicherheitsdiensten interpretiert werden kanno 9 Schutz der Privatsph~ire: Viele Dienste, die von der Trusted Software Ebene zur Verfagung gestellt werden, k6nnen gegen Sicherheitsrichtlinien der Endnutzer verstogen, wenn sie nicht pr~izise definiert werden. Werden beispielsweise die von einem TPM zur Verf~gung gestellten Funktionen unfiberlegt eingesetzt, kann die Anonymit~it des Benutzers oder die Konfiguration der Computerplattform kompromittiert werden. Die Sicherheitsdienste der Trusted Software Ebene verhindem diesen Missbrauch, indem sie zus~itzliche Sicherheitsprotokolle oberhalb der Kemfunktionen einsetzen und Anwendungen somit nur einen eingeschr~inkten Zugriff auf TCFunktionen erlauben. 9 Trusted GUI: Basierend auf den Grundfunktionen der Ressource Management Ebene wird den Nutzern eine benutzerfreundliche, aber sichere Benutzerschnittstelle zur Verffigung gestellt, die sicherheitskritische Fehler zu vermeiden hilft. Ein Authentifizierungsmechanismus ffir Anwendungen hilft Nutzern beispielsweise dabei, Trojanische Pferde zu erkennen. Darfiber hinaus ist die sichere Schnittstelle daffir zust~indig, dass bestimmte Befehle (z. B. ,,Kopieren" und ,,Einft~gen") nicht gegen Sicherheitsrichtlinien verstogen. Eine weitere Aufgabe der sicheren Benutzerschnittstelle ist es, die Integrit~tt und Vertrauenswfirdigkeit sicherheitskritischer Eingaben (z. B. ein Pincode) oder Ausgaben (z. B. Prafen eines Dokuments), zu sichem. ~ Secure Installer: Obwohl ein sicheres System dazu in der Lage ist, potenziellen Gefahrencode in einem isolierten Bereich auszuffihren ohne gegen die definierten Sicherheitsregeln zu verstogen (im Allgemeinen ist es nicht m6glich, Trojanische Pferde oder andere Schadsoftware verl~isslich zu identifizieren), sollte die Installation und der Update-Prozess von Anwendungen und sicherheitskritischen Diensten von einem vertrauenswfirdigen Dienst t~berwacht werden. Die Hauptaufgabe des sicheren Installationsdienstes liegt demnach darin, den Anwender zu unters~tzen, die Mindestanforderungen far die notwendige Anwendung abzuleiten und die Ergebnisse zu t~bersetzen und zur Verfagung zu stellen. Dadurch, dass der sichere Installationsdienst Sicherheitsregeln durchsetzt, die der Anwender selber festgelegt hat, ist es beispielsweise m6glich, sicherza.lstellen, dass das ganze System oder auch nur ein Teil des Systems als abgeschlossenes System fungiert, welches nur von autorisierten Personen ge~indert werden kann. ~ Sichere Speicherung: Anwendungen ben6tigen persistenten Speicher mit den unterschiedlichsten Sicherheitseigenschaften: Neben der Integrit~it und der Vertraulichkeit von Anwendungsdaten muss beispielsweise auch sichergestellt werden, dass ein manipulierter Sicherheitskem oder eine manipulierte Anwendung keinen Zugriff auf sensitive Daten bekommt. Eine sichere Plattform ben6tigt jedoch noch weitere Sicherheitseigenschaften: Um Replay-Angriffe (das Einspielen veralteter Daten, z.B. von alten Audit-Logs) abwehren zu k6nnen, muss ein Sicherheitskern auch die sogenannte ,Freshness' von bestimmten Daten garantieren.

92

Die Sicherheitsplattform Turaya

3.4 Anwendungen Oberhalb des von dem Trusted Software Layer zur Verfagung gestellten Sicherheitsdienstes k6nnen neue Anwendungen und existierende Betriebssysteminstallationen parallel ausgefiihrt werden. Auch mehrere unterschiedliche Instanzen herk6mmlicher Betriebssysteme k6nnen isoliert voneinander ausgefahrt werden. Sie bieten bekannte Benutzerschnittstellen und erm6glichen die Weiterverwendung existierender Anwendungen. Der Benutzer kann also auch herk6mmliche Anwendungen und Softwarekomponenten weiter verwenden, wobei der Sicherheitskem unabh~ingig von den Betriebssysteminstanzen benutzerdefinierte Sicherheitsregeln durchsetzt.

4 Eigenschaften Die Kombination von Trusted Computing Komponenten wie dem TPM und einer Sicherheitsplattform wie Turaya erm6glicht substanzielle Eigenschaften, die im Folgenden kurz skizziert werdeno

4.1 Mehrseitige Sicherheit Die Turaya Sicherheitsplattform erm6glicht die Durchsetzung sowohl der Richtlinien (,,Policies") des Inhalteanbieters, als auch die Richtlinien des Benutzers. Dies wird durch entsprechendes Policy-Management auf dem attestierten Sicherheitskem durchgefahrt. Damit erm6glicht Turaya die Durchsetzung von verbindlichen Richtlinien far die Verarbeimng sicherheitssensitiver Daten und kann gleichzeitig die elementaren Rechte der Benutzer garantieren (z.B. Datenschutz vs. Lawful Interception) und schafft somit auch die Basis far sichere und vertrauenswfirdige DRM-Anwendungen. Dieser ,,fair-use"-Aspekt ist eine wichtige Voraussetzung far die breite Akzeptanz der TC-Technologie. Mit Hilfe von erweiterten Ffunktionen wie z.B. der Property-Based Attestation [SaSt2004] k6nnen darfiber hinaus nicht nur die Diskriminierung beim Einsatz von Open-Source Software technisch ausgeschlossen werden, es vereinfacht darfiber hinaus auch Softwarebackups und-updates.

4.20ffene Systemarchitektur Aufgrund der offenen Architektur und der auf einem sinnvollen Niveau gehaltenen Komplexit~it sicherheitskritischer Komponenten erm6glicht die Plattform eine hohe Verl~isslichkeit und Vertrauenswfirdigkeit. Die reduzierte Komplexit~it verkleinert auch die Fehlerwahrscheinlichkeit im Entwicklungs- und Warmngsprozess, wodurch wiederum die Vertrauenswtirdigkeit der Implementierung erh6ht wird. Darfiber hinaus wird eine Evaluierung nach Sicherheitsstandards, wie beispielsweise den Common Criteria (CC), mOglich. Dies ist von besonderer politischer und gesellschaftlicher Bedeutung, da der OpenSource Aspekt verschiedenen Interessengruppen den Zugang zu entsprechenden Softwareressourcen kosteneffektiv erm6glicht und eine kontinuierliche Kontrolle aller betroffenen Parteien erlaubt. Somit ist die Plattform von Endbenutzem und Inhalteanbietem unmittelbar bezaglich der Einhaltung der eigenen Sicherheitsregeln evaluierbar. Zertifizierungskriterien sind neben technischen Aspekten der ITSicherheit vor allem rechtliche Aspekte des Datenschutzes und des Urheberrechts. Der Source-Code der Turaya Sicherheitsplattform ist offen gelegt.

Die Sicherheitsplattform Turaya

93

4.3 Vertrauensw~irdiger Einsatz der TCG-Technologie Da Sicherheitsfunktionen immer auch gegen die Interessen der Benutzer angewandt werden k6nnen, sollte der Interessenkonflikt zwischen den Datenschutzanforderungen der Endbenutzer (Schutz der Privatsphfire und Selbstbestimmung) und den Sicherheitsanforderungen der Inhalte- und Anwendungsanbieter durch eine Betriebssystemplattform gel6st werden, welche eine Ausgewogenheit zwischen den Interessen aller beteiligten Parteien garantiert. Daher ist eine Sicherheitsplattform mit einer offenen Systemarchitektur, die die Systemereignisse und Hardwarekomponenten kontrolliert, gleichzeitig often gelegt und jederzeit evaluierbar ist, die Voraussetzung far eine diskriminierungsfreie Nutzung der TC-Technologie.

4.4 Plattformunabh~ingigkeit und Interoperabilit~it Die Turaya-Architektur ist plattformunabMngig und daher auf verschiedenen Hardware-Plattformen verfagbar. So werden z.B. im Rahmen des EMSCB-Projektes Implementierungen ft~ Anwendungen auf Desktop-Systemen, Notebooks und Embedded Controllern, im Rahmen des europNschen OPENTC Projektes far Server-Anwendungen und im Rahmen des TRUCOM-Projektes far PDA und Mobilfunktelefone umgesetzt.

4.5 Kompatibilit~it zu bestehenden Systemen Ein vertrauenswfirdiges System, dass bestehende Anwendungen nicht unterstfitzt, ist von geringem Nutzen, das haben Ans~ttze in den vergangenen drei Jahrzehnten immer wieder gezeigt. Durch die Integration von modernen Virmalisierungstechniken erm6glicht Turaya die Nutzung bisheriger Betriebssysteme wie Linux oder Windows bei gleichzeitiger Separierung kritischer Softwarekomponenten wie dem VPN-Client oder der Festplattenverschlfisselung.

5 Einsatzfelder f ir Turaya Die neuen, durch die Trusted Computing Technologie far den Masseneinsatz verfagbar gemachten Sicherheitsfunktionen erm6glichen zahlreiche neue Geschfiftsmodelle, die zuvor organisatorisch nur durch so genannte Trusted Third Parties (TTP) umsetzbar waren oder einen hohen technischen und organisatorischen Aufwand nach sich zogen. Im Folgenden sind einige interessante Einsatzfelder skizziert.

5.1 Distributed Policy Enforcement Bisherige Magnahmen zum Schutz digitaler Inhalte auf Endbenutzerger~iten zeigten bisher nur m~il3igen Erfolg. Dies ist vor allem darauf zurack zu fahren, dass die Endbenutzerger~ite meist vollst~indig durch den Benutzer kontrolliert werden und ein reiner Softwareschutz nicht ausreichto Die Erfahrung aus der Vergangenheit zeigt auch, dass propriet~ire Hardwarel/Ssungen, wie z.B. Dongles aufgrund ihrer hohen Komplexit~it, Inkompatibilit~it und nicht ausreichender Sicherheit wenig Akzeptanz erfahren haben. Hinzu kommt, dass die Sicherheit bei solchen geschlossenen L6sungen meist auf einem geheimen Algorithmus beruht, der im Widerspruch zum fundamentalen kryptographischen Paradigma steht, nach der die Sicherheit des Systems nur vonder Unkenntnis des Schlfissels abh~ingen soll. Darfiber hinaus wurden trotz ~iul3erster Geheimhaltung und Androhung rechtlicher Schritte der Inhalteanbieter, die meisten Sicherheitsmal3nahmen gebrochen.

Trusted Computing- eine E i n t ' t ~ n g 94

Die Sicherheitsplattform Turaya5

Infrastrukturanforderungen und-aufwendungen, bedingt durch die und erforderliche Personalisierung und Die Sicherheitsplattform hingegen, verbindet einen Sicherheitskem Trusted Computing-Hardware Verwaltung deseine Lebenszyklus von SmartCards, erheblich und schafft so geeignete Basis zur Durchsetzung von an. verteilten Richtlinien. Zum Beispiel k6nnen Lizenzvereinbarungen zwischen Endanwendern und Informationsanbietern durchgesetzt werden, soZudem hat sich herausgestellt, dass der Sicherheitsanker ,,personalisiertes Token" im Hinblick auf Anbald diese von beiden Seiten akzeptiert worden sind. Dabei sorgt die Sicherheitsplattform einerseits wendungsumgebungen zu schwach ist. Alle Angriffe auf die t~brigen IT-Systemkomponenten bleiben dafar, dass der Endanwender nur Zugriff auf die Information erlangt wenn er daf'ttr eine entsprechende wirksam. Deshalb werden zusammen mit der SmartCard zahlreiche zus~itzliche SicherheitskomponenGegenleistung erbracht hat. Andererseits wird sichergestellt, dass der Informationsanbieter nur die Daten (sichere Kartenterminals, sichere I/O-Kan~ile, sicherer Viewer, virenfreie Anwendungsumgebung ten von Endanwender erMlt die wirklich n6tig sind. M6gliche Einsatzszenarien sind Kopierschutzrechusw.) empfohlen, die kostentr~ichtig sind und die Anwendungsflexibilit~it reduzieren. te von multimedialen Dateien, eLearning, elektronische Bircher. Bisher die ist Plattform die Verbreitung LOsung mit niedriger Performance, komplexem Handling nur Durch wird diedieser unautorisierte Verteilung digitaler Inhalte deutlich erschwert. Die und Sicherwenigen Akzeptanzstellen gering. Ihre konsequente Umsetzung als Grundlage fiir sichere IT-Anwenheitsplattform stellt auch die Basis far pragmatische und faire Digital-Rights-L6sungen zur Verfagung. dungen erfolgt zungchst nursind propriet~ir unddaran Ftir geschlossene Anwendergruppen. In diesem Zusammenhang wir sehr interessiert, die Entwicklung unserer Plattform an die Konzepte use" und ,,firstzeigt sale"sich anzupassen, um privaten eine auf einmalige WeiterleiDas Risikoyon des,,fair Nutzerverhaltens insbesondere dadurch,Anwendem dass die Nutzer Links in E-Mails tung oder den nicht gewinnbringenden Einsatz Webseiten zu erm6glicheno von unbekannten Absendem und mysteri6sen klicken, und sich so Schadsoftware auf ihren Rechnersystemen laden. Dabei nutzen sie oft keine Virenscanner und Personal Firewalls und sind aus

diesemMulti-Level Grund far Angreifer leichte Opfer. Zudem tragen zur Verbreitung Rights von Schad- und Angriffs5.2 Security (MLS) und sieEnterprise

programmen bei.

Management (ERM)

Als ein Fazit ergibt sich: V611ige Sicherheit ist als Vertrauensgrundlage nicht erreichbar! Die VerantworGeschgftsprozesse Untemehmen den Austausch sensibler Daten und Dotung aller Partner inzwischen der Netzwelt (Anwender,erfordern Anbieterh~iufig von L6sungen oder GescMftsprozessen, Dienstkumente (z.B. Finanzbuchhaltung, Patentantrgge, technische Kooperationen), deren Verwendung leister, Infrastrukturbetreiber usw.) f'~ einen vertrauenswtirdigen Systemzustand kann von Technologie vertraglich, beispielsweise Geheimhaltungsvereinbarungen, reglementiert sind. Auch unternehzwar unterstf~tzt, aber durchdurch sie nicht abgel6st werden. mensintern sind technische Schutzmagnahmen essentiell, die Zugriffe auf Dokumente aul3erhalb des vorgesehenen Workflows verhindern. So sollte beispielsweise verhindert werden, dass Mitarbeiter geheime Dokumente lesen, sensible zu Dokumente (versehentlich oder vors~itzlich) aul3erhalb des Unterneh2 Die Alternative heutigen Sicherheitsl6sungen mens verbreiten oder unbefugte Anderungen an Dokumenten vornehmen. Vor dem Hintergrund der bisher zusammengefassten Erfahrungen wird deutlich, dass die bisher verfolgDie existierenden k6nnen keinen wirksamen Schutz zur Handhabung klassifizierter ten Konzepte zur Rechnerplattformen IT-Sicherheit erg~tnzungsbedfirftig sin& Erfolgversprechende Bemfihungen in diese Dokumente bieten, ihre folgende BenutzerZiele Kontrollmechanismen umgehen k6nnen, indem sie die entspreRichtung sollten vorda allem verfolgen: chenden vorhandenen Funktionen f'ttr ihre Zwecke einsetzen oder Softwarekomponenten durch Ausnut9 Reduzierung der Kosten ftir Sicherheits-Hardwaremodule und ffir Infrastrukturdienste; zung von Sicherheitslficken manipulieren. 9 Integration standardisierter Sicherheits-Hardwaremodule in Ger~ite und Systemkomponenten Die Turaya Sicherheitsplattform garantiert die Durchsetzung und Daten-bezogener Sicherzur Verwaltung von Ger~iteidentit~iten sowie zur Prfifung globaler der Vertrauenswfirdigkeit und Integritfit heitsrichtlinien (,,Object-Security") bei der Verarbeitung von Daten. Mit Hilfe dieser Eigenschaft kann ihrer Konfiguration; die Nutzung von sensiblen oder vertraulichen Inhalten fiber die Lebensdauer der Dokumente ~ Vereinfachung des Handlings der Sicherheitsl6sungen undgesamte Verbesserung ihrer Performance; garantiert werden (,,Information Flow Control" und ,,Life-time cycle"). Bei herk6mmlichen Systemen Durchsetzung einer betriebssystemunabh~ingigen Standardisierung der Sicherheitsfunktionen wird ~lediglich zum Zeitpunkt des Zugriffs die Berechtigung t~berprfift (,,Access Control"). Uber die und ihrer Anwendbarkeit; weitere Verarbeitung bzw. Weitergabe der Daten verliert der Datenanbieter jegliche Kontrolle. ~ Standardisierung von Schnittstellen f-fir sichere Anwendungen, weitere Kryptoger~ite (SmartDies stellt die Basis ffir die Realisierung eines den praktischen Gegebenheitenund angepassten Systems mit Cards, USB-Token, intelligente Speicherkarten usw.), Infrastrukturen Management. Multi-Level Security (MLS). Bisherige MLS-L6sungen sind aufgrund ihrer hohen Komplexit~it bzw. Letztendlich Gestaltung k6nnen nur (streng auf diesem WegeHardware) hochwertige Sicherheitsfunktionen in die allgemein verfagineffizienten getrennte nicht befriedigend. baren Anwendungen und Systemarchitekmren eingebracht werden. Eine weitere wichtige Anwendung, die erst durch eine sichere Rechnerplattform realisiert werden kann, sind Multi-Server-Systeme, bei denen verschiedene sicherheitskritische Dienste, wie beispielsweise vir2.1 Poststellen Das Trusted Computing Konzept tuelle und Security Gateways, parallel auf einem Server laufen und hermetisch gegeneinander abgeschottet werden. M6gliche Fehler oder Sicherheitslticken in einzelnen Komponenten, wie dem Das Trusted Computing Konzept greift diese Ziele auf, indem zun~ichst konsequent ein SicherheitsNetzwerkstack, k6nnen damit eingegrenzt und Auswirkungen begrenzt werden. Hardwaremodul (Trusted Platform Module - TPM) definiert und spezifiziert worden ist, das in prozessorgestfitzte Gergteplattformen fest integriert werden kann. Seine standardisierten Grundfunktionen und Schnittstellen unterstfitzen die lokale Anwendung von Kryptoverfahren auf einem Sicherheitsniveau,

Die Sicherheitsplattform Turaya

95

5.3 Sichere Endbenutzer Systeme Die heutigen Standard-Endbenutzersysteme bieten kaum verl~issliche Sicherheitseigenschaften, die far rechtsverbindliche Transaktionen unerl~isslich sind. Dies spielt insbesondere in den Bereichen ECommerce und E-Government eine zunehmend wichtige Rolle, aber auch im privaten Bereich zeigt die Problematik des Phishings und des dadurch entstandenen Schadens die Bedeutung von verl~isslichen IT-Systemen. Diese Problematik l~isst sich nicht durch heutige Sicherheitstechniken wie Smart-Cards sicher 10sen, wie bei der elektronischen Signatur deutlich wird: Die Signaturkarten, auf denen Dokumente signiert werden, sind selbst vertrauenswt~rdig und sicher, aber ein Benutzer kann nicht sicher sein, dass das Dokument, dass an die Signaturkarte zum Signieren geschickt wurde, nicht vorher durch Schadsoftware ver~indert worden ist. Das Konzept, das an dieser Stelle benOtigt wird, ist unter dem Namen ,,What you sign is what sou see `~bekannto Eine Sicherheitsplattform 10st dieses Problem durch die Trennung von kritischen Anwendungen, wie Banking oder Signaturerstelhmgskomponenten, von anderen Komponenten und durch die Bereitstellung eines vertrauenswfirdigen Kanals (,,Trusted Path") zwischen dem Benutzer und den kritischen Komponenten.

5.4 Embedded Security Ein weiterer wichtiger Anwendungsbereich far die geplante Sicherheitsplattform ergibt sich aufgrund der stetig steigenden Integration von Prozessor-Plattformen in andere Produkte (Eingebettete Systeme), z.B. in der Automobilindustrie. Die hohe Komplexit~it der verwendeten Software fahrt jedoch zu einer hOheren Fehlerwahrscheinlichkeit, die durch den Einsatz eines Sicherheitskerns kompensiert werden kann. Des Weiteren wird in Zukunft die Integration von Informations- und Multimediasystemen in Kraftfahrzeugen eine immer wichtigere Rolle spielen, wodurch sich far die Hersteller neuartige MarktmOglichkeiten ergeben (siehe auch [Paar03], [AHSS05], [HuSW06] und [ScSW06]). Die angestrebte Plattform bietet hierfttr die notwendige Grundlage und ermOglicht insbesondere der deutschen Automobilindustrie die Entwicklung innovativer Produkte.

6 Fazit Sichere Betriebssysteme bzw. Sicherheitskerne sind neben den TC-Hardwarekomponenten essentielle Voraussetzung zur sinnvollen Nutzung der Trusted Computing Technologie. Mit Turaya steht eine solche offene Sicherheitsplattform bereit, die bereits jetzt Grundlage vieler nationaler und europ~iischer Trusted Computing Projekte ist und bereits erfolgreich in industriellen Produkten [A1SS07] im Einsatz ist.

Literatur [AHSS05] Adelsbach, Andr6 und Huber, Ulrich und Sadeghi, Ahmad-Reza und Stable, Christian: Embedding Trust into Cars- Secure Software Delivery and Installation. In: Third Workshop on Embedded Security in Cars (escar 2005), Cologne, Germany, November 29-30, 2005. [A1SS07] Alkassar,Ammar und Scheibel, Michael und Stable, Christian: Sicheres VPN-Management mit Trusted Computing. In: Tagungsband zum 10. Deutschen IT-Sicherheitskongress, Bad Godesberg, Mai 2007.

96

Die Sicherheitsplattform Turaya

[ASSS05] Alkassar, Ammar und Selhorst, Marcel und Sadeghi, Ahmad-Reza und Stable, Christian: Towards Secure Computing Platforms with Open-Source and Trusted Computing. In: Tagungsband zum 9. Deutschen IT-Sicherheitskongress, Bad Godesberg, SecuMedia Verlag, Mai 2005. [ASSS06] Alkassar, Ammar und Scheibel, Michael und Sadeghi, Ahmad-Reza und Stable, Christian: Security Architecture for Device Encryption and VPNo In: Proceedings of ISSE (Information Security Solution Europe) 2006~ [HuSW06] Huber, Ulrich und Sadeghi, Ahmad-Reza und Wolf, Marko: Security Architectures for Software Updates and Content Protection in Vehicles. In: Automotive Safety and Security 2006, Stuttgart. [Paar03]

Paar, Christof: Eingebettete Sicherheit im Automobil. In: Embedded IT-Security in Cars (ESCAR), KOln, 2003. http:// ww.escarconference.org

[SaSP04]

Sadeghi, Ahmad-Reza und Stable, Christian und Pohlmann, Norbert: European Multilateral Secure Computing Base - Open Trusted Computing for You and Me. In: Datenschutz und Datensicherheit (DUD) 9/2004, Vieweg Verlag, pp. 548-553, 2004.

[SaSt03]

Sadeghi, Ahmad-Reza und Stable, Christian: Taming Trusted Computing by Operating System Design. In: Proceedings of the 4th International Workshop on Information Security Applications (WISA), Korea, Springer Verlag, 2003.

[SaSt04]

Sadeghi, Ahmad-Reza und Stable, Christian: Property-based Attestation for Computing Platforms: Caring about policies, not mechanisms. In: New Security Paradigm Workshop NSPW, Nova Scotia, 2004~

[SaSt05]

Sadeghi, Ahmad-Reza und Stable, Christian: Towards Multilateral Security On DRM Platforms. In: Proceedings of the First Information Security Practice and Experience Conference (ISPEC 2005), LNCS 3439, Springer-Verlag, 2005

[ScSW06] Scheibel, Michael und Stable, Christian und Wolf, Marko: Design and Implementation of an Architecture for Vehicular Software Protection. In: Embedded Security in Cars Workshop (escar ,06), 14.- 15. November 2006, Berlin. [SSSW06] Sadeghi, Ahmad-Reza und Scheibel, Michael und Stable, Christian und Wolf, Marko: Play it once again, S a m - Enforcing Stateful Licenses on Open Platforms. In: Proceedings of The Second Workshop on Advances in Trusted Computing (WATC ,06 Fall).

Trusted N e t w o r k C o n n e c t Ve rt ra u e nswLi rd ige N e t z w e r k v e rb i nd u ngen Marian Jungbauer 9 Norbert P o h l m a n n institut f-fir Intemet Sicherheit, FH Gelsenkirchen {jungbauer ] pohlmann} @internet-sicherheit.de

Zusammenfassung Die durch die Globalisiemng entstandene wirtschaftliche Abh~ingigkeit von schnellem und kostengfinstigem Informationsaustausch fahrt zu einer immer stfirkeren Vernetzung. Das Internet stellt eine weltweit verfagbare Kommunikations-Infrastruktur bereit. Es bietet aber keine M6glichkeiten einer vertrauenswiirdigen Kommunikation, da die im Netz befindlichen Rechnersysteme nicht auf deren Systemintegrit~it und Vertrauenswiirdigkeit gepraft werden k6nnen. Gleiches gilt far Intranets. Besucher und Aul3endienstmitarbeiter, die ihre Rechnersysteme, zum Beispiel Notebooks, sowohl aul3erhalb als auch innerhalb des Firmennetzes einsetzen, stellen mit diesen Rechnersystemen eine Bedrohung far das Unternehmen dar. Durch die Benutzung der Rechnersysteme auf3erhalb des Firmennetzes arbeiten diese auch auf3erhalb der Schutzmaf3nahmen und des Kontrollbereichs der Untemehmens-IT. L6sungsAnsfitze wie zum Beispiel Trusted Network Connect (TNC), stellen Methoden zur Feststellung der Integrit~it von Endpunkten bereit, die als Basis far vertrauenswtirdige Kommunikation dienen. Die Konfigurationen der Endpunkte lassen sich sowohl auf Software- als auch auf Hardwareebene messen, l~lber den Abgleich von definierten Sicherheitsregeln kann eine Policy-gesteuerte Zugriffssteuerung realisiert werden.

1 Einleitung Noch vor wenigen Jahrzehnten wurden Daten und Dokumente sowohl innerhalb als auch zwischen Firmen pers6nlich oder per (Haus-)Post ausgetauscht. Ffir den Transport sensibler Daten mussten vertrauenswfirdige Kommunikationswege wie etwa eigene, kostenintensive Postdienste genutzt werden. Sp~tter boten erste Formen der elektronischen Datentibertragung, wie beispielsweise die Obertragung per Fax, die M6glichkeit, Dokumente schnell von A nach B zu fibertragen. Die vertrauliche 121bermittlung sensibler Daten konnte aber nicht gew~thrleistet werden. Die zunehmende Verbreitung von Computerarbeitspl~itzen und die immer weiter fortschreitende elektronische Datenhaltung f'tihrten zur Bildung von Rechnemetzwerken innerhalb und zwischen Firmen. Ffir den vertraulichen Austausch von Informationen wurden hingegen weiterhin die bestehenden Kommunikationswege genutzt. Heute, in Zeiten der Globalisiemng, vergr6f3em sich sowohl die Distanzen, die Menge, als auch die Wichtigkeit der auszutauschenden Informationen zwischen Firmen oder ihren Niederlassungen. Zus~itzlich wirkt auf alle betrieblichen Prozesse ein erh6hter Kosten- und Zeitdruck. Klassische, 6rtlich begrenzte Netzwerke (Intranets) auf der ganzen Welt werden daher immer intensiver in grol3e, 6rtlich unbegrenzte Firmennetze integriert. Heim- und Augendienstmitarbeiter ben6tigen einen schnellen, siN. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 97-109

6 98

Trusted Computingeine Einfahrung Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

wie es auch von SmartCards geboten Darfiber hinaus er6ffnet das Konzeptzuzahlreiche weitere Ancheren und ortsunabh~ngigen Zugriffwird. auf Daten im Firmennetz. Transaktionen anderen Organisatios~tzeinsbesondere far innovativeimL6sungen, mit denen Vertrauenswttrdigkeit und die Sicherheit von IT-Systemen nen, B2B-Bereich, laufendie verst~irkt auf elektronischem Wegeo erh6ht werden k6nnen. Die Darstellung dieser M6glichkeiten ist ein Grundanliegen dieser Publikation. Ehemals statische Netz-Infrastrukturen mit klaren Systemgrenzen weichen so verst/~rkt heterogenen Da die IT-SystemeNetzen tendenziell komplexer und heterogener werden, entscheidet die Bewertbarkeit des und dynamischen [Hart05]. Sicherheitszustandes von Systemkomponenten (PCs, aber auch andere computergestt~tzte Ger~ite im Netz wie Mobiltelefone, Speicherger~tte, Drucker usw.) zunehmend tiber die Vertrauenswfirdigkeit von Anwendungen. Diese Anforderung stand bei der Formulierung des Trusted Computing Konzeptes Das Trusted Module (TPM) kann kryptographischer die entgegen, Integrit~it DerPate. Flexibilit~it und derPlatform kostengtinstigen Nutzung des mittels Intemets steht ein Mangel Verfahren an Sicherheit der Softund Hardware-Konfiguration eines Ger~ites messen und deren Hashwerte (Prafwerte) sicher der eine umfassende beh6rdliche und industrielle Nutzung in sicherheitskritischen Bereichen zurzeit im TPM speichern. Diese Messwerte k6nnen remote t~berprfift werden und machen Anderungen der nur eingeschr~inkt zul~isst. Soft- oder Hardware-Konfiguration erkennbar. Trusted Computing ben6tigt dazu als Voraussetzung und Infrastrukturkomponentenutzen eine Sicherheitsplattform sicheres kleines Betriebssystem), Aul3endienstmitarbeiter ihre Rechnersysteme(eigenst~indiges, in vielen verschiedenen Umgebungen mit unterwelche diese Integrit~its(iberprfifungen anst6f3t und auch auswertet. schiedlichem Sicherheitsbedarf. Heimarbeiter nutzen ihre PCs meist auch far private Zwecke. Mitarbeiter nehmen immer Mufiger ihre Notebooks mit nach Hause oder schliegen private Rechnersysteme W~ihrend die beteiligten Hardwaremodule die entsprechenden Software-Schnittstellen standardian das Firmennetz an. Diese zeitweilig oderund dauerhaft aus dem Firmennetz ausgelagerten Rechnersyssiert sind, die ben6tigte Sicherheitsplattform propriet~ir sowohl vonder als auch teme sind wird wesentlich gr613eren Gefahren ausgesetzt, da sie nicht unter den Software-Industrie lokalen Schutzmagnahmen von Open Source Teams entwickelt. des Firmennetzes stehen. Kommt es zu einer Kompromittierung durch Malware in einer unsicheren Umgebung, erfolgt die Trusted Reintegration in dasKonzept Firmennetz (direkt oder fiberMarktplayer das Internet)Verantworeine UmBedeutsam ist, dass durch mit dem Computing die entscheidenden gehung der firmeneigenen Sicherheitsmechanismen und somit, fiber das Untemehmensnetz undreale den rang far die Gestaltung und Umsetzung der genannten Ziele fibernommen haben. So besteht die angeschlossenen Rechnersystemen, eine Gef~ihrdung des Untemehmens selbst. Chance, entsprechende L6sungen von unterschiedlichen Anbietem wettbewerbsneutral u n d - was die

1.1 Problemstellung

Hardwareerg~tnzung betrifftzu geringstm6glichen Zusatzkosten bereit zu stellen. Der Erfolg wird weLfisst sich die Benutzung von privaten Rechnersystemen durch intern definierte Sicherheitsund Datensentlich durch die Nutzerakzeptanz bestimmt werdeno Hier spielt die Transparenz der angebotenen Sischutzrichtlinien verbieten, bleiben die Probleme bei der Integration von Heim- und Augendienstmitcherheitsfunktionen eine entscheidende Rolle. Sie sollte far die Vertrauensbildung als ebenso bedeutend arbeitern bestehen. Hier werden heute meist Virtual Private Networks (VPNs) mithilfe von Softwareangesehen werdenum wiesodiesichere Befolgung der Kerkhoff-Prinzipien 1 far die verwendete Kryptographie. Clients aufgebaut Verbindungen fiber 6ffentliche, unsichere Netzwerke zu erm6glichen. Die Verbindung von ganzen Netzwerken geschieht ebenfalls fiber VPNs, die hier durch VPN-Gateways an Zugangspunkten der Netzwerke zum Internet erzeugt werden. Die VPN-Technologien setzen auf 2.2denTPM Verbreitung eine Nutzerauthentifikation sowie eine verschl%selte und integrit~itsgesicherte Datenfibertragung. Sie Spezifikationskonforme TPM Prtifung 1.2 Module werden von mehreren fahrenden Chip-Produzenten angebieten aber durch die fehlende der Systemintegrit/it, das heigt der Prfifung der Konfigurationen boten und inzwischen in die Motherboards und Laptops verbreiteter Marken von Hardund Software, keine M6glichkeitvon der Servern, Prfifung Desktops der Vertrauenswfirdigkeit der zugreifenden integriert. Rechnersysteme.

k~176

[

..~ ..~~5

Die renommierte Marktforschungsorganisation IDC hat dazu eine Analyse und Vorschau geliefert (siehe Abbildung 1). Es wird erwartet, dass im Jahr 2010 bereits mehr als 250 Millionen TPM Module ausgeliefert werden. .

.

.

.

Gateway

Angreifer

mit Zugangsdaten)

OrganisationA

Abb. 1 M6gliche Gef'~ihrdungentiber VPN 1 Die Sicherheitdes Kryptosystemsdarfnicht von der Geheimhaltungdes Algorithmusabh~ingen.Sie darfsich nur auf die Geheimhaltungdes Schlfisselsgrfinden.

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

99

An den Zugangspunkten des VPNs ist folglich kein Schutz vor Angriffen durch die zugreifenden Rechnersysteme gegeben. Abbildung 1 zeigt zwei m6gliche Gef'~ihrdungen eines Netzwerks bei der Nutzung einer durch VPN abgesicherten Kommunikationsverbindung. 9 Zum einen ist kein Schutz des Rechnernetzes, mit seinen angeschlossenen Rechnersystemen und Diensten, vor einem durch Malware kompromittierten Rechnersystem m6glich, da eine 121berprfifung der Integrit~it des Rechnersystems fehlto ~ Zum anderen kann nicht festgestellt werden, dass das Rechnersystem, mit dem kommuniziert wird, auch wirklich das Rechnersystem ist, das es vorgibt zu sein. Gelangt ein Angreifer an Zugangsdaten eines VPNs, so kann er diese ft~r einen unberechtigten Zugriff nutzen.

1.2 Anforderungen an heutige Rechnernetze Die Anforderungen an heutige und zukfinftige Netzwerke sind umfangreich. Sie mfissen flexibel und in ihrer Ausdehnung often sein. Gleichzeitig sollen sie eine vertrauenswfirdige Kommunikation erm6glicheno Schon heute existieren M6glichkeiten, vorhandene Netzwerke ftexibel zu erweitern und mit Sicherheitsdiensten auszustatten- wie das oben genannte Beispiel der Anbindung fiber VPNs. Auf der anderen Seite fehlen aber Sicherheitsmechanismen, die die Vertrauenswfirdigkeit der vom Anwender genutzten Rechnersysteme gew~ihrleisten. Ziel neuer Sicherheitssysteme muss eine direkte oder indirekte 121berprfifbarkeit der Vertrauenswftrdigkeit der beteiligten Rechnersysteme und die Herstellung sicherer Kommunikation sein. Es mfissen neben den bekannten Angriffen auf Netzwerke (Netzkomponenten und Leitungen) auch die Angriffe fiber mit Malware kompromittierte Rechnersysteme sowie Angriffe durch Dritte mittels gestohlener Zugangsdaten verhindert werden.

2 Vertrauensw

irdige Netzwerkverbindungen

Von einer vertrauenswfirdigen Kommunikation wird gesprochen, wenn die Vertrauenswfirdigkeit aller beteiligten Kommunikationspartner festgestellt werden kann. Wichtig ist dabei, dass die Vertrauenswfirdigkeit ffir jede Kommunikationsrichtung getrennt betrachtet wird. Man kann mit einer Person, der man selbst vertraut, ein vertrauliches Gespr~ich fahren, ohne dass der Gegent~ber einem dieses Vertrauen selbst entgegenbringt. Grundsgtzlich mfissen aber nicht nur die Personen als vertrauenswfirdig eingestuft werden, sondern auch das Umfeld, indem die Kommunikation stattfindet. Findet die Kommunikation lokal statt, so muss der Ort als vertrauenswfirdig eingestuft werden, also zum Beispiel frei von Abh6reinrichtungen sein. Findet die Kommunikation fiber eine gewisse Distanz statt, so muss der 121bertragungsweg, beispielsweise ein Postdienst mit all seinen Mitarbeitern und R~iumlichkeiten, vertrauenswfirdig sein. Zus~itzlich ist die Vertrauenswfirdigkeit abh~ingig von den Anforderungen des Kommunikationspartners. Dieser definiert seine Anforderungen an eine vertrauenswfirdige Kommunikation mit Hilfe einer Policy. In dieser Policy k6nnte definiert sein, welchen Botendienst er f-fir vertrauenswfirdig h~ilt und wie die Lieferung verpackt sein muss, um kompromittierte Sendungen feststellen zu k6nnen Diese Gesetzm~il3igkeit kann auch direkt auf Kommunikation fiber Netzwerke angewendet werden. Ffir eine vertrauenswttrdige Kommunikation tiber Rechnernetze mt~ssen zum Einen alle an der Kommunikation beteiligten Personen zuverl~issig authentifiziert werden und zum Anderen die Integrit~it aller an der Kommunikation beteiligten Rechnersysteme gew~ihrleistet sein.

100

Trusted Network Connect- Vertrauenswiirdige Netzwerkverbindungen

Schon heute existieren Techniken die eine zuverl~issige l~erprfifung der Identit~it der an der Kommunikation beteiligten Personen erm6glicheno Zus~itzlich bieten diese Techniken meist auch eine gesicherte Obertragung von Daten tiber Netzwerke. Ein verbreitetes Beispiel sind die bereits vorgestellten VPNs. Was noch fehlt, sind geeignete und zus/itzliche Sicherheitsmechanismen, die eine Integrit/~tsprfifung der zur Kommunikation eingesetzten Endpunkte (Rechnersysteme) erm6glichen. Die Vertrauenswfirdigkeit eines Rechnersystems ist vom Gesamtzustand aller Hard- und Softwarekomponenten mit ihren Konfigurationen abh~ingig. Eine gemessene Integrit~it stellt dabei den aktuellen Zustand eines Rechnersystems fest. Ob ein Rechnersystem als vertrauenswfirdig gilt oder nicht ist von den Sicherheitsrichtlinien (Policies) der Kommunikationspartner abh~ingig, also welcher Gesamtzustand gemessen worden ist. So kann zum Beispiel ein Betreiber eines Netzwerkes die Vertrauenswiirdigkeit eines Rechnersystems durch die Nutzung eines aktuellen Betriebssystems als bewiesen ansehen, w~ihrend ein anderer Betreiber zum Beweis auch aktuelle Anwendersoftware, zum Beispiel einen aktuellen Browser, verlangt. Erst wenn alle in der Policy des Netzbetreibers definierten Systemkomponenten, das heigt Hard- und Software, in einem gewollten und nicht-kompromittierten Zustand sind, gilt die Vertrauenswfirdigkeit des Systems als gesichert. Das Problem dabei ist, dass heutzutage eine Kompromittierung, besonders bei Betriebssystemen, nicht direkt, sondern nur indirekt fiber das Vorhandensein weiterer Software messbar ist. Dies geschieht zum Beispiel durch die Nutzung eines aktuellen Virenscanners und einer optimal eingestellten Personal-Firewall. Nur solange diese Programme installiert sind, die richtige Konfiguration haben und einen aktuellen Datenstand aufweisen, kann die Wahrscheinlichkeit einer Kompromittierung als gering betrachtet werden. Genau hier setzen die neuen Konzepte zur Etablierung integrit/~tsgeprt~fter Netzwerkverbindungen an. Unter dem Oberbegriff ,,Network Access Control" (NAC), erm6glichen diese eine 121berprfifung der Konfiguration der Endpunkte schon beim Aufbau einer Netzwerkverbindung. Welche Konfigurationen aus Hard- und Software eines Rechnersystems in einem Netzwerk erlaubt sind, wird vom Netzbetreiber fiber Policies festgelegt. Diese Policies schreiben beispielsweise sowohl die Pr/~senz eines Virenscanners mit aktueller Virensignatur als auch eine installierte und gut konfigurierte Personal-Firewall und ein akmelles Patch-Level ffir Betriebssystem und Anwendungen vor. Nur bei Erfiillung der Policies wird einem anfragenden Endger~it ein Zugriff auf das Netzwerk mit seinen Diensten gew~ihrt. Bei diesen neuen Sicherheitskonzepten wird auch von einem Wechsel der Schutz-Strategie von Netzwerken und deren Diensten gesprochen. Durch die l]berprt~fung der Rechnersysteme vor dem Netzzugriff findet ein Wechsel vonder Gefahren-Reaktion hin zur Pr~ivention statt. W~ihrend heute mit Intrusion-Detection-Systemen (IDS) versucht wird, anhand von abnormalen Messwerten im Netzwerkverkehr kompromittierte Rechnersysteme zu erkennen- das heigt, ein durch Malware infiziertes Rechnersystem muss sich erst ,,falsch" verhalten (Reaktion), bevor es entdeckt werden k a n n - verhindern die pr~iventiven Sicherheitskonzepte, dass Rechnersysteme mit einer fehlerhaften oder unerwfinschten Systemkonfiguration und somit mit einer eventuellen Kompromittierung t~berhaupt in das Netzwerk gelangen und die dort vorhandenen Dienste nutzen.

3 Trusted Network Connect Mit der Trusted Network Connect-Spezifikation (TNC) entwickelt die Trusted Computing Group einen eigenen NAC-Ansatz. Die Entwicklung findet durch die Trusted Network Connect-Subgroup [Trus06] mit ftber 75 vertretenen Firmen statt und liegt aktuell (Mai 2007) in Version 1.2 vor [Tru+06].

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

101

Ziel ist die Entwicklung einer offenen, herstellemnabMngigen Spezifikation zur 12Iberpr~fung der Endpunkt-Integrit~it. Diese lJberpl"fifung ist grundlegend zur Feststellung der Vertrauenswfirdigkeit eines Rechnersystems. Zus~itzlich bietet TNC Sicherheitsmechanismen far die Zugriffskontrolle. TNC soil dabei keine vorhandenen Sicherheitstechnologien ersetzen, sondem auf diesen aufbauen. So werden beispielsweise aktuelle Sicherheitstechnologien fin- den Netzwerkzugriff (,,802.1x" und ,,VPN"), far den Nachrichtentransport (,,EAP", ,,TLS" und ,,HTTPS") und ffir die Authentifizierung (,,Radius" und ,,Diameter") unterstfitzt. Durch diese Eigenschaften soll sich TNC leicht in bestehende Netzinfrastrukturen integrieren lassen.

3.1 Phasen Alle durch TNC bereitgestellten Funktionen lassen sich in drei Phasen einordnen: Die Assessment Phase umfasst alle Aktionen vom Versuch eines Verbindungsaufbaus zu einem TNCgeschfitzten Netzwerk bis zur Entscheidung fiber dessen Integrit~it. In dieser Phase werden Messwerte vom Rechnersystem an einen Server im Netzwerk gesendet und dort anhand von Policies verglichen. Durch diesen Vergleich ist eine Entscheidung fiber die Vertrauenswfirdigkeit des Rechnersystems m6glich. Wird das Rechnersystem, bei Nichterffillung der Policies, als nicht vertrauenswfirdig eingesmft, gelangt es in die Isolation Phase. In dieser Phase wird das zugreifende Rechnersystem in einen geschfitzten Netzwerkbereich isoliert, welcher vom restlichen Netz abgeschottet ist. Eventuell mit Malware kompromittierte Rechnersysteme oder Rechnersysteme von Angreifern erlangen so keinen Zugriff auf das Netzwerk und die dort angebotenen Dienste. Die Remediation Phase bietet den isolierten Rechnersystemen die M6glichkeit ihre Integrit~it, zum Beispiel fiber die Installation fehlender Sicherheitssoftware, wiederherzustellen und, nach einer emeuten Uberprfifung, Zugriff auf das Netzwerk mit seinen angebotenen Dienste zu erlangen. Sowohl die Isolation- als auch die Remediation-Phase sind durch die TNC-Spezifikation nicht vorgeschrieben und mfissen somit nicht zwangslfiufig implementiert sein.

Abb. 2: Zusammenhang der Phasen von TNC

3.2 Struktur Grunds~itzlich wird in der TNC-Spezifikation zwischen drei Elementen unterschieden. Das Rechnersystem, fiber das eine Neztwerkverbindung zu einem TNC-Netzwerk aufgebaut werden soll, wird Access Requestor (AR) genannt. Auf dem Access Requestor befinden sich TNC-Komponenten far Verbindungsanfrage, Messwertfibermittlung und Messung.

102

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

Die Messung der einzelnen Komponenten des Rechnersystems findet durch so genannte ,,Integrity Measurement Collectors" (IMC) statt. Ffir jede zu messende Komponente existiert dabei ein passender IMC, beispielsweise einer f'tir Virenscanner und einer Far die Personal-Firewall. Zum Systemstart werden die IMCs vom TNC-Client auf dem zugreifenden Rechnersystem initialisiert, um bei einem Verbindungsaufbau Messwerte von den jeweiligen Komponenten sammeln zu k6nnen. Die Art der m6glichen Messwerte ist dabei zun~ichst nicht begrenzto Bei einem Virenscanner k6nnen zum Beispiel Informationen fiber Hersteller und Alter der Virensignatur wichtig sein, bei einem angeschlossenen Drucker die Version der Firmware und ob der Drucker Fax-Funktionalit/~t besitzt. Damit ein IMC diese detaillierten Messwerte sammeln kann, bedarf es einer sehr genauen Kenntnis der zu messenden Hardware/ Software. Diese Kenntnis besitzt meist nur der Hersteller von Hardware beziehungsweise Software. Eine Mitarbeit durch die Hersteller bei der Erstellung oder Bereitstellung eines IMC ist also zwingend notwendig.

PEP !

.,..,

Integrity Measurement Collectors t

C >',O

TNC-Client LLI |. . . . . . . . . !

i>,

Network Access Requestor

Policy Enforcement Point

t m Q. ~i f }

an

VPN Gateway

Abb. 3" Strukmr von TNC Auf Seiten des Netzwerks existieren zwei TNC-Elemente" Der Policy Decision Point (PDP) stellt die Gegenseite zum Access Requestor (AR) dar. Es handelt sich dabei um einen Server, der die Aufgabe hat die Messwerte eines Access Requestors zu sammeln und mit Hilfe yon Policies eine Zugriffsentscheidung zu formuliereno Diese Entscheidung wird anschlief3end der ausffihrenden Stelle ffir den Zugriff mitgeteilt. Die Network Access Authority (NAA) im Policy Decision Point entscheidet, ob ein AR Zugriff bekommen soll oder nicht. Dazu fragt der NAA den TNC Server, ob die Integrit/~tsmessungen des ARs mit der Security Policy fibereinstimmen. Nur wenn das der Fall ist, ist das zugreifende Rechnersystem vertrauenswfirdigo

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

103

Auf dem PDP stellen so genannte ,,Integrity Measurement Verifier" (IMV) das Gegenstiick zu den IMCs des AR dar. Auch hier existieren mehrere IMVs fOr die unterschiedlichen Sicherheitskomponenten. FOr jede zu fiberprfifende Sicherheitskomponente muss es, neben dem IMC, auch einen passenden IMV geben (siehe Abbildung 3)~ Sie vergleichen die fibermittelten Messwerte anhand der in den Policies festgelegten Regeln und teilen ihr Ergebnis dem TNC-Server im PDP mito Dieser trifft mit den Teilergebnissen eine Gesamtentscheidung fiber die Integrit~it des Rechnersystems und teilt diese Entscheidung dem Policy Enforcement Point t~ber die NAA mit. Der Policy Enforcement Point (PEP) ist das TNC-Element am Eintrittspunkt des Netzwerkes. Seine Aufgaben sind die Entgegennahme und Weiterleitung von Verbindungsanfragen sowie die AusfOhrung der Handlungsentscheidung des PDPs. Der PEP stellt als Eintrittspunkt den zuerst adressierenden Verbindungspunkt des Netzwerkes dar. Ankommende Verbindungsanfragen eines AR werden direkt an den PDP weitergeleitet. Nachdem ein PDP seine Entscheidung fiber die Vertrauenswfirdigkeit des AR getroffen hat, teilt er diese dem PEP mit, der gem~ig dieser Entscheidung den Zugriff auf das Netzwerk mit seinen Diensten gestatten oder verhindern muss. Ein PEP kann laut TNC-Spezifikation ein eigenst~indiges Rechnersystem sein oder in den PDP oder in anderes Netzwerk-Equipment integriert sein. So ist es m6glich, den PEP wahlweise direkt in ein VPNGateway zu integrieren oder, um vorhandene Netzwerkstrukturen unbert~hrt zu lassen, vor beziehungsweise hinter diesem Gateway.

3.3

Beispielkonfiguration

anhand

yon WLAN

Im Folgenden wird das TNC-Konzept anhand eines WLAN Beispiels etwas kor~reter dargestetlt.

f

...... ..... [

!

,Mcs

t:

I 802. lX Authenticator Abb. 4: WLAN-TNC-Beispiel

Abbildung 4 zeigt eine m6gliche Konfiguration eines mit TNC-Funktionen erweiterten und mit WPAEnterprise gesicherten WLANs. Da WPA-Enterprise EAP und 802olx nutzt, kann die TNC-Spezifikation in diesem Fall sehr einfach in die vorhandene WLAN-Struktur integriert werden.

104

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

Mit einem Notebook, linke Seite, wird ein Verbindungsaufbau zum WLAN initiiert, das heigt, dass das Notebook die Rolle des Access Requestor fibemimmt. Auf diesem Notebook ist ein 802. Ix-Supplicant installiert der um einen NAR erweitert wurde. Zus~itzlich existiert ein TNC-Client, der die erforderlichen IMCs, in diesem Beispiel far Virenscanner bzw. Desktopfirewall, anspricht. Der zur Zugriffssteuerung genutzte 802.1x Authenticator des WLAN Access Points (PEP) wurde um einen TNC-PEP erweitert. Dieser kommuniziert direkt mit der NAA, die in den Radiusserver des Authentication Server (PDP) implementiert wurde. Zus/~tzlich besitzt der Server einen TNC-Server und mehrere IMVs die jeweils Zugriff auf eine (oder mehrere) Policy haben. Durch die sehr allgemein gehaltene Spezifikation ist das oben gezeigte Beispiel nicht nur eines von vielen Einsatzgebieten, sondern auch nur eine m6gliche L6sung des konkreten WLAN-Problems. Eine andere M6glichkeit w/~re es den TNC-Client in den Supplicant und den TNC-Server in den Radiusserver zu integrieren.

3.4 A n w e n d u n g s f e l d e r Trusted Network Connect soll m6glichst flexibel bei vielen Anwendungen zum Einsatz kommen, weshalb die Spezifikation sehr allgemein gehalten ist. Zwischen den vielfNtigen Anwendungsfeldem stechen zwei klassische Einsatzgebiete heraus. Diese sind der Schutz des Firmennetzes und der direkte Schutz des Intranets, die jeweils in den nfichsten Abschnitten vorgestellt werden.

3.4.1 Schutz des Firmennetzes TNC soll den Schutz des Intranets vor Angriffen von augen erh6hen. Heimarbeiter und insbesondere Augendienstmitarbeiter, die sich in st/~ndig wechselnden Sicherheitsumfeldem aufhalten, wghlen sich heute, zwecks Datenzugriff, meist fiber VPNs in das eigene Firmennetz ein. Wurde ein Rechnersystem eines Aul3endienstmitarbeiters kompromittiert, so stellt ein Zugriff fiber das VPN eine Umgehung der Sicherheitsmagnahmen, beispielsweise einer Firewall, des Firmennetzes dar. Die Malware auf dem kompromittierten System erhNt Zugriff auf das Firmennetz und die darin angeschlossenen Rechnersysteme. Durch eine Erweiterung des VPN-Zugriffs mit TNC-Funktionalit/~t l~isst sich die Integrit/it der Rechnersysteme messen und damit die Vertrauenswfirdigkeit vor dem Zugriff auf das Netzwerk mit seinen Diensten feststellen, um diesen gegebenenfalls, also bei Nichterfallung der Sicherheitspolicy, zu unterbinden. Durch die Nutzung der Funktionen eines Trusted Platform Modules (TPM) ist es zus~itzlich m6glich, einen VPN-Zugang an bestimmte Rechnersysteme zu binden, um etwa einen Zugriff von aul3erhalb mit gestohlenen Zugangsdaten zu verhindem.

3.4.2 Direkter Schutz des Intranets Neben dem Einsatz nun Schutz vor Angriffen von augen l~isst sich TNC auch zum Schutz vor Angriffen yon innen einsetzen. Mit 802.1x unterstfitzt TNC eine verbreitete Methode zur Authentifizierung. Durch die Ausstattung aller Rechnersysteme im Intranet mit um TNC-Funktionen erweiterten 802. IxSupplicants, k6nnen Angriffe von innen pr~iventiv abgewendet werden. Zus~itzlich besteht die M6glichkeit Rechnersysteme von G/~sten zuverl~issig auf ihre Integrit/it zu prafen und somit m6gliche Gefahren durch firmenfremde Rechnersysteme zu minimieren.

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

105

3.4.3 Weitere Einsatzfelder Abgesehen von diesen klassischen Einsatzgebieten l~tsst sich TNC noch viel spezieller einsetzen. Aufgrund der offenen Spezifikation, lassen sich auch VPN-Gateways als Endpunkt ansehen. So wird eine sichere Anbindung yon Niederlassungen an ein Firmennetz mittels TNC-Mechanismen erm6glicht. Diensteanbieter im Internet, wie zum Beispiel Banken, erhalten die M6glichkeit, von ihren Kunden die Installation von aktuellen Virenscanner sowie einer Personal-Firewall zu verlangen. So wird verhindert, dass potentiell gef'~ihrdete Rechnersysteme auf die Dienste zugreifen und damit sich selbst und die angebotenen Dienste gef'~ihrden. Als Einschr~inkung far dieses Einsatzfeld muss bedacht werden, dass vorher entweder eine VPN-Verbindung zu den Servern etabliert sein muss (was technisch kein Problem darstellt und aus Sicht der Sicherheit nicht negativist), oder, neben VPN und 802. lx, eine weitere M6glichkeit von TNC-gesicherten Netzwerkverbindungen geschaffen werden muss.

4 Alternative Ans itze Neben TNC existieren weitere NAC-Ans~itze. Die prominentesten Vertreter sind Microsoft NAP und Cisco NAC die hier n~iher erl~iutert werden. Die alternativen L6sungen, auch die von Microsoft und Cisco, sind, im Gegensatz zur offenen TNC-Spezifikation, propriet~ir und vom Grundsatz her nicht interoperabel (n~iheres in Kapitel 5).

4.1 Microsoft NAP Microsoft entwickelt mit der ,,Microsoft Network Access Protection" (Microsoft NAP) eine eigene NAC-L6sung [Micr06a]. Microsoft NAP soll mit der auf Microsoft Vista aufbauenden Server-Version verfagbar werden. Client-Software wird sowohl far Vista als auch far Windows XP entwickelt. Die Steuerung des Netzwerkzugriffs erfolgt mittels vorhandener Technologien wie 802. l x und bietet unter anderem Untersttitzung far VPNs. Dadurch ist es weitestgehend hardwareunabh~ingig. Auf Softwareseite werden mit dem Network Policy Server (NPS) sowie der n6tigen Clients Softwareprodukte von Microsoft zwingend vorausgesetzt.

4.2 Cisco NAC Cisco Network Admission Control (Cisco NAC) ist Teil der ,,Self-Defending Network"-Strategie und geh6rt ebenfalls zu den Policy-basierten Zugriffssteuerungen [Cisc04]. Cisco setzt dabei komplett auf ihre eigene Hardware, d.h. dass im ganzen Netz spezielle NAC-f~ihige Hardware ben6tigt wird, was zu einer zwingenden Bindung an Cisco-Hardware fahrt. Cisco NAC ist bereits auf dem Markt verfagbar.

4.3 Weitere L6sungen Neben den drei ,,grol3en'~ vorgestellten LOsungen existieren viele weitere Ans~itze von Firmen wie zum Beispiel: ~ Check Point 9 Juniper Networks ~ StillSecure ~ Symantec ~ Vernier Networks

106

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

5 Kritische Betrachtung Im Folgenden werden einige Aspekte des TNC-Konzeptes kritisch diskutiert. Dazu geh6ren die Vertrauenswfirdigkeit der erfassten Messwerte, die Administration, die Sicherheit und insbesondere die Interoperabilitgt~

5.1 Vertrauensw irdigkeit der Messwerte Die Sicherheit von TNC ist abh~ingig von der Vertrauenswt~rdigkeit der Messwerte. Diese mt~ssen korrekt gemessen und unverf~ilscht an den TNC-Server fibermittelt werden. Bei heutigen Systemen gibt es zungchst keine M6glichkeit, die korrekte Messung des Systemzustands und dessen korrekte 121bertragung zu garantieren. Wurde die Hardware oder das Betriebssystem eines Rechnersystems kompromittiert, mfissen auch die Messwerte als nicht mehr vertrauenswfirdig angesehen werden, da diese durch die Malware jederzeit beeinflusst werden k6nnen. Da die Messwerte aber zur Entdeckung von fehlender Integrit~it genutzt werden sollen, entsteht durch die st~indige Gefahr der unbemerkten F~ilschung ein dauerhaftes Misstrauen gegent~ber den Messwerten. Dies wurde unlfingst auf der Black Hat Konferenz 2007 anhand von Cisco NAC vorgefahrt. Mittels eines modifizierten Cisco Trust Agent (CTA) war es jederzeit m6glich, unabh~ingig vom Rechnerzustand, Zugriff auf ein NACgeschfitztes Netzwerk zu erlangen [Heis07]. Um dieses Paradoxon zum umgehen, bietet TNC durch seine optionale und direkte Unterstfitzung des Trusted Platform Moduls (TPM) einen gewissen Schutz vor Manipulation der Hardware sowie die M6glichkeit der Signierung und somit Absicherung der 121bertragung der Messwerte. Ohne eine vertrauenswfirdige Ermittlung der Messewerte ist die durch den TPM-Einsatz erreichte Sicherheit aber immer noch begrenzt. Erst mit Einffihmng von geeigneten Sicherheitsplattformen, wie zum Beispiel der Turaya Sicherheitsplattform des EMSCB Projektes [Emsc07], lassen sich auch die Messwerte aller Sicherheitskomponenten vertrauenswftrdig ermitteln. Dieses Problem stellt aber kein spezifisches Problem von NAC-Ans~itzen dar, sondem ein Gesamtproblem heutiger Rechnersysteme, das durch die zuldinftige Nutzung von Sicherheitsplattformen, die auf Trusted Computing aufbauen, gel6st werden kann.

5.2 Administration Neben der Problematik der vertrauenswfirdigen Messdatenerfassung und -fibermittlung verursachen Policy-basierte Ans~itze einen erh6hten Administrationsaufwand bei der Planung als auch w~thrend des Betriebs eines Netzwerks. Dies gilt besonders in heterogenen Netzwerken. So mftssen ffir alle im Netz befindlichen Endpunkte Zugriffsregeln f'ttr jede erdenkliche Konfiguration definiert werden. Zus~itzlich besteht die Gefahr, dass zu enge Regeln weitere Nebeneffekte erzeugen. Schreiben zwei Firmen nicht nur allgemein, also herstellerunabh~ingig, einen Virenscanner vor, sondern verlangen spezielle Virenscanner unterschiedlicher Hersteller, so ffthrt dies unter Umst~inden auf dem Notebook eines Mitarbeiters, der in beiden Firmen t~itig ist, zu Inkompatibilit~iten. Ein weiterer wichtiger Punkt ist das Thema Patch-Management. Es muss gekl~irt werden, wie die Daten der Policies optimal aktuell gehalten werden. So muss zum Beispiel jederzeit bekannt sein, welche Versionsnummer die aktuelle Virensignatur eines Virenscanners hat, ob die eingesetzte Personal-Firewall aktuell (das heif3t frei von bekannten Sicherheitslficken) ist und welchen Stand die Patch-Datenbank des

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen

107

eingesetzten Betriebssystem und der verwendeten Anwendungen hat. Diese Informationen mfissen von den Herstellern der einzelnen Komponenten bereitgestellt und an den Netzbetreiber fibermittelt werden. Ein Netzbetreiber ist somit nicht nur beim Aufbau des Netzes auf die Hersteller, die ihre Software mit IMC und IMV-Funktionen ausstatten m~ssen, angewiesen, sondern auch w~ihrend des Betriebes. Hier mtissen neue Formen der Zusammenarbeit gefunden und vertragliche Aspekte zur Haftung gekl~irt werden. Es muss klargestellt werden wie man die einzuspielenden Patches bezieht und installiert. M6glich wgre ein zentraler Patch-Server innerhalb der Firma oder ein Bezug direkt von den Herstellern. Ein zentraler Patch-Server minimiert auf der einen Seite den Datenverkehr zum Internet. Auf der anderen Seite stellt es sich als schwierig dar, s~imtliche Patches immer aktuell verfagbar zu halten, in der Praxis w~ire deshalb eine Kombination beider M6glichkeiten optimal. Besonders in wechselnden Umgebungen sind weitere Probleme denkbaro Schreibt eine Organisation aus Grfinden der Kompatibilit~it (mit anderen Programmen) eine veraltete Version einer Software vor und eine andere Organisation eine neuere Version, so kOnnen nicht beide Policies erfallt werden. Ein st~indiges Up- und Downgrade der Versionen ist entweder vom Aufwand her nicht vertretbar, oder schlichtweg nicht m6glich.

5.3 Sicherheit Ein weiteres ,,Problem" aller NAC-Ans~itze ist die netzabh~ingige Sicherheit. Das heigt, dass zwar eine Messung m6glich ist, aber kein Vergleich der ermittelten Daten mit den Policies. Wird ein offline betriebenes Rechnersystem t~ber lgngere Zeit nicht mit Updates gepflegt, steigt die Gefahr einer Kompromittierung wieder. Dies fahrt dann ebenfalls zu einer Gefiihrdung der zuvor aus dem Netzwerk kopierten Daten. Erst mit einem erneuten Aufbau zu einem mit NAC gesicherten Netzwerk werden diese Schwachstellen erkannt. Dieser Aspekt ist aber kein Schwachpunkt der NAC-Ans~ttze sondern soll durch andere Sicherheitsmechanismen, wie zum Beispiel Enterprise Rights Management Systeme, gel6st werden. Grund hierfar ist, das NAC zuallererst ein Netzwerk mit seinen angeschlossenen Rechnersystemen und angebotenen Diensten schfitzen soll.

5.4 Interoperabilit~it und Standardisierung Trotz ~ihnlicher Strukturen und zumeist gemeinsam genutzter Basistechnologien sind alle auf dem Markt und in der Entwicklung befindlichen NAC L6sungen zumeist propriet~ir und nicht kompatibel zueinander. Dieser Punkt stellt sich als Hemmnis far die Verbreitung dieser L6sungen dar, da Firmen die sich heute far eine auf dem Markt befindliche L6sung entscheiden keine Sicherheit haben, dass die gew~ihlte L6sung sich auf dem Markt behaupten wird. Durch die Wahl von L6sungen marktbeherrschender Hersteller besteht deswegen eine besonders grol3e Gefahr der Bildung von De-facto-Standards, die andere Mitbewerber aus dem Markt dr~ingen. Des Weiteren besteht far Rechnersysteme die in h~iufig wechselnden Umgebungen eingesetzt werden, beispielsweise von Aul3endienstmitarbeitern, ein zus~itzlicher Aufwand. Diese Ger~ite m%sen Far alle erdenklichen L6sungen vorbereitet sein. Seit Mitte 2006 bestehen mehrere, unterschiedliche Bestrebungen die Interoperabilitgt verschiedener L6sungen zu gew~ihrleisten. Diese Bestrebungen werden im Folgenden kurz erlgutert und diskutiert:

108

Trusted Network Connect- Vertrauenswfirdige Netzwerkverbindungen 9 Cisco und Microsoft haben im September 2006 die Unterst~itzung der jeweils anderen L6sung angekfindigt [Micr06b]. Hinter dieser Ankfindigung verbirgt sich keine direkte Anpassung der Architekturen sondern haupts~ichlich eine Unterstfitzung beider Technologien auf Client-Seite. Das heif3t, dass die Clients beider Hersteller sowohl Netzwerke mit Cisco NAC als auch mit Microsoft NAP unterstfitzen~ Auf Netzwerk-Seite mfissen sich die Netzbetreiber weiterhin fttr eine der L6sungen entscheiden. 9 Verschiedene Hersteller von NAC-Produkten (Anm.: nicht Cisco NAC) gestalten ihre Produkte zu mehreren L6sungen kompatibel (Beispiel: Complete NAC von StillSecure). Hier findet zumeist eine Konzentration auf die drei ,,grol3en" LOsungen Cisco NAC, Microsoft NAP und TNC statt. Dies bedeutet mr L6sungen anderer Hersteller ein Wettbewerbsnachteil. 9 Microsoft hat sein Statement of Health-Protokoll (Soil) der Trusted Computing Group zur Verf'tigung gestellt. Diese hat Soil als zus~itzliche Schnittstelle (IF-TNCCS-SOH) zwischen dem TNC-Client und dem TNC-Server spezifiziert [Trus07a] [Trus07b]. Dieser Schritt bietet zuallererst den TNC=geschfitzten Netzwerken, die die Neue Schnittstelle unters~tzen, den Vorteil, dass als Client seitens des AR die bei Windows Vista/Longhorn Server mitgelieferten NAP-Clients genutzt werden k6nnen. Auf der anderen Seite bleibt abzuwarten, inwieweit sich beide Schnittstellen gemeinsam Administrieren lasseno Sollte der Administrationsaufwand stark steigen, so werden wahrscheinlich beide Schnittstellen nicht koexistieren k6nnen. Zus~itzlich finden sich bisher keine Aussagen dartiber, wie neue Versionen des SoH-Protokolls entwickelt werden (das heil3t ob gemeinsam mit anderen Anbietern oder alleine von Microsoft) und ob diese Protokolle als offene Spezifikation ver6ffentlicht werdeno ~ Die zurzeit einzige Bestrebung einer Standardisierung im NAC-Sektor findet durch die IETF mit der ,,Network Endpoint Assessment Working Group" statt. Anfang Mai 2007 erschien die zweite Version des ,,Overview and Requirements"-Papers [Ietf2007] ffir das ,,Network Endpoint Assessment" (NEA) in dem unter anderem zur Begriffsbildung ein auf TNC, Cisco NAC und Microsoft NAP basierendes Referenzmodell beschrieben wird. Mitglieder dieser Arbeitsgruppe sind unter anderem Cisco und Symantec.

6 Fazit Im Zuge der immer st~irkeren Vernetzung innerhalb und zwischen Firmen fiber unsichere Netzwerke ist eine Erh6hung der Vertrauenswttrdigkeit von Netzwerkkommunikation unabdingbar. NAC-L6sungen wie die TNC-Spezifikation der Trusted Computing Group bieten die M6glichkeit, Endpunkte auf deren Integrit~it zu untersuchen, und tragen somit zu einer Erh6hung der Vertrauenswtirdigkeit bei. Im Gegensatz zu anderen, propriet~iren L6sungsans~itzen besitzt TNC durch seine Offenheit einen grogen Vorteil. Durch die Offenheit ist TNC weder an die Hard- noch an die Software bestimmter Hersteller gebunden. Dies erm6glicht eine Akzeptanz und Adaption durch alle Hersteller von Systemkomponenten und Netzwerktechnologie, was einen wichtigen Faktor far den Erfolg darstellt. Es ist aber zu beachten, dass bei allen Ans~itzen ohne den Einsatz sicherer Betriebssystemstrukturen die Vertrauenswttrdigkeit der Komponenten nicht ausreichend gew~ihrleistet wird und somit der momentan zu erreichende Grad an Vertrauenswfirdigkeit begrenzt ist. Da TNC weder spezielle Hardware, wie TPMs, noch spezielle Betriebssystemstrukturen voraussetzt und zudem vorhandene Netzinfrastrukturen unterstt~tzt (bzw. darauf aufbaut), lgsst es sich schon heute sehr gut in vorhandene Netzwerke integrieren.

Trusted Network C o n n e c t - Vertrauenswfirdige Netzwerkverbindungen

109

Literatur [Cisc04] [Emsc07] [Heis07] [Hart05] [Ietf07] [JuPo06] [Micr06a] [Micr06b] [Micr06b] [Trus06] [Tru+06] [Trus07a] [Trus07b]

Cisco Systems GmbH, Die Evolution des Self-Defending Network, 2004 http://www.cisco.com/global/AT/pdfs/prospekte/Securtiy_CNAC_032004.pdf Das EMSCB-Projekt, www.emscb.de News: Ciscos Netzwerkzugangskontrolle NAC ausgetrickst- M~irz 2007 http://www.heise.de/ newsticker/meldung/mail/87663 Michael Hartmann, Trusted Network Connect- Netzwerkhygiene auf hohem Niveau, 2005, Datenschutz und Datensicherheit (DUD) Network Endpoint Assessment (NEA): Overview and Requirements, Mai 2007 http://www.ietf.org/ internet-drafts/draft-ietf-nea-requirements-02.txt M. Jungbauer, N. Pohlmann: ,,VertrauenswOrdige Netzwerkverbindungen mit Trusted Computing- Sichef vernetzt?" IT-Sicherheit - Management und Praxis, DATAKONTEXT-Fachverlag, 6/2006 Microsoft Corporation, Network Access Protection- Homepage 2006 http://www.microsoft.com/ technet/network/nap/default.mspx Microsoft Corporation, NAP-Whitepaper, 2006 http://www.microsoft.com/technet/network/nap /naparch.mspx Microsoft Corporation, Cisco and Microsoft Unveil Joint Architecture for NAC-NAP Interoperability, 2006 http://www.micr•s•ft.c•m/presspass/press/2••6/sep•6/•9-•6SecStandardNACNAPPR.mspx Trusted Computing Group: Trusted Network connect Subgroup, 2006 https ://www.trustedcomputing group, org/groups/network Trusted Computing Group, TCG Trusted Network Connect TNC Architecture for Interoperability, 2006 https://www.trustedcomputinggroup.org/specs/TNC/TNC_Architecture_vl 2 r4.pdf Microsoft and Trusted Computing Group Announce Interoperability, Mai 2007 https://www.trustedc•mputinggr•up.•rg/news/press/TNC-NAP-inter•p-re•ease-•na•-may18.pdf TCG TNC IF-TNCCS: Protocol Bindings for Soil, Mai 2007 https://www.trustedcomputinggroup.org/ spec s/TNC/IF-TNC CS- SOH_v 1.0_r8.pdf

Interaktionen TPM und Smart Card Florian Gawlas 9 Gisela M e i s t e r - A x e l Heider Sebastian Wallner Giesecke & Devrient GmbH, Prinzregentenstral3e 159, 81677 Mt~nchen {florian.gawlas ] gisela.meister I axel.heider[ sebastian.wallner }@gi-de.com

Zusammenfassung Trusted Platform Module (TPM) entsprechend dem Industriestandard der Trusted Computing Group (TCG) ~ihneln von ihrer Funktionalitfit einer Smart Card. Doch w~ihrend eine Smart Card als Plastikkarte mit Chip oder als Token transportabel ist, wird das TPM fest in ein Ger~it (z.B. Mainboard des PCs) oder einen anderen Hardwarebaustein integriert. Ziel der vonder TCG entwickelten Konzepte ist es, den Schutz der Integritfit der Ger~ite in einer zunehmend vernetzten Welt zu gew~ihrleisten. Die bestehenden Anwendungen zum TPM zeigen, dass neben den gerfitebezogenen auch personenbezogene Daten vom TPM verwaltet werden. Dies hat mr den Anwender hinsichtlich der Benutzerfreundlichkeit sowie der Datensicherheit Nachteile. In diesem Kapitel stellen wir Ans~itze zur geeigneten Einbindung von personenbezogenen Smart Cards in die TCG-Konzepte vor.

1 Trusted Computing heute Das TPM als zentraler Baustein der TCG (siehe [Trus07]) gewinnt weiter zunehmend an Bedeumng. Schon heute z~ihlt die TCG mehr als 100 Mitgliedsfirmen. In neue Laptops werden TPMs standardm~igig integriert. Auch in vielen Desktoprechnem sind TPMs mittlerweile verfiigbar. Der Verbreimng an TPMs steht aber immer noch ein Mangel an Anwendungen und Betriebssystemen gegent~ber, welche die M6glichkeiten des TPMs ausreichend nutzen k6nnen. Des Weiteren sehen viele Menschen im TPM eher eine Bedrohung, da der Entzug der Kontrolle fiber den eigenen PC und die eigenen Daten befarchtet wird. Ein wichtiger Schritt fttr mehr Vertrauen in TCG-Anwendungen k6nnte die Trennung von personenbezogenen oder hoch-kritischen Daten vom Gergt (also vom TPM) und eine st~irkere Bindung der Daten an die entsprechende Person sein. Hierzu bieten sich vor allem Smart Cards an. Smart Cards sind eine bew~ihrte Technologie, die den allerh6chsten Sicherheitsanforderungen gent~gt und auch deshalb ein entsprechendes Vertrauen bei Benutzern geniel3t. Diese Empfehlung hat auch die Deutsche Bundesregierung bereits 2003 in einer Stellungnahme geguBert [Bund07]:

,,Insofern das Sicherheitsmodul (TPM) fest mit der restlichen Hardware des IT-Systems (z.B. PC) verbunden ist, sollte sich die Funktionalit~it des Sicherheitsmoduls darauf beschr~inken, die Sicherheit und Integritdt der Plattform zu gewgihrleisten. Die Nutzung von personalisierten Programmen, Daten und Onlinedienstleistungen sollte wenn nOtig nicht an das Sicherheitsmodul (TPM) gebunden werden, sondern an eine personalisierte N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 110-121

Interaktionen TPM und Smart Card

111

Smart-Card. Damit liefle sich der anwenderbezogene Zugriff auf Daten flexibler gestalten und Migrationsprobleme wiirden deutlich reduzierto " Das Vertrauen in die Sicherheit von Smart Cards wird unter anderem durch die mittlerweile fiblich gewordenen Common Criteria (ISO 15408) Evaluierungen entsprechend der Stufe EAL 4 mit hoher Mechanismenst~irke (SOF-hoch) gewonnen, wobei man die Vertrauensw~rdigkeitsklassen um eine Analyse far Angriffe mit hohem Angriffspotential erweitert. Smart Cards sind unter alleiniger Kontrolle eines Benutzers und sind somit aus Sicht des Datenschutzes zur Speicherung personenbezogener Daten unbedenklicher als andere Technologien wie etwa das TPM, das auch von mehreren Anwendern genutzt werden kann. 9 Die Daten auf einer Smart Card k6nnen vom Benutzer unwiederbringlich physikalisch zerst6rt werden, beispielsweise durch Zerschneiden mit einer Schere. Um ein TPM auf dem Motherboard im Inneren eines Ger~its ausfindig zu machen, braucht man schon mehr Kenntnisse der Elektronik. Es gibt zwar einen TPM-Befehl zum L6schen aller Inhalte; dieser l~isst sich aber an einem defekten Ger~it na~rlich nicht mehr ausfahren. 9 Smart Cards erlauben es, dem Benutzer seine Geheimnisse (z.B. Schlfissel, Passw6rter) nicht nur an einem bestimmten Ger~it sondern an vielen Ger~iten zu nutzen, w~thrend sich der Datentransport bei TPM basierten Systemen technisch anspruchsvoll gestaltet. 9 Die Zugangsbeschr~inkungen des TPMs basieren heute weitgehend allein auf Wissen, w~ihrend die Zugangsbeschrgnkung bei Smart Cards aus Besitz und Wissen oder Besitz und biometrischem Merkmal bestehen k6nnen, und damit eine h6here Sicherheit bieten (siehe auch [Meis04]). 9 Nach Auslieferung des TPM-gesicherten Ger~its oder einer Smart Card sind Korrekturen am ausfahrbaren Chipcode in der Regel nicht mehr m6glich. Treten nachtr~iglich Sicherheitslficken am TPM auf, ist ein Austausch des TPMs nicht m6glich, ohne dabei das gesamte Ger~it austauschen zu m~ssen. Smart Cards k6nnen dahingegen mit wesentlich geringerem Aufwand ausgetauscht werden. 9 W~ihrend TPMs eine Anwendungsschnittstelle far Applikationen bieten, die aul3erhalb des TPMs betrieben werden, enth~ilt die Smart Card neben dem Betriebssystem auch die Applikation. Die Anforderungen an die Smart Card hinsichtlich Funktionalit~it und Sicherheit k6nnen somit speziell auf die Anwendung zugeschnitten werden. Die Anforderungen an spezielle Anwendungen (z.B. auch die in Europa rechtsgt~ltige qualifizierte elektronische Signatur) ist mit einer extern gehaltenen Anwendung nicht vereinbar. Es zeigt sich, dass das TPM im Rahmen der PC-Sicherheit die Smart Card keinesfalls ersetzen kann. Andererseits ist auch die Smart Card nicht in gleichem Mal3e geeignet die Integrit~it des Ger~its zu gew~ihrleisten. Die Herausforderung liegt also eher in der geeigneten Kombination yon Smart Card und TPM-Technologie um ein Maximum an Benutzerfreundlichkeit und Datensicherheit zu gew~ihrleisten. Kombinierte L6sungen sollten auch helfen die Akzeptanz neuer Sicherheitstechnologien zu erh6hen.

2 Gesamtl6sungen Erste GesamtlOsungen bestehen bereits. Beispielsweise werden Smart Cards zur Benutzerautorisierung eingebunden. In dieser L6sung werden Schw~ichen des allein TPM-basierten Systems durch die Nutzung von speziellen Eigenschaften der Smart-Card-Technologie verbessert. Eine solche Anwendung ist also ein gutes Beispiel far eine gelungene Gesamtl6sung. Man gelangt zu unterschiedlichen L6sungen, je nachdem ob man nach Verbesserungsvorschl~igen far TPM-Anwendungen oder nach einer besseren

112

Interaktionen TPM und Smart Card

Anbindung bereits bestehender Smart-Card-Infrastrukturen sucht. Beide Aspekte werden im Folgenden n~iher diskutiert.

2.1 Gesamtl6sungen aus Sicht des TPMs Der am weitesten erprobte Ansatz zur Verbesserung des TCG-Konzepts unter Einbeziehung der Smart Card, ist das Konzept der Benutzerautorisierung ([GaMe05],[Patr03]).

2.1.1 Passw6rter Nach der TCG Spezifikation 1.2 bestehen die Autorisierungsdaten aus einem 20 Byte langen, m6glichst zuf'~illigen Wert. Die Benutzerschnittstelle des TPMs (Teil des TCG Software Stacks - TSS) bietet verschiedene Protokolle zur Generierung, Anderung oder zum Nachweis der Autorisierungsdaten an. Ein Beispiel ist das OSAP-Protokoll. Im OSAP-Protokoll wird zun~ichst ein Sitzungsschlfissel ausgehandelt. Der Sitzungsschlfissel wird aus einer HMAC-Berechnung fiber die Autorisierungsdaten und jeweils einer Zufallszahl des TPMs und einer Zufallszahl des Benutzers erzeugt. Der Sitzungsschlfissel wird anschliel3end benutzt, um einen Autorisierungsblock wieder mit Hilfe eines HMACs fiber Kommandodaten der TPM-Befehle zu berechnen. Das TPM hat damit die M6glichkeit, die Zugriffsberechtigung des Benutzers far bestimmte Objekte zu prCtfen. Das Problem an den meisten Implementierungen dieses Autorisierungsverfahrens, liegt an der Verwendung von einfachen Passwortmechanismen zur Eingabe der Autorisierungsdaten: 9 20 Byte lange, rein zuf'~illige Passw6rter sind zu lang, um sie sich zu merken. Der Benutzer wird sich die Passw6rter aufschreiben und untergr~ibt damit die Sicherheit des Systems. 9 Wer sich Passw6rter nicht aufschreiben will, wird in der Regel keine rein zufNligen Zeichenfolgen als Passwort w~ihlen und ist damit eher anfNlig gegen W6rterbuchangriffe. 9 Wenn ein Passwort ausgesp~iht wurde, erlaubt es dem Angreifer den direkten Zugriff auf die jeweiligen Daten. Eine zus~itzliche Hfirde, z.B. die Inbesitznahme eines pers6nlichen Tokens, ist bei einem TPM-gesicherten PC in dieser Variante nicht gegeben. 9 Heute verwenden verschiedene TSS-Implementierungen noch unterschiedliche Mechanismen, um aus einen Benutzer-Passwort ein 20 Byte langes Passwort zu erzeugen. Daher ist es unter Umst~tnden mit bestehenden Systemen nicht m6glich, auf ein Objekt zuzugreifen, wenn eine andere Software oder gar ein anderes Betriebssystem verwendet wird. Um das Passwort zu verkfirzen, aber die Sicherheit nicht zu reduzieren, kann man eine Smart Card in das Konzept integrieren. Die Sicherheit von Smart Cards basiert auf Wissen und Besitz. Zus~itzlich erlauben Smart Cards Zugangskontrollen mit einem Fehlbedienungsz~ihler, der bei mehrmaliger Falscheingabe der PIN den Zugangsmechanismus sperrt. Fttr TPMs ist ein solcher Fehlbedienungszghler schwerer umsetzbar, weil der Verwaltungsaufwand f'tir Ger~ite mit blockierten TPMs wesentlich schwerer zu handhaben ist, als far blockierte Smart Cards. Entsprechende Mechanismen k6nnen nur in Software, beispielsweise im TSS, implementiert werden. Die TPM Spezifikationen definieren zwar, dass ein TPM beispielsweise W6rterbuchangriffe erkennen soll, lassen jedoch often, wie dies genau umgesetzt werden soll. Durch Einbindung der Smart Card l~isst sich der Wissensanteil auf eine vier- bis sechsstellige zufgllige numerische PIN verkfirzen. Die angestrebte Gesamtl6sung kann sich wie folgt darstellen: ~ Die 20 Byte langen Autorisierungsdaten werden auf der Smart Card generiert. Diese stellt sicher, dass auch tats~ichlich 20 zufNlige Byte verwendet werden und nicht nur Buchstaben oder Zahlen.

Interaktionen TPM und Smart Card

113

9 Die Smart Card und das TPM handeln zu Beginn einer Sitzung einen Sitzungsschl%sel aus. Die dazu verwendete Zufallszahl des Benutzers wird vonder Smart Card mit einem Zufallszahlengenerator erzeugt. 9 Die PC Applikation sendet zungchst TPM-Befehle zur Smart Card, die anschliegend mit Hilfe des Sitzungsschl~ssels einen Autorisierungsblock berechnet, und diesen an die PC-Applikation zurfick schickto 9 Die PC-Applikation schickt den Autorisiemngsblock inklusive dem TPM Befehl ans TPMo 9 Das TPM verifiziert mit Hilfe seines Sitzungsschlfissels den Autorisierungsblock und erlaubt bei erfolgreicher P~fung den Zugriff auf das entsprechende Objekt. Eine solche Smart Card / TPM L6sung bietet eine verbesserte Benutzerfreundlichkeit, weil sie den Wissensanteil stark reduziert und gleichzeitig den Schutz der vom TPM verwalteten Daten durch eine verbesserte Zugangskontrolle u.a. durch den zus~itzlich ben6tigten Besitz erhOhto

2.1.2 Bootprozess Auch hinsichtlich des authentisch gemessenen Bootprozesses k6nnen Smart Cards das bestehende TCG Konzept unterstfitzen. Beim Booten eines Gergts werden nach dem Konzept der TCG Integrit~itsmessungen der Reihe nach fiber das BIOS, die Laderoutine des Betriebssystems, das Betriebssystem und andere Komponenten gerechnet. Das TPM stellt sichere Speicherzellen (Plattform Configuration Register oder kurz PCR) zur Speicherung zur Verfagung. Ein extemer Server kann sich dann nach Bedarf die Inhalte der PCRs vom TPM signiert schicken lassen, um sich ein Bild vom Zustand des TPM gesicherten Systems zum Zeitpunkt des Bootens zu machen. Vireninfizierte Rechner k6nnen so beispielsweise von einem zentralen Server schnell innerhalb eines Firmennetzwerks identifiziert werden. Sind Rechner allerdings nicht vernetzt, bleiben diese Messungen im Allgemeinen ungenutzt, weil die TCG dem TPM eine rein passive Rolle zugeordnet hat. Das TPM misst, tiberl~isst aber die Bewertung der Messungen in der Regel anderen. Das TPM spem also beispielsweise nicht den Zugang zu einem mit Viren infizierten Rechner, es verhindert nur die Nutzung gewisser Schlfissel, die an einen bestimmten Zustand gebunden sind. Der Boot-Vorgang der TCG ist damit nicht zu verwechseln mit einem sicheren Boot-Vorgang, bei dem zwangslgufig in einen sicheren Zustand gebootet wird. Smart Cards k6nnen aber far den Benutzer die Rolle der 12Iberprafung der Integrit~itsmessungen fibernehmen. Hierzu ist folgendes Konzept denkbar (siehe auch Abb.1): 9 Die PC-Anwendung erfragt die signierten PCR Inhalte vom TPM. 9 Die PC-Anwendung schickt die signierten PCR-Inhalte zur ()berprfifung an die Smart Card. 9 Die Smart Card vergleicht die Werte mit entsprechenden auf der Smart Card gespeicherten Referenzwerten ~. 9 Das Ergebnis der Uberprfifung wird an den Benutzer (z.B. in Form einer geheimen Nachricht auf dem Bildschirm) weitergeben. Dariiber hinaus werden erst nach erfolgreicher Uberprfifung gewisse Funktionen auf der Smart Card freigeschaltet. Auch im Fall vemetzter Rechner kann die Smart Card eine wichtige Rolle spielen. Beispielsweise, wenn die Nachricht fiber den Integrit~itszustand eines Rechners anonymisiert an einen Server weitergeben werden soll. Die Smart Card teilt einem entfemten Server nur noch mit, dass sich eine Plattform 1 Eine Verwaltungder Referenz-PCR-Werteauf der Smart Card hinsichtlich Software~inderungenauf dem Ger~ithat durch den Administrator zu erfolgen,

114

Interaktionen TPM und Smart Card

in einem vertrauenswttrdigen Zustand befindet, nicht aber, wie dieser genau aussieht. Der Server kann somit keine direkten Rfickschlfisse ziehen, welche Software auf der Plattform l~iuft. PC Server PCR Contents

Smart Card

Result

Abb. 1: Konzept Integrit~itsmessung Auch in dieser Anwendung bietet die Einbindung der Smart Card eine Erweiterung des TCG Konzepts hinsichtlich Datensicherheit und Datenschutz. Ein Rechner mit TPM und Smart Card bietet die M6glichkeit, vor der Eingabe von Passw6rtern etwas fiber den Integrit~itszustand des PCs zu erfahren. Der Anwender kann selbst entscheiden, wie er auf m6gliche Integrit~itsverletza.mgen reagieren m6chte. Aul3erdem k6nnen Konfigurationsdaten des Ger~its vor dem Server verborgen werden, ohne dem Server den Integrit~itszustand der Ger~ite Software vorzuenthalten.

2.1.3 Authentizit~itspr~ifu ngen Jedes TPM wird in der Produktion mit einem RSA-Schlfisselpaar ausgestattet, den man Endorsement Key (EK) nennt. Der 6ffentliche Schlfissel wird von einer Zertifizierungsinstanz zertifiziert und kann anschliel3end aus dem TPM exportiert werden. Die Verwendung des privaten EKs durch das TPM z.B. zur Erstellung von Signamren wfirde es einer externen Instanz erlauben, Nachrichten einem bestimmten Ger~it zuzuordnen. Dies ist aus Datenschutzgrfinden nicht gewollt. Die TCG-Konzepte sehen deshalb vor, dass das TPM zus~itzliche Schlfisselpaare generiert, sogenannte Attestation Identity Keys (AIKs), die als Pseudonyme des EKs eines TPMs verwendet werden. Damit eine dritte Instanz einer AIK-Signatur vertrauen kann, braucht sie eine Beglaubigung des zugeh6rigen 6ffentlichen Schltissels. Solche Zertifikate werden v o n d e r Zertifizierungsinstanz erstellt, nachdem die AIKs signiert mit dem EK an die Zertifizierungsinstanz fibertragen werden. Die Zertifizierungsinstanz, die den 6ffentlichen EK vertrauenswfirdig bekommen und sicher gespeichert hat, kann entsprechend die Signatur fiber die AIKs verifiziereno Dieses Konzept basiert auf grol3em Vertrauen in die Verffigbarkeit und die Sicherheit der Zertifizierungsinstanz und ist deshalb auch innerhalb der TCG umstritten. Als Alternative wurde von der TCG, basierend auf Zero-Knowledge-Protokollen ein Verfahren aufgenommen, das auch ohne eine zentrale Zertifizierungsinstanz auskommt und unter dem Begriff Direct Anonymous Attestation (DAA) bekannt ist (siehe [Bric04]).

Interaktionen TPM und Smart Card

115

Altemativ zu dem DAA-Verfahren kann aber auch eine Smart Card eingesetzt werden, um die Schw~ichen einer zentralen, jederzeit verfagbaren Verwaltung yon Zertifikaten zu umgehen (siehe [He06]). Hierbei wird eine Smart Card vonder Zertifizierungsinstanz herausgegeben, welche die Rolle der Zertifizierungsinstanz beim Zertifizieren der AIKs fibemimmto AIKs werden vom TPM erzeugt, mit dem EK signiert an die Smart Card geschickt, welche die Signatur prfift und bei positivem Ergebnis ein Zertifikat fiber den AIK ausstellt. Mit einer geeigneten Schlt~sselverwalmng k6nnen die Spuren der Smart Cards verwischt werden. Das Ergebnis sind zertifizierte AIKs, die selbst von der Zertifizierungsinstanz nicht mehr einem bestimmten TPM zugeordnet werden k6nnen und eine Zertifikatsinfrastukmr, die keinen zentralen, jederzeit verfagbaren Server ben6tigt.

2.1.4 Schl~isselspeicherung und Kontrolle Die Spezifikation des TPMs sieht nicht vor, dass Schlt~ssel im TPM selbst gespeichert werden (mit Ausnahme des EK und des Storage Root Keys (SRK)). Die Speicherung von Schlfisseln erfolgt verschlfisselt in sogenannten Schlfisselblobs auf extemen Speichermedien. Der Schlfissel zum Ver- und Entschlfisseln des Schl%selblobs ist entweder der SRK selbst oder ein Schlfissel, der selbst wieder in einem Schl~isselblob gespeichert wurde. Wird ein Schlfissel im TPM ben6tigt, mfissen die ben6tigten Schlt~sselblobs ins TPM geladen werden. Auf extemen Speichermedien besteht jedoch kaum Kontrolle fiber die Blobs, so dass sie beliebig vervielf'~iltigt werden k6nnen. Dabei ist zwar der verschlfisselte Schlfissel innerhalb des Blobs vertrauenswfirdig gespeichert, aber ein Schlfisselblob kann in den Besitz Dritter kommen. Problematisch wird dies, wenn die Nutzungsberechtigungen far einen Schlfisselblob ge~indert oder sogar das Passwort fttr die Nutzung des Schlfissels bekannt wird. In jedem Fall wird dann vom TPM ein neuer Schlfisselblob erzeugt. Das TPM selber kann jedoch nicht verhindem, dass der alte Schlfisselblob mit dem alten Passwort bzw. den alten Berechtigungen weiter genutzt wird. Dies muss durch das Betriebssystem, den TSS oder eine andere Instanz gew~ihrleistet werden. Erfolgt die Speicherung der Schlfisselblobs auf einer Smart Card (die handelsfiblich fiber 64 K-Byte verfagt), so hat diese die volle Kontrolle fiber den Schlfisselblob und kann sicherstellen, dass jeweils nur eine aktuelle Version des Schlfisselblobs existiert (siehe [He06])~ Unter der Vorraussetzung, dass zwischen Smart Card und TPM ein sicherer Kanal aufgebaut werden kann, sollte die Kommunikation zwischen Smart Card und TPM zus~itzlich verschlftsselt erfolgen um ein Aussp~ihen beim Ein- oder Auslesen von Schlfisselblobs zu verhindem. Auch beim Konzept der Schl%selmigration von einem TPM auf ein anderes Ger~it kann die Smart Card nfitzliche Dienste leisten. Unter Einbindung der Smart Card liege sich der in den TCG-Konzepten bestehende Migrationsprozess feiner steuern: Die Migration kann damit in mehrere Arten aufgeteilt werden, beispielsweise: 9 121bertragung eines Schlfisselblobs von einem TPM auf ein anderes wobei der Schlfissel danach nicht mehr mit dem alten TPM nutzbar ist. Die Smart Card stellt die Echtheit des Ziel-TPMs durch Prfifung von dessen Zertifikat(en) sicher. ~ 12rbertragungdes Schlfisselblobs an eine Instanz, die kein TPM ist, jedoch im jeweiligen Szenario trotzdem ein Migrationsziel sein kann. ~ Kopie des Schlfisselblobs, damit er mit beiden TPMs bzw. von verschiedenen Instanzen genutzt werden kann~ 9 Migration des Schlfissels auf die Smart Card 9 Backup des Schl%sels, so dass eine Freigabe erfolgen kann, falls das TPM zerst6rt wurde.

116

Interaktionen TPM und Smart Card

In allen Fgllen fibernimmt die Smart Card die Rechteverwaltung. Dies hat den Vorteil, das in den TPMProtokollen keine generische Rechteverwaltung flit alle denkbaren Anwendungsszenarien n6tig ist, denn diese kann sehr komplex und somit schwer fiberschaubar werden. Die Smart Card hingegen muss nur solche Verwaltungen implementieren, die far das jeweilige Szenario benOtigt werden~ Spfitere Erweiterungen sind dann ggf. durch Austausch der Smart Card m6glich, wobei die hierbei verwendeten Prozesse dann nicht mehr an das TPM gebunden sind, sondern von den Betreibern des jeweiligen Systems bestimmt werden.

2.2 Gesamtl6sungen aus Sicht der Smart Card Aus Sicht der bestehenden Smart-Card-Anwendungen wgre es sinnvoll, eine Kompatibilit~it zwischen den bisher unterschiedlichen Konzepten der TCG und denen der Smart-Card-Standards anzustrebeno Das TPM muss dazu nicht notwendigerweise eine ISO-7816-Schnittstelle anbieten, aber das TPM sollte eine sichere Umsetzung auf der Ebene der PC-Anwendungen erlauben. Dies bedeutet letztlich, dass die PC-Anwendung keinen besonderen Schutz ben6tigen sollte, weil alle Geheimnisse auf dem TPM oder auf der Smart Card verbleiben und nicht im Klartext ausgetauscht werden mfissen. Das Verfahren sollte sicherstellen, dass das TPM und die Smart Card bei der gegenseitigen Authentisierung Sitzungsschlfissel aushandeln die ffir einen sicheren Kanal zum authentischen und vertrauenswttrdigen Austausch von sicherheitsrelevanten Daten zwischen den beiden vertrauenswfirdigen Endpunkten TPM und Smart Card verwendet werden k6nnen (siehe Abb. 2). Um eine solche L6sung mit einer echten Ende-zu-Ende Sicherheit zu realisieren, k6nnte man beispielsweise eine kleine Applikation auf dem TPM unterbringen~

d Data \

TPM

Trusted Platform Abb. 2: Sicherer Datenaustausch Smart Cards der n~ichsten Generation k6nnen auch direkt fiber USB mit dem PC verbunden werden. Die Kommunikation erfolgt dann fiber TCP/IP sowie HTTP und SSLo Eine solche Internet Smart Card kann dann direkt mit dem TSS auf dem PC kommunizieren, indem dessen Webservice Schnittstelle und SOAP verwendet wird. Somit kann eine Internet Smart Card fiber das TSS direkt mit dem TPM kommunizieren, w~ihrend der Benutzer die Internet Smart Card fiber seinen Browser nutzt (Abb~ 3). Uber die

lnteraktionen TPM und Smart Card

11 7

Internetverbindung des PCs kann die Internet Smart Card mit entfernten Servern Kontakt aufnehmeno Folgende Anwendungsszenarien w~iren dann denkbar: 9 Bereitstellung eines VPNs in ein Firmennetzwerk fiber die Internet Smart Card nach erfolgreicher Integrit~itsprafung des PCs. 9 Internet Smart Card als Proxy zur Zugriffsbeschr~inkung und Anonymisierung des eigenen PCs und TPMs gegenfiber Servern, die ebenfalls die Webservice Schnittstelle des TSS nutzen wollen. ~ Bindung von Audio/Video Content an die Internet Smart Card statt an das TPM; eine Freigabe der Daten durch die Internet Smart Card kann auch im Offline Betrieb nach erfolgreicher Integrit~itspriifung erfolgen.

Internet Smart Card

Trusted Platform

Abb. 3" Internet Smart Card und TPM

3 Die Zukunft von Token und TPMs Zur Zeit werden TPMs ausschliel31ich in PCs integriert. Die TCG bescMftigt sich aber in einer eigenen Arbeitsgruppe auch mit der Sicherheit von mobilen Ger~iten im speziellen mit Mobiltelephonen. Mobile Ger~ite verfagen heute im Allgemeinen fiber Schnittstellen zur Einbindung von Smart Cards z.B. USBAnschlfisse und SIM-Slots. Neben Smart Cards werden m6glicherweise in zuktinftigen Ger~iten Mufig auch fest integrierte Sicherheitsbausteine zu finden sein. Anwendungen k6nnen dann for die Absicherung der Ger~itesoftware, die Gergteauthentisierung, zur Absicherung sicherheitskritischer Applikationen und zur Benutzerauthentisierung variable und fest integrierte Sicherheitsbausteine wie Smart Cards und TPMs in geeigneter Art und Weise verwendeno

3.1 Fest integrierter Sicherheitschip Dieser Typ, zu dem auch das TPM geh6rt, ist ein Sicherheitsbaustein der fest in ein Gergt integriert ist. Dem TPM entsprechend soll dieser Baustein eine Schnittstelle fftr Anwendungen bieten, die auf den Ger~itespeichern liegen und selbst keine Anwendung gespeichert haben. Der Vorteil der sich durch die feste Anbindung ergibt ist, dass der Baustein schon zu einem sehr frfihen Zeitpunkt im Bootprozess Sicherheit gew~ihrleisten kanno

118

Interaktionen TPM und Smart Card

In jfingster Zeit werden TPM/~hnliche Hardwarebausteine immer h/~ufiger direkt in Schnittstellenbausteine z.Bo LAN, W-LAN Controller oder in eingebettete Systeme implementiert. Der Vorteil ist hier einerseits eine Flgcheneinsparung auf dem PCP-Board und eine h6here Ausfallsicherheit, andererseits aber auch die M6glichkeit das TPM mit einer schnelleren Kommunikationsschnittstelle (z.B. PCI, USB) z.B. fin" Echtzeitanforderungen auszustatten. Des Weiteren enthalten speziell abgewandelte TPMs zusgtzliche kryptografische Funktionen, bei denen z.B. ein symmetrischer Verschlfisselungsalgorithmus in Hardware implementiert wurde, um einen hohen Datendurchsatz bei der Verschlfisselung von z.B. Audio- oder Videodaten zu erreichen.

3.2 Variabler Sicherheitschip Dieser Typ, zu dem auch die Smart Card geh6rt, ist ein Sicherheitsbaustein der in einem kleinen tragbaren Geh~iuse sitzt und fiber eine Schnittstelle von einem Ger~it genutzt werden kann. Einem solchen Smart Card Chip ist eigen, dass die Applikation auf dem Chip gespeichert und betrieben wird. Neben der klassischen Smart Card im Scheckkarten oder SIM Karten Format sind das z.B. USB-Token mit Sicherheitschip, oder Secure Multi Media Karten. Der Vorteil hier ist, dass die Applikation sicher verwahrt ist, das Gergt ,Smart Card' sehr preisgfinstig und die Smart Card klein, handlich und ger/~teunabh~ingig iSto

3.3 L6sungen mit variablen und fest integrierten Sicherheitsch ips Ft~r fast jedes Netzwerk stellt sich die Aufgabe die mobilen und station~iren Ger~ite im Netzwerk sowie die Zugriffe durch Benutzer zu kontrollieren. Ein Beispiel ist ein Firmennetzwerk. Es geht also einerseits um Ger~iteidentifikation und andererseits um Benutzerauthentisierung in einem Netzwerk. Bei der Ger~iteidentifikation kann das TPM oder ein anderer fest integrierter Sicherheitschip des Ger/its nfitzliche Dienste leisten, denn er ist eng mit dem Ger~it verbunden. Ffir die Benutzerauthentisierung ist ein fest integrierter Sicherheitschip allerdings ungeeignet (siehe Diskussion in Kapitel 1). Die Benutzerauthentisierung mittels Smart Cards bietet nicht nur dem Benutzer sondern auch dem Netzbetreiber wesentliche Vorteile. In vielen Fgllen sind Smart Cards auch bereits Bestandteil der Infrastmktur z.B. als Betriebsausweise in einem Firmennetzwerk.

3.4 Hardwaresicherheit in eingebetteten Systemen Kryptografische Funktionen wie Verschl~sselung und Authentifizierung spielen in modernen eingebetteten Systemen eine wichtige Rolle. Gerade mit dem Einzug elektronischer Systeme in immer mehr Bereiche des t/~glichen Lebens und einer damit verbundenen fortschreitenden Speicherung pers6nlicher Daten in elektronischer Form, sind die Rechteinhaber von digitalen Inhalten wie Musik- und VideoDaten oder Software daran interessiert, eine unberechtigte Vervielf~tltigung zu verhindern (z.B. durch Digital Rights Management [DRM]). Ein unsicheres System kann z.B. aber auch ffir die Hersteller von Spielekonsolen zu empfindlichen finanziellen Einbugen fahren, wenn sich Daten (z.B. Videospiele) beliebig kopieren lassen und fiber das Internet Verbreitung finden.

Interaktionen TPM und Smart Card

119

Gleichzeitig sind die Hardware-Ressourcen in eingebetteten Systemen, abh~ingig vom anvisierten Zielmarkt, beschr/inkt. So ist gerade bei Produkten der Unterhaltungselektronik der Preis ein entscheidender Faktor far den Erfolg eines Ger~ites. Der Einsatz von Kryptografie muss daher mit m6glichst geringem Aufwand und Kosten in Form von Chipfl/~che und Stromverbrauch m6glich gemacht werden. Die spezielle Fokussierung bei der Implementierung von kryptografischen Algorithmen far ressourcenbeschr~inkte Ger~te wird auch unter dem Begriff ,,Lightweight Cryptography" zusammengefasst [PaaPelSchWeiWol]. Hier wird versucht, far die bereits bekannten symmetrischen (z.B. AES, 3DES) und asymmetrischen (z.B. RSA, ECC) Verfahren effiziente Hardwarerealisierungen zu entwickeln, die sich durch eine besonders kleine Siliziumfl/~che bzw. durch eine besonders geringe Stromaufnahme auszeichnen. In verschiedenen Projekten werden neben Optimierungsm6glichkeiten bestehender Verfahren [PaaPelSchWeiWol] auch alternative Verfahren betrachtet [M~IWal]. A11gemein ist davon auszugehen, dass der Bedarf an ,,leichtgewichtigen" kryptografischen Funktionen in der Zulamft aufgaxmd von immer mehr batteriebetriebenen Ger/~ten noch entscheidend zunehmen wird. Chip-to-Chip Bussysteme sind ein Kembestandteil vieler eingebetteter Systeme. Sie stellen die Verbindung zwischen einzelnen Komponenten eines Ger/~tes her, die sich nicht auf einen Chip integrieren lassen. Diese Busse stellen einen empfindlichen Punkt im Sicherheitskonzept eines Systems dar, da durch die fortschreitende technische Entwicklung ein Man-in-the-Middle Angriff oder ein Abh6ren der Daten zwischen einzelnen Chips in einem System mit einfachen Mitteln m6glich ist. Ein prominentes Beispiel, wie mit einfachsten Mitteln fiber einen unverschlfisselten Datenbus das Sicherheitskonzept eines Ger/~tes umgangen werden kann, ist der von A. Huang beschriebene Angriff auf die erste Generation der Microsoft Spielkonsole XBOX aus dem Jahre 2002 [Hua]. Ein Schwachpunkt war u.a. die fehlende Busverschlfisselung, die es erm6glichte einen einfachen Angriff auf das Gesamtsystem durchzuffihren. Dabei wurde mit einem FPGA basierenden Logic Analyzer die Kommunikation auf dem Bus zwischen Southbridge und Northbridge abgeh6rt und analysiert. Huang ist es mit dieser Methode gelungen, den Secret Boot Block der XBOX vollst/~ndig zu rekonstruieren und daraus den geheimen RC4 Schlt~sseI zu extrahieren. Mit der Kenntnis des geheimen Schlfissels war es nun m6glich, einen eigenen Bootloader in das System einzubringen und verschlfisselt im Flash-ROM der XBOX abzulegen, welcher das Abspielen beliebiger Programme bzw. das Abspielen kopierter Spiele erm6glicht. Bei der im November 2005 als Nachfolger der XBOX auf den Markt gebrachten XBOX 360 hat Microsoft das Sicherheitskonzept deutlich ~iberarbeitet. Trotz des neuen Sicherheitskonzeptes wurde im M~irz 2006 ein DVD-ROM Firmware-Hack ffir die XBOX 360 ver6ffentlicht, der fiir das Abspielen kopierter Spiele-DVDs verwendet werden kann. Im Intemet sind hierzu weitere Informationen zu finden. Im Nachfolgenden soll kurz auf das verwendete Sicherheitskonzept eingegangen werden und ein m6glicher sicherer L6sungsansatz mit TPMs pr~isentiert werden. Bei der XBOX 360 wird fiber ein Challenge-and-Response-Protokoll zwischen dem DVD-Laufwerk und dem System geprfifl, ob es sich bei der eingelegten DVD um eine Original-DVD handelt. Die Responses befinden sich physikalisch in bestimmten Regionen der DVD, welche bei einer kopierten DVD defekt oder nicht vorhanden sind. Somit schl/~gt die Authentifizierung bei einer kopierten DVD fehl.

120

Interaktionen TPM und Smart Card

Es ist jedoch gelungen, die Firmware des DVD-ROM Laufwerks auszulesen und das Challenge-andResponse-Protokoll zu rekonstruiereno Mit diesem Wissen konnte eine modifizierte Version der DVDROM Firmware geschrieben werden, die eine Authentifizierung simuliert, auch wenn sich keine original Spiele-DVD im Laufwerk befindet. Die Firmware im dem Flash Speicher des DVD-Laufwerks war nicht geschtitzt. Eine m6gliche L6sung wgre hier der Einsatz eines TPMs oder eines embedded TPMs in den IDE-Controller des DVD-ROMs der es erm6glicht, eine sichere Identifikation der Hardware fiber ein Challangeand-Response mit dem t~brigen System durchzuffihren und verschl~sselt zu kommunizieren. Im Gegensatz zu softwarebasierenden L6sung von Microsoft w~ire hier eine hohe Sicherheit zu gew~ihrleisten. Das Konzept lieBe sich wie in Abbildung (Abbo 4) dargestellt erweitern, indem jede Komponente in einem System einen TPM ~hnlichen Chip erh~ilt, der sich gegent~ber dem Hostsystem (CPU) authentisieren muss. Weitere L6sungsans~itze ftir die Identifikation von Systemkomponenten in konventionellen Bussystemen (z.Bo AMBA Bus-System) sind unter [MfilWal] zu finden. Ergfinzend zu dem Einsatz des fest integrierten Sicherheitschips bei Spielekonsolen w~ire es auch denkbar, einen variablen Sicherheitschip (Smart Card) beim Kaufvon Spielen fiber das Internet einzusetzen. Hier k6nnte die personenbezogene Smart Card, vorausgesetzt ein entsprechender Kartenslot oder eine Kontaktlosschnittstelle steht beim Ger~it zur Verffigung, ffir den Bezahlvorgang eingesetzt werden. Eine Kombination von variabler und fest integrierter Sicherheitstechnologie w~ire in diesem Fall einfach vorstellbar. Gerneineamer vertrauenswLirdiger Bereich

Um oicherheiisfunktioner~ en~Jeiterter Bus-Controller

. ~

.... . . . .

I

1/

//

........

......

....

~~ "

............. V e r s c h l a s s e l t e

Kommunikation

.....

Bus / /

Abb. 4" Absicherung von Hardwarekomponenten in einem Chip-to-Chip Bussystem mittels einer Sicherheitsfunktion die mit Hilfe eines TPMs realisiert ist.

4 Fazit Smart Card und TPM erg~inzen sich bereits in einigen Anwendungsf~tllen gut. Das Potenzial an neuen Technologien in dieser Richtung ist aber noch lange nicht ausgesch6pft. Die Erweiterung der PCs durch ein TPM Sicherheitsmodul wird zu einer verbesserten Absicherung der Smart Card / PC Verbindung ffihren. Hieraus ergeben sich neue M6glichkeiten fin" verbesserte GesamtI6sungen.

Interaktionen TPM und Smart Card

121

Literatur [Bric04]

E. Brickell, J. Camenisch, and L. Chen: Direct anonymous attestation. In Proceedings of l lth ACM Conference on Computer and Communications Security, ACM Press, 2004

[Bund07]

Bundesamt far Sicherheit in der Informationstechnik: ,,Stellungnahme der Bundesregierung zu den Sicherheitsinitiativen TCG und NGSCB im Bereich Trusted Computing~ In: http://www.bsi.bund.de/ sichere_plattformen/trustcomp/stellung/StellungnahmeTCG l_2a.pdf

[DRM]

http ://www.drmwatch.com

[GaMe05] Gawlas, Florian & Meister, Gisela: ,,Interaktionen TPM und Smartcard." In: Smartcard Workshop 2005, http://www.sit.fraunhofer.de/_veranstaltungen/smartcard-ws/ [He06]

Heider, Axel: ,,Interaktion von Chipkarten der n~ichsten Generation mit vertrauenswiirdigen Rechnerumgebungen", Diplomarbeit, TU Mtinchen, 2006

[Hua]

Huang Ao: ,,Keeping Secrets in Hardware: The Microsoft XBOX Case Study", Proceedings of the Workshop on Cryptographic Hardware and Embedded Systems (CHES), ppo 213-227, LNCS, Springer 2002

[Meis04]

Meister, Gisela: ,,Die Rolle der Smart Card in der eSociety." In: Smartcard Workshop 2004, http:// www.sitofraunhofer.de/_veranstaltungen/smartcard-ws/

[MtilWal] Mtihlbach S., Wallner S.: "Secure and Authenticated Communication in Chip-Level Microcomputer Bus Systems with Tree Parity Machines", Proceedings of IEEE IC-SAMOS'07- Greece, July 2007 [PaaPelSchWeiWol] Paar C., Pelzl J., Schramm K., Weimerskirch Ao, Wollinger %, ,,Eingebettete Sicherheit: Stateof-the-art", D-A-CH Security, Basel 2004 [Patr03]

George, Patrick: ,,User Authentication With Smart Cards In Trusted Computing Architectures." http:// www.gemplus, com/smart/rd/publications/pdf/S AM2406 .pdf

[Trus07]

Trusted Computing Group: ,,http://www.trustedcomputinggroup.org"

Anwen d u ngsszenari en

Enterprise SecurityInformationsschutz im Unternehmen Michael Hartmann 9 Gunter Bitz SAP AG {michael.hartmann ] gunter.bitz} @sap.com

1 Enterprise Security Das Thema Enterprise Security ist sehr vielschichtig, angefangen bei dem Schutz von Leib und Leben der Mitarbeit, fiber den Schutz der Gebgude, Zutrittschutz zum Geb/iude, physikalischer Schutz der Anlagen, Schutz der IT-Systeme bis zum Schutz des Intellectual Property, der Information als solcher. Im weiteren Artikel werden wir uns auf den Schutz der Informationen und den damit zwangsl/iufig einhergehenden Schutz der IT-Systeme konzentrieren. In einem global aufgestelltem Konzem mit einem stark ausgepr/~gtem Okosystem ist Verfagbarkeit von Informationen und die damit einhergehende notwendige Vernetzung der Partner und deren IT-Systeme, sowie der eigenen IT-Systeme ein entscheidender Erfolgsfaktor. Vertriebsmitarbeiter, Berater, Kunden, Partner, tun nur einige zu nennen, mfissen jederzeit und von ftberall auf die flu" sie bestimmten und relevanten Informationen zugreifen kOnnen. Zulieferer, Kunden, Partner und Dienstleister werden stetig weiter in die eigenen Gesch~iftsprozesse integriert. Dabei gilt es die Prozesse und die damit verbundenen IT-Systeme flexibel zu gestalten, um zeitnah neue Projekte, Partner, Veranstalmngen, etc. erm6glichen zu k6nnen. Bei all diesen Anforderungen muss selbstverst~indlich die Vertraulichkeit, Integrit~tt und Verfftgbarkeit der Informationen gew~ihrleistet sein. Gleiches gilt daher auch ft'~rdie IT-Systeme. In der / Microsoft-Sicherheitssmdie 2006 wurden die Bedrohungen der IT-Systeme nach ihrer Bedeutung bewertet. Rang Eins erreichte der ,,Irrmm und Nachl/issigkeit eigener Mitarbeiter", gefolgt von Malware (Viren, Wfirmer, Trojanische Pferde .... ) sowie Software- und Hardware-M/~ngeln/Defekte. Erst danach kommen ,,unbefugte Kenntnisnahme, Informationsdiebstahl, Wirtschaftsspionage", Hacking (Vandalismus, Probing, Missbrauch,...) und ,,Manipulation zum Zweck der Bereicherung". Um diesen Bedrohungen zu begegnen, werden unterschiedliche Gegenmal3nahmen eingesetzt, die sich in drei Kategorien einteilen lassen: Vertragliche Verpflichtungen und organisatorische Magnahmen (dazu z~ihlen Arbeitsvertr/~ge, Geheimhaltungsvereinbarungen, Policies, etc.), technische Ans/~tze (Network Access Control, Antivirensoftware, Firewalls, Intrusion-Detection-Systeme, Intrustions-Prevention-Systeme, Identity und Access Management Systeme, etc.) und Awareness-Magnahmen. Tabelle 1 zeigt eine Aufstellung, welche Magnahmen den einzelnen Bedrohungen entgegengesetzt werden:

N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 125-139

126

Enterprise Security- Informationsschutz im Unternehmen Tab. 1: Bedrohungen und m6gliche GegenmaBnahmen. Bedrohung

Mafinahme

Irrtum und Nachl~issigkeit eigener Mitarbeiter (und Awareness MaBnahmen, Identitymanagement, ArbeitsExterner) vertrag .... Malware (Viren, Warmer, Trojanische Pferde ....)

Virenscanner, Personal Firewall, IDS, IPS, ADS ....

Software- und Hardware-M~ingel-/Defekte

CERT, Patchmanagement, Einkaufsbedingungen ....

unbefugte Kenntnisnahme, Wirtschaftsspionage

Informationsdiebstahl, Arbeitsvertrag, NDA, Need-to-Know-Prinzip

Hacking (Vandalismus, Probing, Missbrauch ....)

Firewalls, IDS, IPS, ADS ....

Manipulation zum Zweck der Bereicherung

Arbeitsvertrag, gesetzliche Vorgaben, Segregation of Duty, ...

Zur Durchsetzung der Einhaltung vertraglicher/organisatorischer Maf3nahmen, dem sogenannten Policy Enforcement, ergeben sich durch den Einsatz der Trusted Computing Technologie einige neue M6glichkeiten. Diese werden im Folgenden n~iher beschrieben.

2 Policy Enforcement mittels Trusted Computing Wie bereits in anderen Artikeln dieses Buches erw~ihnt baut die Trusted Computing Technologie auf dem so genannten Trusted Platform Module (TPM) auf. Dieser physikalisch geschfitzte und mit dem IT-System verbundene Hardwarebaustein bildet den grundlegenden Vertrauensanker (,,root-of-trust") in einer langen Vertrauenskette (,,chain-of-trust"). Das TPM erm6glicht eine eindeutige Messung des mit ihm verbundenen Systems, beginnend mit dem Bootvorgang fiber das geladene Betriebssystem bis zu den darauf installierten Applikationen und deren Konfiguration. 15ber diese Messung lasst sich gegent~ber einem Dritten die Konfiguration des System nachweisen und durch diesen Dritten auf seine Integrit~it fiberprfift werden. Hier spricht man von ,,remote attestation". Wenn dadurch die Systemintegritgt eines einzelnen Systems sichergestellt ist, kann dart~ber ein gesicherter Netzwerkzugang realisiert werden, der letztendlich die Integrit~it der gesamten Infrastruktur und deren Nachweisbarkeit erm6glicht. Die Integrit~it der eigenen Infrastruktur stellt eine wichtige und zwingende Voraussetzung far ein zuverl~issiges Policy Enforcement dar. Darauf aufbauend kann dann ein Enterprise Rights Management (ERM) System realisiert werden, welches die Rechteverwaltung der Informationen innerhalb der Organisation und in einem weiteren Schritt organisationst~bergreifend realisiert. Der gesicherte/vertrauenswt~rdige Netzwerkzugang wurde bereits vonder Trusted Computing Group (TCG) unter dem Namen ,,TNC - Trusted Network Connect" spezifiziert und wird in einem anderen Artikel in diesem Buch n~iher erl~iutert. TNC bietet eine gute, weitere technische M6glichkeit, die Verbreitung und Auswirkungen von Malware zu bek~impfen und kann gleichzeitig Hacking-Angriffe von Insidern reduzieren, da der Zugang zur Netzwerkinfrastruktur restriktiv verwaltet werden kann. ERM hat als Ziel die Informationen einer Organisation direkt zu schtitzen und die Regelungen far den Umgang damit durchzusetzen (Policy Enforcement). Dadurch eignet sich ERM dazu die Bedrohungen, die sich aus dem Irmun und der Nachl~issigkeit von Mitarbeitern ergeben zu begegnen, genauso wie den vors~itzlich begangenen Regelverst0gen vorzubeugen, da die Informationen direkt geschfitzt werden und nur noch die erlaubten Verwendungsoptionen von Informationen m0glich sind. Im Folgenden werden wir das Enterprise Rights Management als eine der komplexesten M6glichkeiten der Trusted Computing Technologie genauer betrachten.

Enterprise Security- Informationsschutz im Untemehmen

127

3 Enterprise Rights Management ERM bedeutet im Zusammenhang mit Informationen die technische Umsetzung einer Informationsklassifikationsvorschrift sowie die Definition eines Informationseigen~mers~ Diese zwei Forderungen sind Bestandteil von Sicherheitsrichtlinien vieler Untemehmen, werden aber in der Regel nicht konsequent eingehalten. Viele vertrauliche Dokumente werden so z.B. entgegen ihrer Klassifikation weitergegeben, weil der Absender des Dokuments dies im eigenen Ermessen ,,fitr eine gute Idee" h~ilt. Es mag im Einzelfall durchaus berechtigt sein, den Empf'~ingerkreis einer vertraulichen Information zu erweitern, weil dies zur AusNhrung eines Gesch~iftsprozesses notwendig ist. Allerdings wird durch ein bloges Weiterleiten einer Information die Sicherheitsrichtlinie verletzt, da der Ersteller, d.h. der Informationseigentfimer, nicht in diesen Prozess eingebunden wirdo Die Situation wird v611ig unkontrollierbar, wenn die augerhalb jedes Sicherheitsprozesses hinzugekommen Empf'gnger einer Information diese selbst wieder an weitere Personen versenden. Der Informationseigentfimer und damit das Untemehmen verlieren die Kontrolle fiber die Information. Dadurch wird der Weitergabe von Information an Dritte, die dem Untemehmen schaden k6nnen, T~r und Tor ge6ffnet, da ein potentieller T~tter unter diesen Umst~inden h6chstwahrscheinlich unentdeckt bleiben wird. Das Kernproblem digital vorliegender Informationen ist deren einfache Kopierbarkeit. Die Kopie ist dem Original gleichwertig. Die Erstellung einer Kopie ist ffir einen zugangsberechtigten Nutzer in der Regel sehr einfach. ,,Enterprise Rights Managements" oder ERM versucht, dieser Problemstellung zu begegnen. Der Begriff hat sich in der Industrie zunehmend durchgesetzt, um sich bewusst von den ,,Digital Rights Management" Konzepten der Multimedia Industrie abzugrenzen. Auf den ersten Blick mag die Zielsetzung, also die Erstellung nicht autorisierter Kopien eines Originals, zwar identisch sein, allerdings finden sich doch im Detail erhebliche Unterschiede. Zun~ichst einmal handelt es sich im Multimedia-Umfeld um ein Massenproblem, man wird hier eher versuchen, die illegale Verbreimng urheberechtlich geschfitzter Werke quantitativ einzuschr~inken. Hier ist es durchaus als Erfolg zu werten, wenn technisch normal versierte Anwender keine Kopien erstellen k6nnen. Im Enterprise Umfeld kann bereits eine einzige Kopie eines sensiblen Dokuments erheblichen Schaden ft~r das Untemehmen bedeuten. Ebenso ist die Verwalmng der Berechtigungen im Unternehmensumfeld wesentlich komplexer. Es gilt m6glichst geschickt und ohne zus~itzlichen Aufwand ffir den Benutzer, die Frage zu beantworten, wer auf welche Dokumente unter welchen Umst~inden zugreifen darf. In der Vergangenheit, als Informationen im Wesentlichen noch in gedruckter Form verffigbar waren, war die Durchsetzung einer Sicherheitsrichtlinie entsprechend einfachero Das Dokument wurde an einem gesicherten Ort z.B. in einem Tresor verwahrt. Es gab die Rolle des ,,Archivars", dessen Aufgabe darin bestand, die Zugangsberechtigung von Antragstellem zu prfifen und ein Dokument nur an berechtigte Personen auszugeben. Dies wurde ebenso wie die Rt~ckgabe des Dokuments in einem ,,Logfile" vermerkt. Fflr besonders scht~tzenswerte Dokumente erfolgte die Ausgabe in einer speziell gesicherten Umgebung ohne Kopierm6glichkeit. Das Dokument konnte nur an Ort und Stelle in dieser sicheren Umgebung eingesehen werden. Damit wurden unberechtigte VervielfNtigungen effektiv verhindert.

128

Enterprise Security- Informationsschutz im Unternehmen

3.1 Status aktueller ERM Implementierungen Eine ERM-Implementierung [Micr03,Auth04,Sea105] simuliert elektronisch den oben beschriebenen Prozess der sicheren Dokumentenausgabe an berechtigte Personen in einer sicheren Umgebung. Insbesondere bei der Definition einer sicheren Umgebung wird Trusted Computing einen wesentlichen Beitrag leisten, doch dazu sp~iter mehr. Die Funktionsweise von ERM l~isst sich wie folgt in Analogie zu dem ,,Archivar" beschreiben: Zu jeder Information, besser gesagt zu einem Block von Informationen physisch abgebildet in einer Datei, werden ein Informationseigentttmer und eine Dokumenten-Policy definiert. Technisch ist meistens der Ersteller eines Dokuments auch gleichzeitig der Informationseigentamer, sodass die ERM-Software auch den Ersteller automatisch als Informationseigentfimer definiert. Sollte davon abgewichen werden mfissen, kann natarlich der Ersteller einmalig einen anderen Informationseigentfimer definieren~ Er gibt damit aber alle Rechte an der Datei an den Informationseigentfimer ab. Die Aufgabe des InformationseigentfLmers ist die Definition der Dokumenten-Policy. Typischerweise hat ein Unternehmen verschiedene vordefinierte Policies. Z.B. ffir verschiedene Abteilungen wie HR, Finance, Research, Sales, Training, Consulting, Production, usw. Einer vordefinierten Policy sollte auch direkt eine vordefinierte Liste von zugangsberechtigten Personen zugeordnet werden~ Die PolicyErstellung l~isst sich erheblich vereinfachen, wenn man sie rollenbasiert gestaltet und in ein Identity & Access Management System integriert. Stehen solche vordefinierten Policies zur Verffigung, sollte sich die Arbeit des Informationseigentttmers darauf beschr~inken, dem Dokument die passende Policy zuzuordnen. Sogar dieser Vorgang k6nnte noch automatisiert werden, indem ein Content-Scanner das Dokument nach Schlfisselworten durchsucht, automatisch klassifiziert und die entsprechende Dokumenten-Policy vergibt~ Der Name der Dokumenten-Policy wird im Header des Dokuments abgespeichert, w~ihrend die Policy selbst auf einem zentralen, firmeninternen ERM Policy-Server gespeichert wird. Dies hat den grogen Vorteil, dass die Policy auch nach Distribution des Dokuments noch ge~indert werden kann, z.B. um weitere berechtigte Personen in die Liste der Zugangsberechtigten aufzunehmen. W~ire die Policy innerhalb des Dokuments selbst gespeichert, w~ire in diesem Fall eine erneute Verteilung des Dokuments erforderlich ebenso wie das LOschen der alten Version, was ein mt'thsames Unterfangen w~ire, wenn viele dezentrale Kopien existieren. Die Nutzdaten des Dokuments und der Header, welcher den Namen der anzuwendenden Policy enth~ilt, sind verschlt~sselt, um eine Manipulation des Policy-Namens lind ein unberechtigtes Einsehen des Dokumenteninhalts zu verhindern. Ein mit ERM geschfitztes Dokument lgsst sich zun~ichst also wegen der Verschl~sselung nicht 6ffnen. Die Rolle des ,,Archivars" (vergl. oben) wird vonder ERM-Software fibernommen. Die ERM-Software schafft sozusagen die sichere Umgebung, in welcher ein kontrollierter Zugriff auf die Information gew~ihrt wird. Die ERM-Software wird als Programm-Modul direkt in die Anwendung, die das Dokument 6ffnen soll, integriert (z.B. gibt es Module flir die Microsoft Office Palette, f'ttr html und Adobe Acrobat. Prinzipiell w~ire ein Modul Ftir jede in Frage kommende Anwendung denkbar und wird wohl - entsprechende Nachfrage vorausgesetzt - auch entwickelt werden.) S~imtliche Ein- und Ausgaben der betreffenden Software werden nun vom ERM-Modul kontrolliert. Zun~ichst dekodiert das ERM-Modul den Policy-Namen und l~idt sich die betreffende Richtlinie vom Policy-Server, wenn diese lokal nicht vorhanden ist. In der Tat bedingt eine ERM-Implementierung,

Enterprise Security- Informationsschutz im Unternehmen

129

dass jeder Anwender- zumindest beim ersten Offnen der D a t e i - in der Lage sein muss, eine Verbindung zum Policy-Server aufzubauen. Danach ist prinzipiell auch eine offline Nutzung m6glich, da die ERM Module die Policy aber auch Schlasselmaterial, ben6tigt zum Entschltisseln des Dokumenteninhaltes, lokal auf dem Client Rechner zwischenspeichern. Eine Ausnahme bilden jene Dokumente, far die explizit eine reine online Nutzung per Dokumenten-Policy gefordert ist. In diesem Fall werden keine Daten lokal zwischengespeichert und stattdessen immer neu vom Policy-Server geladen. Dadurch werden Anderungen an der Dokumenten-Policy ohne Verz6gerung bei allen Anwendern beim n~ichsten Offnen der Datei wirksam. Nach dem Laden der Dokumenten-Policy prfift das ERM-Modul nun, ob der auf das Dokument zugreifende Anwender gem~il3 Dokumenten-Policy fiberhaupt zugangsberechtigt ist. Ist dies nicht der Fall, so bricht der Vorgang ab und es werden keine Schlfissel zum Dekodieren des Dokuments geladeno Ist der Anwender zugangsberechtigt, so wird das Dokument dekodiert und alle Rechte des Anwenders nach Auswertung der Dokumenten-Policy lokal in einer Tabelle vermerkt. Bei jeder weiteren Ein- Ausgabe-Operation wie z.B. Speichern, Speichern als, Copy & Paste, Bildschirmkopie, Andern des Dokuments (auch Tastatureingaben) wird gepraft, ob der Anwender zu dieser Operation befugt ist~Ansonsten wird der Vorgang abgebrochen, bzw. eleganter erst gar nicht im Programm-Menfi angeboten~ So l~isst sich z.B. durch Sperren von ,,Copy & Paste" und ,,Speichern als" verhindern, dass fiber diesen Umweg eine neue Kopie des Dokuments erstellt wird. Zum Beispiel s~ihe eine typische Dokumenten-Policy fttr einen Informationsempf'~inger, der die Information nicht weiter modifizieren muss, dergestalt aus, dass far berechtigte Personen ein lesender Zugriff (Offnen) auf das Dokument gew~ihrt wird, w~ihrend alle weiteren Rechte gesperrt sin& Dadurch kann dieser Informationsempf~inger die Datei lediglich ansehen, sie aber nicht ver~indern. Ebenso wenig k6nnte er den Kreis der zugangsberechtigten Personen ~indern. Somit kann jeder Anwender lediglich im Rahmen seiner in der Dokumenten-Policy erlaubten MOglichkeiten agieren. Das ERM-Software Modul stellt dies technisch sicher. Die Frage der Robustheit solch einer L6sung gegen Angriffe wird separat diskutiert werden~ Trusted Computing stellt hier einen guten L6sungsansatz dar, tun ffir Anwendungen mit hohem Schutzbedarf eine sichere Ablaufumgebung ffir das ERM-Modul bereitzustellen.

3.2 ERM und TC Gerade beim Datenaustausch mit Externen kann die Sicherheit von Rights Management signifikant mittels einer Sicherheitsplattform auf Basis der Trusted Computing Technologie erh6ht werden. Es bietet dem Informationseigentfimer eine bequeme M6glichkeit, fiber die Integrit~it des Systems, welches auf sein Dokument zugreifen m6chte, einen verlgsslichen Zustandsbericht zu erhalten. Entspricht dieser Zustandsbericht nicht den Vorgaben des Informationseigent~mers, so wird der Zugriff auf das Dokument automatisch verwehrt. Damit l~isst sich fiber die Grenzen der eigenen IT Infrastruktur hinweg eine technische Forderung an die Client Systeme durchsetzen, um z.B. sicherzustellen, dass keine Software auf dem System vorhanden ist, die geeignet w~ire, den Rights Management Schutz anzugreifen. Trusted Computing kann also eine sichere Ablaufumgebung far ERM Softwaremodule bereitstellen und dies messbar machen. In dieser sicheren Umgebung kann nun durch die ERM-Software selbst auf Informationen und Dokumente zugegriffen werden kann. Dabei muss verhindert werden, dass ein b6sartiger Angreifer versucht, den ERM-Schutz zu umgehen, indem er die Plattform, also die Umgebung in der die ERM-Software

130

Enterprise Security- Informationsschutz im Unternehmen

ausgefahrt wird, oder die ERM-Software selbst oder die Anwendtmg, die das Dokument 6ffnet, manipuliert. Letztendlich soll Trusted Computing die Integrit~it der gesamten Plattform sicherstellen. Die Trusted Computing Group bezeichnet diese Funktionalit~it als ,,remote attestation", also als die verbindliche Aussage eines Systems fiber seinen Zustand, in dem es sich gerade befindet~ l)blicherweise versteht man darunter einen detaillierten Bericht fiber die auf dem System gestarteten Anwendungen. Mit Hilfe von TC kann fiber den Zustand eines Systems zweifelsfrei berichtet werden kanno Durch Verwendung einer ,,root-of-trust"- fiblicherweise realisiert in Hardware mittels eines TPM - kann das zu prfifende System diesen Bericht fiber seinen eigenen Zustand nicht f'~ilschen. TC stellt sicher, dass die Messung und 12rbermittlung des Zustandes immer korrekt ist. Es verhindert jedoch nicht, dass ein System in einen unsicheren Zustand wechselt, macht dies aber nach augen sichtbar. Die prinzipielle Funktionsweise von TC im Kontext Unternehmenssicherheit wurde sehr gut von IBM [Sail04] beschrieben.

3.3 Angriffsvektoren Es werden die unterschiedlichen Angriffsvektoren auf ERM Systeme erl~iutert. Um zu verstehen, wie die aktuellen Entwicklungen der Trusted Computing Group die Sicherheit des ERM-Schutzes verbessern k6nnen, ist es hilfreich, Angriffszenarien auf Rights Management Szenarien zu studiereno Hier kann man auf Erfahrungen aus dem Multimediabereich zurfickgreifen. Da die zu Grunde liegende Technik vergleichbar ist, ist damit zu rechnen, dass diese Angriffe auch auf in diesem Artikel dargestellte Anwendungsgebiete fibertragen werden. 9 Black Box Angriff: Hierunter versteht man einen Angriff auf eine mit ERM geschfitzte Datei, wobei der Angreifer lediglich fiber die Datei selbst verffigt. Damit bleiben nur die Wege, die Verschlfisselung der mit ERM geschtitzten Datei zu brechen oder den ERM Policy-Server anzugreifen. Beide Angriffvektoren sind sehr schwierig auszuffihren und k6nnen durch gutes Design der Anwendung noch weiter erschwert bis unm6glich gemacht werdeno Allen im Folgenden beschriebenen Angriffen ist gemeinsam, dass der Angreifer teilweise fiber Berechtigungen verf~igt und nun versucht, diese zu erweitem~ Ein direkter Angriff auf den Policy-Server ist wie beim Black Box Angriff sehr schwierig auszut~hren, daher wird der Angreifer in der Regel eine Komponente des Client Systems attackieren~ Er wird versuchen, den ERM-Schutz komplett zu entfernen bzw. den Inhalt der Datei in eine neue Datei ohne ERM-Schutz zu transferieren. 9 Angriff auf ERM Client: Hierbei wird der Angreifer versuchen, die auf dem Client installierte ERM-Software dergestalt zu modifizieren, dass sie sich gegenfiber dem ERM Policy-Server v611ig normal verhNt, also z.B. auch Schlfisselmaterial zum Lesen der Datei anfordert, ansonsten aber die vom Server gelieferte Dokumenten-Policy weitgehend ignoriert und dem jeweiligen Benutzer volle Kontrolle t~ber das Dokument einr~iumt. Der Angreifer hfitte dann z.B. die M6glichkeit fiber ein einfaches ,,Speichern unter" ein neues Dokument zu erzeugen, das keinen ERM-Restriktionen unterliegt.

Enterprise Security- Informationsschutz im Unternehmen

131

Client Components Application / RM Client

ClientAttacks

<

II

Hardware & I/O

I

Grab output data

Drivers Kernel

Prevent Policy Enforcement

<: <

'1

Copy or modify memory All sorts of bus attacks and "Analog Hole" problems

Abbo 1: Angriffsm6glichkeiten auf den ERM Schutz in verschiedenen Ebenen des IT Systems. 9 Angriff auf Applikationsebene: Hier erfolgt der Angriff direkt auf die Applikation, die das Dokument 6ffnet und anzeigt. Der Angriff kann auch hier wieder zum Ziel haben, ein eigentlich gesperrtes ,,Speichern unter" zu aktivieren. 9 Angriff auf Treiberebene: Bei diesen Angriffen wird ausgenutzt, dass die mit ERM geschfitzten Inhalte an einer Stelle ffir den Benutzer lesbar ausgegeben werden. Der Angreifer kann sich in Ausgabe-Treiber einklinken und damit eine Kopie der ungeschfitzten Daten erzeugen. Bei dieser Angriffsart geht allerdings in der Regel das Original Dateiformat verloren. Z.B. verwandelt sich eine Word- Datei in eine Grafikdatei. 9 Angriff auf Betriebssystemebene: Dieser Angriff nutzt aus, dass das Betriebssystem oder Teile desselben (z.B. der Kernel) ungehinderten Zugriff auf den kompletten Arbeitsspeicher des Rechners besitzen. Der Angreifer fagt dem Betriebssystem eine Funktion hinzu, die den Arbeitsspeicher nach den gewfinschten Daten durchsucht, und diese direkt aus dem Speicher in eine neue Datei schreibt- selbstverst~indlich ohne ERM-Schutz. 9 Angriff auf analoge Daten: Dies wird oft auch als ,,The analog h o l e - Die analoge Lficke" bezeichnet. Wie der Name bereits andeutet unterscheidet er sich yon allen anderen Angriffen dadurch, dass nicht das digital vorliegende Dokument sondern analoge Ausgangsdaten angegriffen werden. Im Multimedia Bereich werden z.B. die Daten an den Video- und Audio-Ausggngen des Rechners abgegriffen. 12rbertragen auf Dokumente und Informationen erstellt dieser Angriff einfach Kopien des Bildschirminhaltes, z.B. mit einer Fotokamerao Es ist sehr schwer, sich gegen diese Art des Angriffs zu scht~tzen, da er aul3erhalb des Einflussbereichs von Computer Soft- und Hardware stattfindet. Solange ein Mensch am Bildschirm die Information lesen muss, besteht diese Lt~cke immer. Man muss allerdings beachten, dass dieser Angriff bei umfangreichen Dokumenten (z.B. Handbficher) sehr aufwendig auszuffthren ist, und dass das Original Dolalmentenformat nicht erhalten bleibt. Dies mag bereits hinreichend abschreckend wirken, so dass der Angriff letztendlich nicht zum Tragen kommt. Bei sehr wertvollen Informationen muss man diesen Angriff allerdings sehr wohl in Betracht ziehen und Gegenmal3nahmen implementieren. Eine M6glichkeit w~ire, diese Dokumente nur an bestimmten Terminals zug~inglich zu machen und das Mitbringen von Aufnahmegergten in die entsprechenden R~iumlichkeiten zu untersagen und

132

Enterprise Security- Informationsschutz im Unternehmen auch zu kontrollieren. Zus~itzlich besteht die M6glichkeit, Benutzer bezogene Wasserzeichen in die Dokumente zu integrieren. Dies erm6glicht zumindest eine gewisse Nachvollziehbarkeit, auf welchem Wege die Informationen verbreitet wurden.

Abbildung 3 fasst diese Angriffsvektoren, die verschiedenen Komponenten des IT Systems zugeordnet werden k6nnen, noch einmal zusammen~ Zu jeder Komponente des Systems sind die typischen Angriffsvektoren dargestellt~

3.4 TC-Gegenmal~nahmen Die Diskussion der Angriffsvektoren zeigt, dass die Angriffe auf das Client System inklusive ,,Analog Angriff' die am einfachsten auszuftihrenden Angriffe sind, wobei der Angriff auf analoge Daten eine Sonderstellung einnimmt. Er ist ungeachtet des verwendeten Schutzmechanismus immer mitzubetrachten und ist in den seltensten Fgllen mit zus~itzlicher Soft- oder Hardware zu verhindern. In den Fgllen wo die Nachteile des ,,Analog Angriffs" wie z.B. die nicht perfekte Kopie des Originals ft~r den Angreifer unerheblich sind, oder der Wert der Information den aufwgndigen Angriff rechtfertigt, sollte man zus~itzlich zum eingesetzten Software Schutzverfahren (z.B. ERM) immer entsprechende organisatorische Mal3nahmen treffen, um den Angriff abzuwehren. Auch der Einsatz von Trusted Computing kann an dieser Tatsache nichts ~indern, da das Problem aul3erhalb des IT Systems gel6st werden muss. Den Client Angriffen ist gemeinsam, dass immer eine Modifikation von Software erforderlich ist, um erfolgreich zu sein. Genau hier setzt Trusted Computing an. TC bietet ein sicheres Messverfahren, um die Integritgt einer Plattform und der darauf eingesetzten Software messen zu k6nnen. Dieses Verfahren, genannt ,,remote attestation", funktioniert auch sicher fiber eine Netzwerkverbindung in einer Client-Server Umgebung [TCG205]o Ausgehend von einer ,,root of trust", die manipulationssicher im ,,Trusted Plattform Module (TPM)" [TCG105] verankert ist, werden Integritgtsmessungen vom Bootsektor, Bootloader und weiteren Teilen des Betriebssysterns vorgenommen, bis das System die Integrit~it der Anwendungen selbst messen kann. Durch die lt~ckenlos aufeinander aufbauenden Integrit~itsmessungen wird sichergestellt, dass ein Angreifer nicht die Messroutine selbst manipulieren kann. Dies wfirde von der vorangegangen Messung vor Start des manipulierten Codes bemerkt werden. Diese Integrit~itsmessungen sind nun der Schlftssel zu einem sicheren Rights Management auf einer IT Infrastruktur, die man nicht direkt kontrollieren kann. Zum Offnen einer ERM-geschfitzten Datei muss der Client vom ERM Policy-Server die DokumentenPolicy und das zum Entschl~sseln notwendige Schlt~sselmaterial anfordern. Diesem Prozess schaltet man nun die ,,remote attestation" Messung entsprechend der TCG Spezifikation voro F~illt dieses Messung negativ aus, ist dies ein Hinweis, dass an der Software auf dem anfordernden Client manipuliert wurde. Der ERM Policy-Server unterbricht an dieser Stelle die Kommunikation mit dem nicht konformen Client und tibertr~igt die ben6tigten Schl(issel nicht. Der versuchte Angriff durch Softwaremanipulation ist gescheitert. Dabei stellen die TCG Verfahren eine manipulationssichere Messung bereit. Durch Binden der Dokumenten-Schlfissel an die eindeutige Identitgt des TPM des anfordernden Clients l~isst sich sicherstellen, dass das Dokument tatsgchlich nur auf dem Client ge6ffnet werden kann, auf welchem auch die Integrit~itsmessung durchgeffihrt wurde. Zusammenfassend kann man sagen, dass die auf der Trusted Computing Technologie basierenden Konzepte eine wirkungsvolle MOglichkeit darstellen, um allen Angriffen, die auf der Manipulation der Client Software beruhen, zu begegnen Allerdings sind die Konzepte der TCG in der Praxis noch

Enterprise Security- informationsschutz im Unternehmen

133

nicht soweit umgesetzt, dass es bereits roll nutzbar w~ire. Derzeit fehlt noch das vertrauenswttrdige Betriebssystem, das eine lfickenlose Integrit~itsmessung bis zur Anwendung erst erm6glichen wfirdeo Mit dem Release von Microsoft Vista sieht man nun, was von den einstigen Pl~inen realisiert wurde. Man beschr~inkt sich auf das ,,secure startup", was eine Integrit~itsmessung bis zum Bootloader bedeutet und Bitlocker, eine Festplattenverschlfisselung die optional das TPM nutzen kann. Eine ausfahrliche Diskussion des Themas Angriffe auf ERM und Abwehrm6glichkeiten der Angriffe durch Trusted Computing findet sich in [Bitz05]. Auf europNscher Ebene sieht das EMSCB Projekt [Sade05] recht viel versprechend aus. Hier wird der Ansatz verfolgt, ein minimales ,,Security Kernel" statt des kompletten OS voll TCG konform zu gestalten, das dann wiederum als Basis far sichere Anwendungen dient und in dessen Rahmen ein ERMSystem entwickelt wird. Bis zur Erfallung dieser Voraussetzungen wird man also noch eine Weile auf ein robustes Rights Management System warten mfissen. Dies mag auch der Grund sein, warum die ERM Hersteller bisher noch keine TC Integration anbieten. Trotzdem lohnt es sich, die Entwicklung auf diesem Gebiet voranzutreiben, da das TC Konzept nach wie vor das beste Mittel ist, um auf fremden Rechnersystemen eine firmeneigene Information sicher bereitzustellen.

4 Operations Um far den Einsatz in grof3en und komplexen Organisationen geeignet zu sein, m%sen ERM Systeme und speziell die zugrunde liegende Trusted Computing Technologie einigen weiteren Anforderungen gerecht werden, die fiber die bereits beschriebenen Funktionalit~iten hinausgehen. Der Eigentfimer m6chte die vollst~indige Kontrolle fiber sein System behalten, auch wenn er einem Dritten durch die Messung der Systemkonfiguration erm6glicht, die Integrit~it des Systems zu prfifen. Die Trusted Computing Technologie muss sich sauber in bereits existierende L6sungen und Prozesse integrieren. Hier sei speziell die Integration in die vorhandenen Systemmanagement, Support- und Recoveryprozesse genannt. Es mfissen Mechanismen geschaffen werden, die ein zentrales Keymanagement far TPMs erm6glichen und die Funktionalit~it der Remote Attestation muss durch die unterschiedlichen Systeme in einer heterogenen Infrastruktur unterstfitzt werden. Um die Kompatibilit~it mit Komplement~irtechnologien zu gew~thrleisten, sind offene Standards zu schaffen und durch die Hersteller zu nutzen, um beispielsweise zentrale Benutzerverzeichnisse, verschiedene Benutzerauthentisierungsmethoden oder auch Dokumentenmanagementsysteme problemlos anbinden zu k6nnen. Exemplarisch sind im Folgenden unterschiedliche Integrationsanforderungen an ERM Implementierungen erlgutert:

4.1 Integrationsm6glichkeiten einer ERM Implementierung 4.1.1 Identity& Access Management Systeme Unternehmen ft~ren in der Regel das Mitarbeiterverzeichnis zentral. Es gibt ein System, in welchem Mitarbeiter angelegt und auch gesperrt oder gel6scht werden k6nnen. Diesem zentralen System muss sich selbstverst~indlich auch die Rights Management Userverwaltung unterordnen. Es muss also ein IT

134

Enterprise Security- Informationsschutz im Unternehmen

Prozess etabliert werden, der diese Userdaten repliziert. In der Regel wird dies mittels Connectoren zu Directory Services (wie z.B. das Active Directory von Microsoft um nur eines zu nennen) gel6st. Damit ist ein Teilproblem - n~imlich das ,,Identity-Mapping" von Mitarbeiter-Identit~it zu Identit~it im Rights Management S y s t e m - erledigt. Rights Management L6sungen, die dieses einfache Mapping nicht beherrschen, sind den Autoren nicht bekannt. Wesentlich anspruchsvoller gestaltet sich die Aufgabe, auch den ,,Access" Teil sauber zu integrieren. Diese Integration sieht in der Theorie so aus, dass das zentrale System alle Rollendefinitionen aller User verwaltet. In der Rollendefinition, die verschiedene Zugangs- und Zugriffsaspekte in sich vereint, ist somit auch ein Teil enthalten, der den Zugang zu Dokumenten und Informationen regelt. Hier wfirde man in Form von Policies die Zugriffsrechte zu Dokumenten definieren. Typischerweise kann jeder Geschfiftsbereich eine Liste von Dokumentenkontexten erstellen. Diese k6nnte far die Entwicklungsabteilung einer Softwarefirma exemplarisch wie folgt aussehen: 9 Sourcecode von bereits im Markt befindlichen Produkten 9 Sourcecode aktueller Entwicklungsprojekte 9 Spezifikation & Designdokumente 9 M6gliche neue Produktideen 9 Patentanmeldungen 9 Strategie & Planungsdokumente 9 Marktstudien: Marktentwicklung und Marktbedarf 9 Beschreibung von nicht ver6ffentlichen Sicherheitsl(icken im Produkt Die Liste k6nnte natfirlich beliebig erweitert werden. In der Praxis mag es aber durchaus legitim sein, diese nicht detaillierter auszugestalten, da der Verwaltungsaufwand fiberproportional zum Sicherheitsgewinn ansteigen wfirde. Im zweiten Schritt werden nun Regeln (,,Policies") erstellt, die Zugriffsrechte far Dokumentenkontexte den Mitarbeiterrollen zuordnen~ Auf Ebene der Zugriffsrechte unterscheidet man typischerweise zwischen: 9 Lesezugriff auf Dokumente 9 Erstellen neuer Dokumente 9 Dokumente editieren 9 Drucken (mit und ohne Wasserzeichen) 9 Dokumentenkontext ~indern 9 Dokumentenklassifikation ~indern Der Ablauf der Erstellung der korrekten Dokumentenzugriffsrechte aus diesen Parametem ist schematisch in Abbildung 1 dargestellt. Viele ERM Systeme bieten daraber hinaus noch weitaus intelligentere Rechtevergabem6glichkeiten, wie z.B. das Recht zum einmaligen Lesen (Offnen) einer Datei oder die M6glichkeit ein Ablaufdatum zu setzen. Diese speziellen Rechte sind allerdings schwer in einer generellen Policy zu erfassen und werden eher individuell oft auch beim Datenaustausch mit Externen vergeben. Mit dem Instrument des Ablaufdatums oder dem manuellen Zurfickrufen einer bestimmten Datei lgsst sich auch sehr gut eine Versionskontrolle erzwingen, indem man veraltete Versionen eines Dokuments far ungfiltig erklgrt.

Enterprise Security - Informationsschutz im Unternehmen

13 5

Alle Rights Management Systeme bieten in ihrer Management Konsole eine entsprechende PolicyVerwaltung an. Allerdings lgsst die Integration in ein zentrales Identity & Access Management System noch zu wfinschen t~brig. Hier ist mitunter noch viel Entwicklungsarbeit auf Herstellerseite zu leisten. Manche Hersteller bieten APIs zum Zugriff auf die Policy-Verwaltung an, k6nnen aber noch keine vollst~tndige Integration mit den klassischen IAM Systemen zeigen. Diese mtisste zun~ichst vom Kunden bzw. von seinem System-Integrator selbst geleistet werden. Es ist verst~tndlich, dass die Haltung vieler grol3er Unternehmen eher noch abwartend ist, da der Investitionsaufwand nicht hinreichend genau abzusch~ttzen ist. Hier sollten die Hersteller dringend nachbessern und ,,out of the box" L6sungen zur Integration mit den grogen Identity-Management Systemen anbieten.

Office-Applications

U se rs

Documents

"--21

Classification Level DocumentType Roles or Groups

Other

Attributes

[N~

DirectoryService(IAM

RM SecurityPolicy Document Access-Rights

I

Abb. 2: Generierung von Dokumentenzugriffsrechten (ERM Security Policy)

4.1.2 A u t o m a t i s i e r t e D o k u m e n t e n k l a s s i f i k a t i o n Eine wesentliche Rolle bei der korrekten Zuordnung einer ERM Policy spielt die Einstufung des Dokuments hinsichtlich Vertraulichkeitsstufe (z.B. 6ffentlich, interner Gebrauch, vertraulich, streng vertraulich, geheim). Mit zunehmender Vertraulichkeitsstufe eines Dokumentes wird man in der Regel auch restriktivere Policies anwenden und na~rlich den Kreis der Leseberechtigten immer weiter einengen. Ffir viele Untemehmen, wo sich eine sehr grol3e Anzahl von Dokumenten in Umlauf befindet, ist eine korrekte Klassifikation ein groges Problem. Oft wurde ein Klassifikationsschema zwar formal eingeffihrt, aber es fehlt oft an technischen Hilfsmitteln, die den Anwender bei der Klassifikation untersttitzen warden oder die Klassifikation einfach erzwingen. So verwundert es nicht, dass in Grol3unternehmen immer noch die Mehrheit der Dokumente nicht ordnungsgem~ig klassifiziert ist oder gar keine Klassifikation tr~igt.

136

Enterprise Security- Informationsschutz im Unternehmen

Hilfreiche Ans~itze sind z.B. kleine Pop-up Fenster, die in die Anwendung oder in ein Dokumentenmanagementsystem integriert werden k6nnen und beim Speichern oder Einpflegen eines neuen Dokuments vom Anwender die Klassifikation aktiv erfragen. Dies unterstCttzt auch das Konzept, dass letztendlich nur der Informationseigentamer eine korrekte Klassifikation vornehmen kann. Dies 16st natCtrlich nicht das Problem der bereits erstellten unklassifizierten Dokumente. Hierffir zeigen sich erste Ans~ttze, dies mit so genannten ,,Content-Scannern" zu 16sen. Die Scanner bestehen aus einem Linguistik Modul und versuchen im Dokumenteninhalt bestimmte Muster und Schlfisselw6rter zu finden, die eine Einstufung in ein Klassifikationsschema erm6glichen. Diese Scanner wurden ursprfinglich entwickelt, um aus Kommunikationsinhalten (E-Mails oder Sprachinformation) relevante Informationen herauszufiltern und sind daher auf eine Verarbeitung groger Datenmengen gut vorbereitet. Um eine zuverlgssige Einstufung zu erzielen, muss natttrlich das Regelwerk, an Hand dessen die Scanner eine Einstufung vornehmen, individuell auf die Bedftrfnisse der Company angepasst werden. So wird z.B. das Vokabular einer Firma, die in der Pharmabranche tgtig ist, sich g~tnzlich vom Vokabular einer Softwarefirma- und damit auch die Inhalte besonders schfttzenswerter Dokumente- unterscheiden. Im Idealfall wqirde man eine Softwarekomponente erstellen und verteilen, die alle auf der lokalen Festplatte befindlichen Dokumente zun~ichst automatisch klassifiziert und anschliel3end im Kontext des Rechnerbesitzers in eine per Rights-Management geschfitzte Datei umwandelt.

4.1.3 Integration mit Content-Management Systemen Informationen und Dokumente, die in Content Management Systemen abgelegt sind, bieten yon Hause aus eine gewisse Ordnungsstruktur, die sich zur Erstelhmg einer ERM Policy verwerten l~isst. Da immer mehr Unternehmen bei stetiger wachsender Dokumentenzahl solche Systeme einffihren, sollte dies der Ansatzpunkt der Wahl ffir Rights Management Systeme seino Das Content Management System liefert dabei einige wertvolle Informationen quasi ,,frei Haus": 9 Eigentttrner des Dokuments 9 Funktion oder Rolle des Eigentfimers 9 Verwendungszweck des Dokuments 9 Inhalt des Dokuments (soweit durch das System bestimmbar) 9 Vertraulichkeitsklassifikation (kann beim Einstellen erfragt werden) ~ Umgebung (Kontext), in der das Dokument abrufbar ist Diese Meta Informationen lassen sich zur ERM Policy-Definition verknt~pfeno Die Erstellung und Pflege der Regeln selbst nimmt man im zentralen Identity Management System vor. Es erfolgt dann eine Propagation der Regeln zum CM System, wo abschliegend ffir jedes Dokument die korrekte ERM Policy erzeugt wird. Dieser Prozess kann vollautomatisch ablaufen, erzeugt also keinen manuellen Overhead. Die Regeln mt~ssen lediglich einmalig definiert werden, was die Gesch~iftsbereiche ffir ihre eigenen Informationen selbst tun k6nnen und mCtssen. Denn nur der Eigentamer der Information ist in der Lage, die Auswirkungen einer zu liberal oder auch einer zu eng definierten Regel abzuscMtzen. Sind diese Vorraussetzungen geschaffen, muss das Unternehmen aktiv darauf hinwirken, dass die Autoren (Informationseigentfimer) sensitive Informationen zentral im CM System verwalteten statt auf lokalen Festplatten, um von dieser Integration zu profitieren. Im Anschluss ist es unsch~idlich, wenn Benutzer diese Informationen aus dem CM System lokal zwischenspeichern, da hier bereits der Schutz durch ERM greift. Das CM System erlaubt den Export von

Enterprise Security- Informationsschutz im Unternehmen

137

Informationen lediglich in geschfitzter Form. Dieser Prozess ist in Abbildung 2 schematisch dargestellt. Die ehemals ungeschfttzte Datei wird beim Transport in das CM System automatisch in eine per ERM geschfitzte Datei umgewandelt. Anschliegend k6nnen Anwender mit dieser Datei wieder normal weiterarbeiten. Auch die Hersteller von ERM Systemen bewegen sich langsam in dieser Richtung. Man findet einige wenige Content-Management Systeme mit Rights-Management Anbindung. Allerdings sind den Autoren keine vollst~indige Integration aller drei Komponenten einschlief31ich Identity & Access Management bekannt.

Client (authorized)

~ e .

~~ Chent" ~~authorized receives document

i~

~: ~!~~ 4. DRM protected N ~ ~ ~_. stored i= ~ ~ ,N~-~ document i~~=-~ In system

2. authorization ! i objects

PriceList, axl~

3. DRM policy

Abb. 3" Integration von ERM und Content Management Systemen.

4.2 Interoperabilit~it mehrerer ERM L6sungen Ein grundlegendes Problem von Rights Management ist derzeit die fehlende Interoperabilit~it der L6sungen von verschiedenen Herstellern. M6chte man ERM lediglich innerhalb der eigenen IT Infrastmktur einsetzen, spielt dieser Aspekt keine Rolle, da man auf allen Clients natfirlich nur eine ERM L6sung installieren wird, eben genau diese L6sung, ffir die sich das Unternehmen entschieden hat. Nun stelle man sich aber folgendes beispielhafte Szenario vor: Mehrere groge Automobilhersteller haben sich entschlossen, ihre Konstruktionszeichnungen, die sie an ihre Zulieferer herausgeben, mit Rights Management zu scht~tzen. Dabei haben sich die Hersteller untereinander nicht abgestimmt (warum auch - sie konkurrieren miteinander und habe keine Veranlassung zur Kooperation), sondern haben die fttr ihre Bedfirfnisse beste L6sung ausgesucht. Nehmen wir einfach an, dass dabei die g~ingigen ERM Anbieter gleichmN3ig berficksichtigt wurden. Typischerweise hat ein Automobilunternehmen eine groge Anzahl von Zulieferem. Aus Effizienzgrt'mden wird natfirlich ein Unternehmen ffir alle seine Zulieferer die gleiche ERM L6sung verwenden wollen. Der Zulieferer, der sich auf die Herstellung bestimmter Baugruppen spezialisiert hat, beliefert nun wiederum mehrere Automobilhersteller. Da dieser aber die zu verwendende ERM L6sung spezifiziert hat,

138

Enterprise Security- Informationsschutz im Unternehmen

ergibt sich far den Zulieferer das Problem, dass er mehrere Rights Management Datenformate gleichermagen unterstfitzen muss. Dies l~isst sich Stand heute lediglich durch Installation aller ERM Plug-ins der ben6tigten Formate realisiereno Falls die L6sungen zudem noch keine Parallelinstallation zulassen, kann es sogar dazu fahren, dass der Zulieferer manche Arbeitsplgtze mit mehreren Rechnersystemen ausstatten muss, was den Aufwand auf seiner Seite natarlich betr/~chtlich erh6ht. Die Anbieter von ERM Software haben dieses Problem zwar prinzipiell erkannt, aber eine L6sung ist noch nicht abzusehen. Es ist zu bef'ttrchten, dass alle Hersteller die Strategie verfolgen, dies einfach vom Markt entscheiden zu lassen- natfirlich in der Hoffnung, dass sich ihr eigenes Produkt durchsetzt. Dies kann eine sehr gef'ghrliche Strategie sein, denn es hat sich immer wieder gezeigt (z.B. bei DVD-R gegen DVD+R oder jetzt aktuell beim der HD-DVD und Blu-Ray), dass dies ein langsamer und langwieriger Prozess ist, der insgesamt dem schnellen Erfolg einer neuen Technologie hinderlich ist. Die Anwender tendieren dazu abzuwarten, bevor sie eine Investition t~itigen, die in eine technologische Sackgasse f'tthrt. AuBerdem ist nicht garantiert, dass sich tats~ichlich das technisch beste Produkt durchsetzt. In den 80er Jahren hat sich das technisch unvorteilhafteste aller VCR Systeme durchgesetzt: Das VHS System. Dieser Betrachtung ist ~iugerst wichtig, wenn man plant ERM Technologie far den Datenaustausch mit Externen einzusetzen und nicht wie in obigem fiktivem Beispiel in der Lage ist, einfach einen Standard zu diktieren. Die Interoperabilit/itsprobleme k6nnen letztlich zum Scheitern des Projektes fahren, weil der externe Partner die vorgeschlagene L6sung nicht akzeptierto

5 Fazit ERM ist ein viel versprechendes Konzept zum Schutz sensibler Gesch/~ftsdaten. ERM etabliert wieder eine zentrale Kontrolle eines Informationseigentttmers fiber seine Daten. Nur mit Freigabe durch den Informationseigentamer kann der Empf'~inger eines Dokuments dieses an eine dritte Person weitergeben. Dies verhindert effektiv eine unkontrollierte Verbreitung von sensiblen Informationen. Ffir Firmen, die darauf angewiesen sind, Daten mit Externen auszutauschen, und auch hier die Kontrolle fiber die Verbreitung ihrer Daten behalten m6chten, ist ERM besonders attraktiv. In grogen Firmen sieht man sich allerdings mit einem Massenproblem konfrontiert. Es gilt eine Vielzahl von Benutzem, Rollen, Berechtigungen und Dokumente zu verwalten. Dies ist sinnvoll nur durch Integration von Rights Management mit Identity & Access Management zu bew/~ltigen. Als Stand-alone System betrieben besteht die Gefahr, dass die Gesamtkosten die Vorteile (Risikoreduktion) der besseren Dokumentensicherheit fibersteigen. Die Integration von ERM mit Content Management Systemen in Verbindung mit einem Connector zum zentralen Identity & Access Management zur Verwaltung der Rollen und Berechtigungen ist ein viel versprechender Ansatz, um den manuellen Zuordnungsaufwand der korrekten ERM Policy zu automatisieren. Ein weiteres Problem, das es in Grogunternehmen zu 16sen gilt, ist das ,,Altlastenproblem" der existierenden, nicht n/~her klassifizierten Dokumente. Hier k6nnen die Content Scanner in Verbindung mit lokalen Agenten gute Dienste leisten, die in Leerlaufzeiten des Systems die Festplatten durchsuchen

Enterprise Security - Informationsschutz im Untemehmen

139

und die identifizierten Dokumente in RM gesch~tzte Dokumente umwandeln. Alternativ k6nnte man die Dokumente alle in CM Systeme migrieren, was wiederum manuellen Aufwand verursacht. Eine Vielzahl von Angriffen auf ein ERM-System kann dutch eine vorherige Integritgtsprfifung der Plattform verhindert werdeno Hiefar leistet das Konzept der Sicherheitsplattform auf Basis der Trusted Computing Technologie einen grol3en Beitrago Allerdings muss die M/Sglichkeit, die Daten auf analogem Wege zu erlangen, immer mitbetrachtet und entsprechend abgesichert werdeno Gerade f ~ den sicheren Datenaustausch mit Externen k6nnte Trusted Computing den einzig gangbaren Weg darstellen, um die Integrit~it einer nicht direkt zug~inglichen Plattform zu ftberprfifen. Damit w~ire Rights Management auch zum Datenaustausch mit Externen eine sichere LOsungo Wie man sieht, ist ERM ein sehr nt~tzliches Werkzeug, um die unkontrollierte Verbreitung sensibler Informationen zu verhindern. Allerdings muss nach Meinung der Autoren noch Einiges an Entwicklungsaufwand geleistet werden, um diese L6sung far Grol3unternehmen attraktiv und mit geringer TCO nutzbar zu machen. Auf dem Weg zum Produktionseinsatz der Trusted Computing Technologie im A11gemeinen und von ERM L6sungen im Speziellen sind noch einige Herausforderungen durch die Hersteller und Standardisierungsgremien zu leisteno Da Stand heute noch nicht in allen Endger~iten TPM Bausteine vorhanden sind, gilt es Migrationsm6glichkeiten zu schaffen, um TC bereits heute vor einer fl~ichendeckenden Verfagbarkeit nutzbar zu machen. Die existierenden und noch zu schaffenden Standards mt~ssen die Interoperabilit~it zwischen den Produkten unterschiedlicher Hersteller gew~ihrleisten und eine Kompatibilitfit zu Komplementfirtechnoligen erm6glichen. Die Trusted Computing Technologie muss einfach und leicht verst~indlich in der Anwendung sein, um die TCO nicht durch aufw~indige Wartung und Schulung der Mitarbeiter zu belasten.

Literatur [Sail04] [Micr03] [Auth04] [Seal05] [TCG105] [TCB205] [Sade05]

[Bitz05]

IBM Research Report ,,The role of TPM in Enterprise Security"; Ro Sailer, Lo Van Doom, J~R Ward www.trustedcomputingroup.org/press/news_articles/rc23363.pdf Information Rights Management in Microsoft Office 2003" www.microsoft.com/technet/prodtechnol/ office/office2003/operate/of03irm.mspx Enterprise Rights Management for document protection; www.authentica.com/request/downloadwp. aspx?fileId=ERM_doc_protectopdf Whitepaper Sealed Media Core Technology; http://www.sealedmediaocom/products/wp_core_technology.pdf TCG Specification Architecture Overview; www.trustedcomputinggroup.org/downloads/TCG 1 0 Architecture_Overview.pdf TCG Trusted Network Connect; www.trustedcomputinggroup.org/downloads/specifications/TNC_ Architecture_vl 0 r4.pdf "Auf dem Weg zur multilateral-sicheren Rechnerplattform - Mit Open-Source und Trusted Computing"; A-Ro Sadeghi, M. Selhorst, C. S~ble, A. Alkassar; Bundesamt far Sicherheit in der Informationstechnik "IT Sicherheit geht alle an!'" Tagungsband BSI Kongress 2005; ISBN 3-922746-99-3 ,,Informationsschutzim Unternehmen"; Magazin DuD - Datenschutz und Datensicherheit; Ausgabe 09/2005; Vieweg Verlag; http://www.dud.de

U nterneh mensweites TPM Key Management Bernhard Weiss Utimaco Safeware AG BU Transaction Security [email protected]

Zusammenfassung Einen Weg zu finden, die sicherheitssensitiven Schlt~sselinformationen eines ,,Trusted Platform Modules (TPM)" zentral zu administrieren und von dem Potential eines TPM zu profitieren, ist aktuell eine der Aufgaben in den meisten Untemehmen. Unternehmeskunden fordern ein zentralisiertes Sicherheitsmanagement, um verl~tssliche Sicherheit garantieren und kontrollieren zu k6nnen. Sicherheitsmechanismen, welche durch den Benutzer administriert werden, bieten den Unternehmen keine verlgl31icheSicherheit. Bei dem Vergleich mit den standardm~iBig verfagbaren Backupwerkzeugen heutiger Betriebssysteme f~illtauf, dass keine bzw. nur eingeschr~inkt Werkzeuge ffir die Sicherung und Wiederherstellung von TPM spezifischen Schlt~sselmaterialien vorhanden sind. Des Weiteren tendieren existierende Wiederherstellungsl6sungen dazu, das Backup und Restore dem Benutzer zu t~berlassen. Im nachfolgenden Artikel wird durch die Kombination von verftigbaren Technologien eine zentrale Sicherheitsinfrastruktur zum sicheren Backup, zur Wiederherstellung und zur Migration, des TPM Schltisselmaterials, unter Verwendung der Hardware-Sicherheitsmodul Technologie, vorgestellt.

1 Einsatz von T P M in U n t e r n e h m e n Wurde ein ,,Trusted Platform Module (TPM)" in der Vergangenheit noch als verd~ichtiger ,,Fritz Chip", der negative Aufmerksamkeit erregt, angesehen, so hat sich dieses Bild hin zu einem akzeptierten Standard gewandelto Dies spiegelt sich vor allem in der Bandbreite der Endger~te [TCG] wieder, welche einen TPM Chip enthalten. Darfiberhinaus wird erwartet, dab die Verbreitung von TPM Chips sowohl in Desktops wie auch Laptops in den n~ichsten Jahren weiter wachsen wird. Experten gehen davon aus, dass im Jahr 2010 nahezu 100% aller ausgelieferten Laptops, sowie 90% aller verkauften Desktopger~ite eine TPM Einheit enthalten werden. Worin liegt der Reiz bzw. der Vorteil in der Nutzung eines TPM? EIN TPM ist ein im Endger~it fest installierter Mikrocontroller welcher Schltissel, Passw6rter und Zertifikate sicher speichem kann. Als zus~itzlicher Baustein erweitert ein TPM die Systemarchitekmr z.B. eines Laptops um Sicherheitsfunktionen zur Generierung von Schlt~sseln, zur Erzeugung von elektronischen Signaturen und zur Datenverschlftsselung, um nur eine Auswahl der M6glichkeiten zu nennen. Die Sicherheitsfunktionen werden t~ber spezifizierte und standardisierte Schnittstellen in das System bzw. die Anwendungen integriert. Von der Nutzung eines TPM profitieren Anwendungen wie z.Bo Festplattenverschlfisselungs- oder Authentifiziemng-/Identifizierungsl6sungen.

N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 140-155

Unternehmensweites TPM Key Management

141

Im Rahmen des untemehmensweiten Einsatzes stellt sich nun die Frage, welche M6glichkeiten stehen dem Untemehmen zur zentralen Verwalmng und Kontrolle der, durch ein TPM pro Endger/it gescht~tzten sensitiven Schl~sselinformationen zur Verffigung? Hier ist zu p~fen, ob und welche Schlt~ssel zentral verwaltet und gesichert werden mt~ssen und k6nnen. Des Weiteren ist zu kl~iren, wie kann eine entsprechende L6sung in die bereits vorhandenen und etablierten Prozess- und Rollenstrukmren integriert werden. Ein Aspekt ist hierbei die Reduzierung der Administrationskosten, die Verbesserung der Interoperabilit~it zwischen den einzelnen TPM Implementationen sowie die Vereinfachung der Backup- und Restore-Mechanismen zur Sicherung der Schlfisselinformationen, welche zur Sicherung der Daten z.B. auf einem Desktop bzw.-Laptop verwendet werdeno Eine entscheidende Rolle spielt jedoch die Frage der Schlfisselgenerierung bei der Einftihrung von TPM gesttitzten Prozessen. Insbesondere die Realsierung yon vertrauenswfirdigen und leistungsf'~ihigen kryptographischen Prozessen sowie ein effektives Schlfisselmanagement erforderen eine sorgf~iltige Planung. Der erste Teil dieses Artikels illustriert die Herausfordemngen in Bezug auf das Schlfisselmanagement bei der Einffihmng von TPM. Der zweite Teil diskutiert L6sungskonzepte bei der Umsetzung eines unternehmensweiten TPM Schlfisselmanagements.

2 IT Management im Unternehmen Untemehmen, die vor dem Hintergrund der derzeit stattfindenden technologischen Revolutionen- insbesondere im Bereich des ,,Mobile Computing"- versuchen, ihre Gesch~iftsprozesse zu optimieren, sehen sich heute ganz anderen Bedrohungen ~ r die Datensicherheit gegenfiber, als dies in der Vergangenheit der Fall war. Vor allem im Bereich der mobilen Endger/~te erfordert der allgegenw~irtige Anstieg in den Bereichen Computerkriminalit~it, -betrug, -spionage, Datendiebstahl und Datenverlust auf Grund technischer Defekte oder menschlichen Fehlverhaltens das Bedfirfnis nach verstfirktem Schutz der Unternehmensdaten. Dem erh6hten Schutzbedarf haben Untemehmen durch die Einft~hmng der Datenverschlfisselung auf vielen E b e n e n - vonder E-Mail Kommunikation, fiber die Datenverarbeitung, den Datenaustausch bis hin zur vertraulichen Datenablage- Rechnung getragen. Mit dem breit gef~icherten Einsatz der Datenverschltisselung zum Schutz der sicherheitsrelevanten Untemehmensdaten gegen Verlust oder Diebstahl steigen die Anforderungen hinsichtlich Erzeugung, Anwendung, Verteilung, Austausch und Archivierung der zur Schutz der Daten verwendeten kryptographischen Schl(issel. Gerade im Bereich des ,,Mobile Computing" geh6rt die sichere Speicherung und Anwendung der kryptographischen Schlfissel zu den Schlftsselfaktoren in Bezug auf die Authentizit/~t, Integrit/~t und Vertraulichkeit der Daten. Deshalb bedt~rfen diese Schlftssel eines besonderen Schutzes gegen Angriffe und unberechtigtes Auslesen. Trusted Platform Module (TPM) bieten ein hohes Mag an Sicherheit bei der Speicherung, Verarbeitung und Verwaltung von Schlt~sseln. Passw6rtem und Zertifikaten. Die fest in das Endger/~t integrierten TPM stellen dem Betriebssystem Sicherheitsfunktionen zur Generierung von Schlfisseln, zur Erzeu-

142

Unternehmensweites TPM Key Management

gung von elektronischen Signaturen und zur Datenverschlt~sselung, um nur eine Auswahl der M/SgIichkeiten zu nennen, unmittelbar und dauerhaft zur Verfagung. Entscheidend im Hinblick auf den Einsatz eines TPM im Unternehmensumfeld ist die Beantwortung der offenen Fragen in Bezug auf die Realisierung eines vertrauenswfirdigen und effektiven Schlt~sselmanagements zur zentralen Verwaltung und Kontrolle der sensitiven Schl%selinformationen.

2.1 IT Security Policy Verl~issliche Sicherheit erfordert zentrale Sicherheitsverwaltung. Sicherheitsmechanismen, deren Einsatz der KontroUe durch den Benutzer unterliegen, bieten dem Unternehmen keine zuverlgssige Sicherheit. Man kann sich nicht darauf verlassen, dass Benutzer- selbst wenn sie geschult sind - die Sicherheitsmechanismen auch tatsfichlich anwenden, sei es aus Bequemlichkeit, Unwissenheit oder sogar b~swilligen Grfinden. Deshalb ist es im Unternehmensumfeld unverzichtbar, Einstellungen und Regeln der Sicherheitssoftware zentral vorgeben, kontrollieren und durchsetzen zu k6nnen. Dafar ist die Sicherheitsadministration verantwortlich. Zu ihren Aufgaben geh6ren u.a. 9 Planung der Sicherheitsregeln, Definition der Konfigurationseinstellungen- Anpassung einer Sicherheitssoftware an die individuellen Sicherheitsanforderungen der Organisation, 9 Installation und Verteihmg der Sicherheitssoftware auf die Clients, 9 Initialverschlt~sselung, 9 Durchsetzung der Sicherheit; Uberwachung der Wirksamkeit der Sicherheitsmechanismen, 9 Wartung - Akmalisierung der Sicherheitssoftware, 9 Entwicklung und Anwendung von Backup- und Restore-Strategien sowie 9 Support der Sicherheitssoftware. Der nicht nachlassende Kostendruck in den Unternehmen erfordert von IT-Abteilungen hohe Produktivit~it. Dies bezieht sich selbstverst~indlich auch auf die Sicherheitsadministration und den Helpdesk. So sind mobile Anwender, welche fern der Infrastruktur ihrer Firma arbeiten, verst~irkt yon der korrekten Funktionsweise ihres ,,mobilen Bfiros" abh~ingig. Treten technische Probleme auf, so ist es essentiell, dass die Funktionsf'~ihigkeit und damit die Produktivit~it in kfirzester Zeit und mit geringstem Aufwand, vor allem ohne ,,Onsite"-Support, wieder hergestellt werden kann. Daher werden Helpdesk L6sungen zur schnellen und kostensparenden Wiederherstellung von Passw6rtern bzw. Schlfisseln zwingend ben6tigt. Eventuell kann dem Benutzer auch die Wiederherstellung ,,Online", ohne den Rfickgriff auf Helpdesk-Personal, erm6glicht werden. Des Weiteren sind bei der Auswahl und Einfahrung von IT Management L6sungen die unterschiedlichen IT Administrationsrollen, welche im jeweiligen Unternehmensumfeld etabliert sind, zu berficksichtigen. Die folgenden Rollen werden unterschieden: 9 IT Administration, 9 IT Security Administration und 9 Identity Management. Die IT Administration zeichnet verantwortlich far den Helpdesk sowie den Rollout von Hard- bzw. Software. Aufgabe des Identity Managements ist die Bereitstellung von Trustcenter Dienstleistungeno Im Bereich der IT Security Administration werden die unternehmensweiten IT Security Richtlinien definiert und die Einhaltung derselben t~berwacht.

Unternehmensweites TPM Key Management

143

Die fttr die Administration verantwortlichen Bereiche mfissen in die Lage versetzt werden, Sicherheit16sungen in die aktuelle bzw. zukfinftige Sicherheitsinfrastruktur schnell und mit geringem A u f w a n d integrieren zu k6nnen. Diese A n f o r d e r u n g e n stellen eine e n o r m e H e r a u s f o r d e r u n g an die Hersteller von individuellen S e c u r i t y - M a n a g e m e n t L6sungen. Insbesondere die Kompatibilit~it zu aktuellen IT- und Sicherheitsstandards ist entscheidend ffir die reibungslose Integration in eine bestehende Infrastruktur, ebenso wie die zuldinftige A n b i n d u n g neuer 3rd-party M o d u l e oder Security Hardware. Weitere Hera u s f o r d e r u n g e n sind die s t a n d a r d k o n f o r m e U m s e t z u n g , Integration in die v o r h a n d e n e n Organisationsstrukturen und - p r o z e s s e sowie intensive Kompatibilit~itstests. Die U m s e t z u n g der soeben aufgeffihrten Kriterien sind entscheidend flir die A k z e p t a n z yon T P M Schlfisselmanagement L 6 s u n g e n im u n t e r n e h m e n s w e i t e n Einsatz.

2.2 Unternehmensweites TPM Key Management heute I m Prinzip generiert, speichert und verwaltet ein Trusted Platform M o d u l e (TPM) kryptographische Schlfissel. Ein T P M unterscheidet bei der Verarbeitung verschiedene Arten von k r y p t o g r a p h i s c h e n Schlfisseln:

Tabelle 1" TPM Schliisselart

Schl%seltypen

] Nutzungsart

] Migrierbar?

Speicherung direkt innerhalb des TPM Bausteins. EK Endorsement Key

TPM spezifischer Schlfissel, welcher zum Identitgtsnachweis des TPM Bausteins und damit der Plattform genutzt werden kann. Wird nicht zur Signatur oder Verschl~isselung verwendet.

Nein

SRK Storage Root Key

2048bit RSA Schlfissel zur Speicherung der auf3erhalb des TPM abgelegten Schl~issel. Oberster Schlfissel der TPM Schlt~sselhierarchie.

Nein

Speicherung auBerhalb des TPM (z.B. Festplatte) geschiitzt durch SRK. AIK Identity Attestion Key

Signaturschl~ssel welche ausschlief31ich zur Signatur von TPM generierten Daten, zum Nachweis der Identit~t, verwendet werden.

Nein

Signing

Generischer asymmetrischer Schlfissel zur Signatur von Nachrichten oder Daten.

Abh~ingig vonder Generierung.

Storage

Generischer asymmetrischer Schliissel zur Verschlfisselung von Daten bzw. weiteren Schliisseln.

Abh~ingig vonder Zuordnung (migrierbare oder nicht migrierbare Schlfissel).

Binding

Schlfissel welche zur Bindung an ein TPM, bzw. zum Schutz sensitiver Daten (Transport von Daten zwischen zwei TPM) verwendet werden.

Abh~ngig von der Generierungo

Legacy

Extern generierte Schlt~ssel, welche nachtr~glich in das TPM importiert wurdeno Diese Schl~ssel k6nnen zur Signatur bzw. Verschlt~sselung eingesetzt werden und sind per Definition migrierbar.

Authentication

Symmetrische Schliissel zum Schutz von Kommunikationsdateno

Nein

Authorisierungsdaten zum Schutz der SchI~ssel. User secret

Benutzerpasswort welches bei jedem Zugriff auf einen Schlt~ssel angegeben werden muss, sofern dieses zuvor gesetzt wurde.

Nein

Migration secret

Migrationspasswort welches bei der Migration eines Schlfissels angegeben werden muss, sofern dieses zuvor gesetzt wurde.

Nein

144

Unternehmensweites TPM Key Management

Die in Tabelle 1 aufgelisteten Schlfisseltypen werden in Bezug auf den Speicherort- innerhalb des TPM aul3erhalb des T P M - sowie der Migrationseigenschaft unterschiedeno

-

So werden innerhalb eines TPM nur der ,,Endorsement Key (EK)" und der ,,Storage Root Key (SRK)" gespeichert. Jeder weitere, der durch das TPM erzeugten oder gescht~tzten Schltissel wird mittels des SRK verschlCtsselt und im Normalfall dauerhaft auf der lokalen Festplatte gespeichert (siehe Abbildung 1). Bei einem Defekt des TPM oder bei einer Anderung des SRK, mt~ssen alle Schl{issel welche direkt mit dem SRK verschlt~sselt waren, auf den SRK des neuen TPM bzw. den ge~tnderten SRK umgeschlt~sselt werden. In Bezug auf die Migrationseigenschaften werden die folgenden Typen unterschieden: 9

nicht-migrierbare Schlfissel

9 migrierbare Schltissel und 9 zertifizierbare, migrationsf'~ihige Schlt~ssel. Die M6glichkeit der Zertifizierung eines migrationsf'~thigen Schlfissels wurde erst mit der Version 1.2 der TPM Spezifikation geschaffen. Nachfolgend werden die Migrationseigenschaften der Schliissel weiterfahrend untersucht.

2.2.1 Migrierbare und nicht-migrierbare Schl~issel TPM generierte Schlt~ssel welche bei der Erzeugung als transferierbar markiert wurden, werden auch als migrierbare Schlftssel bezeichnet ~Demgegent~ber stehen die nicht migrierbaren Schlfissel. So sind z.B. alle ,,Identity Attestion Keys (AIK)", sowie der ,,Endorsement Key (EK)" bzw. der ,,Storage Root Key (SRK)" nicht migrierbar. D.h. eine Sicherungskopie dieser Schltissel kann nicht erstellt werden~ Die Migrationseigenschaft wird durch die Applikation gesetzt, welche den Generierungsvorgang initiiert hat. Eine nachtr~igliche Anderung der Migrationseigenschaft eines generierten Schlt~ssels ist nicht mehr m6glich. Wie in Abbildung 1 dargestellt, werden die migrierbaren und nicht-migrierbaren Schl%sel in getrennten Teilb~iumen unterhalb des SRK gespeichert. Des Weiteren sind jedem Speicherschlt~ssel zwei Passw6rter zugeordnet. Hierbei handelt es sich um das Benutzerpasswort (User secret) und das Migrationspasswort (Migration secret). Das Benutzerpasswort dient zur Authorisierung der Nutzung des Schlt~ssels. Das Migrationspasswort authorisiert den Export der, unter dem Speicherschlfissel, abgelegten Schlfisselinformationen.

Untemehmensweites TPM Key Management

145

En6orse~en[ Key

D St~a~, Root Key I

Key

,-

Sle';~

I ......

|

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

I

i

9 ~_ ~ . I (z_B. Festplaf~.e) ..,~,.

\

[

i "*~ t !: N

It

]t

Id~t~tsscNas~ (AIK)

f

i i D

SN|@!eNcNasset

I I

NTr~ migrierbas,-e S,chl~s.sel

9

""---"---...____._____~______

_, ~ i

l

I

Signatur~hFJssel

i i ~

. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I I

i i

Mig~erbare -Sd~[fi~sel

VerscNfisse~

~

i

i Ver~chl{~elte D~ten I j

,

/

Abbildung 1: TPM Schltisselspeicher N a c h f o l g e n d eine Kurzfibersicht der wichtigsten E i g e n s c h a f t e n v o n m i g r i e r b a r e n bzwo nicht-migrierbaren Schlfisseln.

Tabelle 2: Eigenschaften von migrierbaren vs. nicht-migrierbaren Schltisseln Migrierbare Schliissel

Nicht-migrierbare Schlfissel

Erzeugung

Migrierbare Schliissel k6nnen innerhalb und au6erhalb eines TPM erzeugt werden.

Nicht-migrierbare Schlfissel miissen innerhalb des jeweiligen TPM erzeugt werden.

Bindung

Diese Schlt~ssel sind nicht an ein TPM gebunden. Es k6nnen extern generierte Schliissel importiert werde.

Diese Schliissel sind an das TPM gebunden, von dem diese erzeugt wurdeno

Migrierbare Schltissel k6nnen durch den Eigentiimer unbegrenzt vervielf~iltigt werden.

Ein Duplikat z.B. in Form einer Sicherungskopie kann nicht erstellt werden.

Die Anzahl der Kopien ist nur dem Eigen~mer bekannt.

Speicherung

Der Import extern generierter Schliissel zur sicheren Speicherung durch ein TPM ist m6glich. Die Erstellung einer Sicherungskopie ist m6glich. Migrierbare Schl~issel sind durch ein ,,Migration secret" vor nicht authorisierter Vervielf~ltigung geschiitzt.

Der private Schltissel eines nicht-migrierbaren Schliisselpaars ist niemals in Klartextform au6erhalb des TPM verfiigbar.

146

Untemehmensweites TPM Key Management

Der Transfer eines migrierbaren Schlfissels zwischen zwei TPM benOtigt die entsprechende Vorbereitung der Zielplattfrom sowie die Kennmis des ,,Migration Secrets" des zu migrierenden Schltissels. Nachfolgend wird die Migration eines Schlfisels kurz beschrieben. Migration eines SchlfJssels Key_A von TPM_A zu TPM_B

TPM A

TPM B % Erz~ugur~ees Se~as~eipaa~sKeya . -",..,,

9

tt--[5;bertra~mg6Z~nifii~'ke.rreild~<~ "~ -

1

i

*

.

.

"

.

.

.

.

.

.

.

.

.

.

....... 4........ :- .....................

.........

.

.

.

.

.

.

.

.

.

--

\i %%.

~--}

9

...........

9

I

",._ ................. 7 ............................................ ;" ...................... j .........

Abbildung 2" Migration eines Schl%sels zwischen zwei TPM Ziel ist die Migration eines Schltisselpaars Key_A von TPM_A zu TPM_B. ~ Key_A ist z.B. durch den SRK des TPM_A geschfitzt. Der private Tell des Key_A ist mit dem 6ffentlichen Teil des SRK des TPM A verschltisselt. 9 Der Key_A soll auf der Zielplattform unterhalb des Speicherschlftssels Key_B abgelegt werden. 9 Zur Durchfiihrung des Transfers wird auf der Zielplattform TPM_B der Key_B durch Aufruf der Funktion TPM_AuthorizeMigrationKey vorbereitet (erzeugt). 9 Der dadruch erzeugte, 6ffentliche Teil des Key_B wird von TPM_B aufTPM_A tibertrageno 9 Durch den Aufruf der Funktion TPM CreateMigrationBlob auf TPM_A, unter Verwendung des Key_B, erfolgt die Umschltisselung des Key_A. Der Key_A wird hierbei nach der Entschlftsselung, unter Verwendung des privaten Teils des SRK, mit dem 6ffentlichen Teil des Key_B verschltisselt. Zur erfolgreichen Durchffihrung des Kommandos ist die Kenntnis des ,,Migration Secrets" yon Key_A notwendig. 9 Der umgeschlfisselte Key_A kann nun auf TPM_B iibertragen und unterhalb des Key_B abgespeichert werden.

Die Migration eines Schliissels von einem TPM Chip zu einem Zweiten bedarf der Interaktion auf beiden Seiten. Des Weiteren ist die Zustimmung des Schltisselinhabers notwendig. Dies bedeutet, dass eine automatische Backupfunktion ftir migrierbare Schlftssel unter Umst~inden vom Schlfisselinhaber blockiert werden kann. Des Weiteren ist es von dem Eigentftmer des jeweiligen Schlfissels abh~ingig, wieviele Kopien erzeugt werden.

2.2.2 Zertifizierbare migrationsf~ihige SchlLissel Die bisher beschriebenen Migrationskonzepte (siehe Kapitel 2.2.1) wurden in der tiberarbeiteten Spezifikation Version 1.2 des TPM durch den ,,Certifiable Migration Key (CMK)" erg~inzt~Mit der Methode

Unternehmensweites TPM Key Management

147

der zertifizierbaren Migration- Certifiable Migration (CM) - wird die M6glichkeit zur Wahl eines vertrauenswfirdigen Dritten geschaffeno Diese auch als ,,Migration Authority (MA)" bezeichnete Instanz koordiniert die Migration eines migrierbaren Schlfissels bzw. CMK. Eine Migration kann dabei direkt fiber die MA bzw. durch Vermittelung seitens der MA erfolgeno Zur Migration eines CMK ist ein Authorisierungtoken erforderlich, welches auf der Basis von privaten Schlfisseln (Signatur des CMK Zertifikats) generiert wird~ Die dazugeh6rigen 6ffentlichen Schlfissel sind Bestandteil des CMK Pakets. Anhand der Signatur eines CMK Zertifikats kann festgestellt werden, ob der CMK durch ein gfiltiges TPM geschfitzt wird und ob eine Freigabe durch einen Dritten ben6tigt wird, bevor der CMK kopiert werden kann. Des Weiteren kann dieses Szenario durch die ,,Migration Selection Authority (MSA)" erweitert werden~ Aufgabe der MSA ist die Authorisierung des Migrationsziels. Bei der Verwendung einer MSA erfolgt, neben der Authorisierung des Migrationsziels durch den Besitzer des TPM, sowie der Freigabe durch den Inhaber des zu migrierenden Schlfissels, eine zus~itzliche Authorisierung des Migrationsziels. Durch die Umsetzung des Konzepts der MSA kann eine Kontrollinstanz eingeffihrt werden, so dass ohne Genehmigung der MSA kein Schlfissel migriert werden kann.

2.2.3 TPM Benutzer vs. Besitzer Der Besitzer eines TPM kontrolliert den Zugriff auf den EK und SRK eines TPM Bausteins. Hierzu wird das ,,User secret" verwendet, welches in Form eines Passworts, innerhalb des geschfitzten Bereichs des TPM, gespeichert wird. Das ,,User secret" wird, ebenso wie der SRK, bei dem Kommando TPM_TakeOwnershiperzeugt. Damit der zuldinftige Besitzer den TPM Chip nutzen und das ,,User secret" setzen kann, muss der TPM zuvor im BIOS aktiviert werden. Seit der Version 1.2 der TPM Spezifikation wird die Delegation von Aufgaben zur Trennung zwischen TPM Besitzer und TPM Benutzer unterstfitzt. Der TPM Besitzer kann Operationen und Schlfissel spezifizieren und die Nutzung dieser mit zus~itzlichen Passw6rtern sichern. Dieser Mechanismus erlabut die effektive Trennung von Aufgaben. So k6nnen im praktischen Einsatz die IT-Administratoren als Besitzer definiert werden, w~ihrend der Benutzer nur die freigegebenen Funktionen und Schl(issel verwenden kann. Insbesondere die Migration von Schlfisseln kann effektiv an die Rechtevergabe gekoppelt werden.

2.2.4 Zusammenfassung TPM Key Management heute Ffir den unternehmensweiten Einsatz von TPM bestfickten Laptops oder Desktops stehen die Konzepte zur Migration der entsprechend markierten Schlfissel zur Verffigung. So kann die Migration von Schlfisseln direkt bzw. durch Vermittelung seitens der ,,Migration Authority (MA)" erfolgen. Dieses kann durch den Einsatz einer ,,Migration Selection Authority (MSA)" dahingehend erweitert werden, dass das Migrationsziel von einem Dritten vorgegeben werden kann und nicht mehr alleine dem TPM Besitzer fiberlassen ist. Des Weiteren kann eine effektive Trennung zwischen TPM Besitzer und Benutzer realisiert werden, welches die M6glichkeit zur Migration von Schlfisseln an die Rechtevergabe koppelto Ist dies die ideale L6sung far ein unternehmensweites TPM Key Management?

148

Unternehmensweites TPM Key Management

Nein, der Nachteil der bisher beschriebenen M6glichkeiten ist in der dezentralen Verteilung der Aufgaben zu seheno Die Schlt~sselgenerierung erfolgt aufjedem TPM individuell und erfordert, um jeglichen Datenverlust ausschliegen zu k6nnen, eine zeitnahe (unmittelbare) Sicherung aller erzeugten Schltissel durch den TPM Besitzer bzw. Benutzer. Des Weiteren muss bei der Schlfisselgenerierung sicher gestellt werden, dass nur migrierbare Schlftssel far die Verschl~isselung von unternehmenskritischen Daten zum Einsatz kommen. Da dies jedoch dem Anwender, bzw. der Applikation welche die Schlftssel erzeugt, obliegt, kann diese Anforderung nicht erfallt werden. Im nachfolgenden Kapitel werden die Anforderungen an ein unternehmensweites TPM Schlt~sselmanagement weiter detailiert.

2.3 Anforderungen an ein unternehmensweites TPM Key Managment Ausgehend von den bereits beschriebenen M6glichkeiten und Konzepten zum Management von TPM spezifischen Schltisseln wird nachfolgend die Frage der Schlt~sselgenerierung in Verbindung mit den Folgen far Backup und Recovery betrachteto Bisher wurde nur die M6glichkeit der Schlt~sselgenerierung durch ein TPM diskutiert. Die Generierung erfolgt hierbei dezentral durch den Anwender bzw. die Applikation far jeden TPM Baustein individuell. Daraus folgt, dass die Sicherung der TPM spezifischen Schlt~ssel ebenfalls individuell far jedes TPM einzeln, durch den jeweiligen Benutzer, erfolgen muss. Warren nicht einfach extem generierte RSA Schlftsselpaare in ein TPM importieren? Welche Optionen ergeben sich durch den Import von RSA Schlfisselpaaren in ein TPM hinsichtlich des Zugriffs auf die verschl(isselt gespeicherten Daten? Bevor diese Frage gekF,irt werden kann, ein kurzer Blick auf die zur Verfagung stehenden Betriebssystem eigenen Werkzeuge zur Verwaltung der TPM Schlt~sseln. Im Vergleich zu den Standard Datensicherungswerkzeugen bieten heutige Betriebssysteme keine Backup und Wiederherstellungsprozeduren far TPM spezifische Schlt~ssel an. Des Weiteren sind die am Markt verfagbaren Schlfisselmanagementl6sungen auf die Backup- und Restoremechanismen wie in [BaMS] spezifiziert beschr~inkt. D.ho die in Kapitel 2 aufgefahrten Anforderungen an ein unternehmens= weites IT-Management werden in Bezug auf die TPM Schlfissel nicht erfallt. 9 Dies wttrde far einen Benutzer, welcher sich nicht auf einen Defekt des TPM vorbereiten will, bedeuten, dass dieser nach dem Austausch des defekten Ger~ites eine Neuinstallation des kompletten Systems mit anschlief3ender Generierung neuer TPM spezifischer Schlt~ssel durchfahren muss. Der Zugriff auf zuvor verschl(isselt gespeicherte Daten w~ire verloren. 9 Die Benutzer, die sich auf diese Art von AusfNlen vorbereitet wollen, nutzen entsprechend verfagbare Backup- und Wiederherstellungswerkzeuge um die TPM spezifischen Schlt~ssel zu restaurieren. 9 Unternehmen die bereits eine PKI im Einsatz haben, nutzen bereits ger~itebezogene RSA-Schlfisselpaare (z.B. far den VPN-Zugang) oder m6chten die Schlfissel aufgrund der eigenen Richtlinien zentral generieren~ Eine Sicherung der Schlftssel k/Snnte somit ebenfalls zentral erfolgen. Damit ergeben sich drei unterschiedliche Modi, aus denen gew~ihlt werden kann.

Unternehmensweites TPM Key Management

149

2.3.1 Keine Wiederherstellung der TPM Schl~issel Die Schl~ssel werden ausschliel31ich durch das TPM generiert. Eine Sicherungskopie wird nicht erstellt. D.ho bei einem Defekt des TPM Chips bzw. dem Austausch des SRK k6nnen die, mit den TPM Schlt~sseln gesicherten Daten nicht wiederhergestellt werden. Vorteile: Keine Nachteile: Alle Daten, welche durch die mittels TPM Baustein generierten Schlfissel gesichert werden, sind im Falle eines Defektes verloren.

2.3.2 Recovery mittels verf~igbarer Backup- und Restorewerkzeuge Die Wiederherstellung der vom TPM generierten und verwalteten Schlt~ssel - migrierbare Schl%selerfolgt durch den Benutzer unter Verwendung handels~blicher Backup- und Recoverywerkzeuge. Es liegt in der Verantwommg des Benutzers die Sicherungskopien zu erstelleno Im Falle eines Defektes mt~sste der Benutzer die Wiederherstellung, nach dem Austausch des Ger~ites, selbstt~itig durchfthhren. 1. Vorteile: Die Schl~ssel k6nnen wiederhergestellt werden. Der Zugriff auf sensitive Daten kann gew~ihrleistet werden. 2. Nachteile: a. Der Benuzter ist far die Sicherung der Schlfissel verantwortlich. b. Der Benutzer muss in die Nutzung der Software eingwiesen werden. c. Die untemehmensweiten Richtlinien in Bezug auf Sicherung der Schlt~sselinformationen k6nnen nicht automatisch eingefordert und kontrolliert werden. d. Ein Untemehmen kann den Zugriff auf relevante Daten verlieren, wenn der Benutzer die hierzu ben6tigten Schlfissel nicht sichert bzw. explizit 16scht. e~ Die Software zur Sicherung der Schlfissel muss installiert und in die Updateprozesse integriert werdeno f. Vor-Ort Support f'ttr Augendienstmitarbeiter k6nnte erforderlich sein. g. Das Benutzer gesteuerte Sicherungsverfahren far die TPM spezifischen Schlfissel widerspricht den definierten organisatorischen Prozessen und Rollen.

2.3.3 Zentralisierte Generierung der TPM Schl~issel Die RSA Schl~ssel werden zentral durch eine PKI generiert, z.B. in Form einer PKCS#12 Schlt~sseldatei bereitgestellt und anschliel3end in ein TPM importiert, so wie es bereits heute mit handelsfiblichen PKI L6sungen und TPM Software L6sungen abbildbar ist. Die Wiederherstellung des Schlfisselmaterials ist bei dieser Art der Vorgehensweise in jedem Fall gegeben, da die Schlfissel zentral durch die PKI gesichert werden k6nnen. 1. Vorteile: a. Vollst~indigeKontrolle t~ber die Schl%selgenerierung und-sicherung. b. Die L/Ssung ist transparent far den TPM Benutzer. Ein Training wird nicht ben6tigt. c. Die untemehmensweiten Richtlinien far das Schlt~sselmanagement k6nnen effektiv umgesetzt und kontrolliert werden. do Der Zugriff auf verschl~sselte Daten, auch wenn der Schlfissel explizit gel6scht wurde, ist sichergestellt.

150

Unternehmensweites TPM Key Management e. Helpdesk-Prozesse k6nnen dahingehend erweitert werden, dass ein Vor-Ort-Support nicht ben6tigt wird. fo Die Heldesk- und Administrationskosten werden durch die zentralisierte Umsetzung reduziert. g. Die Anpassung der Schl~sselmanagementfunktionen f'tir den Support unterschiedlicher TPM Versionen bzwo TPM Bausteine verschiedener Hersteller erfolgt an zentraler Stelle und muss somit nur einmal vorgnommen werden. h. Die Integration in die bestehenden organisatorischen Prozesse und Rollen ist m6glich. i. Die Kombination mit der benutzerorientierten Variante zur Sicherung der Schlfissel (siehe Kapitel 2.3.2) ist m6glich.

2. Nachteile: a. H6here Anschaffungskosten. b. Es sind h6here Support und Wartungskosten aufgrund der erweiterten Infrastruktur zu berficksichtigen. Abschliegend lfisst sich sagen, dass die zentrale Schlfisselgenerierung aus Sicht der Unternehmen die optimale L6sung darstellt.

2.3.4 Zusammenfassung der Anforderung an ein unternehmensweites TPM Key Management Der unternehmensweite Einsatz von TPM basierenden Sicherheitsl6sungen erfordert, zwecks vollst~indiger Kontrolle fiber das Schltisselmaterial und die damit verschlftsselten Daten, die zentrale Generierung der RSA Schlfisselpaare in Verbindung mit einer zentralen Backup und Restore Komponente. Nur ein zentrales Schlt~sselmanagement erlaubt die effektive Aufgabentrennung anhand der organisatorischen Richtlinien sowie die schnelle und kostenoptimierte Adaption an TPM Bausteine anderer Hersteller bzw. neuerer Bauart. Ffir den Anwender ist ein zentrales Schl~sselmanagement die optimale L6sung in Bezug auf die Wiederaufnahme der T~itigkeit nach einem Ger~itedefekt bzw. hinsichtlich der Transparenz zur Technik.

3 L6sungsskizze eines unternehmensweiten TPM

Key Managments

Ausgehend von den bisherigen Betrachtungen wird nachfolgend das abschliegende Konzept zum unternehmensweiten TPM Key Management auf der Basis einer zentralen Sicherheitsinfrastruktur, bestehend aus PKI, ,,Migration Authority" und Hardware-Sicherheitsmodul vorgestellt, welches die Sicherheit einer zentralen Schlfisselmanagementl6sung durch den Einsatz eines Hardware-Sicherheitsmoduls zur Generierung der RSA-Schl~ssel, sowie bei der Erzeugung der Migrationsdaten, weiter erh6hen kann.

3.1 Hardware-Sicherheitsmodul (HSM) Mit der Hardware-Sicherheitsmodul Technologie (HSM) - auch Host Security Modul genannt- wurde eine L6sung zum effektiven Schutz des Rechnersystem, auf dem kryptographischen Transaktionen ausgefffflrt werden und auf dem die zum Einsatz kommenden Schlfissel gespeichert sind, entwickelt. Ffir ein Hardware-Sicherheitsmodul gelten die folgenden allgemeinen Grunds~itzen:

Unternehmensweites TPM Key Management

15 1

9 Ein Computer muss so zuverl~tssig geschfitzt werden, dass seine Daten und Programme niemals manipuliert und ausgelesen werden k6nnen. 9 Die Kommunikation mit der Recheneinheit des HSMs erfolgt fiber einen Kanal, der keine Angriffe fiber die Anwendungsschnittstelle zul~isst. 9 Die Recheneinheit des HSMs ist mit einem Schutzsystem versehen, das Angriffe von augen sofort erkennt und darauf aktiv mit dem L6schen der gespeicherten Informationen reagiert, um die Vertraulichkeit der Daten zu garantiereno Der zuletzt genannte Grundsatz beschreibt genau die Eigenschaften welche mit dem Begriffmanipulationssichere (,,tamper-resistant") Hardware gemeint sind. Hierunter versteht man Sensoren zum automatischen Erkennen von Angriffen sowie Schaltungen zum Ausftthren entsprechender Gegenmagnahmen. Die aktuelle Generation der Hardware-Sicherheitsmodule verft~gen fiber Magnahmen zum Schutz vor: 9 Auslesen und Durchleuchten 9 Temperaturangriffen 9 mechanischen Angriffen 9 chemischen Angriffen 9 Manipulationen durch elektrische Spannung Die M6glichkeit zum Ausffihren entsprechender Gegenmaf3nahmen ist einer der Hauptunterschiede zwischen einem Hardware-Sicherheitsmodul und einem TPM. Des Weiteren sind die Erweiterbarkeit in Bezug auf neue Algorithmen und interne Applikationen, die Performance, der zur Ablage von Schlfisselinformationen vorhandene Speicherplatz sowie die M6glichkeit zur zentralen Administration der Schlfisselinformationen zu nennen. Eine entsprechende Gegenfiberstellung ist der nachfolgenden Tabelle zu entnehmen. T a b e l l e 3 : TPM versus HSM Funktionalit~it

TPM

HSM

Generierung von RSA Schlf~sseln

'/

'/

Interne RSA Einheit

't"

~/

RSA Verschliisselung (Verschl~sselung mit dem privaten Teil des RSA Schl~isselpaars)

'/

v/

RSA Signatur (Verschlfisselungmit dem 6ffentlichen Teil des RSA Schlfisselpaars)

v/

'/

Sichere Speicherung der privaten Schl~ssel

,/

u"

Sichere Speicherung einer grogen Anzahl privater Schlfissel Interne symmetrische Verschlfisselungseinheit

'/ v/

Sichere Verschlasselung von Massendaten mit symmetrischen Schlt~sseln Sichere Speicherung symmetrischer Schlt~ssel

~/ v/

,/

u"

Sichere Speicherung einer grof3enAnzahl symmetrischer Schlfissel

'/

Erweiterbarkeit um neue Algorithmen und Applikationen

r

Sichere Speicherung von Applikationen

'/

Hohe Performance in Bezug auf kryptographische Operationen

,1"

Sicheres Backup der Schlt~ssel Sicheres zentrales Schlfisselmanagmenteinschliel31ich Backup Aktive Gegenmal3nahmenzum Schutz der Daten und Schlt~ssel * Der migrierbaren Schliissel

'/*

'/ '/ r

152

Unternehmensweites TPM Key Management

Ein Hardware-Sicherheitsmodul wird idealerweise dann eingesetzt, wenn: 9 eine hohe Performance in Bezug auf die Schl%selgenerierung und Transaktionsverarbeitung entscheidend ist, ~ die Sicherheit des Schlfisselmaterials garantiert werden soil, ~ eine Trennung in IT-Security und IT-Administration ntowendig bzw. vorgegeben ist, ~ die Flexibilit~it in Bezug auf zukfinftige Erweiterungen bzw. Anpassungen vorzusehen ist und 9 Stablilit~it und Verfftgbarkeit ein Kriterium sin& Auf Grund dieser Eigenschaften ist ein Hardware-Sicherheitsmodul die ideale Erg~inzung der zentralen Sicherheitsinfrastruktur zum unternehmensweiten Key Management der denzentral, in denEndger~iten, eingesetzten TPM.

3.2 Zentrale Generierung der TPM Keys Migrationsdienste, wie in [BaMS] (siehe ,,Migration services") beschrieben, ist ein vom Client initiierte Interaktion mit einem ,,Service Provider (SP)". Im Normalfall handelt es sich bei dem SPum eine ,,Migration Authority (MA)", wo die Schlfissel in einer sicheren Umgebung generiert, bzw. hinterlegt werden um von einem authentisierten Client genutzt zu werden. Nach erfolgreicher Authentikation kann der Client ,,Migrations Packages (MP)" bereitstellen, abholen bzw. abfragen. Zus~itzlich kann das L6schung eines MP aus der Umgebung des MA erm6glicht werden. Neben der Bereitstellung von ,,Migration Packages" durch den Client k6nnen diese jedoch auch durch eine zentrale Instanz, hier die PKI in Verbindung mit der ,,Migration Authority" erstellt und bereitgestellt werden. Darfiberhinaus kann, durch die Nutzung von HSM, wie in Abbildung 3 dargestellt, zur Generierung und Administrations von TPM Schlfisselmaterial, garantiert werden dass: ~ das Schltisselmaterial zum Zugriff auf unternehmensrelevante Daten, welche auf Laptops oder Desktops gespeichert sind, jederzeit wiederhergestellt werden kann, 9 dass der Zugriff auf das Schlt~sselmaterial effektiv auf die geschulten und authorisierten Personen (IT-Security Administartoren) beschr~inkt werden kann und ~ das die kryptographischen Schlfissel zu jeder Zeit sicher verwaltet werden k6nneno Des Weiteren kann eine Option zur sicheren Wiederherstellung von Schlfisseln in Bezug auf Augendienstmitarbeiter implementiert sowie ,,Identity Management", ,,IT Administration" und ,,IT Security Administration" effektiv, entsprechend den organisatorischen Vorgaben, getrennt werden.

Unternehmensweites TPM Key Management

Desktops

153

Laptops ~-~'~-~'~---.

,..

(,F

PDAs

\

"-......_

IT Security Administration

iT Administration Abbildung 3" TPM SchlfJsselmanagementbasierend auf zentralisierten MA und HSMs

3.2.1 Zusammenfassung der L/Ssungsskizze Der untemehmensweite Einsatz von TPM basierenden Sicherheitsl6sungen erfordert, zwecks vollst~indiger Kontrolle fiber das Schlfisselmaterial und die damit verschlt~sselten Daten, die zentrale Generierung der RSA Schlfisselpaare in Verbindung mit einem zentralen Backup und Restore. Die Migration von Schlfisseln erfolgt direkt seitens der ,,Migration Authority (MA)".Die MA erh~ilt die zentral generierten Schl~ssel vonder PKI und stellt diese in Form yon Migration Packages far authentifzierte Clients zur Verfagung. Die Hardware-Sicherheitsmodule erh6hen die Sicherheit bei der Generierung der RSA-Schlt~ssel, sowie bei der Erzeugung der ,,Migration Packages" und erm6glichen eine effektive Rollentrennung bei der Erzeugung und Verwaltung des Schlfisselmaterials. Das zentrale Schltisselmanagement erlaubt die effektive Aufgabentrennung unter Berficksichtigung der organisatorischen Richtlinien sowie die schnelle und kostenoptimierte Adaption an TPM Bausteine anderer Hersteller bzw. neuerer Bauart.

154

Unternehmensweites TPM Key Management

4 Aktuelle Entwicklungen 4.1 Import extern generierter Schl~issel Aktuelle TPM Software Produkte wie z.B. das ,,TPM Professional Package" von Infineon [Infi] enthalten bereits Schnittstellen zum Import extern generierter Schlfissel und Zertifikate. Als Transportformat kommt hier das PKCS#12 [P12] Format zur Anwendung, welches den privaten RSA Schlftssel sowie das Zertifikat, Passwort gescht~tzt beinhaltet.

4.2 Migration Authority Implementierungen auf Basis des ,,Migration Authority" Konzepts werden von dem Unternehmen Wave Systems Corp. [Wave] angeboten. Des Weiteren bietet das Unternehmen Utimaco Safeware AG [USAG] mit SafeGuard Enterprise eine modulare L6sung far plattformfibergreifende Datensicherheit auf Endger~iten und Speichermedien an, welche auch TPM ,,enabled" Endger~ite mit einbezieht.

5 Fazit Die Einf'tihrung von TPM basierenden Endger~iten kann die Verfagbarkeit von Daten, welche auf diesen Endger~iten gespeichert sind, im Falle eines Defekts in Frage stellen. Durch die Implementierung einer zentralisierten L6sung zur Schl~sselgenerierung und-administration auf der Basis der Hardware-Sicherheitsmodul Technologie kann der Zugriff auf die durch TPM Schlfissel gescht~tzten Daten sichergestellt werden. Zus~itzlich kann der Zugriff auf das Schl~sselmaterial effektiv auf authorisierte Personen limitiert werden. Das vorgestellte Konzept stellt weiterhin sicher, dass die Anforderungen von Unternehmen an eine TPM Schlfisselmanagementl6sung, wie: 9 Zentrales Sicherheitsmanagement, 9 Produktivit~tt des IT-Personals wird nicht negativ beeinflusst und 9 Integration in die bestehenden Prozesse und Rollen erfallt wird. Aufgrund der Einfachheit und ,,Unsichtbarkeit (Transparenz)" far den Benutzer, erfibrigt sich eine Schulung im Umgang mit der L6sung. Damit wird kostbare, aus der Sicht der Unternehmen ,,unproduktive" Zeit eingespart. Dies kommte der Akzeptanz und damit letztendlich der Durchsetzung der Sicherheitsmechanismen in Unternehmen zugute.Dadurch das die Sicherheitsmechanismen zentral definier-, kontrollier- und durchsetzbar sind, wird der Benutzer automtisch seiner Mitverantwortung in Bezug auf die Einhaltung der unternehmensweiten IT-Security Policy gerecht ohne explizit t~itig werden zu mt~ssen. Nur durch den zentralen Einsatz von Hardware basierenden Sicherheitsl6sungen kann ein sicheres Framework far die Administration aller TPM Schl%selinformationen erreicht werden. Denn nur ein Hardware-Sicherheitsmodul verhindert, dass nicht autorisierte Personen sich Zugriff auf wichtige Schlfisseldaten verschaffen kOnnen. Das HSM sorgt ffir die sichere Generierung, Speicherung und Anwendung von kryptografischen Schlt~sseln und Zertifikaten und umfasst Verwaltungsfunktionen, die eine sichere und zuverlgssige Implementierung elektronischer Prozesse gew~ihrleisten.

Unternehmensweites TPM Key Management

155

Literatur [Arch] [BaMS] [Infi] [Kay] [LAG] [P12] [TCG] [USAG] [Wave]

TCG; TCG Specification Architecture Overview (Draft, work in progress); Revision 1.3, 28. March 2007; File: TCG 1 3 Architecmre_Overview.pdfo TCG; Interoperability Specification for Backup and Migration Services; Revision 1.0, 30 June 2005; for TPM Family 1o1b Level 1; File: IWG_Backup_and_Migration_Services.pdfo Infineon, TPM Professional Package, Version 3.0, http://www.infineon.com/. Kay, Roger L.; The Furore of Trusted Computing, IDC, GovSec 2005. Intel; LaGrande Technology, Preliminary Architecture Specification; May 2006; Link: http://www. intelocom/technology/security/. RSA Laboratories, PKCS #12, Personal Information Exchange Syntax Standard, Version 1.0, http:// www.rsa~ Trusted Computing Group, TPM enabled Products,https://www.trustedcomputinggroup.org/kshowcase/view. Utimaco Safeware AG, SafeGuard Enterprise, SafeGuard CryptoServer, http://www.utimaco.com/o Wave Systems Corp., Embassy Trust Suite, Embassy Key Management Server, http://www.wave. com/

Trusted Computing im Hochsicherheitsbereich Peter Kraaibeek 9 Hans Marcus K N g e r . Kai Martius secunet Sectmty Networks AG {Peter.Kraaibeek ] Hans.Krueger ] Kai.Martius} @secunet~

Zusammenfassung Anwendungen im Hochsicherheitsbereich bedt~rfen besonders vertrauensw~rdiger Komponenten und Architekmren. Bausteine des Trusted Computing wie TPM sollen zur Erh6hung der Sicherheit yon IT-Systemen beitrageno Sie sind auch im Hochsicherheitsbereich einsetzbar, es ist jedoch zu diskutieren, inwieweit sie den hohen Anfordemngen gent~gen. Nach einer kurzen Vorstellung des Begriffs Vertrauenswfirdigkeit und resultierender Sicherheitsanfordemngen diskutiert das Papier einige Aspekte, die bei dem Einsatz von TPM-Ger~iten relevant sein k6nnteno Anschlief3end wird der Ansatz ftir eine Sichere Inter-Netzwerk Architekmr vorgestellt, der ffir den Einsatz in Umgebungen mit sehr hohen Sicherheitsanforderungen geeignet ist.

1 VertrauenswOrdigkeit Die Nutzer yon informationstechnischen Systemen (IT-Systeme) verlassen sich im Allgemeinen darauf, dass diese so funktionieren, wie die Nutzer es w~nschen. Insbesondere erwarten diese, dass die Ger~ite genau die geforderte Funktionalitfit erbringen. Ebenso soll die Sicherheit der genutzten Anwendungen und der gespeicherten und fibertragenen Daten gew~ihrleistet werdeno Einerseits finden wir Sicherheitsanforderungen - seien sie formuliert oder implizit v o r h a n d e n - bei Business-Anwendern und Organisationen, die IT-Systeme professionell einsetzen, in der 6ffentlichen Verwaltung ebenso wie in Wirtschaftsuntemehmen~ Andererseits finden wir Sicherheitsanforderungen - fast immer nur implizit- bei Privatanwendem. Betroffen sind hier die Endnutzer von IT-Systemen ebenso wie die Anbieter von Diensten sowie AnNeter von Daten. So sollen etwa Leismngen, ffir die bezahlt werden muss, nur insoweit genutzt werden, wie hierfiir auch die Berechtigung gegeben ist~ Besonders hohe Anforderungen werden im Hochsicherheitsbereich im 6ffentlichen Bereich und in der Privatwirtschaft gestellt. Im Endeffekt ben6tigen alle Betroffenen Sicherheitsmaf3nahmen, die an ihre Einsatzgebiete und an ihren Bedarf angepasst sin& So gibt es unterschiedliche Interessen, die aber alle darauf abzielen, dass eine Umgebung bereitgestellt wird, die den Sicherheitsanforderungen aller Beteiligten entspricht~ Es muss also mehrseitige Sicherheit gewghrleistet werden. Einerseits mftssen die genutzten Endger~ite vertrauenswt~rdig sein, andererseits natfirlich auch die Infrastrukturen, Dienste und Serverkomponenteno Die Interessen der Endnutzer m~ssen ebenso wie die Interessen der Anbieter beracksichtigt werden.

N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 156-169

Trusted Computing im Hochsicherheitsbereich

157

2 Sicherheitsanforderungen Systeme k6nnen far einen Anwender nur dann vertrauenswt~rdig sein, wenn ihr Aufbau - in Hardware wie in Software - klar und transparent ist. Dabei muss die Komplexit~it der Systeme so beschaffen sein, dass diese insgesamt t~berschaubar bleiben und ihre Funktionalit~it nachvollziehbar ist [HoKr00]. Dies gilt sowohl fiir ihre Anwendungs-Funktionalit~it wie auch far ihre Sicherheitsmechanismen. Kommen hier zus~itzlich in Hardware realisierte Mechanismen zum Einsatz, so kann dies die Sicherheit und damit auch die Vertrauenswfirdigkeit noch einmal erh6hen. Jedoch ist dies kein Allheilmittel. Die Verwendung von Systemen, die eine m6glichst geringe Komplexit~it aufweisen, ist unabdingbare Voraussetzung far den Einsatz in Umgebungen, die besondere Anforderungen an die Vertrauenswfirdigkeit stellen. Dies ist auch eine Voraussetzung far eine ausreichende Oberprfifbarkeit- etwa durch unabh~ingige Instanzen. Geringe Komplexit~it ist in derzeitigen Standard-IT-Systemen bisher nicht - oder nur in Ausnahmefitll e n - zu finden. Handelst~bliche IT-Gergte sind somit insbesondere far Bereiche mit besonders hohen Sicherheitsanforderungen (Hochsicherheitsbereich) nicht einsetzbar. Hier mftssen Speziall6sungen eingesetzt werden. Diese k6nnen auch Neuentwicklungen sein. Durch geringe Systemkomplexit~it kann gegenfiber dem Anwender der Grad des Vertrauens transparent gemacht werden, etwa durch unabh~ingige Prtifungen. Der Anwender vertraut auf Basis solcher P ~ fungen dann m6glicherweise der Funktionalit~it und den Eigenschaften seines IT-Ger~its. Damit muss er aber nicht nur dem IT-Ger~it selbst trauen, sondern im Kommunikationsfall auch der zugrunde liegenden, von ihm genutzten Infrastruktur und wom6glich einigen, ihm zuvor nicht bekannte IT-Ger~iten, etwa denen seiner Kommunikationspartner. Im Endeffekt muss er damit den Herstellern und Anwendungsanbietern sein Vertrauen schenken. Dies ist jedoch nur m6glich, wenn es hier objektive Kriterien gibt, anhand derer ein Vertrauensbeweis gefahrt werden kann. Sollen hier zus~itzliche Sicherheitsmagnahmen eingebracht werden, etwa durch zus~itzliche HardwareModule, so sind eine Reihe von Anforderungen zu erft~llen. So d~rfen diese Technologien etwa den Privatnutzer nicht in seiner Freiheit beschneiden und dem Nutzer nicht unbemerkt die Kontrolle fiber seine pers6nlichen Daten entziehen. Es sollten nur Mal3nahmen eingebracht werden, die das Vertrauen in die eingesetzte IT erh6hen. Voraussetzung hierfar ist eine transparente Informationspolitik zu den eingesetzten Konzepten und Mechanismen. Zudem dttrfen durch die Mechanismen keine Marktzugangsschranken geschaffen werden. Alle enthaltenen Funktionen mfissen auch entsprechend dokumentiert werden. Die P~fbarkeit durch unabMngige Instanzen muss gew~ihrleistet werden. Bei Multimedia-DRM sind gesetzliche Bestimmungen zu beachten. So ist etwa das Recht auf Privatkopie zu beNcksichtigen. Schlfissel in TPM mfissen auf andere Hardware-Plattformen migrierbar sein, insbesondere auch bei defektem TPM. Sowohl urheberrechtlich geschfitzte wie auch nicht geschfitzte Daten mt~ssen auf andere HW-Plattformen migrierbar sein. TPM darfkein Single-Point-of-Failure werden. Diese Anforderungen sind einerseits im Entwicklungsprozess, andererseits beim Betrieb von vertrauenswfirdigen IT-Systemen zu berficksichtigen.

3 Trusted Computing im Entwicklungsprozess Informationstechnische Systeme, die hohen Sicherheitsanforderungen genfigen sollen, haben einen besonderen Entwicklungsprozess zu durchlaufen.

158

Trusted Computing im Hochsicherheitsbereich

Dies beginnt in der Phase der Definition der Anforderungen und setzt sich fort im System- und Softwaredesign sowie in Realisierung, Test, Evaluierungen und Zulassungen. Hierzu geh6rt etwa 9 vertrauenswf~rdiges Personal 9 eine vertrauenswfirdige Entwicklungsumgebung 9 die Beschr~inkung der Funktionalit~it auf die unbedingt notwendige. Dies soll zu geringerer Systemkomplexitgt fahren. Der Grad der Komplexit~it spielt ~ r die Sicherheit von Systemen eine wesentliche Rolleo Geringe Komplexitfit erm6glicht einfachere Evaluierungen. 9 Architekturkonzept: In physisch geschlossenen Systemen k6nnen Anforderungen bezfiglich einer Sicherheitsstrategie in der Regel leichter erfallt werden als in offenen Systemen. Ein wesentlicher Grund daflir ist darin zu sehen, dass geschlossene Systeme fiber eine (natttrliche) physische Sicherheitsinfrastruktur verfagen, durch die etwa eine anforderungsgerechte Zutritts- oder Zugangskontrolle gew~ihrleistet iSto 9 Erh6hen des Vertrauenspotentials durch Hardwaremagnahmen 9 Prfifung der Sicherheitsfunktionalit~iten und Mechanismen durch unabh~ingige Instanzen, wegen der Globalisierung und der grenzfiberschreitenden Prozesse - sowohl im privaten wie auch im Business-Bereich- auf internationaler Basis. Ohne Umsetzung der genannten Anforderungen bereits im Entwicklungsprozess ist Trusted Computing etwa besonders im Hochsicherheitsbereich nicht umsetzbar.

4 Trusted Platform Module im Betrieb Gerade im Hochsicherheitsbereich spielen Sicherheitsmechanismen eine groge Rolle. So kann etwa das sichere Urladen (engl. secure booting) eines Systems durch Hardware-Mechanismen unterstfitzt werden. Das Betriebssystem kann etwa von einer CD/DVD oder von einem Token oder einer SmartCard gebootet werden~ Diskutiert werden hier auch andere Sicherheits-Hardwarebausteine wie TPM-Ger~ite (TPM: Trusted Platform Module), die es erm6glichen sollen, IT-Systeme vertrauenswtirdig zu starten. IT-Systeme werden in Hochsicherheitsbereichen zwar oft als geschlossene Systeme betrieben, womit die Sicherheit an sich schon erh6ht wird. Auf zus~itzliche Mechanismen, die ein Trusted Computing unterstiitzen, kann aber nicht verzichtet werden. Einige Aspekte werden in den folgenden Kapiteln er6rtert.

4.1 Entferntes Attestieren nach TCG Die entfernte Attestierung (engl. remote attestation- R A ) soll zuverl~issig die Programme und deren Reihenfolge ermitteln, die eine zu attestierende, entfernte Plattform bis zu einen gegebenen Zeitpunkt ausgeRihrt hat bzw. ausfahrt. RA wird im Zusammenhang mit dem Trusted Platform Module (TPM) [TCG06] durch die Trusted Computing Group (TCG) entwickelt. Die TCG ist ein Konsortium namhafter Hersteller von Soft- und Hardware, die sich das Ziel gesetzt hat, eine sichere Plattform zu entwerfen. Die Sicherheit soll auf kryptographisch gut untersuchten Algorithmen und einem Ger~tt, das in den gesamten Lade-Prozess des Rechners einbezogen wird und diesen protokollieren kann, basieren.

Trusted Computing im Hochsicherheitsbereich

159

Ein wichtiges Element bildet das sichere bzw. ~berprfifbare Urladen (englo secure booting / authenticated booting) von Systemeno Dieser Ansatz grfindet auf der Annahme, dass, wenn die gesamte, auf einem System ausgefahrte Software sicher ist, das System als sicher angesehen werden kann. Wenn die M6glichkeit best~nde, entfernt festzustellen, welche Anwendungen ausgefahrt wurden und immer noch werden, so kann die Sicherheit eines Systems aus diesen Informationen abgeleitet werdeno Das t~berprfifbare Urladen wird durch das Ladeprotokoll realisiert. Dabei wird die Prfifsumme jeder ausgefahrten Anwendung von dem Zeitpunkt an, in dem das System eingeschaltet wird, in einem Protokoll vermerkt. Dieses Protokoll schliegt die Initialisierung des Systems, das Hochfahren des Betriebssystems, alle Treiber und sonstigen Anwendungen ein. Die Prfifsummen sind far jedes Programm eineindeutig und werden durch kollisionsresistente Algorithmen (etwa SHA1) gebildet. Die Prfifsummen aller erlaubten Anwendungen sind bekannt und folglich 1/~sst sich die Sicherheit eines Systems messen, indem das Ladeprotokoll aufunbekannte Prfifsummen fiberprfift wird. Der Ladezustand drackt einen Zustand in dieser Ladereihenfolge des Systems aus. Jeder Ladezustand kann durch ein Ladeprotokoll dokumentiert werden. Der Einsatz des Ladeprotokolls bringt einige Probleme mit sich, die in den ngchsten Abschnitten erl/~utert werden.

4.2 Migration, Sealing und Binding Ein viel diskutiertes Problem von TPM-Ger~iten ist das Problem der Migration, das bei Akmalisierung der Hardware und im Fall eines Wiederherstellens eines Backups auftritt. Ein TPM-Ger~it erlaubt mit den Operationen sealing (engl. f'tir versiegeln) und binding (engl. f't~ binden) das Koppeln von Geheimnissen an eine P lattform in einem bestimmten Ladezustand. Wird die Plattform gewechselt oder der Ladeprozess ver~indert, so gndert sich auch das Ladeprotokoll und der ehemalige Ladezustand kann nicht wiederhergestellt werden. Als Folge k6nnen diese Geheimnisse nicht mehr entschlftsselt werden und sind faktisch verloren. Diese Funktionalit/~t wurde insbesondere in Hinblick auf das digitale Rechtemanagement entwickelt, denn es soll verhindert werden, dass beispielsweise Musikstficke auf unterschiedlichen Plattformen abgespielt werden k6nnen. Doch, technisch betrachtet, sind b6sartige Manipulationen das Gleiche wie eine Anderung des Ladeprozess, die zum Beispiel durch aktualisierte Software-Komponenten erwirkt wurde. Genau so gibt es technisch gesehen keinen Unterschied zwischen dem Kopieren eines gescht~tzten MusikstCtcks und dem Einspielen eines Backups auf eine andere Maschine. Der Ladeprozess/indert sich auch dann, wenn neue Hardware im System installiert wird. Die Spezifikationen sehen zwar das Konzept der Migration vor, doch muss zuvor ein Schlfisselaustausch zwischen beiden beteiligten TPM-Ger/~ten erfolgt sein. Dieses Szenario muss insbesondere far den Fall des Wiederherstellens von Backups betrachtet werden. Die Vorbereitungen far den Ernstfall mt~ssen zudem vorher erfolgen, denn ist ein TPM-Gergt einmal defekt, so ist die Wiederherstelhmg der Daten aussichtslos. Die starke Bindung der Daten an eine Plattform ist insbesondere im Bfiroumfeld unfiblich, da dort die Daten mit den Anwendern umziehen - ausschlaggebend ist dort meistens der Anwender (bzw. seine Rolle) und nicht der Arbeitsplatz an sich.

160

Trusted Computing im Hochsicherheitsbereich

4.3 Ausdrucksschwaches Ladeprotokoll Einer der Grfinde, warum die angesprochenen Probleme vorhanden sind, ist, dass das Ladeprotokoll nicht ausdrucksstark genug ist. Es erscheint sinnvoll statt der Prfifsummen der geladenen Software ihre Eigenschaften als Grundlage far die Prfifung durch das TPM heranzuzieheno Ein Programm ist nicht dann sicher, wenn es eine bestimmte Prafsumme hat, sondern, wenn es bestimmte Eigenschaften oder nachweislich besitzt. Ffir diesen Ansatz gibt es bereits mehrere LOsungen. Wissenschaftlich wurde das Thema u. a. von Poritz et al. [PSHW04], Sadeghi und Stfible [SaSt04] oder von Krfiger [Krfig07b] behandelt. Doch auch das digital rights management, DRM, des Softwareproduzenten Microsoft ist ein Ansatz, die Schw~ichen des Ladeprotokolls zu umgehen. Alle L6sungen haben gemeinsam, dass sie nicht durch das TPM-Gergt selbst sondem das Betriebssystem umgesetzt werden. Doch w/ihrend DRM meistens nur in Verbindung mit Multimedia-Daten erw/~hnt wird, zeigt insbesondere [Krfig07b] wie ein solches System grunds~itzlich auf einem MikrokernSystem umgesetzt werden kanno

4.4 Statische Vermessung Eine statische Vermessung von Systemen mittels Prfifsummen beim Laden von Software ist an sich unzul~inglich- sie bietet keinen Schutz vor dynamischen Ver~inderungen, etwa Puffer-12Iberl~tufen (engl.

buffer overflows)~ Das System ist unbekannten Gefahren gegenfiber noch genau so anf~illig wie ohne den Einsatz von TPM-Ger~iten. Und solange der Angreifer keine permanenten )knderungen am System durchfahrt, bleibt sein Angriffunbemerkt. Um solchen eingebetteten Trojanern zu entgegnen darf die Sicherheit sich nicht alleine auf einem Punkt konzentrieren. Vielmehr ist das Zwiebelmuster bzw. defence in depth anzuwenden, in dem die Sicherheit aus mehreren Schichten besteht. Der Einsatz von TPM-Ger~iten ist nur eine Magnahme unter anderen, die ein System sicher machen sollen.

4.5 Fremde Software Die grogen Betriebssysteme sind weiterhin monolithisch. Diese Systeme haben somit noch einen weiteren Nachteil: es gilt, wie sonst fiberall in der Sicherheit aufIT-Systemen, dass die Kette am schw~ichsten Glied reil3t. Ffir g~ingige Betriebssysteme bedeutet dies, dass jedes Stfick Software, das geladen wird, den Sicherheitsanforderungen genfigen muss. Das gilt insbesondere far Treiber. Windows Vista setzt das Konzept secure booting ein: Jeder Treiber muss in jeder Version und far jede Version von Microsoft zugelassen werden~ Alle anderen bleiben augen vor. Diese Tatsache k6nnte vor allem far Open-Source-Projekte und far kleine Firmen relevante Folgen haben, da eine Finanzierung derartiger 15berprt~fungen gegebenenfalls nicht m6glich ist. Um einen Entwicklungsprozess zu unterstfitzen erlaubt Windows Vista auch das Laden nicht signierter Treiber. Konsequenterweise muss sich damit das Betriebssystem fortan als unsicher ausweisen. Das Problem liegt in der Tatsache, dass Treiber meistens im sogenannten Kernel-Modus-Kontext laufen, und somit einen direkten Zugriff auf die Hardware besitzen. Sie k6nnen insbesondere die Sicher-

Trusted Computing im Hochsicherheitsbereich

161

heitsrichtlinien des Betriebssystems hintergehen, wodurch ihre besondere Stellung begrfindet wird. Lediglich Mikrokern-basierte Systeme haben, zumindest theoretisch, das Problem, das von Ger~itetreibern ausgeht, gel6st. ~Amliche l]berlegungen gelten auch flir die Ver~inderung des Ladeprozess des Rechners. Wenn der Anwender ein zweites Betriebssystem installiert, mit der M6glichkeit zum Startzeitpunkt zwischen den beiden System auszuw~ihlen, dann hat der Anwender in den Ladeprozess eingegriffen~ Dieser Eingriff bedarf einer Genehmigung. Analog gilt dies auch ffir Systeme, die auf virtuellen Maschinen installiert werden, secunet setzt solche Hrtual Sessions beispielsweise ein, um unterschiedliche Sitzungen mit unterschiedlichen Sicherheitseinstufungen auf einem System parallel ausftthren zu k6nnen. Die Frage, wer diese Genehmigung erteilt, ist noch schwieriger zu beantworten. Im Endeffekt kann jeder Dienstleister frei bestimmen kann, welches System er einsetzt. Durch die Monopolstellung einiger Softwarehersteller ist es aber naheliegend, dass diese einen grogen Einfluss auf die Erteilung dieser Genehmigungen haben k6nnten. Der Einsatz von TPM-Ger~iten scheint zumindest theoretisch eine Ausgrenzung zu erlauben.

4.6 Ben6tigte Ressourcen Das TPM-Ger~it hat nur beschr~inkte Ressourcen. Auch kann ein TPM-Ger~tt in seiner aktuellen Spezifikation nicht auf mehreren Systemen aufgeteilt werden. Ein Problem entsteht nun bei der Lastverteilung auf grogen Systemen. Jedes System hat einen eindeutigen Chip. Transparente Proxies und Lastverteilung, wie sie gerne bei grogen Installationen eingesetzt werden, wt~den nicht mehr ohne weiteres funktionieren. Dies kann dazu ffihren, dass TPM-Ger~ite nur ffir die Absicherung von Basis-Systemen angewendet werdeno Den Rest wfirde das Betriebs-System in Software erledigen. Durch ihre Unteilbarkeit k6nnen TPM-Ger~ite auch nicht f-fir unterschiedliche virtuelle Maschinen eingesetzt werden. Auch hier muss das TPM-Ger~it mehrfach ausgelegt sein, oder in Software durch das Wirt-Betriebssystem (engl. host operating system) bereitgestellt werden.

4.7 Suspend to disk/ram Beim secure booting werden die Prfifungen ausschliel31ich zum Zeitpunkt des Startens der Software durchgeffihrt. Anderungen, die zur Laufzeit durchgefi~hrt werden, k6nnen dadurch nicht verhindert werden~ Bei dem Einsatz von softwarebasierten Verschl~sselungssystemen existiert immer das Problem mit der Aufbewahrung der Schlt~ssel im Speicher. Bei einem suspend to disk muss die Auslagerungsdatei (englo swap) entsprechend verschlfisselt werden. Soll das System auch gegen abrupte StromausfNle sicher sein, so muss diese Datei ausschliel31ich verschlftsselt geffihrt werden. Ein suspendiertes System soil seinen Vertrauenswttrdigkeitszustand fiber das Suspendieren hinweg retten k6nnen. Die Frage ist: wie geht eigentlich das TPM mit Suspend urn, d.h. wie merkt das TPM, ob und dass es seinen Integrit~ttsmesswert nach dem Resume behalten soll? K6nnte ein suspendiertes System derart manipuliert werden, dass das TPM von einem g~inzlich anderen Zustand nach dem Resume

I62

Trusted Computing im Hochsicherheitsbereich

ausgeht, als tats~tchlich vorhanden ist? Man k6nnte theoretisch den gesicherten Zustand eines ganz anderen, aber hardwarem~tl3ig identischen Systems einspielen. Die Antwort darauf findet sich in Pacifica und Vanderpool~ Diese erlauben das Starten mehrerer Instanzen eines Betriebssystems. Vorstellbar w~tre, dass bei suspend ein unabMngiges, sicheres System gestartet wird, das alle Daten einpackt und verschlftsselt. Bei einem resume startet wieder ein unabMngiges, sicheres System und macht alles wieder l"fickg~ingigoDas setzt natfirlich voraus, dass der Zustand des TPM-Ger~its ebenfalls gesichert und anschliel3end wiederhergestellt werden kann. Die TPM-Ger~ite erlauben das Sichern des internen Zustands durch die Operation Save&ate. Doch zum einem kann immer nur ein Zustand gespeichert werden, zum anderen wird dieser Zustand nur zu dem Zeitpunkt wiederhergestellt, zu dem das TPM-Ger~it initialisiert wird. Dies erfolgt zum Startzeitpunkt des Systems. Ft~ das Einfrieren des Zustands einer Virtuellen Maschine ist dieser Ansatz wirkungslos. Da immer nur ein Zustand gesichert wird, kann dieser Ansatz auch nicht verwendet werden, um ein TPM-Ger~it f't~ mehrere virtuelle Sitzungen einzusetzen.

4.8 Manipulationen an Hardware TPM decken Manipulationen an der Hardware, beispielsweise an speziell pr~iparierten Speicherchips, nicht ab. Zwar werden im Ladeprozess die Opt-Ins geprffft, aber das reicht noch nicht aus. Opt-Ins sind Codestt~cke, die von den PCI-Karten in den Ladeprozess eingeh~ingt werden. Ein Beispiel sind SCSIController. Die Opt-Ins stellen ein Problem dar. Jeder Ein- oder Ausbau, eventuell sogar der Tausch der Steckplgtze (und somit der Reihenfolge) wftrde auf ein anderes Ladeprotokoll hinauslaufen.

4.9 TPM als Quelle des Vertrauens Nicht nur die Sicherheit der monolithischen, geschlossenen Betriebssysteme muss hinterfragt werden, auch die Herkunft der TPM-Chips ist von Bedeutung. Fftr Hochsicherheitsl6sungen ist besonders das Innenleben interessant. Dieses Auditing kann sich jedoch als schwierig erweisen, da unterschiedliche Regierungen und Dienste unterschiedliche Anforderungen stellen und gegebenenfalls nicht daran interessiert sind, dass andere L~inder Einblick in die Entwicklung haben. Weiterhin spielt auch die Sicherheit der verwendeten Kryptoalgorithmen eine Rolle. SHA1 wurde lange far sicher gehalten, war wohl untersucht. Aber dann gab es doch erfolgreiche Angriffe [Heis05]. Das gleiche kOnnte etwa mit anderen vielfach eingesetzten Kryptoalgorithmen passieren. Das TPM-Ger~it fahrt seine Berechnungen auf Grundlage von SHA1. Die Austauschbarkeit der PNfsummenbildung wurde nicht beachtet.

5 H o c h s i c h e r e D a t e n v e r a r b e i t u n g und Kommunikation Nun ist zu diskutieren, ob mit Hilfe von TPM-Ger~tten die besonderen Anforderungen im Hochsicherheitsbereich erfallt werden k6nnen. Im Folgenden wird eine Architektur vorgestellt, die sich im Hochsicherheitsbereich bew~ihrt hat, dort far die 121bertragung geheimster Daten zugelassen ist und mit ihren gep~ft vertrauenswfirdigen Komponenten die Anforderungen an ein Trusted Computing erfallt. Hier

Trusted Computing im Hochsicherheitsbereich

163

wird deutlich, dass ein TPM-Ger~it hOchstens ein kleiner Bestandteil in einer Gesamtarchitektur sein kann. Diskutiert werden in diesem Kapitel einige Anforderungen, eine Sicherheitsphilosophie und ihre Umsetzung.

5.1 Anforderungen im Hochsicherheitsbereich Gerade im Hochsicherheitsbereich werden besondere Sicherheitsanfordemngen gestellt. Einige dieser Anforderungen sind auch schon aus anderen Bereichen bekannt. Ben6tigt werden etwa 9 eine vertrauenswfirdige Plattform mit Sicherheitsfunktionen (inklusive einer flexiblen kryptographischen Schicht) als Grundlage und Basis des Systems. ~ sicher abgeschottete Bereiche auf dieser Plattform, um eine brauchbare Umgebung Rtr einen einzigen Sicherheitslevel zu habeno Ein solcher Bereich sollte generisch sein, damit klassifizierte Daten mit handelst~blichen Anwendungen bearbeitet und/oder betrachtet werden k6nnen. ~ ein kryptographisches Filesystem (CFS: cryptographic file system), um klassifizierte Daten bei Bedarf lokal speichern zu kOnnen. Es darf fiir nicht vertrauenswfirdige Anwendungen nicht mOglich sein, Informationen aus dem CFS zu erhalten. ~ ein konfigurierbarer Zugang zu lokalen I/O-Ports, auch etwa Hardware wie USB. ~ die M6glichkeit, eine gewisse Anzahl solcher Bereiche auf einer Plattform mit unterschiedlichen Sicherheitsstufen laufen zu lassen. Dazu wird eine sehr starke Abschottung zwischen den Bereichen ben6tigt. ~ die M6glichkeit, streng kontrollierte 12Iberg~ingezwischen den Bereichen zu konfigurieren.

5.2 Sicherheitsphilosophie Ft~r den Hochsicherheitsbereich wird eine Architektur mit Komponenten ben6tigt, die besonders hohen Sicherheitsanforderungen gent~gt. SINA (Sichere Inter-Netzwerk Architektur) erfallt diese Anforderungen. Dieser Architektur liegt eine bestimmte Philosophie zu Grunde, die im Folgenden dargestellt wird. Sie hat Einfluss auf Entscheidungen, wie bestimmte Funktionsweisen umgesetzt werden. Sie beeinflusst die Kosten der Implementierung, die Integration und die Umsetzbarkeit von bestimmten Merkmalen. SINA ben6tigt gerade im Bereich der Hochsicherheitsanwendungen eine Reihe ausgewogener Sicherheitsprinzipien, die in ihrem Zusammenspiel einen angemessenen Sicherheitsstandard garantiert, der damit f'ttr die geforderte Vertrauensw~rdigkeit sorgto Die grundlegende Philosophie der SINA-Architekmr lgsst sich in folgenden Punkten zusammenfassen: 9 Die Systemplattform, die Code-Basis und die Funktionalitgt minimieren und auf ihre Sicherheit analysieren. 9 So weit wie m6glich Open-Source-Software (OSS) verwenden. 9 Die OSS und die handelst~bliche bzw. Black-Box-Komponenten evaluieren und testen. 9 Nicht vertrauenswt~rdige funktionale Komponenten so kapseln und abschotten, dass sie nicht mehr sicherheitskritisch sind. 9 Strenge Sicherheitsaudits einfahren, die in einem geregelten Prozess rechtzeitig Verst6ge gegen die Sicherheitsbestimmungen sowie neu entstehende Schwachstellen aufdecken und beseitigen.

164

Trusted Computing im Hochsicherheitsbereich 9 Sich nicht auf einen einzigen Sicherheitsmechanismus verlassen, sondern das Prinzip der ,,Defence in Depth" (d.ho mit mehreren Verteidigungsfronten) anwenden. 9 Sicherheitskritische Funktionsweisen in zentralen Teilen des Systems zusammenffihren, z.B. eine generische Krypto-Provider-Schnittstelle, um bestimmte Software- und Hardware-KryptoModule zu verbergen. 9 Ein modular aufgebautes System bauen, das fiir den praktischen Gebrauch flexibel konfiguriert und parametriert werden kanno

5.3 Bausteine Als erstes wird ein sicherer, auf der oben beschriebenen Philosophie aufbauender Systemkern ben6tigt, der grundlegende Sicherheitsfunktionen wie Kryptographie, Netzwerksicherheit, Speicherschutz usw. bietet. Dieser Systemkern basiert etwa auf stabilen sicherheitsgeprfiften und minimierten Linux-Komponenten (hier S1NA Linux). Zu diesem Kern werden sessionorientierte Funktionen hinzugeffigt. Eine Session ist hier die Verbindung mit dem Anwender und kann unterschiedliche Ansichten der Anwendung und der Daten erm6glichen. Jede Session wird einer einzigen Sicherheitsstufe zugeordnet. Auf einem SINA-System k6nnen gleichzeitig bis zu sechs unterschiedlich klassifizierte Sessions laufen. Aus diesen Sessions kann jeweils auf verschiedene Sicherheitsstufen zugegriffen werden. Die Sitzungen sind durch Kapselung und Abschottung komplett voneinander getrennto SINA Linux verfftgt fiber die Mechanismen for eine sichere Kapselung. Innerhalb dieser Sessions k6nnen nicht vertrauenswfirdige Teile des Systems betrieben werden wie ein Thin-Client-Zugang zu einem Windows-Terminal oder ein komplettes Windows- oder Linux-Betriebssystemo SINA Linux und einzelne Sessions werden im Folgenden kurz dargestellt.

5.4 SINA Linux SINA Linux wurde von Grund auf entwickelt. Es basiert nicht auf einer herk6mmlichen Distribution. Es enthNt zahlreiche zus~itzliche Sicherheitsmechanismen, die konsequent aufeinander abgestimmt wurden. Letztendlich blieb nur die eigentliche Kernfunktionalit~it als Betriebssystem erhalten. SINA Linux hat nichts mit der Standard Linux Workstation gemeinsam auger der Verwendung einiger identischer Bausteine (etwa Betriebssystemkernel und libc), die zumeist angepasst und auf Sicherheit analysiert wurden, um den Anforderungen der SINA-Umgebung zu gent~gen. Der SINA Linux-Kern enth~ilt die Grundfunktionalit~it. Dazu geh6ren 9 der Betriebssystemkern 9 Speicher- und Prozessverwaltung 9 Prozesstrennung und Inter-Prozesskommunikations-Mechanismen (IPC) 9 Rollenbasierte Zugangskontrolle (RSBAC) fiir fein granulare Verwaltung der Zugangsrechte 9 Basisvernetzung (IP, PPP, Ethernet, Token Ring) 9 Dateiverwaltungssystem / kryptographisches Dateiverwaltungssystem 9 Gergtetreiber (seriell, USB, parallel, Netzwerk) 9

USB-Firewall

Trusted Computing im Hochsicherheitsbereich

165

9 kryptographische Primitive 9 Symmetrische Kryptoalgorithmen 9 Asymmetrische Kryptoalgorithmen 9 Authentifizierungsfimktion 9

Hash-Funktion

9 Krypto-Hardwaretreiber 9 Zufallszahlengenerator 9

Smartcard-Funktionen

9 Netzwerksicherheit 9 IPSEC (erweitert um zusfitzliche Sicherheitsfunktionen) 9 IKE und andere Schl%selmanagement-bezogene Funktionen (Zertifikatsmanagement) 9 Paketfilterung (IPtables) 9 Spezifische Paketmarkierung (Verfolgung der Pakete innerhalb des Kernels) 9 Dateisystemsicherheit 9 kryptographisches Dateisystem 9 Optionaler Integrit~itsschutz pro Datenblock 9 Key-Usage-Z~ihler und Wiederverschlfisselungsoption 9 Sicherheitsaudit 9 Betriebssystem-Audit 9 Hostspezifisches Netzwerkaudit 9 Logging 9 Intrusion Detection and Response 9 Virmalisierungsschicht: x86 Virtual-Machine-Software (entwickelt auf Basis strenger Sicherheitsanforderungen) 9 Ressourcenmanagement: Kontrolle des Hardware-Schnittstellenzugangs aus dem Innern einer Session, festgelegt nach Sicherheitsstufe und Medienzugangskontrollliste 9 Managementschnittstelle 9 Systemkonfiguration und Initialisierungsprozess 9 Hardware- und Software-Manipulationsschutz

5.5 SINA-Session-Typen 5.5.1 Virtual-Machine-Session Virtualisierungstechnologien sich in Standard-PC-Umgebungen immer mehr eingesetzto Gleichzeitig wird der Hardware-Support der Virtualisierung bei x86-Prozessoren erh~iltlich- bekannt als ,,Vanderpool-Technology" - VT - v o n Intel und ,,Pacifica" von AMD. Teile der VM-Software mftssen mit Kernel-Privilegien l a u f e n - auch in den hardwareunterstatzten Varianteno Dies beruht auf der Tatsache, dass ein Virtual Machine Monitor (VMM) auf Funktionen angewiesen ist, die im Kern ausgeftthrt werden mt~ssen. Daher muss ein vertrauenswt~rdiger VMM mit verifizierbarem Quellcode verwenden werden. Aus diesem Grund wurde eine Virtual Machine integriert, die genau diese Anfordertmgen erffillt.

166

Trusted Computing im Hochsicherheitsbereich

Nehmen wir nun an, ein Betriebssystem stellt mehrere virmalisierte Betriebssysteme zur Verfagung. Dann sind diese Systeme selbst nicht durch das ursprtingliche Ladeprotokoll abgesichert. Diese Absicherung muss das Host-System gew~thrleisten- die zus~itzliche Schicht far die Absicherung der Sicherheit auf Anwenderebene wird in diesem Fall zu einer Voraussetzung. Es bedeutet aber, dass das Ladeprotokoll alleine nicht hinreichend ist.

5.5.2 Das Virtual Machine Prinzip Der Virtual-Machine-Session-Typ liefert damit die Kapselungsumgebung far ein komplettes -potentiell nicht vertrauensw~rdiges - Betriebssystem. Er bietet eine Runtime-Umgebung, die wie ein normaler PC aussieht und erlaubt augerdem die Nutzung mehrerer Gastbetriebssysteme nebeneinander. Das nicht vertrauensw~rdige Gastbetriebssystem interagiert nur t~ber festgelegte Schnittstellen mit der reellen Hardware und mit allen Ressourcen des Systems, etwa Server, Bibliotheken, Hardware, Kommunikation, und zwar immer fiber den Virtual Machine Monitor. Diese Schnittstellen k6nnen daher vonder Virtual Machine und dem Host-Betriebssystem sehr gut kontrolliert und gesichert werden. Das Prinzip von ,,Abschottung, Abkapselung und Audit" wird also exakt erfallt. Als Host-Betriebssystem bietet SINA Linux alle Sicherheitsfunktionen, die far die Sicherheit des Dateisystems und der Kommunikation gefordert sind. Ein kritischer Teil in einem Multi-VM-Szenario ist die Ressourcen-Kontrolle und Arbitrierung. Da physische Ressourcen wie Netzwerkschnittstellenkarten und USB-Ports durch die zugrunde liegende Hardware festgelegt sind, muss das SINA-Linux-Host-Betriebssystem far Arbitrierung und Sperrung sorgen. Dies h~ingt sowohl vonder allgemeinen Verfagbarkeit, d.h. der Ressourcenverfagbarkeit, die von den schon laufenden Virtual Machines abhgngig ist, und vonder Erlaubnis des Administrators ab, d.h. von der Erlaubnis, eine Ressource auf einer bestimmten Sicherheitsstufe zu verwenden. Zudem gibt es Ressourcen, die geteilt werden mfissen, etwa die CPU. Die sichere Zuteilung dieser Ressourcen erfolgt mit Hilfe von Zugriffberechtigungen, etwa via einen Scheduler. Abschottung l~isst sich in Virtual-Machine-Sessions viel schwieriger erreichen als etwa in Thin-ClientSessions, weil die Interaktion mit lokalen Ressourcen mehr potentielle Kreuzungspunkte oder verdeckte Kan~ile bietet als die graphische und die Netzwerkschnittstelle. Kreuzungspunkte sind hier KommunikationskanNe, an denen nicht vertrauenswfirdige Anwendungen ohne das Wissen des Benutzers Daten austauschen k6nnen. Ben6tigt werden also ,,Session-Label", um auf dem Host-Betriebssystem zu entscheiden, welche Schnittstellenzug~inge und welche Netzwerkkommunikation zu einem bestimmten Gastbetriebssystem und anderen Ressourcen, etwa Dateien, Netzwerkkarten und andere Komponenten zugelassen sind. Jede laufende Virtual Machine Session ftbernimmt die Einstufung des Gastbetriebssystem-Images, d.h. der virtuellen Festplatte, mit der sie l~tuft. Man kann es sich so vorstellen, dass die Vimtal Machine beim Booten von dem virtuellen Festplattenimage eingef'~irbt wird. Augerdem erlaubt oder verweigert eine gesicherte Konfigurationsdatei - die Medienzugangs-Kontrollliste - far bestimmte Sicherheitsstufen administrativ den Zugang zu lokalen Schnittstellen und Ressourcen. Beispiel: Zwei CFS-Container: A ist streng geheim, B ist often. A und B besitzen die Schnittstelle CFS~ Wird die Zugangskontrolle auf der Schnittstellenebene gemacht, mfissten A und B die gleiche Einstufung/Einschr~nkungen haben.

Trusted Computing im Hochsicherheitsbereich

167

5.5.3 Transfer-Session Die Transfer-Session hat das Ziel, Schnittstellen oder Entry-Points fOr Datenimport und Datenexport aus Arbeitssessions - etwa der Virtual-Machine-Session - bereitzustellen. Dem liegt das Problem zugrunde, dass alle ungep141ften und unbekannten Datenabflt~sse aus einer normalen Arbeitssession verhindert werden m0ssen. Es wird eine restriktive, geprftfte Methode ben6tigt, die einen Transfer nun sehr selektiv erlaubt. Der Transfer muss gesch0tzt sein und kann auf unterschiedliche Weise konfiguriert werden. ~ Dem Benutzer kann erlaubt werden, Daten entweder mit einem Gruppen- oder einem individuellen SchlOssel unverschlOsselt und / oder verschlOsselt zu exportieren 9 Der Transfer bietet 9 gesicherte Schnittstellen zu anderen Arbeitssessions, die sehr restriktiv gescht~tzt sind, um einen Datenabfluss zu verhindern ~ 121berpl'fifungsmOglichkeiten aufAnwendungsebene (was wurde wann und wohin Obertragen und wie wurde es geschtitzt?) 9 Einsatz von Medien-Labelling, um die Abschottung aufrecht zu erhalten (fftr verschlOsselte M e d i e n - ffir unverschlfisselte Medien ist dies nicht sinnvoll) FOr solche 13bertragungen muss auch das Sessionkonzept ausgeweitet werden: Der Export auf und der Import von einem externen Speichermedium muss mit den MaBnahmen, die aufNetzwerkseite ergriffen werden, Obereinstimmen. Das ,,andere Ende" eines Netzwerks - etwa ein Serverbereich- hat dieselbe Sicherheitsstufe wie die Session. Also gilt dies auch im Fall eines lokal angeschlossenen Speichers. Wenn der Datentransfer unverschlOsselt ist geh6rt der Speicher zur gleichen Sicherheitsstufe. Wenn der Transfer verschlOsselt ist, dann kann er als ein spezielles (Offline-) Netzwerk angesehen werden.

5.5.4 Quarant~ine-Session Die Quarant~tne-Session unterstatzt die Transfer-Session. Wenn ein Anwender Daten Ober einen Weg erh~ilt, den er in der Transfer-Session nicht benutzen dart', er aber trotzdem sofort Zugang zu diesen Daten braucht, kann er die Daten in eine Quarant~tne-Session importieren. Diese Session kann wahlweise nicht persistent sein, so dass Viren und Trojanische Pferde unerheblich sind. Die Quarant~ine-Session ist komplett von anderen Sessionbereichen und Kommunikationsverbindungen abgeschottet.

5.6 Zusammenspiel der Sessions Die oben beschriebenen Sessions sind im normalen Anwendungsfall v611ig isoliert voneinander. So werden auch die unterschiedlichen Sicherheitsstufen voneinander getrennt. In speziellen Fgllen ist es jedoch notwendig, die Sessions miteinander zu verbinden. Dies ist dann der Fall, wenn nur ein gewisses MaB an Isolation zwischen verschiedenen Funktionalit~iten und/oder eine Umgebung mit bestimmten Eigenschaften- etwa Nicht-Persistenz der Quarant~ine-Session - ben6tigt wird. Die technischen Mittel zur Verbindung sind ~ interne Vernetzung ~ gemeinsam genutzte O r d n e r - direkt miteinander verbunden 9 gemeinsam genutzte O r d n e r - Einsatz der Transfer-Session

Interne Vernetzung ist die ,,offenste" Methode, zwei Sessions miteinander zu verbinden. Sie kann nur zwischen Virtual-Machine-Sessions eingesetzt werden. Das Host-Betriebssystem hat keinen Kontroll-

168

Trusted Computing im Hochsicherheitsbereich

Mechanismus, um den Datenfluss einzuschranken und zu p~fen. Die Gast-Betriebssysteme haben eine virtuelle Netzwerkverbindung- so als waren ihre virtuellen Netzwerkkarten an einen Hub oder Switch angeschlossen. Die Art der Verbindung wird nur zwischen Sessions der gleichen Sicherheitsstufe erlaubt werden.

Gemeinsam genutzte Ordner- direkt miteinander verbunden." Mit mehr Einschrankungen ist es verbunden, File-Sharing zwischen den Sessions zu erm6glichen. Dies geht mit einer starkeren Isolierung einher als der Einsatz intemer Vemetzung, weil die Session / das Gastbetriebssystem ohne jegliche Vernetzung laufen kann~ File-Sharing wird durch den so genannten Shared-Folder-Mechanismus der Virtual Machine oder durch oder durch interne Merkmale eines Thin-Clients (ICA/RDP) erm6glicht. In allen Fallen wird ein Verzeichnis (Verzeichnisbaum) im Gastbetriebssystem / in der Terminal ServerSession sichtbar. Wenn nun zwei Sessions im Host-Betriebssystem denselben Verzeichnisbaum benutzen, entsteht eine dateibasierte Verbindung. Diese Art der Verbindung wird voraussichtlich nur zwischen zwei Sessions der gleichen Sicherheitsstufe erlaubt werden oder bei stufenfdrmig angeordneten Sessions, zwischen denen sich isolierte (nicht vemetzte) Sessions befinden.

Gemeinsam genutzte Ordner- Einsatz der Transfer-Session: Die am strengsten isolierende und am besten kontrollierbare Methode ist es, die Transfer-Session zwischen zwei andere Sessions zu schalten. Dann wird das Export- / Import-Verzeichnis jeder Session nur dieser einen Session zugeordnet. Der p~ffiihige Transfer-Prozess auf SINA Linux bestimmt die Art der 121bertragung (verschliisselt oder often, und auditiert). Es gibt keine unkontrollierte Ubertragung. Diese Art von Verbindung ist m6glich zwischen unterschiedlich eingestuften vernetzten Sessions.

6 Fazit An informationstechnische Systeme im Hochsicherheitsbereich werden augergew6hnliche Anforderungen gestellt. Diese Anforderungen lassen sich mit Systemen umsetzen, die auch in anderen Bereichen einsetzbar sind. Informationstechnische Sicherheitssysteme und Mechanismen, die far andere Bereiche, etwa den Massenmarkt, entwickelt wurden, lassen sich hingegen im Hochsicherheitsbereich nur beschrankt einsetzen. TPM wurden entwickelt, um die Sicherheit der IT-Systeme zu verbessem, etwa um einen besseren Schutz vor Computerviren zu haben. TPM dienen auch dazu, den Schutz der Urheberrechte zu verbessern. Hierzu muss die Reaktion der Wirtschaft abgewartet werden. Werden die Einschrankungen zu streng gewahlt, so entstehen f-fir den Verbraucher Ht~rden, die wiederum der Marktwirtschaft hinderlich sin& TPM sollen zu Vertrauen fahren: sorgloses Bezahlen im Internet, elektronisches Bargeld, sichere Verwahrung von Gesundheitsdaten~ Gegebenenfalls auch durch einen portablen Chip gesichert. Es ist za.t diskutieren, inwieweit sich das gesellschaftliche Leben nur auf die Sicherheit eines Chips statzen darf. Sicherheit muss mehrschichtig und vorausschauend sein. Insbesondere darf sich der Anwender nicht in falscher Sicherheit wiegen, nur weil er ein TPM einsetzt. Egal wie sicher eine Komponente auch ist, die Sicherheit ist ein Problem im Management und nicht in

Trusted Computing im Hochsicherheitsbereich

169

einem Chip. Es geh6ren Risikoanalysen dazu: Risikobeschrgnkung bei Eintritt, Eintrittswahrscheinlichkeit minimieren und ~berwachende Systeme. Im Hochsicherheitsbereich bringt das TPM nur einen geringen Beitrag. Es erlaubt die Hfirde far einen erfolgreichen Angriff nochmals zu erh6hen, eine sehr hohe Sicherheit wird alleine durch den Einsatz eines TPM nicht erreicht. Sollen hier TPM eingesetzt werden, so muss dies vorher grfindlich t~berlegt werden und in die Entwicklungen einfliegen. Die Systeme werden gegebenenfalls sicherer, aber auch teurer. Letztendlich werden TPM sich als erg~inzende Mechanismen im Bereich von normalen Sicherheitsanforderungen durchsetzen. Im Hochsicherheitsbereich k6nnen Sie nur einen Beitrag leisten. FUr den Hochsicherheitsbereich wurde die SINA-Architektur aus folgenden Bausteinen entwickelt: 9 Eine sichere Plattform mit grundlegenden Sicherheitsfunktionen, VPN und CFS 9 Darauf eine Session-Konstruktion, die abgeschottete Bereiche mit festgelegten Funktionalit~iten und Schnittstellen bietet. 9 Mittel, um die Sessions kontrolliert miteinander zu verbinden. 9 Physische Schnittstellen, um das System mit einem oder mehreren Netzwerken oder anderen Peripherieger~iten zu verbinden. Die Kombination dieser Bausteine bietet eine L6sung ~ r Bereiche mit besonders hohen Sicherheitsanforderungen.

Literatur [HoKr00] Horster, Patrick; Kraaibeek, Peter: Grundlegende Aspekte der Systemsicherheit. In: Horster: Systemsicherheit, Vieweg-Verlag, 2000, S. 1-16. [Krt~g07a] Krager, Hans Marcus: Entfernte Attestierung von Eigenschaften auf Mikrokern-basierten Architekturen. In: Innovationsmotor IT-Sicherheit: Tagungsband zum 10. Deutschen IT-Sicherheitskongress, SecuMedia-Verlag, 2007, S. 445-460. [Krfig07b] K~ger, Hans Marcus: Entfernte Attestierung von Eigenschaften auf Mikrokern-basierten Architekturen~ Diplomarbeit. Technische Universit~it Dresden, Fakult~it Informatik, Institut far angewandte Informatik, http://skbrasil.net/-hans/DA/DAopdf [Heis05] http://www.heise.de/security/news/meldung/56428 [HHF+05] H~irtig, Hermann, Michael Hohmuth, Norman Feske, Christian Helmuth, Adam Lackorzynski, Frank Mehnert und Michael Peter: The Nizza Secure-System Architecture. In: Proceedings of CollaborateCom, 2005. http://os.inf.tu-dresden.de/papers ps/nizza.pdf. 12, 13, 30, 45, 48 K141ger,Hans Marcus: Entfernte Attestierung von Eigenschaften auf Mikrokern-basierten Architekturen. Diplomarbeit, Technische Universit~it Dresden, 2007. [PSHW04] Poritz, Jonathan, Matthias Schunter, Els Van Herreweghen und Michael Waidner: Property Attestation - - Scalable and Privacy-friendly Security Assessment of Peer Computers, 2004. 19 [SaSt04]

[TCG06]

Sadeghi, Ahmad-Reza, Christian S~ble: Property-based attestation for computing platforms: caring about properties, not mechanisms. In: NSPW'04: Proceedings of the 2004 workshop on New Security Paradigms, Seiten 67-77, New York, NY, USA, 2004. ACM Press. 19, 31 Trusted Platform Module (TMP) Specifications, 2006 Versionl.2, Revision 94.

Trusted Computing f(i r automobile IT-Systeme Andrey Bogdanov ~. Thomas Eisenbarth 2. ChristofPaar 2- Marko WoW 1 escrypt- Embedded Security GmbH Lise-Meitner-Allee 4, 44801 Bochum {abogdanov ] mwolf} @escrypt.com 2 Ruhr-Universit~it Bochum Universit~itsstrage 150, 44780 Bochum {eisenbarth I cpaar} @crypto.rub.de

Zusammenfassung FOr viele automobile Anwendungen ist Informationstechnik (IT) von zentraler Bedeutung. W~ihrend die Zuver1/~ssigkeit und Fehlertoleranz automobiler IT-Systeme weitgehend sichergestellt werden kann, beginnt sich die Absicherung gegen gezielte Eingriffe und Manipulationen erst langsam zu entwickeln. Nichtsdestotrotz existieren verschiedenste Automobilanwendungen, wie die elektronische Wegfahrsperre oder der digitale Fahrtenschreiber, welche schon jetzt sicherheitskritische Daten verarbeiten. Um auch zukiinftige, komplexe Automobilanwendungen sicher realisieren zu k6nnen, wird IT-Sicherheit eine Schliisseltechnologie zuk~nftiger Fahrzeuggenerationen werden [Ross03]. Wfihrend OEMs aus dem Automobilbereich bei der Thematik IT-Sicherheit bisher eher aufpropriet/~re miteinander inkompatible Entwicklungen gesetzt haben, bietet die Technologie des Trusted Computing auch im Automobilbereich zahlreiche M6glichkeiten IT-Sicherheit kostengiinstig, kompatibel und zuverl/~ssig umzusetzen. Auch wenn TC bisher eher im Server und Desktopbereich eingesetzt wird, existieren bereits erste Implementierungen [Atme06], welche auch den besonderen Anforderungen eingebetteter Systeme gerecht werden k6nnen. Im folgenden Beitrag werden daher nach einer kurzen Einfahrung in die Thematik der IT-Sicherheit im Automobil einige Anwendungen aus Automobilbereich vorgestellt, welche von den verschiedenen TC-Mechanismen profitieren k6nnen. Es werden m6gliche Angreifer und Angriffsszenarien identifiziert und klassifiziert, damit anschlieBend die zugeh6rigen Sicherheitsziele zusammen mit ihren technischen und organisatorischen Rahmenbedingungen her= geleitet werden k6nnen. Der Beitrag schlief3t mit verschiedenen L6sungsvorschl~igen far ein Hardwaresicherheitsmodul und einer prototypischen Implementierung von Trusted Computing Technologie far einen Anwendungsfall aus dem Automobilbereich.

1 EinfiJhrung Nur etwa 2% der Mikroprozessoren befinden sich in herk6mmlichen PCs, wohingegen fast 98% aller heute weltweit hergestellten Mikroprozessoren in so genannten ,,eingebetteten Systemen" verwendet werden [EGH00]. Eingebettete Systeme sind meist far eine Spezialanwendung konzipiert, deren Rechnerfunktionalit~it nach augen oft nicht sichtbar ist. Sie verfagen meist nur fiber eingeschr~inkte Ressourcen (z. B. bzgl. Rechenleistung oder Energie) und m~ssen, um millionenfach hergestellt werden zu k6nnen, besonders kostengt~nstig sein. Eine wichtige Dom~ine far eingebettete Systeme ist das AutomobiI. In einem modernen Fahrzeug sind schon heute bis zu 80 Steuerger~ite verbaut, welche in fast alle Bereiche eines Fahrzeugs (Motorsteuerung, Bremsen, Antrieb etc.) eingreifen. Sie kommuniN. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 170-186

Trusted Computing far automobile IT-Systeme

171

zieren intern t~ber verschiedenste Bussysteme, die zunehmend auch Schnittstellen zur Augenwelt (z.B. Bluetooth, WLAN, GPRS, UMTS) anbieten.

e\~s~o~~ i

Z.entralverriegelung ! [

Automabkschaltng i Antiblockiersy~~'~" Adap~veGe~iebestrg. i I Spurhalteunler~]tzung ! !

i Z~trale Hinweisle~ch~/~ .......~t~scNupfregelung

[

!

Autornat~scherNoiruf

i

[ AdaptiveCrdise Contrd I

{

Aul..... Fahren OnlineSer,ic~

ii

1960

1970

i[

1980

i,iiii iii

1990

,IImHIHIII H

2000

I

2010

mHll~l

Abb.l" Stetig steigende IT-Sicherheitsanforderungen im Automobilbereich Durch die in Abbildung 1 verdeutlichte, stetig fortschreitende ,,Elektronikisierung" und die zunehmende Vernetzung vieler Ger/~te untereinander sind elektronische Systeme schon heute in viele sicherheitskritische Bereiche vorgedrungen. Oft geschieht dies jedoch, aufgrund der historischen Entwicklung oder des stets pr/~senten Kostendrucks, ohne dass besondere Vorkehrungen gegen b6swillige Angreifer getroffen werden. Durch unautorisierte Manipulationen beispielsweise an der elektronischen Stabilit/~tskontrolle oder der Tempomatsteuerung k6nnen allerdings schon heute kaum absehbare Gefahren f'~ alle Verkehrsteilnehmer ausgehen. Zuk~nftige Anwendungen wie Drive-by-wire oder C2C-Kommunikation sind ohne besondere IT-Sicherheitsmal3nahmen kaum realisierbar. Fftr die Zukunft der Automobilelektronik sind allerdings schon jetzt zwei wesentliche Trends erkennbar. Um maximale Flexibilit/~t, Wartbarkeit und minimale Kosten weiterhin gew/~hrleisten zu k6nnen, wird ein Grol3teil der Fahrzeugfunktionalit~it in Zukunft rein softwarebasiert realisiert werden. Um den durch die Vielzahl einzelner Steuergergte stetig zunehmenden Vernetzungsgrad und die damit verbundene, schwer beherrschbare Komplexit~it in den Griff zu bekommen, wird zudem in Zukunft eine Integration mehrerer Steuerger~ite in wenige, leismngsfiihige zentrale Steuergedite erfolgen. Ft~r die Absicherung solcher softwarebasierter Fahrzeug-IT-Systeme ist Trusted Computing Technologie eine vielversprechende M6glichkeit. Nachfolgend werden daher in diesem Beitrag in Kapitel 2 m6gliche Anwendungen far Trusted Computing Technologie vorgestellt und in Kapitel 3 m6gliche Angreifer im Automobilbereich identifiziert. Kapitel 4 erl~iutert die grunds~itzlichen Sicherheitsziele im Automobilbereich zusammen mit den besonderen technischen und organisatorischen Rahmenbedingungen, w~ihrend in Kapitel 5 m6gliche Realisierungen eines Hardwaresicherheitsmoduls er6rtert werden. Der Beitrag endet mit der Vorstellung einer prototypischen Implementierung von Trusted Computing Technologie far einen Anwendungsfall aus dem Automobilbereich.

172

Trusted Computing ffir automobile IT-Systeme

2 Anwendungen Kir Trusted Computing im Automobilbereich Mit der M6glichkeit eingebettete Systeme um Trusted Computing Funktionalitgt zu erweitern, ergeben sich zahlreiche Anwendungsszenarien, welche von den besonderen M6glichkeiten des Trusted Computing profitieren k6nnen. Im folgenden Abschnitt werden beispielhaft einige Bereiche im Automobil vorgestellt, welche von Trusted Computing Technologie profitieren k6nnen.

2.1 Komponentenschutz Schon heute wird der Grof3teil der technischen und finanziellen Ressourcen der Fahrzeugentwicklung in der Entwicklung von elektronischen Komponenten und deren Software verwendet [Fris03, SaWe03]. Sind diese Komponenten ohne weitere Schutzmal3nahmen versehen, k6nnen sie leicht analysiert und kopiert werden. Konkurrierende Hersteller, aber vor allem Hersteller illegaler Kopien haben ein grol3es Interesse wertvolles Know-how zu erlangen. Obwohl in den meisten L~indern der Welt wirksame Gesetze zum Schutz von geistigem Eigentum existieren, gibt es dennoch m~tchtige Volkswirtschaften, die den Diebstahl oder Missbrauch geistigen Eigentums kaum verfolgen. Obwohl der Schutz von Know-how haupts~ichlich durch organisatorische Magnahmen innerhalb des Entwicklungsprozesses sichergestellt werden muss, kann TC helfen, Know-how innerhalb von ausgelieferten Komponenten kryptografisch zu sichern oder den Ursprung einer m6glichen Schwachstelle zumindest im Nachhinein festzustellen und ggf. m6gliche Schadensersatzansprt~che durchzusetzeno Die zweite grof3e Gefahr durch ungeschfitzte Komponenten entsteht durch den Vertrieb gefNschter (Ersatz-)teile. Allein der finanzielle Verlust wird dabei auf t~ber drei Milliarden Dollar j/~hrlich gesch~itzt [Gie05]. Hinzu kommen die kaum bezifferbaren Sch/~den aus unberechtigten Garantieansprfichen, Markensch~idigung und untergrabenen Gesch/~ftsmodellen~ Vor allem aber kOnnen gefNschte Ersatzteile die Sicherheit des jeweiligen Fahrers und aller t~brigen Verkehrsteilnehmer gef~ihrden. Die professionelle F/ilschung von automobilen Komponenten kann durch die bisherigen Ans~itze wie holografische Etiketten oder spezielle Tags kaum verhindert werden. Im Gegenteil, es existieren eigene Gesch/~ftsbereiche, welche sich auf die Herstellung gefNschter Etiketten, Typenschilder und Verpackungen spezialisiert haben [Ross04]. Auch hier kann TC helfen FNschungen zu verhindern oder sie zumindest als solche zu erkennen. Hierzu k6nnte TC Technologie beispielsweise auf Anforderung oder bei jedem Start die aktuelle Fahrzeugelektronik auf eventuelle F~ilschungen, aber auch m6gliche fehlerhafte oder inkompatible Originalkomponenten hin ~berprfifen und den Fahrer gegebenenfalls warnen.

2.2 Manipulationsschutz Digitale Fahrtenschreiber (tachograph) und Unfalldatenschreiber (event data recorder) sind allein aufgrund ihrer juristischen Bedeutung besonders zuverl~issig gegen m6gliche Manipulationsversuche zu schfitzen. Weitere potenzielle Ziele fttr Manipulationen sind beispielsweise die gespeicherte Laufleistung- far einen erh6hten Wiederverkaufswert, aber auch ffir eine gef~tlschte Steuererkl~irung- oder die Motorsteuerung zur unzul~issigen Leistungssteigerung. Im Vergleich zu klassischen iT-Sicherheitsszenarien, kann ein Angreifer hier vollst~indig t~ber sein Angriffsziel verfiigen, das heil3t er hat sowohl vollen physikalischen Zugang als auch unbegrenzte Zeit (vgl. Kapitel 3 ,,Angreifer").

Trusted Computing far automobile IT-Systeme

173

TC Technologie kann helfen die Integrit~it kritischer Fahrzeugdaten und Sensoren hardwarebasiert zu schfttzen, indem entweder der Aufwand den zu erwartenden Gewinn ftbersteigt (economic security) oder Manipulationen zumindest nachtr~iglich nachweisbar sind (tamper evidence).

2.3 Zugangsschutz Die elektronische Wegfahrsperre und der kontaktlose Fahrzeugschlt~ssel sind wohl die ~iltesten kryptografischen Anwendungen im Automobilbereich. Heutige automobile Zugangsschutzsysteme basieren in der Regel auf so genannten Challenge-Response-Verfahren. Dafar sendet das Fahrzeug eine kryptografische Aufgabe (challenge), welche nur der Berechtige korrekt beantworten kann (response). Grundlage far die fahrzeugseitige Authentisierung ist ein sicher geschfitztes Geheimnis, welches nur das Fahrzeug und die berechtigten Fahrzeugschl%sel kennen. Da das Abh6ren der Kommunikation zwischen Fahrzeug und Fahrzeugschlt~ssel nicht ausgeschlossen werden kann, wird niemals das gemeinsame Geheimnis selbst Obertragen. AuBerdem wird auch das Wiedereinspielen (replay) einer zuvor mitgeschnittenen korrekten Antwort kryptografisch verhindert. Trusted Computing Technologie kann im Bereich Zugangsschutz beispielsweise eingesetzt werden, um die far einen unberechtigten Zugang (z.B~Diebstahl) notwendigen Fahrzeugmanipulationen soweit zu erschweren, dass der Aufwand den zu erwartenden Gewinn Obersteigt (economic security)~Trusted Computing kann sowohl im Autoschl%sel (auBerhalb des Fahrzeugs) als auch in der Wegfahrsperre (innerhalb des Fahrzeugs) eingesetzt werden. In Zusammenhang mit dem raschen Fortschritt physikalischer Angriffsmethoden (side-channel und invasive attacks) beginnt die physikalische Sicherheit der Zugangsmechanismen eine zunehmend gr6Bere Rolle zu spielen. Ein Beispiel der entsprechenden Angriffsszenarien ist wie folgt. Der Angreifer mietet ein Fahrzeug und kopiert das kryptografische Geheinmis aus dem Autoschlfissel. Nach der Rfickgabe des Fahrzeugs verkauft der Angreifer das Geheimnis an interessierte kriminelle Organisationen, welche dann damit den Diebstahl leicht durchft~ren k6nnen.

2.4 Sichere Softwareaktualisierung Schon heutige Fahrzeuge verfagen fiber zahlreiche Steuerger~ite, welche das Aktualisieren oder Oberspielen ihrer Firmware erlaubeno Die Anderungen an der Software k6nnen m6gliche Programmfehler beseitigen, neue Funktionalit~iten hinzufagen oder einen vorhandenen Datenbestand erneuern. Die Softwareaktualisierung (software update) wird in der Regel fiber eine spezielle Diagnoseschnittstelle durchgefahrt. Immer h~iufiger k6nnen dafar aber auch viele andere Kommunikationsschnittstellen, wie eine Radio-CD-ROM, Bluetooth oder GSM benutzt werden. Eine solche Kommunikationsschnittstelle muss jedoch abgesichert werden, um das unberechtigte Einspielen manipulierter oder falscher Software zu verhindern. Eine weitere wichtige Anforderung bei der Softwareaktualisierung ist die Versionskontrolle bzw. die Sicherstellung der Kompatibilit~it der einzuspielenden Softwarekomponente mit der vorhandenen Fahrzeugkonfiguration. Beide Anforderungen k6nnen mit Trusted Computing Technologie effizient und sicher realisiert werden.

2.5 Digitale Rechteverwaltung Mit der Integration von Trusted Computing Technologie im Automobilbereich l~isst sich auch eine zuverl~issige digitale Rechteverwaltung realisieren, die eine Reihe neuer GescMftsmodelle erm6glicht, von denen alle beteiligten Parteien (OEM, Zulieferer und Kunde) profitieren k6nnen. Im Zuge der Serienfertigung wird beispielsweise oft die gleiche Hardware mit je nach Modell- und Ausstattungsvariante unterschiedlicher Softwarekonfiguration verbaut. Mit Hilfe einer digitalen Rech-

174

Trusted Computing fftr automobile IT-Systeme

teverwaltung k6nnte auf allen entsprechenden Bauteilen auch die gleiche Software aufgespielt werden, bei der erst nachtr~iglich die gewt~nschten Funktionen freigeschaltet werden. Die Freischaltung von zus~itzlichen Softwarefunktionen kann insbesondere auch erst nach dem Verkauf des Fahrzeugs als zus~itzliche Dienstleistung (after-sale business) angeboten werden~ Eine zuverl~issige digitale Rechteverwaltung erm6glicht natfirlich auch den sicheren Einsatz yon beliebigen, gescht~tzten Daten aus dem Bereich Infotainment. Damit k6nnen beispielsweise Hersteller gezielt Informationen an ihre Fahrzeuge versenden oder bestehende DRM-Systeme (iTunes, Windows Media, etc.) leicht in das Fahrzeug integriert werden.

2.6 Sichere Fahrzeugkommunikation Der sich im Rahmen der elektronischen Mauterhebungen erst langsam entwickelnde Datenaustausch yon Fahrzeugen mit externen Kommunikationspartnern ist erst der Anfang einer bevorstehenden, deutlichen Ausweitung der extemen Fahrzeugkommunikation. Aktuelle Anwendungsszenarien und Szenarien aus der ngheren Zukunft sind beispielsweise die vollautomatische Mauterhebung, der automatische Notruf (eCall), verschiedene (ortsgebundene) Informationsdienste (location based services) oder das elektronische Nummemschild, welche alle weitgehend unter dem Begriff Fahrzeug-Infrastruktur-Kommunikation (C2I) zusammengefasst werden k6nnen. In mittlerer Zukunft k6nnen durch die Kommunikation von Fahrzeugen untereinander (C2C) beispielsweise gegenseitige Warnungen (Stauende, Stra13enverh~iltnisse, Notbremse, etc.), automatische Vorfahrtsregelungen oder autonomes Fahren realisiert werdeno Hierbei und auch bei der fahrzeuginternen Kommunikation (Stichwort: drive-by-wire) kann Trusted Computing Technologie entscheidend helfen vertrauenswfirdig Kommunikationspartner zu erkennen und die Kommunikation gegent~ber Unbefugten abzusichern.

3 Angreifer im Automobilbereich Die M6glichkeiten eines Angreifers im Automobilbereich unterscheiden sich grundlegend von den M6glichkeiten, die z. B. einem Hacker im PC-Bereich zur Verffigung stehen, der versucht ein fremdes System anzugreifen. Im Automobilbereich muss grunds~itzlich davon ausgegangen werden, dass der Angreifer physischen Zugang zu dem Zielsystem hat. Das System kann mit allen M6glichkeiten, die dem jeweiligen Angreifer zu Verffigung stehen, manipuliert und beobachtet werden. Daher muss schon w~ihrend des Entw~rfs des Systems berficksichtigt werden, dass dieses in einer unsicheren Umgebung laufen wirdo

3.1 Angriffsm6glichkeiten Die m6glichen Angriffe sind vielf'~iltig und werden nur durch das Fachwissen und die finanziellen M6glichkeiten des Angreifers beschr~inkt. Generell wird zwischen aktiven und passiven Angriffen unterschieden. W~ihrend sich der passive Angreifer auf das Abh6ren von Busleitungen oder das Messen des Stromverbrauchs oder der elektromagnetischen Abstrahlung einzelner Bauteile beschr~tnkt, kann der aktive Angreifer Busleitungen auch manipulieren und selbst einzelne Bauteile gegebenenfalls komplett ersetzen. Bei den aktiven Angriffen wird dann zwischen invasiven Angriffen, bei denen interne Signale auf Chipebene manipuliert werden k6nnen (z. B. mit Laser und UV-Licht) und nicht-invasiven Angriffen, bei denen die normale Funktionalit~it des Bauteils nur durch Fehlerinjektion gest6rt wird, unterschieden. Bei den passiven Angriffen sind vor allem die Seitenkanalangriffe wie DPA oder SPA (differential bzwo simple power analysis) interessant, bei denen die Kryptografie mittels Analyse des Stromverbrauchs (oder der elektromagnetischen Abstrahlung bei DEMA-Angriffen) gebrochen wird.

Trusted Computing far automobile IT-Systeme

175

Eine weitere M6glichkeit Sicherheitsfunktionalitgt zu umgehen bietet das Reverse Engineering. Hier werden Komponenten wie z.B. die Wegfahrsperre komplett ersetzt oder die Signale zur Kommunikation mit einer Komponente manipuliert. Dazu wird eine neue Komponente, die in der Lage ist, die Kommunikation zum angegriffenen BauteiI zu manipulieren, eingebaut~ Beispielsweise kann der angegriffenen Komponente eine andere Umgebung vorget~iuscht werden. Mit den oben beschriebenen Mitteln kann der Angreifer durch Codemanipulation oder Manipulation von Signalen versuchen, die Funktionalit~it zu vergndem oder Sicherheitsmechanismen auger Kraft zu setzen. Durch Seitenkanalangriffe oder Reverse Engineering kann, fiber das Auslesen der entsprechenden Geheimnisse, das komplette Sicherheitsmanagement gebrochen werden, um beispielsweise ganze funktionale Einheiten zu kopieren oder in ihrer Funktion zu/~ndem.

3.2 Angreiferprofile Je nach Anwendung sind verschiedene Angreiferprofile in Betracht zu ziehen. Im Automobilbereich wird, wie in Tabelle 1 dargestellt, zwischen vier typischen Angreifergruppen unterschieden. Tab. 1: Typische Angreifer im Automobilbereich und ihr Angriffspotenzial Angreifer

Zeit

Expertise

Zugang

Ausriistung

Dieb Fahrer/Besitzer Werkstatt Organisierte Kriminalit~it

niedrig hoch mittel hoch

mittel niedrig mittel hoch

niedrig niedrig hoch hoch

mitteI niedrig mittel hoch

Basierend auf [CCIM04] und [CCDB06] wird das Angriffspotential eines Angreifers als eine Kombination der folgenden Faktoren definiert: 9 Zeit" Die einem Angreifer ffir einen Angriff auf das Fahrzeug zur Verffigung stehende Zeit. ~ Expertise" Wissen fiber Aufbau und Funktionsweise und des Zielsystems bzw. Grad der Fghigkeit bestimmte Angriffe auszufahren. ~ Zugang: M6glicher Umfang des Zugriffs auf das Fahrzeug bzw. Anzahl der fiir Angriff verfagbaren Zielsysteme, die ffir den Lemprozess eingesetzt werden k6nnen. ~ Ausrfistung" Finanzielle Ausstattung und Technische Ausrfistung, die dem Angreifer zur Verfagung stehen. Wie in Tabelle 1 leicht ersichtlich, verfagen Diebe in der Regel fiber das geringste Angriffspotenzial, wenngleich sie durchaus fiber eine gute Expertise (bspw. aus dem Umfeld der organisierten Kriminalit~it) verfagen k6nnen. W/~hrendessen man bei Fahrzeugbesitzem im Allgemeinen nur von geringem Know-how und geringen finanziellen Ressourcen ausgehen kann, verfagen sie fiber nahezu unbegrenzte Zeit um einen m6glichen Angriff durchzufahren. Gleichzeitig haben Besitzer (technisch und erfahrungsbedingt) nur im begrenzten Umfang Zugang zum Angriffsziel sowie eine nur begrenzte Anzahl von Versuchen oder Vergleichsfahrzeugen. Werkst/~tten hingegen verfagen zwar nur Ober eine mittlere Zeitspanne far einen erfolgreichen Angriff, k6nnen aber oft auf sehr gute Ausrfistung und erhebliches Know-how zurfickgreifen. Ffir die Gruppe der organisierten Kriminalit~it (F~ilscher, Diebstahlvorbereiter, Konkurrenten, etc.) gelten nahezu keine Einschr~inkungen. Solange sich ein Angriff (bspw. durch leichte Skalierbarkeit) wirtschaftlich auszahlt, werden Aufwand, Expertise, technische und finanzielle Ressourcen allein durch den zu erwartenden Gewinn begrenzt.

176

Trusted Computing far automobile IT-Systeme

3.3 Angriffsszenarien Je nach Interesse und F~ihigkeit des Angreifers sind verschiedene Angriffsszenarien vorstellbar. Beispielsweise k6nnte der Fahrer eines Fahrzeugs an unrechtm~il3igen Manipulationen (chip tuning) interessiert sein. Hierfar b0te sich ein Austausch oder eine Manipulation der Motorsteuerung an. Werkstatt oder Besitzer k6nnten versuchen, durch Kilometerstandsmanipulation den Wert des Fahrzeugs zu steigem. Hierbei w~iren passive Angriffe zu bevorzugen, damit die Manipulation unentdeckt bleibt. Typische Angriffe far organisierte Kriminalit~it sind Diebstahl oder auch das Herstellen und Handeln gef~ilschter Ersatzteile. Je nach Angriff mfissen die Angriffsszenarien angepasst werden. W~ihrend beim Diebstahl eines Fahrzeugs der Zugang zum Fahrzeug und seinen Komponenten stark eingeschr~inkt ist und der Angreifer nur wenig Zeit far den Angriff hat (in der Regel nur wenige Minuten), kann far die Vorbereimng eines solchen Angriffs schon deutlich mehr Aufwand betrieben werden. Oft muss dieser Aufwand nur einmal pro Fahrzeugtyp betrieben werden. Gleiches gilt far die FNschung von Ersatzteilen~ Hier wird der Aufwand nur durch die F~ihigkeiten des Angreifers eingeschr~inkto Auch kann ein wenig erfahrener Angreifer Wissen einkaufen. So wird ein Fahrer eine Werkstatt aufsuchen, die far ihn ein illegales Tuning durchfthhrt oder den Kilometerz~ihler manipuliert.

4 Sicherheitsanforderungen im Automobilbereich Der folgende Abschnitt erl~iutert die grunds~itzlichen Sicherheitsziele im Automobilbereich zusammen mit den besonderen technischen und organisatorischen Rahmenbedingungen.

4.1 Sicherheitsziele Basierend auf den zuvor genannten Angriffsszenarien sind, um die Verkehrs- und Funktionssicherheit eines Fahrzeugs zu gew~ihrleisten und fahrzeugbasierte GescMftsmodelle ausreichend abzusichern, folgenden Sicherheitsziele obligatorisch. 9 Integrit~t: Unautorisierte Manipulationen an der Fahrzeughard- und software sind nicht m6g-

(tamper resistance) oder werden durch Fahrzeugsystem zumindest nachtr~iglich erkannt (tamper evidence). lich

9 UnMonbarkeit: Die unautorisierte Herstellung von identischen Hardwarekopien (Klonen) ist nicht m6glich oder solche Kopien werden zumindest als nicht authentisch erkannt. 9 V e r t r a u l i c h k e i t v o n I n f o r m a t i o n e n : Der unautorisierte Zugang zu vertraulichen, intemen Information ist nicht mOglicho 9 Integritiit v o n I n f o r m a t i o n : Die unautorisierte Manipulation kritischer Informationen ist nicht mOglich oder ist zumindest detektierbar. 9 Verfiigbarkeit: Autorisierte Hard- und Softwarekomponenten sind stets in der Lage auf die ihnen zugeordneten Informationen und Dienste zuzugreifen.

4.2 Technische Randbedingungen Der Einsatz komplexer Informationstechnik unterliegt im Automobilbereich einigen besonderen technischen Anforderungen oder Einschrgnkungen.

Trusted Computing t~r automobile IT-Systeme

177

Die Rechenkapazitiit und damit einhergehend die Komplexit~it und der m6gliche Umfang der zu verwendenden Software ist im Automobilbereich nicht mit der PC-Welt zu vergleichen. Trotzdem ist oftmals sogar Echtzeitf'~ihigkeit geforderto Es ergeben sich daher besonders hohe Anforderungen an Laufzeiteffizienz und Speicherbedarf. Zudem ist mit vielen architekturspezifischen Einschr~tnkungen zu rechnen~ Fahrzeug-IT-Systeme mfissen oft besondere physikalische Rahmenbedingungen wie grof3e Temperaturschwankungen, hohe Feuchtigkeit oder erh6hte mechanische Belastungen fiber den gesamten Produktlebenszyklus bei minimalem Wartungsaufwand st6rungsfrei bew~iltigen. Automobile IT-Systeme verfagen in der Regel nur fiber begrenzte Kommunikationsmdglichkeiten, um beispielsweise Schlfissel auszutauschen oder Software zu aktualisieren. Die Funktionalit~it muss mit einem in Umfang und H~tufigkeit ~iul3erst geringen externen Kommunikationsbedarf nahezu vollst~indig automatisiert funktionieren w~ihrend einer fiber einen l~ingeren Zeitraum fehlenden M6glichkeit zur externen Kommunikation nicht wesentlich beeintrfichtigt werden. W~ihrend PC-Benutzer weitgehend ergonomische Ein- und Ausgabegergte benutzen k6nnen, verffigen Benutzer in Fahrzeugen oft nur fiber begrenzt ergonomische Peripherie. Da zudem, fiber ein absolutes Minimum hinaus, yon Benutzem kein Eingreifen erwartet werden darf, m~issen alle Prozesse weitgehend autonom ablaufen.

4.30rganisatorische und rechtliche Randbedingungen Neben den technischen Randbedingungen unterliegen automobile IT-Systeme auch einigen besonderen organisatorischen und rechtlichen Rahmenbedingungen, welche sich vonder PC-Welt teilweise deutlich unterscheiden. Eine eventuell notwendige, einz~Mchtende Schltissel- oder Zertifikatsinfrastruktur, erfordert gerade bei der im Automobilbereich Vielzahl von agierenden Parteien (z.B. Hersteller, Zulieferer, OEM, Kunde, Werkstatt, Datenanbieter), komplexe organisatorische Strukturen. Ein weiterer wesentlicher Schlfisselpunkt ist die Interoperabilitiit zu bereits bestehenden Infrastrukturen, um Benutzern eine m6glichst umfassende Integration ihrer bereits vorhandenen IT-Systeme (z.B. mobile Navigationsger~ite, Mobilfunktelefone, Musik-/Videospieler, etc.) zu erm6glichen. Da im Fahrzeug verbaute IT-Systeme in der Regel nur fiber eine begrenzte M6glichkeit zur Wartung ihrer Software verffigen, sind Kompatibilit6t, Zuverl6ssigkeit und Wartungsfreiheit der verwendeten Hard- und Software dringende Voraussetzung. Insbesondere mfissen automobile IT-System im Vergleich zu herk6mmlichen IT-Systemen fttr eine lange Lebensdauer von bis zu zwei Jahrzehnten ausgelegt werden. Da automobile IT-Technologie teilweise auch besonders kritische Fahrzeugbereiche (Stichwort: driveby-wire) steuert, sind flit die erforderliche Betriebs- und Rechtssicherheit oftmals verbindliche Sicherheits- und Zuverl~issigkeitsaussagen erforderlich, die meist nur fiber komplexe und umfangreiche Zertifizierungsverfahren m6glich sind. Die besonderen Anforderungen, zus~itzlichen Dokumente und Tests Far eine m6gliche Zertifizierung mfissen daher schon yon Beginn an in den Entwicklungsprozess integriert werden.

5 Hardwaresicherheitsmodul Um schlfissige Sicherheitskonzepte in eingebetteten Systemen wie Fahrzeugen realisieren zu k6nnen, muss die Hardware besondere Eigenschaften besitzen. Es werden sowohl kryptografische Methoden

178

Trusted Computing ffir automobile IT-Systeme

und technische Sicherheitsl6sungen als auch organisatorische Vorkehrungen notwendig. G~ingige (Hoch-) SicherheitslOsungen in eingebetteten Systemen bauen t~blicherweise auf einer der folgenden Sicherheitsplattformen (secure computing platforms) auf.

5.1 Sicherheitsplattformen Bei den Sicherheitsplattformen wird klassischerweise zwischen zwei Gruppen unterschieden, den sogenannten Security-Controllern, bei denen es sich um erweiterte Mikrocontroller handelt, und SecurityBoxen, extra flir Sicherheitsanwendungen entworfenen Spezial-ICs (Sicherheits-ASICs). Als besondere Untergruppe der Security-Controller k6nnen TPM-Chips angesehen werden. Sie werden im n~ichsten Unterabschnitt n~iher betrachtet. Bei den Security-Controllern handelt es sich in erster Linie um modifizierte Mikrocontroller wie sie typischerweise in Smartcards eingesetzt werden~ Sie sind sowohl gegen aktive physikalische Attacken wie Fehlerinjektionsangriffe (fault injection), Tamper- und andere invasive Angriffe, als auch gegen passive Angriffe wie Seitenkanalanalyse geschfttzt. Des Weiteren sind viele kryptografische Primitive bereits vorimplementiert bzw. werden durch integrierte Coprozessoren unterst~itzt. Beispiele hierf'tir sind kryptografische Algorithmen wie DES oder AES, Hashfunktionen und arithmetische Primitive f'ttr elliptische Kurven oder RSA (vgl. Tabelle 2 und 3). Oft gibt es auch Elemente zur Erzeugung echter Zufallszahlen (TRNGs), die f'ttr das Schl~sselmanagement und viele kryptografische Protokolle ben6tigt werden. Normalerweise haben viele Security-Controller auBerdem einen geschfitzten Speicher zur sicheren Ablage von Schltisseln und anderen sensiblen Informationen. Security-Controller in verschiedenen Bauformen und Leistungsklassen. Von sparsamen 8-bit Modellen bis hin zu hoch getakteten 32-bit CPUs mit unterschiedlichen Speichergr6Ben und Gehgusetypen gibt es sie in einer Vielzahl von Bauformen. Es ist bereits eine Vielzahl unterschiedlicher Security-Controller auf dem Markt verfagbar, welche sich in F~ihigkeiten und Preis unterscheiden. Allen gemein sind niedrige Herstellungskosten und die geringe Entwicklungszeit, da meist nur die Software angepasst werden muss. AuBerdem k6nnen die Sicherheit und Architekturen der Security-Controller von Zertifizierungsstellen in standardisierten Verfahren (z.B. nach Common Criteria [CC06]) gepraft werden. Demgegengber stehen einige Nachteile, die gerade bei automobilen Anwendungen zu Problemen f'tihren k6nnen. Hierzu geh6rt die relativ niedrige Leistungsf~ihigkeit, die sowohl bei Echtzeitanwendungen als auch bei Anwendungen mit hohem Datenvolumen zu Problemen ft~ren kann. Darfiber hinaus sind die meisten verfftgbaren Produkte nicht ft~r die besonderen, technischen Rahmenbedingungen im Automobilbau (vgl. Kapitel 4.2) ausgelegt. Tab. 2: Laufzeiten des Triple-DES Algorithmus auf modernen Security-Controllern Controller

Verschliisslung,

Bemerkungen

Entschliisselung

Infineon SLE66, 15MHz [Infi02] STM ST19WL34, 8.5MHz [STMi04] STM ST22, 33MHz [STMi06]

12 ~ts

Ein 64-bitBlock, inkl. Obertragungszeit, kryptografischerCoprozessor

58 gs

Ein 64-bitBlock, internerTakt, kryptografischer Coprozessor

1.8 gs

Trusted Computing for automobile IT-Systeme

179

Tab. 3: Laufzeiten eines RSA-1024 Algorithmus auf modernen Security-ControlIern Controller

Verifizierung

Generierung

Bemerkungen

Verifizierungmit e=0x10001, Generierungmit CRT, interner Takt, kryptografischer Koprozessor

Infineon SLE66, 15MHz [Infi02]

7 ms

83 ms

STM ST19WL34, 8.5MHz [STMi04]

5.5 ms

85 ms

STM ST22, 33MHz [STMi06]

3.6 ms

79 ms

Infineon SLE88, 66MHz [Infi06]

2 ms

14 ms

Security-Boxes sind

Hochleistungssyteme, welche zus~itzlich mit Schutzmechanismen gegen physikalische Angriffe ausgestattet sind. Typischerweise handelt es sich um spezielle, an einen Kunden angepasste Systeme, deren Leistungsf'ghigkeit die aktueller PCs erreicht oder sogar darfiber hinausgeht. Sie k6nnen als FPGA (field programmable gate array) oder ASIC (application specific integrated circuit) realisiert sein und enthalten neben einem leistungsf~thigen Mikroprozessor oft auch auf Spezialanwendungen angepasste Hardware. Eingesetzt werden Security-Boxes vor allem vom Milit~ir und sicherheitskritischen staatlichen Beh6rden wie Botschaften, seltener auch in sehr sicherheitskritischen Bereichen in der Industrie. In der letzten Zeit kommen auf Security-Boxes basierende L6sungen auch im Automobilbereich zum Einsatz (z.B~ bei der elektronischen Maut oder beim digitalen Tachographen). Der Vorteil dieser Systeme besteht in ihrer hohen Leistungsf'~ihigkeit. So kann Spezialhardware fiir beliebige Einsatzgebiete eingebunden werdeno Beispielsweise kann durch die Realisierung komplexerer kryptografischer Primitive hohe Sicherheit und gleichzeitig ein hoher Datendurchsatz garantiert werden (vgl~ Tabelle 4 und 5). Aul3erdem k6nnen diese Systeme t'lber grol3e Speicherkapazit~tten verfogen. Dem entgegen stehen vergleichsweise hohe Entwicklungskosten und-dauer, da die Systeme in der Regel speziell for den einzelnen Nutzer angefertigt werden. Aul3erdem ist die Zertifizierung schwierig, da es je nach Anwendung oftmals keine Richtlinien gibt. Ebenso sind die Herstellungskosten aufgrund der niedrigen Sttickzahlen oft sehr hoch. Tab. 4: Durchsatzraten von AES-128 auf modernen ASICs und FPGAs Implementierung

Fl/iche

Durchsatz

Technologie

Frequenz

[HoVe04]

473.000 GE

77.6 Gbps

0.18 ~tm CMOS

606 MHz

[HoVe04]

116.000 GE

15.7 Gbps

0.18 gm CMOS

245 MHz

[HoVe03]

9446 Slices

21.64 Gbps

FPGA, XC2VP20-7

169.1 MHz

Tab. 5: Durchsatzraten von RSA-1024 auf einem ASIC Implementierung

Fliiche

Verifizierung

Generierung mit CRT

Technologie

Frequenz

[Grof300]

1000000 GE

560 Kbit/s

560 Kbit/s

0.6 ~tm CMOS

200 MHz

5.2 TPM als Sicherheitsmodul Bei TPMs handelt es sich um smartcard~ihnliche Mikrocontroller. Allerdings ist ihre Funktionalit~it von der Trusted Computing Group (TCG) genau spezifiziert. Als prim~ires Ziel von TPMs gilt, Angriffe auf Softwareebene zu verhindern. Hierzu stellen TPM Chips verschiedene standardisierte Sicherheitsdienste zu Verfogung (vgl. Buchkapitel x.x)~ Hierzu geh6ren zum Beispiel sicherer Speicher fOr Schltissel und Hashwerte, ein interner Zufallszahlengenerator oder die gesicherte Schltisselerzeugung. Aul3erdem ist das TPM in der Lage, Signaturen zu generieren und zu verifizieren oder Hashwerte zu berechneno

180

Trusted Computing ffir automobile IT-Systeme

Zu den Vorteilen von TPM geh6rt ihre hohe Verbreitung. Auf3erdem werden sie oft von den Herstellern nach Common Criteria zertifiziert. Durch diese Standardisierung weisen TPMs eine hohe Transparenz auf. Ein Nachteil ist der festgelegte Funktionsumfang, der im Einzelfall nicht ausreichen, und auch nicht einfach erweitert (oder auch gekarzt) werden kann. Aul3erdem werden ffir viele Funktionen zus/~tzliche vertrauenswiirdige (Software-) Komponenten ben6tigt. In allen anderen Aspekten wie zum Beispiel den niedrigen Kosten, sind sie den Security-Controllern sehr/ihnlich. Unter anderem ist der Durchsatz von auf TPMs implementierten Algorithmen mit dem von Security-Controllern vergleichbar, da in den meisten F/~llen ffir TPMs dieselbe Basisplattform eingesetzt wird (vgl. Tabelle 2 und 3).

5.3 Sicherheitsarchitekturen Bei Sicherheitsarchitekturen werden im Wesentlichen drei verschiedene Ans~itze unterschieden. Die zentralisierte Architektur, die eine Client-Server Infrastruktur realisiert, die verteilte Architektur, die eine Peer-to-Peer Architektur darstellt und die Mischform der beiden Strukturen, die sogenannte semizentralisierte Architektur. In einer zentralisierten Struktur gibt es nur ein einzelnes Sicherheitsmodul (SM). Dieses Modul stellt die geforderte Sicherheitsfunktionalit~t ffir alle anderen Module (CU) zltr Verffigung. Um die Sicherheitsfunktionalit~.t zu gewfihrleisten, muss dieses Modul gegen alle bekannten Angriffe geschfitzt sein. Jedes andere Modul teilt ein gemeinsames Geheimnis mit dem Sicherheitsmodul (zum Beispiel einen individuellen geheimen Schlfissel) um mit Hilfe des Sicherheitsmoduls eine Authentisierung oder ein Schlfisselerzeugungsprotokoll zu erm6glichen. Wenn zwei Module A und B eine gescht'ltzte Kommunikationsverbindung aufbauen wollen, wird das Sicherheitsmodul in diesen Verbindungsaufbau eingebunden. Sobald die Verbindung aufgebaut ist, wird das Sicherheitsmodul ffir die weiterf'tihrende Kommunikation nicht mehr ben6tigt. Es ist also nicht notwendig, dass die einzelnen Module far die Kommunikation mit jedem anderen Modul jeweils einen Schl%sel speichern. Allerdings sollte berficksichtigt werden, dass das System in der Lage sein muss, die notwendigen SchlOssel rechtzeitig fiber das Sicherheitsmodul auszuhandeln und zu verteilen, um m6gliche geforderte Echtzeitanwendungen. Weiterer Speicher kann eingespart werden, wenn die einzelnen Schlfissel zur Kommunikation mit den Modulen aus einem fahrzeugspezifischen Schlfissel abgeleitet werden k6nnen. S~mtliche Kommunikation mit der Augenwelt sollte nur fiber das Sicherheitsmodul abgewickelt werden, um entsprechende Filter und Protokollierungsmagnahmen wirksam durchsetzen zu k6nnen. Augerdem ist es sinnvoll andere sicherheitsrelevante Komponenten, wie beispielsweise die elektronische Wegfahrsperre oder den Kilometerz~hler, mit in das Sicherheitsmodul zu integrieren. Das Sicherheitsmodul kann sowohl als eigenst~ndiges Modul realisiert werden oder in ein bereits existierendes Modul integriert werden. Es sollte allerdings berficksichtigt werden, dass ein erfolgreicher Angriff auf das Sicherheitsmodul, einen erfolgreichen Angriff auf die gesamte zentralisierte Architektur gleichzusetzen ist~ Deshalb sollte ein erfolgreicher Angriff auf das Sicherheitsmodul mindestens genauso schwierig sein, wie ein Angriff auf alle oder zumindest einen Grogteil der fibrigen Module~ Einige m6gliche Umsetzungen des zentralen Sicherheitsmoduls in Hardware werden hier vorgestellt: 9 Konventioneller Mikrocontroller: Diese LOsung kann dann ausreichend sein, wenn physische Angriffe ausgeschlossen werden kOnnen. In diesem, eher unwahrscheinlichen Szenario, mtissen

Trusted Computing far automobile IT-Systeme

181

die einzelnen Module trotzdem fiber ausreichende Rechenkapazitgt verfagen, um einen schnellen Schl%selaustausch und die sichere Kommunikation mit der Au6enwelt zu erm6glichen. Diese L6sung ist dann vorzuschlagen, wenn der Security-Controller die physikalischen Rahmenbedingungen im Fahrzeug bew~iltigt und mit einem leistungsf~ihigen kryptografischen Coprozessor ausgestattet ist, um die Kommunikation mit der Auf3enwelt zu erm6glichen.

9 Security-Controller:

~ Security-Box: Die L6sung ist am besten far ein zentrales Sicherheitsmodul geeignet, da diese sowohl gesicherte Echtzeitkommunikation als auch eine gesicherte Kommunikation nach aul3en bereitstellen kann.

Icu~ Ico

Gesch 0 tzter Datenspeicher

H

Externe Partei

Kryptografisch e Dien ste

I CUn Abbo 2: Zentralisierte Sicherheitsarchitektur In einer verteilten Architektur wird die Funktionalit~it des SicherheitsmoduIs auf alle Module eines Systems verteilt. Das System kann so realisiert werden, dass einzelne Module die Sicherheitsfunktionalit~it autonom anbieten und sich nach aul3en wie ein einzelnes Sicherheitsmodul verhalten. Im einfachen Fall teilen externe Partei und Modul ein gemeinsames Geheimnis, mit dem sich die externe Partei authentifizieren kann und die Kommunikation gesichert werden kann. Hierdurch wird der Speicherbedarfjedes Moduls stark erh6ht und die Sicherheit des Gesamtsystems auf das des schw/~chsten relevanten Moduls reduziert, da jedes Modul s~imtliche relevanten Schlfissel enthalten muss. Andemfalls stellen die Module gemeinsam ein abstraktes Sicherheitsmodul dar, das von einer externen Partei angesprochen werden kann. Bei dieser L6sung wird far das Schl%selmanagement deutlich weniger Speicher ben6tigt. Bisher existieren aber nur wenige schliissige Konzepte, die diesen L6sungsansatz aufgreifen. Zur Realisierung in Hardware sind die folgenden Konzepte denkbar: 9 E i n f a c h e M i k r o c o n t r o l l e r : Beim Entwurf des Systems muss ein leistungsf~ihiges verteiltes Schltisselmanagementsystem implementiert werden~ dass die Sicherheitsanforderungen und Geschwindigkeitsanforderungen erffillt. FOr die sicherheitskritischen Anwendungen werden Security-Controller eingesetzt, die anderen Anwendungen bedienen sich herk6mmlicher Mikrocontroller.

9 E i n s a t z e i n z e l n e r Security-Controller:

9 E i n s a t z e i n z e l n e r T P M s : FOr einige Anwendungen mit eingeschr~inkten Sicherheitsanforderungen k6nnen auch TPMs eingesetzt werden. Bei TPMs sollte beachtet werden, dass sie abh~ingig yon der Instanz sind, die ihre Funktionalit~it aufrufen und deshalb in einer sicheren Umgebung laufen sollten.

182

Trusted Computing far automobile IT-Systeme

Ico l Ico, I Ico

I

Ico, I I Icu, [ Extem e Partei

Abb. 3: Verteilte Sicherheitsarchitektur Die semi-zentralisierte Architektur ist eine Mischform der zentralisierten und der verteilten Architekmr. Einerseits bietet sie ein zentrales Sicherheitsmodul, das Sicherheitsfunktionalit/~t far die iibrigen Module bereitstellt. Darfiber hinaus aber werden einige weitere Module, far gew6hnlich die besonders sicherheitskritischen, mit eigener Sicherheitsfunktionalit~it und eigenen extemen KommunikationskanNen ausgestattet. Diese zus~itzlichen Sicherheitsmodule k6nnen Verbindungen mit dem zentralen Sicherheitsmodul und/oder mit den anderen Modulen fiber ihr eigenes Schlfisselmanagementsystem aufbauen. Hierdurch steigt der Platzbedarf far die Schltisselspeicherung nur linear. M6gliche Kandidaten far die zusgtzlichen Sicherheitsmodule sind die kritischen Anwendungen wie die Motorsteuerung, die elektronische Wegfahrsperre oder der Kilometerz~ihler. FOr die Realisierung einer semi-zentralisierten Architekmr kommen typischerweise folgende Hardwarel6sungen in Frage: 9 Standard Mikrocontroller und Security-Controller: Die einzelnen Module werden je nach Sicherheitsbedarf auf normalen Mikrocontrollern oder auf Security-Controllern realisiert. Die Kommunikation zwischen den einzelnen Modulen wird von einem zentralen Sicherheitsmodul gesteuert, welches ebenfalls auf einem Security-Controller realisiert ist. Die Module k6nnen auf3erdem auf die Sicheheitsfunktionalit~it des zentralen Sicherheitsmoduls zugreifen. ~ Standard Mikrocontroller, Security-Controller und Security-Box: Nicht sicherheitsrelevante Anwendungen werden auf normalen Mikrocontrollern implementiert. Die Software sollte allerdings grunds~itzliche Sicherheitsfunktionalit~it unterstfitzen. Sicherheitsrelevante Anwendungen werden auf Security-Controllem implementiert, wobei Aufgaben, die hohe Rechenleistung ben6tigen, an ein zentrales Sicherheitsmodul, die Security-Box, delegiert werden k6nnen."

Trusted Computing far automobile IT-Systeme

183

iillI

Gesch (~tzter Daten speicher

li,

Kryptografische Dienste

/*

/r d

-

~ i

'- ,,, " SM1 ]-,

ExtemePartei

.. ~ ti"

"'~ SMt

Abb.4: Semi-zentra]isierte Sicherheitsarchitektur

6 Beispielimplementierung Um die Praxistauglichkeit von Trusted Computing Technologie im Automobilbereich unter Beweis zu stellen, wird in [ScSW06] ein konkreter Entwurf far eine automobile Sicherheitsarchitektur, welche beliebige Software und Informationen sicher an eine bestimmten Fahrzeugkonfiguration ,,binden" kann, vorgestellto Basierend auf Techniken der Virtualisierung, Trusted Computing und eines minimalen Sicherheitskems, haben hierbei nur zuvor autorisierte Dienste und Konfigurationen Zugriff auf die entsprechend geschiitzten Daten ohne dass dabei gleichzeitig besondere Sicherheitsanforderungen an die Infrastruktur zur Verteilung der Daten gestellt werden miissen. Somit k6nnen beispielsweise Softwareaktualisierungen nur far bestimmte Modelle oder selbst far einzelne Fahrzeuge freigeschaltet werden. S~imtliche unautorisierten Fahrzeuge sind dann nicht in der Lage diese Software einzuspielen. Zum Nachweis der Funktionalit~it wurde zudem ein entsprechender Demonstrator prototypisch implementiert. Der wesentliche Ablauf der Implementierung ist in Abbildung 1 dargestellt. Die zwei agierenden Parteien sind der Datenanbieter und das Fahrzeug bzwo dessen Nutzer. Der Datenanbieter subsumiert alle Anbieter yon digitalen Informationen far Fahrzeuge. Das umfasst sowohl Steuerger~itesoftware, als beispielsweise auch Navigationsdaten oder Multimediadateien. Das eigentliche Ablaufprotokoll besteht im wesentlichen aus vier Schritten, wobei die ersten beiden Schritte auch schon w~ihrend der Fahrzeugherstellung beim OEM durchgefahrt werden k6nnen, ohne dass der Fahrzeugbesitzer involviert werden muss.

184

Trusted Computing far automobile IT-Systeme

r--

Datenanbieter

Fahrzeug

~i]!13~8i~4i~!~i~84 i~!i!i!i!

#~g_____J e-

Fahrzeugkonfiguration

L

Gebundene (verschlasselte) Daten Abb.5: Automobile SW-Schutz aufBasis von Trusted Computing In Schritt eins wird zun~ichst die aktuelle Fahrzeughard- und -softwarekonfiguration mit Hilfe von Trusted Computing Technologie vertrauenswtirdig ,,gemessen" (authenticated boot). Basierend auf dieser Messung wird ein asymmetrisches Schltisselpaar erzeugt, dessen privater Teil sicher im TPM hinterlegt wird, w~ihrend far den 6ffentlichen Teil vom TPM ein Zertifikat tiber die aktuelle Fahrzeugkonfiguration erstellt wirdo Das Zertifikat zusammen mit dem 6ffentlichen Teil des Schltissels wird anschliegend dem jeweiligen Datenanbieter zur Verftigung gestellt~ Im zweiten Schritt kann der Datenanbieter anhand des Zertifikats die Vertrauenswtirdigkeit (und/oder Kompatibilit~tt) der jeweiligen Fahrzeugkonfiguration tiberprfifen. Entspricht die Fahrzeugkonfiguration seinen Sicherheitsanforderungen, kann der Datenanbieter in Schritt drei den 6ffentlichen Teil des Schltissels benutzen, um damit die zu schtitzenden Daten an diese Fahrzeugkonfiguration ,,zu binden". Die so gebundenen Daten k6nnen nun nur noch von dieser zuvor autorisierten Fahrzeugkonfiguration gelesen werden und k6nnen daher fiber eine ungesicherte Infrastrukmr (z.B. CD, Mobilfunktelefon, Internet) zum Fahrzeug tibertragen werden. Im vierten und letzten Schritt werden die Daten im Fahrzeug ,,entbunden" und den jeweils autorisierten Diensten zur Verfagung gestellt. Es ist dabei anzumerken, dass nur die zuvor im Zertifikat ausgezeichnete Fahrzeughard- und -softwarekonfiguration in der Lage ist auf die geschtitzten Daten zuzugreifen. Jeglichen anderen oder auch nachtdiglich ver~tnderten Fahrzeugkonfigurationen wird der Zugriff auf den privaten Teil des asymmetrischen Schltisselpaares durch das TPM verwehrt. Damit kann der Datenanbieter auch nach der Oberprtifung der Zielplattform sicherstellen, dass nur genau diese in der Lage ist seine Daten zu verwenden. Zur Realisierung dieses Szenarios wird auf Fahrzeugseite lediglich ein minimaler Sicherheitskern mit Virmalisierungsfunktionalit~tt und Trusted Computing Erweiterungen vorausgesetzt. Prototypische Implementierungen eines solchen Sicherheitskerns stehen bereits ftir eingebettete Systeme zur Verfagung [EMSC06]o Die Anbieterseite kann allein mittels Standardhard- und -software realisiert werden.

Trusted Computing far automobile IT-Systeme

185

7 Fazit Im diesem Beitrag wurden MOglichkeiten, L6sungen und Herausforderungen far den Einsatz von Trusted Computing Technologie im Automobilbereich betrachtet. Nach einer kurzen Einfahrung in die Thematik der IT-Sicherheit im Automobil, wurden zahlreiche m6gliche Einsatzgebiete von TC im Automobil vorgestellt. Es wurden die besonderen automobilen Angriffsziele, Angriffszenarien und Angreiferklassen, welche sich teilweise deutlich von herkOmmlichen IT-Systemen unterscheiden, detailliert dargestellt. Basierend auf diesem Gef'~ihrdungspotenzial wurden anschlieBend die notwendigen Sicherheitsziele far automobile IT-Systeme zusammen mit ihren spezifischen technischen und organisatorischen Rahmenbedingungen definiert. Es wurden verschiedene, auf unterschiedlichen Hardwareplattformen basierende Sicherheitsarchitekturen, vorgeschlagen, welche insbesondere auch mit Hilfe von TC Technologie kostengt~nstig und effizient realisiert werden k6nneno Der Beitrag schliel3t mit einer prototypischen Implementierung von Trusted Computing Technologie far einen Anwendungsfall aus dem Automobilbereich. Zusammenfassend bleibt zu sagen, dass die Integration von IT-Sicherheit Automobil (i) gegen unbefugte Manipulationen von Besitzern, Werkstgtten und externe Dritten schfitzt, (ii) die Zuverl~issigkeit und Sicherheit eines Fahrzeugs erh6ht, sowie (iii) zahlreiche IT-basierte automobile Anwendungen und Gesch~iftsmodelle fiberhaupt erst erm6glicht. Um IT-Sicherheit sicher und zuverl~issig im Fahrzeug zu implementieren sind noch einige Herausforderungen zu fiberwinden. Neben zahlreichen, weiteren technischen und organisatorischen Maf3nahmen bietet die Technologie des Trusted Computing einige Mechanismen und L6sungsm6glichkeiten um IT-Sicherheit kostengfinstig, sicher und zuverl~issig im Fahrzeugbereich zu realisieren.

Danksagungen Besonderer Dank gilt Dario Carluccio, Andr~ Weimerskirch und Thomas Wollinger, welche durch ihr umfangreiches Fachwissen und viele hilfreiche Kommentare wesentlich zum Gelingen dieses Artikels beigetragen haben.

Literatur [Atme06] Atmel Corp.: Embedded Security (TPM). www.atmel.com/products/Embedded/ [CC06] Common Criteria for Information Technology Security Evaluation. Parts 1, 2 and 3. Version 3.1, September 2006] [CCIM04] Common Criteria. Common Methodology for Information Technology Security Evaluation. Evaluation Methodology. Version 2.2, Revision 256 CCIMB-2004-01-004, January 2004 [CCDB06] Common Criteria. Supporting Document Mandatory Technical Document. Application of Attack Potential to Smartcards, Version 2.1, Revision 1. CCDB-2006-04-002, 2006 [EGH00] D. Estrin, R. Govindan und J. Heidemann: Embedding the Internet. In Communications of the ACM, 43(5):39-41, Mai 2000~ [EMSC06] European Multilaterally Secure Computing Base (EMSCB), www.emscb.de [ESC06] Whitepaper escrypt GmbH: Security Modules for Vehicles, September 2006 [Fris03] Hans-Georg Frischkorn: IT im Automobil- Innovationsfeld der Zukunft, Keynote GI Jahrestagung, 2003. [HoVe03] A. Hodjat and IoVerabauwhede. Speed-Area Trade-Off for 10 to 100 Gbit/s Throughput AES Processor, IEEE, 2003 [HoVe04] A. Hodjat and I. Verabauwhede. A 21.54 Gbis/s Fully Pipelined AES Processor on FPGA, IEEE, 2004

186

Trusted Computing fiir automobile IT-Systeme

[Gie05]

Gieschen Consultancy, Report: IP Theft up 22%, massive $3 Trillion Counterfeits, In www.bascap.com, Mai 2005.

[Grog00]

J. GroBsch~idl. High-Speed RSA Hardware Based on Barret's Modular Reduction Method, CHES 2000, 2000

[Infi02]

Infineon. SLE 66CX642R 16-Bit Security Controller. Short Product Information 11.02, 2002

[Infi06]

Infineono SLE 88CFX4003P for Highest-End Security Applications, Short Product Information 08.06, Infineon, 2006

[Ross03]

Ross Anderson: Electronic Safety and Security- New Challenges for the Car Industry. In Workshop on Embedded Security in Cars, K61n, 2003.

[Ross04]

Sativa Ross: Parts Counterfeiting. In www.aftermarketbusinessocom/aftermarketbusiness/article/ articleDetail.jsp?id=125346, Oktober, 2004

[SaWe03] Alexandre Saad and Ulrich Weinmann: Automotive Software Engineering and Concepts. In GI Jahrestagung, 318-319, 2003. [ScSW06] M. Scheibel, C. Stable, M. Wolf: Design and Implementation of an Architecture for Vehicular Software Protection, Embedded Security in Cars Workshop (escar '06), 14.- 15. November 2006, Berlin [STMi04] STMicroelectronicso ST19WL34. Smartcard MCU with MAP and 34 Kbytes High Density EEPROM, STM, 2004 [STMi02] STMicroelectronics. ST22T064-Ao Smartcard 32-Bit RISC MCU with 64 Kbyts EEPROM with USB Full Speed Device Controller, STM, 2006

Trusted Computing in mobiler Anwendung: Von Zugangskontrolle zu Identit iten Andreas U. Schmidt- Nicolai Kuntze Fraunhofer Institut fiir sichere Informationstechnologie SIT Rheinstrage 75, 64295 Darmstadt {Andreas.U.Schmidt ] Nicolai.Kuntze} @sit.fraunhofer.de

Zusammenfassung Der Sektor mobiler Kommunikation und Dienstleistungen ver~indert sich rasant durch die horizontale Konvergenz yon Zugangstechnologien und .die zunehmende Intelligenz yon Endger~iten. Neue Gesch~iftsmodelle in diesem Bereich brauchen neue Schutzmethoden und Vertrauensgrundlagen technischer Art. Trusted Computing (TC) in seiner Auspr~igung far mobile Ger~ite kann diese bieten. Wir zeigen auf konzeptioneller Ebene und in konkreten Anwendungsbeispielen, wie diese Technologie nicht nur bestehende Anwendungen scht~tzen kann sondern auch neuartige Gesch~iftsmodelle erst erm6glicht. Die Vorteile eines dezentralisierten Ansatzes far Identit~tsmanagement basierend aufTC werden herausgestellt.

1 Einleitung Anbieter von mobiler Kommunikation und Diensten sehen sich weit reichenden Umw~ilzungen gegenfiber. Zum einen wird der Zugang zu Netzen Diensten durch die fortschreitende horizontale Konvergenz von Zugangs-Technologien immer netzwerk-agnostischer. So ffir einen schon heute mobile Endger~ite vielf'~iltige Kommunikationsschnittstellen wie GSM (2G), 3G, WLAN, WiMax, Bluetooth, MobileIR Weitere Schnittstellen wie Nokias kfirzlich vorgestelltes Wibree entwickeln sich rasant. Andererseits werden Endger~ite zunehmend ,,smart" und verlieren die reine Zweckbindung an Sprachkommunikation. Sie sind in der Lage, Anwendungen, Daten und Medien nicht nur zu konsumieren, sondern auch selbst anzubieten und bereitzustellen. Die Studien verschiedener Analysten [KPMG06] zeigen, wie hierdurch die klassischen Gesch~iftsmodelle von mobilen Netzbetreibern (MNOs) und Diensteanbietern bedroht sind. Wie John Curtis, Chef der Abteilung Information, Communications & Entertainment yon KPMG Deutschland betont:

"Doch permanent subventionierte Handys auf den Markt zu werfen, bringt langfristig keinen Geschiifiserfolg. Sinnvoller ist es, sich mit Hilfe attraktiver konvergenter Dienstleistungen [ . . . ] eine stabile und loyale Kundenbasis aufzubauen. Damit wird man fiir Werbekunden und Partner im digitalen Handel attraktiv und erOffnet sich neue Einnahmequellen [ . . . ] Verrechnungsmanagement wird deshalb kiinfiig zu einer Schliisselkompetenz. " KPMG r~it den MNOs in der Tat, sich an den aufkeimenden Gesch~iftsmodellen des Web 2.0 zu orientieren und neben mobilem Entertainment auch mobile vernetzte Spiele ins Auge zu fasseno MNOs seien N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 187-206

188

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit/~ten

aber immer noch privilegierte Marktteilnehmer durch ihre riesigen und stabilen Kundenbasen und weil die Mehrheit der Kunden insbesondere bei der Abrechnung von Diensten die direkte Beziehungen zu einem eindeutigen, vertrauenswttrdigen Anbieter w~nscht. Gerade hier besitzen MNOs eine etablierte technisch weit fortgeschrittene Kompetenz. Gartner st6gt ins selbe Horn [Ga06], warnt aber, dass MNOs aufgrund ihrer klassischen Denkweise ,,wie konstruiere ich einen abrechenbaren Dienst" bei der l~)bernahme yon Web 2.0 Konzepten zun/~chst keine Ft~hrungsrolle innehaben. Kombiniert mit den Bedrohung ihrer klassischen Gesch/~ftsfelder zum Beispiel durch den Preisdruck beim internationalen Roaming, Festnetzterminierung, SMS, voice-mail, etc, m%sten die MNOs in den n/~chsten drei bis fanf Jahren einen Verlust von bis zu 25% bei ihren Gewinnspannen hinnehmen. Jedoch sieht man auch hier weit reichende Chancen. M6glichkeiten zur mobilen Kollaboration, allen voran mobile E-Mail push-Dienste, entstehen in Reaktion auf die zunehmende Mobilit~it von ,,WissensArbeitern" und versprechen Effektivit/~tssteigerungen und ,,Return on Investment". Gartner sagt voraus, dass solche Techniken bis 2009 nicht mehr der Management-Ebene vorbehalten bleiben, sondern zum allgemein verfagbaren Handwerkszeug werden. FOr den Bereich der Smartphones sieht man hier von 2005 bis 2009 ein j~ihrliches Wachstum von bis zu 49%. FOr die hoch gebildeten und technikoffenen Nutzer wird schlieglich die Annahme von Konzepten des Web 2.0 keine Ht~rde bilden, was zu einer Renaissance des m-commerce fahren k6nnte. W/ihrend die ,,Location Based Services" der ersten Generation ein schlechtes Preis-Leistungs-Verh/~ltnis boten und auf der naiven 121bertragung von WWW-Technologien beruhten, bieten Ideen des Web 2.0, insbesondere das autonome bilden von Nutzergemeinschaften die selbstorganisierte Suche nach Gt~tern und Dienstleistungen und Ahnliches, in Kombination mit Konvergenz in Endger~iten g~inzlich neue M6glichkeiten. So wird es m6glich Daten selektiv zu Nutzern zu ,,pushen" (mobile Nutzer haben wenig Zeit for die aktiven Suche nach Inhalten) sobald sie sich zum Beispiel in die N~ihe eines Verk~iufers gegeben, aber stets unter Berficksichtigung der Vorlieben und Einstellungen des Individuums. Nutzung und Gesch/iftsmodelle sind vielf'~iltig. So kann das mobile Endger/~t zur Quelle und Senke lokalisierter Informationen, zum mobilen Verkaufsstand oder zum Bezahlterminal werden. Solche Szenarien ben6tigen einen hinreichend starken Schutz der Prozesse die zur Leistungserbringung fahreno Diese Prozesse lassen sich in die Authentisierung, Autorisierung, Audit sowie Accounting und Charging einteilen. Die Basis far Vertrauen ist hierbei immer eine vertrauenswttrdige starke Authentisierung des Benutzers, auf deren Basis letztendlich der Zugang zu Inhalten und deren Vergebfihrung beruht. Daneben fahrt der oben beschriebene Trend zu immer leistungsf'~ihigeren Endger/~ten und die Verschiebung der Nutzungsgewohnheiten sowie die Diversifizierung der Netzzugangstechnologien zu komplexeren Anwendungsszenarien und konvergenten Netzen. Im Kontext konvergenter Netze wird es deutlich, dass ein einheitliches netzwerk-agnostisches Authentisierungssystem von Vorteil sein kann, dass auch als Basis far die jeweiligen darauf aufsetzenden Szenarien und Prozesse verwendet werden kann. Die Industrie hat im Rahmen der Trusted Computing Group vonder (Fach-)0ffentlichkeit weitgehend unbemerkt diesen Themenkomplex durch die Grfindung der Mobile Phone Working Group adressiert. Das dort spezifizierte Mobile Trusted Module (MTM) berficksichtigt die speziellen Anforderungen, die im mobilen Einsatz von Seiten der Netzbetreiber existieren und basiert auf den Konzepten des bekannten Trusted Platform Module (TPM). Hierdurch wird ein physischer Vertrauensanker in mobilen Endger~iten etabliert und firment~bergreifend standardisiert, so dass die Interoperabilitgt der verschiedenen Implementierungen gew~ihrleistet wird.

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit~iten

189

Auf dieser technischen Basis betrachten wir, welche bekannten und neuartigen Anwendungen durch diese Entwicklungen beeinflusst und kreiert werden. Insbesondere das Plus an Sicherheit das ein physischer Sicherheitsanker liefert, kann bereits bekannte Anwendungen stark aufwerten und far neue Szenarien attraktiv machen. Bei einer direkten Bindung eines Gergtes an einen bestimmten Benutzer, wie es im mobilen Umfeld t~blich ist, kann Trusted Computing auch als Basis einer Identit~itsverwaltung zum Einsatz kommeno Dies 6ffnet neue M6glichkeiten far die kommerzielle Verwendung der mobilen Endger~ite. Die in diesem Beitrag ben6tigten Grundlagen des Trusted Computing werden im Abschnitt 2 dargelegt. Hier wird ein besonderes Augenmerk auf die Funktionalit~iten geworfen, die far die Verwaltung von Identit~iten ben6tigt werden und auf die Auswirkungen bezfiglich der Privatsph~ire und informationellen Selbstbestimmung. Im Abschnitt 3 werden mobile Anwendungen an den Beispielen der funktionalen Restriktion und der Maschinen-zu-Maschinen-Kommunikation vorgestellt. Daraufhin wird in Abschnitt 4 der Schritt hin zu digitalen Identitgten vollzogen, die dezentral durch die Endger~ite realisiert werden. Hierbei wird am Beispiel eines Ticketsystems, einer dynamischen Preisfestsetzung in Reputationssystemen und zuletzt dem Schutz von Daten der Einsatz solcher Identit~iten dargestellt. Kapitel 5 schlieBt mit einem Ausblick.

2 TC Brevier Trusted Computing (TC) hat das generelle Ziel Vertrauen in Plattformen zu etablieren. Hierzu hat die Trusted Computing Group (TCG) eine Familie von Standards definiert in denen ein soggenanntes Trusted Computing Module (TPM) als Vertrauensanker verwendet wird. Dieses Modul bietet die F~ihigkeiten asymmetrische Schlt~ssel sicher zu erzeugen, zu verwahren und zu verwenden. Neben Schl~sseln k6nnen auch beliebige Datenbl6cke, sog~ Blobs, an einen TPM gebunden werden (Blob Binding). Dart~ber hinaus bietet TC die M6glichkeit eine Aussage fiber die Integrit~it der Plattform zu treffen und diese Aussage einer dritten Partei mitzuteilen. Eine Umgebung, die in dieser Art erweitert ist, wird als Trusted Platform (TP) bezeichnet. Der Vertrauensbegriff der TCG kreist um die nachgeordneten Termini ,,Trust", ,,Measurement" und ,,Attestation". Trust im TCG-Sinne bedeutet, dass eine Entit~it (d.h. ein technisches System im Kontext der mit ihm gegent~ber der Aul3enwelt durchgefahrten Transaktionen und Kommunikationsvorg~tnge) sich in jedem Fall in der zu erwartenden Weise verh~ilt, abh~ingig vom jeweiligen Bestimmungszweck. Dieser Vertrauensbegriff ist zun~ichst wertneutral. ,,Measurement" eines Systems ist ein vonder TCG sehr weit gefasster Begriff, der t~ber die Feststellung einer eindeutigen Identit~it einer Entit~it hinaus auch noch die Messung ihrer momentanen Konfiguration beinhaltet. Identit~it meint hier nicht Individualit~it, sondern die Identifikation der Eigenschaft, eine TP zu sein. Attestation ist der Prozess, der diese Identit~it als TP, gegenftber einem Dritten nachweist. Jeder einzelne TPM hat eine eindeutige Identit~it in Form des so genannten Endorsement Keys (EK), der zum Zeitpunkt der TPM-Fertigung erzeugt wird. Der EK ist als asymmetrischer Schlfissel mit einer Lgnge von 2048 Bit ausgelegt, dessen privater Teil den TPM nicht verl~isst. Vom Hersteller wird zugleich ein Endorsement Key Credential (EKC) erzeugt, welches die Echtheit des TPM und des zugeh6rigen EKs best~itigt, sowie dass der private Teil zum EKC sich im TPM befindet. Vor einem Einsatz des TPM muss ein Benutzer zuerst den Besitz fiber den jeweiligen TPM durch das durchfahren des Take-Ownership Protokolls erlangen. In diesem Kontext wird nicht das Wort Zertifikat verwendet sondern auf den mehr generischen Term Credential ausgewichen, da es sich hierbei nicht um Zertifikate entsprechend den X.509 Standards handeln muss. Auch ist nur eine sehr rudiment~ire PKI Struktur von N6ten, diese Credentials zu t~berprtffen.

190

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

Fftr das Erfassen der Systemintegrit~it bietet der TPM die Platform Configuration Registers (PCR), die jeweils 160-bit lange Hashwerte aufnehmen und die technische Basis Ft~reine Attestierung des Systems bilden. Im Rahmen einer Attestierung wird einer dritten Partei signalisiert, dass (1) die Plattform unvergndert ist und (2) sich in einer vertrauenswfirdigen Konfiguration befindet. Es muss aber beachtet werden, dass die endgfiltige Entscheidung, ob eine Plattform vertrauenswt~rdig ist letztendlich bei der dritten Partei liegt. Um diese zwei Eigenschaften zu erfassen ist es n6tig jede Ver~nderung am System ab dem Systemstart zu erfassen und zu speichern, was durch den Trusted Boot Prozess durchgeftthrt wirdo Hierdurch wird eine Vertrauensbasis in die zugrunde liegende Plattform etabliert. Zum Beginn des Systemstarts misst sich eine spezielle Komponente selber und meldet diesen Wert an den TPM und an ein Logbuch. Danach wird durch diese Komponente das BIOS erfasst, der Wert ebenfalls dem TPM und dem Logbuch gemeldet u.nd das BIOS geladen. Dieses wiederum f'tihrt das mit der n~ichsten Komponente im Bootprozess durch. Es entsteht eine Kette von Messwerten, die durch den PCR Wert best~itigt werden.

if!i; ............. !~ii!ii!!iiiii!!ii!!i ii!iiiiiiii!ii84iii~!~!i !i~i!:i~iil!!il~!i~il~ii;~ii~ii84 ~i!i!iii:iiiii~ii!i! ~i~i:~

~

r

'

- -

- -

- -

i

I I I ;

~lT~g~2"

]

a~orm ]

:~

]

:: j C: : mfg

:~

I

AIK credential

II

t:

I

p~

r]

I i

Abb.

1: Remote

~

i

..n

. , i . . m .

roll

~

~

Attestation

Wghrend der Attestierung erhNt die dritte Partei den PCR Wert und das korrespondierende Logbuch, jeweils geeignet gescht~tzt durch den TPM. Hierzu werden die PCR Werte durch spezielle Schlt~sselpaare, die Attestation Identity Keys (AIKs), signiert. Diese sind durch den TPM erzeugt und durch diesen verwaltet. Die Zugeh6rigkeit eines AIK zu einem speziellen TPM wird durch ein Zertifikat best~itigt, dass durch eine vertrauenswfirdige externe Instanz, die Privacy CA (PCA), ausgestellt wird und damit eine pseudonyme Identit~it ffir diesen TPM geschaffen hat. Dieses Verfahren begegnet verschiedenen Bedenken bezfiglich des Datenschutzes, da eine Publikation des EK nicht notwenig ist. Die eindeutige Identitgt des TPM wird hierdurch verborgen. Die adressiere dritte Partei muss auf der Basis der erhaltenen Werte entscheiden, ob die Daten von einer vertrauenswt~rdigen Instanz stammen. Diese Entscheidung muss die jeweiligen Hardwarekomponenten des Kommunikationspartners bert~cksichtigen. Aufgrund der Mannifaltigkeit der heutigen PC Hardware, erfordert diese Entscheidung eine groge Referenzbasis. PCR Werte bieten neben der Attestierung die M6glichkeit, die Verfagbarkeit von Schlt~sseln und Daten an die Konfiguration der Plattform zu binden. Hierzu bieten die verschiedenen Funktionen die M6glich-

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit~iten

191

keit einen bestimmten PCR Wert zu definieren, der im jeweiligen Register zum Zeitpunkt des Zugriffs vorhanden sein muss. Abbildung 1 zeigt den Prozess der Remote Attestation einer TP durch einen Verifizierer. Der ausgewiesene Besitzer der TP fragt beim Verifizierer einen Dienst nach, woraufhin dieser auf eine Attestierung der TP besteht. Der TPM signiert daraufhin den Wert des PCRs mit dem privaten Teil seines AIKs. Die Trusted Platform fibertr~igt den signierten PCR Wert und das AIK Credential, das zum gerade benutzten AIK geh6rt an den Verifizierer. Dieser kann die digitale Signatur verifizieren und sich die G~iltigkeit des AIK credentials von der PCA best~itigen lassen. Festzustellen, ob er der Plattform vertrauen k a n n - auf Basis des PCR-Wertes oder des optional zus~itzlich t~bertragenen Logbuchs- obliegt dem Verifizierer. Neben dem vorgestellten Konzept der PCA und den damit verbundenen Einschr~inkungen bezfiglich der Anonymit~it, die PCA kann potenziell immer eine Identit~it aufl6sen, hat die TCG die Direct Anonymous Attestation (DAA) eingeNhrt. Basierend auf Zero-Knownledge-Proofs wird eine Variante des Idemix-Verfahrens implementiert. Hierdurch ist es m6glich, die Anonymitgt der jeweiligen TPMs zu wahren, da lediglich die Existenz eines Credentials nachgewiesen wird, nicht aber das Credential selber fibertragen wird.

cap

~VDM

*mobiles TPM Profil, derzeit im Standardisierungsprozess der TCG Abb. 2: ,,Trusted" mobiles Endger~it

Aufgrund der Limitierungen der mobilen Endger~ite beztiglich Rechenleistung, Energieversorgung und Speicher, aber auch den gegenftber dem PC-Bereich unterschiedlichen Gesch~iftsmodellen wird durch die Mobile Phone Working Group der TCG eine spezielle Version eines TPMs entwickelt, der diesen Bedingungen gerecht wird. Dieses Mobile Trust Module (MTM) bietet beispielsweise einen speziellen

Trusted C o m p u t i n g - eine Einfahrung 7 192 Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit~tten

Gergteseitigen Verifizierer, so dass das Ger~it ii ! eine Verifizierung 84iii!iiii .... durchfahren kann und dem gegenCtber mitteilen. ....,,......

~@! I D C

Eine hohe Marktdurchdringung wird von der Industrie far dieses Konzept erwartet, dass auf den Konzepten des TPM basiert und durch Firmen wir Nokia, Samsung, Motorola, France Telecom oder Erics(in mi![ions of un;~s shipped) son getragen wird. Hierbei wird das TPM Konzept erweitert um sog. Engines, die jeweils Funktiona300jeweiligen Zustand attestieren k6nnen~ Hierbei wird zwischen den Besitzem lit~iten besitzen und ihren der Engines unterschieden, die entweder der Kontrolle durch den Netzbetreiber oder des Nutzers un250 terliegen~ In dieser Aufteilung spiegeln sich die Anforderungen der Netzbetreiber und deren Bedarf einer vertrauensw~rdigen Instanz in den Endgerfiten wieder. Beispielweise befindet sich schon heute die 200 GSM-Logik in einem dem Benutzer unzug~inglichen Chip und auch die Funktionalitgt der SIM-Karte entzieht sich der Benutzerkontrolle. 150 100

2.1 Privatsph ire, Identit it, Pseudonymit it 50

Der Schutz der Benutzeridentit~it ist von zentraler Bedeutung far die Anwendbarkeit und Annahme von TC und war ein Hauptkritikpunkt an dem Konzept. Da durch die Einfahrung der AIKs ein Konzept zur 0 ~0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 einzelnen 0 0 0 0 0 --~ Kommunizierung der Vertrauenswt~rdigkeit einer Instanz geschaffen wurde, die nicht an einen Benutzer direkt gebunden wurde, kann dieses Pseudonym als ein Ersatz far die Identitgt des BenutSource: IEC zers dienen. In verschiedenen Einsatzgebieten kann eine eins-zu-eins Beziehung zwischen dem Gergt Abbildung 1" TPM Module Forecast (IDC- Oct. 2005) und seinem Besitzer angenommen werden, wie es z.B. im mobilen Bereich (SIM Karte) der Fall ist. In 2010 k6nnen dann nahezu 100 Prozent der ausgelieferten Laptops und ca. 90 Prozent der ausgelieferten Desktop Systeme mit einem TPM Modul ausgestattet sein (Abbildung 2). Geht man von einer Erneuerungsrate von 10-20 Prozent pro Jahr far die PC-Ausstatmng im privaten Bereich in Unternehmen aus, k6nnte in fanf bis zehn Jahren mehr als 80 Prozent der PC-Client. . . . .und .. g Privacy CA Privacy CA Basis des Intemet mit TPM-Modulen ausgestattet sein. Desktop vs. Notebook /

~.

~

[] Desktop [] Notebooks 160 rc

.2 .=_

140 120

c 100 (1} G}

.c

e,_ BJ

m

80 60

40

Generate AIKN+I ..... AIK2N

20 0 2002

Abb. AIKs 2003 3: Pseudonymer 2004 2005 Service-Zugriff 2006 2007 durch 2008

2009

2010

Jahr

Abbildung 3 pr~isentiert einen relativ einfachen Ansatz die Identitgt eines Benutzers in einem ZugriffsAbbildung 2: TPM Module in Desktops vs. Notebooks (Roger L. Kay, Endpoint Technologies Associates) szenario auf einen Dienst zu scht~tzen. Es verwendet die PCA aus dem Attestierungskontext in einer leicht abgewandelten Art. Hier wird die PCA in einer Doppelrolle verwendet, in der sie neben der Pseudonymitgt far die Benutzer auch als pseudonymen Servicezugang gewfihrt und dadurch Eigenschaften

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

193

eines Identity Providers annimmt. Eine Zusammenarbeit zwischen PCA und Serviceanbieter ist denkbar, in der der Anbieter die PCA bittet spezielle Zertifikate auszugeben, mit deren Hilfe der Service verwendet werden kann. Ein mobiles Gergt fahrt eine Attestierung mit Hilfe eines solchen Zertifikates aus und qualifiziert dadurch far den Zugriff auf den Service. Ein zentrales Element dieses Konzeptes ist, dass die Akkumulation von Benutzerdaten auf Seiten des Dienstleisters vorgebeugt wird, da ein AIK in beliebiger Frequenz ausgetauscht werden kann und auch aufVorrat ausgestellt. Hierdurch wird die AIK/Zertifikates-Kombination einer einweg PIN/TAN-Kombination ~ihnlich. Wenn alle bis auf ein AIK aufgebraucht sind erzeugt der TPM neue und l~isst sich diese vonder PCA neu Zertifizieren mit der Hilfe des letzten AIKs~ Da die durch den bisher vorgestellten Attestierungsprozess gebotene Pseudonymit~it nicht in allen F~illen ausreichend ist, hat die TCG die Direct Anonymous Attestation (DAA) [BrCaCh04, Ca04] in den Standard aufgenommen, die auf Zero Knowledge Proofs [Ch85] beruht und mit dem Zfiricher Idemix System [CaVa02] verwand ist. Bisher ist DAA noch nicht im praktischen Einsatz, da die Anforderungen an die Hardware einer Implementierung noch entgegenstehen. Es ist anzumerken, dass der Einsatz von AIKs zur Authentisierung eigentlich einen Missbrauch dieser AIKs darstellt, da sie far das Signieren von PCR Werten eingefahrt wurden. Wie wir hier gezeigt haben sind sie aber auch far weitere Einsatzzwecke n~itzlicho In [HoSo06] wird er6rtert, wie eine AIK-basierte Authentisierung effizient implementiert werden kann. Auch existiert einiges an Forschung, besonders im Rahmen des vonder EU gefdrderten Projektes OpenTC [Sa06, OpenTC], dass eine Open Source Trusted Software und Systemplattform zum Ziel hat.

3 Mobile Anwendungen Zukfinftige Geschgftsmodelle m~ssen ein sich entwickelndes und mannigfaltiges mobiles ()kosystem unterstfitzen [TaSa06]. Aufgrund der Konvergenz der verschiedenen mobilen Technologien wie 3G, WLAN, Bluetooth und WiMax entsteht die Notwendigkeit einer neuen Infrastruktur, die diese Eigenschaften unterstfitzt. Wichtig hierbei ist, dass sie Szenarien unabh~ingig der zugrunde liegenden Netzwerke und Zugriffsmodelle unterst~tzto In diesem heterogenen und potentiell dezentralisierten Umfeld ist das zugrunde liegende Vertrauensmodell entscheidend far den Erfolg bekannter und neuer Gesch~tftsmodelleo In einem dezentralisierten Vertrauensmodell ist es m6glich einzelne Aufgaben von den zentralen Komponenten z.B. auf die Endger~ite zu verlagem. Hier sind Aufgaben wie der Aufbau von Vertrauensbeziehungen, Abrechnung und Gebfihrenerfassung~ Dies kann zu einer deutlichen Kostenreduktion auf Seiten der Infrastrukturanbieter fthhren. Durch die Integration yon bestimmten Funktionen in die mobilen Endgergte und einer Etablierung von Vertrauen in diese k6nnen verschiedene heute bereits bekannte Funktionalit~iten nachgebildet werden wie SIM-Lock, aber auf einem neuen Sicherheitslevel und mit erweiterten Funktionalit~iten. TC bietet neue Ans~itze far das Implementieren von Sicherheit und Vertrauen in Plattformen und zwischen diesen durch das Einfahren eines Hardwareankers, der die Sicherheitsfunktionalit~iten zur Verfagung stellt als eine Basis. Dies isoliert diese Funktionen vonder eigentlichen Plattform und deren Betriebssystem und erm6glicht so ein klares Design, was evaluierbar bezfiglich ihrer Sicherheitsaussagen ist. Die in diesem Abschnitt vorgestellten Anwendungsgebiete far TC im mobilen Bereich haben gemein, dass sie neuartige Gesch~iftsmodelle [LiWh02, KPMG06] far einen Mobilenetzbetreiber (MNO) erm6glichen. Es ist hierbei wichtig zu erw~ihnen, dass diese Konzepte TC anderes verwenden, als dies im Fall von digitalem Rechtemanagements (DRM) der Fall ist. DRM wird h~iufig als der Einzige Einsatzzweck

194

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit~iten

flu" TC angesehen. Weiter hin muss gesehen werden, dass diese Konzepte einen 6konomischen Wert an einen einzelnen TPM-Chip binden und diesen als Vertrauensanker verwenden. Wenn dieser Anker bricht, kann nur ein sehr begrenzter Schaden entstehen, dass dieser Schaden auf diesen TPM begrenzt ist. Im Kontext von DRM hingegen fahrt ein einzelner gebrochener TPM zu einem Weg, dass gescht~tzte digitale Gfiter von dem Schutz befreit werden kOnnen und massenhaft in Verbreitung gelangeno

3.1 Funktionale Restriktion In der Beziehung zwischen Netzbetreiber und Kunden ist die gebr~iuchlichste Methode der Kundenbindung durch den MNO das SIM-Lock, welches eine Bindung des Ger~ites an den Betreiber darstellt. Durch das Verwenden von TC kann eine feiner granulare funktionale Beschr~inkung der Funktionen des Ger~ites durchgefahrt werden. Je nach Gesch~iftsmodell k6nnen bestimmte Funktionen eines Ger~ites auf definierte Benutzergruppen beschr~inkt werden. Ger~itemanagement wird durch die Industrie als ein bedeutender Einsatzzweck far TC angesehen [NTT04]. Aus Sicht eines MNO ist es kosteneffizient eine einzige Produktlinie den Kunden anzubieten, die sich in ihrem Erscheinungsbild, also der Funktionalitfit, an den Kunden anpassen l~isst. Daher ist es m6glich diese Funktionalit~it im dynamischen Betrieb zu ~.ndem und sich damit an ver~inderte vertragliche Gegebenheiten anzupassen. Dies sollte ohne physischen Zugriff auf das Ger~it erfolgen. Ft~r den Benutzer ist es ein ergonomischer Vorteil, dass diese Prozesse weitgehend unbemerkt ablaufen und sich die Ger~ite so an ihn anpassen bzw. personalisiert werden. Das Verfahren basiert auf den Methoden von TC, da sichergestellt werden kann, dass ein Ger~it und somit dessen Besitzer zu einer bestimmten Gruppe geh6rt und dass das Ger~it lediglich die mit dieser Gruppe assoziierten Funktionen zulgsst. Dadurch ist der Schutz der Einstellungen st~irker als es durch SIM-Lock erreicht werden kann, da TC und dessen Hardwarebasis sehr widerstandf~hig gegen Ver~inderungen isto Basierend auf dieser Annahme kann ein Netzbetreiber Inhalte oder spezielle Dienste an diese Gergte und somit einer beschr~inken Gruppe liefem~ Diese funktionale Beschr~tnkung bildet eine solide Basis far Client-basierte Service-Diskriminierung, Regeln oder DRM. Credential tRest ertifizierter AIK

eines Credential CMNO z~

MNO

SIM/USIM

Abb. 4" Beschr~inkungauf eine Untergruppe durch TC Aus theoretischer Sicht [KuSch06] basiert die funktionale Beschr~inkung auf einem generellen Restriktionsprozess, der in jedem der hier vorgestellten Verfahren als Variante vorkommt. Wie in Abbildung 4 gezeigt, bedeutet Beschr~inken, dass eine Untergruppe definiert wird auf der Basis der Benutzer bzw. deren Gergte und der Zugriff aufbestimmte Funktionalit~iten beschr~inkt oder gew~ihrt wird. Im Fall der Kunden eines Netzbetreibers wird eine Untergruppe dieser Kunden gebildet, die durch die Kombination von Geheimnissen m6glich gemacht wirdo Jedes Ger~it einer gr613eren Dom~ine verwendet ein generi-

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit~iten

195

sches Credential cMNO, dass normalerweise die Identit~it des Gergtes fftr den prim~iren Netzzugang trggt. Die Zuordnung zu der entsprechenden Untergruppe wird durch die l]bertragung eines weiteren Credentials tRest durchgefiihrt, welches auf einem durch eine PCA signierten AIK beruhen kann. Diese kann durch den MNO betrieben werden. In diesem Fall wird eine Attestierung zwischen dem Gergt und dem Netzbetreiber durchgeffihrt fiber dessen Netzwerk. Alternativ kann vertrauenswfirdige Software auf dem Ger~it eigene spezielle Geheimnisse verwahren und dem Netzbetreiber vorweisen. Diese muss in geeigneter Weise, z.B. durch den Bootprozess, in ihrer Integrit~it geschfitzt werden. Von den Aussagen, die durch TC zur Verffigung gestellt werden ben6tigt die Restriktion (1) die Pr~isenz eines aktiven und unver~inderten TPMs und (2) eine Aussage fiber die Integritgt der Plattform inkl. der Software auf dieser. Diese Eigenschaften werden durch die Attestierung getestet. Durch die erh6hte Vertrauenswfirdigkeit der Elemente in einer Untergruppe, k6nnen diesen Kunden h6herwertige Dienste und Angebote zur Verffigung gestellt werden. Dies entspricht dem klassischen DRM Szenario. Es wird in verschiedenen Fgllen der Fall sein, dass tRest ein h6heres Schutzniveau bietet als cMNO. Daher bietet es sich aus der Sicherheitsperspektive an, dieses auch in der Authentisierung des Gergtes zu verwenden~ Dies ist nicht in alles F~illen m6glich, wenn zum Beispiel der Kommunikationskanal erst durch cMNO erm6glicht wird. Da der Netzbetreiber (in Zusammenarbeit mit der PCA) die Zugeh6rigkeit von cMNO zu tRest fiberprfifen kann, macht die Untergruppe weniger anf'~illig gegen Duplizierungsangriffe des generischen Geheimnisses. Diese Form der Angriffe ist im mobilen Umfeld nicht unbekannt [Ch05]. Eine geeignete Wahl der Methode, wie das Geheimnis in Umlauf gebracht wird ist essentiell fttr die Vertrauensw~rdigkeit des zus~itzlichen Geheimnisses. Wenn beide Geheimnisse unabh~ingig voneinander auf das Gergt gebracht werden, wird die Widerstandskraft gegen Duplizierungsangriffe reduziert, da der Netzbetreiber in diesem Fall die Zugeh6rigkeit der Geheimnisse zu einem einzelnen Kunden nicht fberprfifen kann. In diesem Fall kann lediglich verhindert werden, dass zwei identische cMNO zeitgleich Zugriff erhalten. Eine zentrale Autorit~it die die Ausgabe kontrolliert, kann dieses Problem umgehen. Die Anonymit~it der Kunden ist konzeptuell limitiert, da die Kommunikation und Authentisierung unter Kontrolle des Netzbetreibers liegt. Es kann aber eine Pseudonymit~it im Dienstezugang erreicht werden, da der MNO lediglich feststellt, dass eine Transaktion durchgefahrt wird, nicht aber, was in dem speziellen Dienst durchgefiihrt wurde. Eine Kombination der funktionalen Beschrgnkung mit mobilen Anwendungen bietet sich an. Dies erm6glicht z.B. ortsabh~ingige Einsatzzwecke mit einer hohen Anforderung an Sicherheit. Vertrauenswfrdige Endgergte k6nnen bestimmte Funktionen aufgrund der Position, z~ der Sendemasten, e i n - oder ausschalten.

3.1.1 Vorabbezahltes mobiles Telefon Ein mobiles Endgergt mit einem integrierten Guthaben kann auf der hier diskutierten Basis implementiert werden. Das Gergt besitzt einen geschfitzten Speicher, in dem das Guthaben gespeichert ist und dort dekrementiert wird durch eine vertrauensw~rdige Software. Der Verbindungsaufbau wird weiterhin durch die SIM-Karte aufgebaut, danach folgt eine Attestierung, die auch das Guthaben prfift. Auf dieser Basis wird der Netzzugang gewghrt. Hierdurch muss der Netzbetreiber keine Abrechnungsinfrastruktur betreiben, da diese Aufgabe an die Endger~ite delegiert ist. Auch kann der Kunde hier anonym gegenfiber dem Netzbetreiber bleiben. Eine Aufl6sung der Identitgt kann durch eine unabh~ingige PCA sichergestellt werden, so dass der EU-weiten Gesetzeslage Rechnung getragen werden kann~

196

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit/~ten

3.2 Maschine-zu-Maschine Kommunikation Eine vertrauenswfirdige Plattform kann in der Maschine-zu-Maschine Kommunikation (M2M) Nachrichten weiterleiten. Der Netzbetreiber kann dies als Dienstleistung Dritten anbieten und dadurch andere Systeme zu ~berwachen und zu warten wie z.B. Heizungen oder Klimaanlagen, Wasserversorgung oder Verbrauchdaten von Ger/~ten erfasseno Der Verbrauch von Strom, Wasser oder anderen Gfitem kann dezentral beim Verbraucher erfasst und automatisch an eine zentrale gemeldet werden. Dies gilt auch far Beleuchtung, Alarmanlagen, Kamerat~ber-wachung, Reservierung von R~iumen, 12rberwachung von R/~umen usw. Aus dieser Liste wird deutlich, dass es viele Einsatzm6glichkeiten far eine gescht~tzte M2M Kommunikation gibt, die sich in Geb~iudemanagementsystemen einsetzten lasseno

Maschinenbezogene Dienstleister

MNO

Dienstleister, z.B. Abrechnung

1

Maschine

Mobiles Endger&t Abb. 5: Generisches M2M Szenario

In Abbildung 5 wird dieses Konzept vorgestellt, in dem das mobile Ger/~t als Brfickenkopf far die Kommunikation zwischen einer Maschine und dem Netzbetreiber dient. Hierbei kann die Maschine auf die Authentisierungs-, Authorisierungs- und Audit-Infrastruktur (AAA) des Netzbetreibers zurfickgreifen, ohne ein eigenes Kommunikationsmodul hierfar besitzen zu mfissen, was Kosten im Ger~it reduziert. Dort reicht ein preiswertes Kommunikationsmodul wie Bluetooth oder IRDA. TC bietet beidseitige Authentisierung und Datenschutz. Die Authentisierung des mobilen Ger~ites erfolgt fiber die bekannte SIM-Karte, hingegen die Authentisierung zwischen mobilem Ger/~t und der Maschine erfolgt auf der Basis der im TPM enthaltenen Geheimnisse. Diese werden verwendet den Benutzer gegent~ber der Abrechnungsstelle zu authentisieren und zu autorisieren. Der Netzbetreiber bietet in diesem Szenario seinen Kunden wie auch den Maschinenbesitzem Dienste und kann zugleich seine Kundenbasis gewinnbringend einsetzen. Durch diese Aufteilung der Zust/indigkeiten [BoE101, NaPo90] zwischen Netzbetreiber und Abrechnungsstelle kann ein guter Schutz der Nutzerdaten realisiert werden.

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

197

Eine spezielle Variante hierbei sind ,,point of sales"(POS)-Szenarien, in denen eine Akzeptanzstelle im Auftrag einer Abrechnungsstelle far beispielsweise ein Gesch/~ft Transaktionen abwickelt~ Hier kann das in Abbildung 3 vorgestellte Konzept eingesetzt werden.

3.2.1 PhysischeZugangskontrolle und Geb~iudemanagement Als das komplexeste Szenario wird hier die physische Zugangskontrolle auf der Basis von normaIen TC-erweiterten mobilen Ger/~ten, wie z.B. ein Handy, betrachteto Dies kann zu einem vollwertigen Geb~iudemanagement ausgeweitet werden, das auf der Infrastrukmr eines Netzbetreibers basiert und grol3e Einsparungseffekte verspricht. Seine Attraktivit~it liegt hierbei dabei, dass der Installationsprozess wesentlich effizienter durchgefthhrt werden kann, als dies bei traditionellen Systemen der Fall ist. Beispielweise sind die Komponenten sofort ein-satzbereit und ben6tigen lediglich eine Steckdose. Dieses Szenario 1/~sstsich sofort mit den bereits vorgestellten Methoden der funktionalen Restriktion kombinieren.

4 Schritte hin zu T C - b a s i e r t e n Identit~iten Die TCG spezifiziert einen TPM als ein ger~itegebundenes Authentifikationsmerkmal. Somit besteht prim~ir erst nut ein Vertrauen in das Endger~it, mit dem es der Diensteanbieter zu tun hat. Wenn aber zus~itzlich eine Bindung zwischen Ger/~t und Benutzer besteht, wie es im mobilen Bereich t~blicherweise angenommen wird, so entsteht eine neue Einheit, die hier als Trusted Agent (TA) bezeichnet wird. Der TA ist eine konzeptionelle Basis far ein Nutzerbezogenes Identit/itsmanagement. Dieser Abschnitt beschreibt erste Schritte hin zx~ einer Infrastrukmr, die dieses Konzept mit Leben fallen kann.

4.1 Ein TC-basiertes Ticket-System Wie bereits erw/~hnt, sind einige Konzepte von TC Methoden des Identity Management verwandt. Sie benutzten in diesem Abschnitt diese Analogie um einen der Ecksteine eines IDM-Systems mit TCTechnologie darzustellen, n/~mlich so genannte Ticket-Systeme, wie sie zum Beispiel in dem weit verbreiteten IDM-System Kerberos Verwendung finden. Grundlegende Idee ist hierbei der ,,Missbrauch" von PCA-zertifizieren AIKs als Tickets. Diese k6nnen dann zum Beispiel far den Zugriff auf beliebige Dienste benutzt, oder in ein existierendes IDM-System eingebunden werden~ Aus Sicherheitsgrfinden beschr/~nkt der TPM die Benutzung von AIKs. Es ist daher nicht direkt m6glich, AIKs zum signieren beliebiger Daten und insbesondere zur Herstellung von Tickets zu verwenden. Man kann dies durch eine Indirektion umgehen, indem man einen vom TPM erzeugten Signaturschlfissel wiederum mit einem AIK signiert- ihn in der Sprechweise der TCG zertifiziert. Die Schlt~sselerzeugung wird durch das Kommando TPN_CMK_Certi f y K e y angeregt, dass ein asymmetrisches Schlftsselpaar zurfick liebt, dessen privater Schl%sel vom TPM zur ausschlieglichen Benutzung durch ihn selbst verschlt~sselt iSto Das Schlfisselpaar wird mit TPM_LoadKey in den TPM geladen, und anschliegend mit T P N _ C e r t i f y K e y zertifiziert. Durch diesen Vorgang trifft der TPM die Sicherheitsaussage ,,dieser (private) Schlfissel wird an einer durch diesen eindeutig bestimmten TPM gesch~tzten Stelle verwahrt und niemals herausgegeben". Um diese Aussage vertrauen zu schenken, muss man natftrlich sowohl den Sicherheitspolitiken des TPM-Herstellers, als auch denen der PCA vertrauen. Damit haben wir ein Signaturschlt~ssel-Paar, das an einen bestimmten AIK gebunden ist und somit verwendet werden kann, insbesondere die Nutzdaten eines Tickets zu signieren, das dann an einen Dienst gesendet und dort akzeptiert werden kann. Wir nennen diese Schl(isseI paar certified signing key (CSK), in Anlehnung an die Sprachregelung der TCG. CSK, AIK und zugeh6riges Zertifikat einer PCA sind die Zutaten um ein einzelnes Ticket herzustellen.

198

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit~iten

Bevor ein TA ein Ticket benutzen kann, muss er es zun~ichst vonder PCA, die wir hier als herausgebende Stelle betrachten, erwerben. Ein Ticket kann dann bei jeder annehmenden Stelle (RS far Receiving System) eingel6st werden. In beiden Prozessen kann ein Charging Provider (CP) als dritte Partei auftreten. Hervorzuheben ist hier die Rolle der PCA hinsichtlich des Datenschutzes durch Pseudonymit~tt. Es ist insbesondere m6glich die von der PCA fin"AIKs herausgegebenen Zertifikate auf Gruppen zu beziehen, das heil3t sie identifizieren keinen einzelnen AIK beziehungsweise das zugeh6rige Ticket, sondem eine bestimmte Preis- oder Wertigkeitsgruppe g aus einer vorgegebenen Menge. In einem solchen Schema erhalten viele TAs die gleichen Zertifikate und nur die PCA ist in der Lage, individuelle Identit~iten aufzul6sen. Damit wird eine datenschutzfreundliche Wertfestsetzung und Preisdiskriminierung ft~ Tickets mOglich. Ffir die praktische Herstellung von Gruppenzertifikaten stehen der PCA mehrere bew~ihrte Methoden, vonder simplen Benutzung des gleichen Schlfisselspaares far die ganze Gruppe bis hin zu ausgeklt~gelten Gruppensignatur-Schemata [ChvH91 ] zur Verffigung. Der Einfachheit halber verzichten im Folgenden auf die Unterscheidung zwischen privatem und 6ffentlichem Schl%sel eines Zertifikats und bezeichnen mit Cert(Enitiit, Zertifkat) die Vereinigung von 6ffentlichem Zertifikatsschlfissel mit der mit dem zugeh6rigen privaten Schlfissel signierten Entit~ito Den Berechtigungsnachweis Cert 0 zu pliifen heil3t dann diese digitale Signatur zm verifizieren.

~

TA

~

PCA

AIKgenerierenrail TPM_Makeldentity

TA

'~AIK, zus~tzl.Daten,Identifikationg - - . ~

RS

CSK erzeugen,

Cert(CSK,AIK), Cert(P,CSK)

Autorisierung

P,Cert(P,CSK),Cert(CSK,AIK),Cert(AIK,g)--------I~

I

~

~ N ~ Verifikation,

! AIKZertifikats-

F

erzeugung

i ~

TPM_Activateldentity

~

ACK

I

Autorisierung

Abrechnung

~"" ~ OberPCA

/

Abb. 6: Ticketerwerb und Einl6sung. Der Erwerb eines Tickets verl~iuft nun wie in der linken Grafik in Abbildung 6 gezeigt. TA erzeugt zun~ichst einen AIK mithilfe des T P M _ M a k e I d e n t i t y Kommandos, far das er dann ein Zertifikat von PCA aus Gruppe g anfordert, wobei weitere Daten ftbermittelt werden, wie es die TCG-Spezifikationen fordem. Die PCA kennt nun die Identit~it des TA, was far Abrechnungszwecke, z. B~ fiber CP, benutzt werden kann. An dieser Stelle kann PCA auch eine Autorisierungsentscheidung fNlen um etwa Teilnehmer auszuschliegen, die unangenehm aufgefallen sind. PCA ftthrt dann einen Handshake aus, um sich zu versichem dass dieser AIK tatsfichlich von ein und demselben TA stammt. Daraufhin wird Cert(AIK, g) erzeugt und an TA fibersandt, wo das Kommando TPM_ACti v a t e I d e n t i t y ausgefahrt wird um diesen AIK sp~tter verwenden zu k6nnen. Die Einl6sung eines Tickets ist dann sehr einfach, wie auf der rechten Seite von Abbildung 1 gezeigt. TA stellt zun~ichst einen CSK her, das heil3t ein Schlfisselpaar CSK und ein Zertifikat Cert(CSK, AIK) gemN3 oben beschriebenem Prozess. Er signiert dann mit CSK einen Satz Nutzdaten P, die zum Beispiel eine Anfrage nach einem bestimmten Dienst enthalten. Die Kette von zertifizierten Daten Cert(P, CSK), Cert(CSK, AIK), Cert(AIK, g) wird dann an RS t~bertragen. Auch RS kann an dieser Stelle noch eine Autorisierungsentscheidung treffen, um zoB. Mehrfachverwendung auszuschlief3en. Schliel31ich bestS-

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

199

tigt RS den Eingang des Tickets und leitet optional eine weitere (nachgelagerte) Abrechnungsoperation fiber PC A ein. .

t

IN

I Dienst ~

.....

Oetd

.....

.....

~\ ,b i ~'e

[ Dlenst

Ge~d

%

:I

~"Oien

.

.,{

/

.~'

9

,,~.~,~.~

~

-

Abb. 7: Anwendungsneutrale Architektur Die Einbettung TC-basierter Tickets in Anwendungssysteme und Gesch~iftsabl~iufe ist in vielen Varianten m6glich. Obige Abbildung 7 zeigt ein einfaches Beispiel. Darin er wird ein Nutzer ein Ticket eines bestimmten Werts von PCA. Dieses Ticket geh6rt zu einer bestimmten Gruppe, was zum Beispiel die Aussage beinhalten kann, dass es nur bei einer bestimmten Gmppe von Diensten eingel6st werden kann. Zudem kann damit ein bestimmter Wert ausgedrfickt werden, sei er monetgr oder immateriell, wie etwa im Rahmen eines Rabattsystems. TA bezahlt for das Ticket bei CP bei der Einl6sung und/oder dem Erwerb, und CP verteilt Erl6santeile zwischen sich selbst, PCA und RS gem~ig Leistungsvertr~igen. RS wiederum vergfitet den Diensteanbieter. Die hiermit realisierte Zugangskontrolle zu mehreren Diensten durch PCA und RS hat drei entscheidende Vorteile: 1. Nichtabstreitbarkeit durch die Kette von Zertifikaten; 2. Zurechenbarkeit, da die Identit~it eines TA durch PCA aufgelSst werden kann; 3. Pseudonymit~it durch Aufgabenteilung (separation of duties [BoE101 ]). PCA und RS zusammen spielen in diesem System eine zentrale Rolle far die Kontrolle der Identitgten die in den pseudonymen Tickets verk6rpert sind. Diese Rolle ist in der Tat eine Verk6rpemng der Rolle eines Identity Providers in ticketbasierten IDM-Systemen. Die Aufgabenteilung zwischen PCA und CP erlaubt ist dem Benutzer im Prinzip sogar anonym zu bleiben, da dieser erst bei der Abrechnung identifiziert werden muss (durch Kreditkartennummer oder sonst wie). Anonymit~it wird jedoch nicht immer erwtinscht sein, da damit die Zurechenbarkeit von gescMftlichen Aktionen zu Benutzem verloren geht. W~ihrend RS durch vertragliche Vereinbarungen in der Lage sein kann, Nutzeridentit~iten von PCA zu erhalten, z.B. bei Betrugsverdacht, k6nnen Datenschutzvorschriften CP durchaus daran hindem Identit~iten preiszugeben. Eine weitere wichtige Rolle die PCA spielt, ist das Anstogen der Abrechnung. Hier bietet sich eine Aufteilung der ErlOse zwischen PCA, RS und CP far die Abrechnungsdienste an. In ihrem Einflussbereich

200

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit~iten

m~ssen RS und PCA Politiken far die Zugangskontrolle far Ticketerwerb und Einl6sung aushandeln und implementieren, um z. B. Mehrfachverwendung auszuschliegen, oder Nutzer auszuschliegen, die sich ein Fehlverhalten zu Schulden kommen lassen. Weiterhin lgsst sich in Zusammenarbeit zwischen PCA und RS praktisch jede beliebige Preisfestsetzung realisieren. Es ist bemerkenswert das in dem vorgestellten Konzept nur PCA die Abrechnung einleiten kann da nur er die Identit~it eines TA erkennen und einen Nutzeridentit~it zuordnen kann. Ffir diese besondere St~irke des Pseudonyms ist es wesentlich dass unser Konzept ausschlieglich auf einer origin~iren TPM-Funktionalit~it beruht und insbesondere keine weitere Software im TA benutzt. W~ire eine solche Software vorhanden die Tickets in irgendeiner Weise verwaltet, so mt~sste ihre Vertrauenswt~rdigkeit in einem Remote Attestation Prozesses nachgewiesen werden, sowohl bei Ticketerwerb wie bei Einl6sung. Die entsprechenden geht die Protokolle fibertragen die zur Boot-Zeit erstellten Messprotokolle an die t~berprfifende Partei. Diese Daten k6nnen a b e r - und dies ist ein grunds~itzliches Problem der Remote Attestation- benutzt werden um eine Trusted Platform zu identifizieren wenn, wie im PC-Bereich, die Zahl der m6glichen Systemzust~inde sehr grog ist und vonder Gr6genordnung her der Nutzerzahl des Tickets Systems gleichkommt. Remote Attestation zu vermeiden ist unter diesem Gesichtspunkt, wie auch unter dem der Ressourcenschonung, gfinstiger. Dass bei dieser L6sung kein Vertrauen bezaglich der Verwaltung der Tickets in den TA gelegt werden kann, ist der Grund warum ein Schutz gegen Mehrfachverwendung und eine Nutzungsautorisierung durch RS bei Ticketeinl6sung realisiert werden mfisseno

4.2 Preisfestsetzung in Reputationssystemen Diese Anwendung des Tickets Systems wurde in [KuSc06] vorgestellt. Elektronische Marktpl~itze sowohl ffir physische wie far Informationsg~ter werden zunehmend von sich selbst organisierenden Angebots- und Bedarfsgemeinschaften eingenommen. Es zeigen sich bier die Charakteristika der so genannten ,,Long Tail Economy", die die klassische Asymmetrie zwischen Anbietern und Konsumenten teilweise aufheben. K~ufer und Verk~iufer stehen sich in nahezu gleicher Anzahl gegenfiber und wechseln ihre Rollen dynamisch. Virtuelle und physische Grater werden in groger Anzahl und Vielfalt angeboten, bei vergleichsweise geringem Bedarf far jedes einzelne. Kontaktaufnahme und Orientierung sind in diesem Umfeld schwierig, langfristige Gesch~iftsbeziehungen schwierig aufzubauen und Vertrauen zwischen Geschfiftspartnern schwer herzustellen [Bakos98]. Ein inzwischen weit verbreiteter Ansatz ist es, die Marktteilnehmer selbst die notwendigen Informationen beitragen zu lassen. Dies ist h~iufig in so genannten Reputationssystemen verk6rpert bei denen K~iufer und Verk~iufer sich und ihre Gfiter gegenseitig beurteilen. Eher zentralistische Varianten sind Empfehlungssysteme, das heigt Programme, die versuchen vorherzusehen welche Gfiter einen Konsumenten interessieren k6nnten, ausgehend von vorliegenden Informationen fiber sein jeweiliges Konsumprofil~ Reputationssysteme versuchen gem~,ig Paul Resnick et al~ [RKZF00, Axe184] ,,den drohenden Schatten der Zukunft aufzubauen, das heigt die Erwammg zukfinftiger Wechselwirkungen und m6glicher Vergeltung far jede einzelne Transaktion, durch die Erwartung, dass andere sp~iter darauf zurfickschauen werden [121bers. D. Autors]". Ziel ist es einen homogenen Markt fttr alle ehrlichen Teilnehmer zu schaffen. Das gemeinschaftliche Bewertungen K~iuferverhalten tats~ichlich stark bestimmen k6nnen, wurde in experimentellen Studien [SaDW06] gezeigt. Bestehende Reputationssysteme k6nnen aber relativ leicht sogar im Rahmen ihrer eigenen Regeln angegriffen werden. Obwohl dies keine Angriffe im Sinne der klassischen Informationssicherheit sind, gef'~ihrden sie doch die Information alle Integritgt und Zweckerfallung dieser Systeme. Dellarocas beschreibt in [Dell00] drei Arten unfairen Verhaltens: 1. Ballot Stuffing. Ein Verk~iufer wird mit einer Gruppe von K~iufern zusammen um unfair viele gt~nstige Bewertung zu erhalten. 2. Bad-Mouthing

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

201

(l)ble Nachrede) einige Kgufer und Verkgufer konspirieren, um andere Verk~iufer unfair niedrig zu bewerten und aus dem Markt zu treiben. 3. Negative Diskriminierung. Verk~iufer reservieren Waren und Dienstleistungen guter Qualit~it fttr eine kleine, beschr~inkte Gruppe von Kgufern. 4. Positive Diskrirninierung. Verk~iufer beliefern bestimmte Kgufer mit besonders guter Qualit~it um selbst wiederum besonders gute Bewertungen zu erhalteno Von verschiedenen Autoren ist es als wesentlich erkannt worden, eine Situation kontrollierter Anonymit~it zu schaffen, um unfaires Verhalten zu unterdracken. In einer solchen Situation kennt der Marktplatz die Identit~it aller Teilnehmer und verfolgt alle Transaktionen und Bewertungen, verbirgt jedoch die Identitgt von Verk~iufern und K~ufern voreinander. Anonymit~it ist zum Beispiel ein wirksames Mittel gegen Bad-Mouthing, hilft jedoch nicht gegen Ballot-Stuffing, der Verk~iufer ihren Mitverschw6rern immer noch verborgene Hinweise auf ihre Identit~it geben k6nnen. Mit Anonymit~it h~ingt auch der wichtigste individuelle Angriff gegen Reputationssysteme zusammen, der so genannte ,,Sibyllinische" Angriff mit Scheinidentit~tten, der es einzelnen erlaubt fiberproportionalen Einfluss zu gewinnen [Douc02]o Friedman und Resnick weisen in [FrRe01 ] auf das grundsgtzliche Problem der Billigkeit von Pseudonymen hin, damit einer einfachen Namensg.nderung unehrliche Teilnehmer die verdiente schlechte Reputation leicht abschfitteln kOnnen, wie theoretisch in [Dell04] untermauert wurde. In [BhGo05] wurde sogar ein expliziter Grenzwert far Transaktionskosten in Reputationssystem angegeben um Ballot Stuffing zu unterdrficken. Eine unvorsichtige Auspreisung der Abgabe von Bewermngen wfirde jedoch eine unerwfinschte Eingangshalle aufbauen. Es gibt inzwischen einige Vorschl~ge, bestimmte Angriffe auf Reputationssysteme abzuwehren [ChFr05], oder far allgemeine Architekturen, die Zurechenbarkeit und Datenschutz in solchen Systemen zu vereinbaren versuchen [BuHu99, ZiFL06]. Daher scheint es vielversprechend, Reputationssystem auf Pseudonymen aufzubauen, die eine flexible Preisfestsetzung erlauben. Die Aufgabenteilung zwischen PCA und RS in unserem Ticket System ermOglicht hierbei genau die kontrollierte Anonymit~it, die far Reputationssysteme so wfmschenswert ist, durch die og. Eigenschaften 1.-3. Das generische Ticketsystem kann auf einfache Weise in einem Reputationssystem verwendet werden. Will der Benutzer eines TA einen anderen Nutzer bewerten, so kauft er ein Bewertungs-Ticket von PCA. In diesem speziellen Kontext kann die Gruppenzugeh6rigkeit des Tickets eine Wertigkeit ausdrficken, z.B. einen Gewichtsfaktor, der vom System bei der Mittelung tiber viele Bewertungen eines Nutzers verwendet wird. Augerdem k6nnen durch Gruppen mehrere verschiedene Reputationssysteme angesprochen werden. Der Nutzer formuliert sodann seine Bewertung und reicht sie mit seinem Ticket als Nutzdaten beim RS, das wir nun mit dem Reputationssystem identifizieren, ein. Daraufhin wird eine Abrechnung eingeleitet. Resultat ist eine Bewertung, die authentisch, zurechenbar und pseudonym abgegeben wurde. Damit kOnnen St6rungen des Systems zu ihren Verursachern zurfickverfolgt werden. Die Auspreisung von Bewertungs-Tickets kann an die Bedttrfnisse des Reputationssystems flexibel angepasst werden. Das Spektrum reicht von kostenlosen Tickets, die nur Zurechenbarkeit gew~thrleisten, bis hin zu ansteigenden Preisen far Bewertungen etwa gemN3 der Frequenz mit dem sie von einem einzelnen Teilnehmer eingereicht werden. Sogar eine Vergfttung, im Sinne von Anreizzahlungen, far das Einreichen von Bewertungen (etwa von besonders guter Qualit~it) ist m6glich.

4.3 Schutz von Inhalten in Push-Diensten Informationsarbeiter mit ,,nomadischer" T~itigkeit h~ingen in hohem Mage von Infrastrukturen far den schnellen und unkomplizierten Datenzugriff ab. E-mail Push-Dienste wie RIMs Blackberry erobern diesen Markt mit grol3em Erfolg und zeichnen sich durch hohe Verfagbarkeit und einfachste Bedienung aus. Push-Dienste sind charakterisiert durch die Fghigkeit, Nutzer t~ber die Ankunft neuer Daten selbst~indig in Kenntnis zu setzen. Bei E-mail Push-Diensten geht dies oft mit der Auslieferung der mail

202

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

einher. Grundlegende Methoden far diese Vorg~inge werden zum Beispiel in den Standards der Open Mobile Alliance, OMA, siehe [OMA06] beschrieben. Einige Anbieter haben Push-Dienste erweitert um zum Beispiel Zugriff auf Firmen-Datenbanken gew~ihren zu k6nnen und damit komplexere Arbeitsabl~iufe far mobile Arbeiter zu erm6glichen. Aufgrund des hohen Wertes der in diesen Netzen ausgetauschten Daten sind sie durch professionelle Angreifer gef'~ihrdet. Daher ist ein spezieller Schutz dieser Systeme notwendig. Die einschl~igigen Sicherheitsprobleme k6nnen in zwei Hauptbereiche unterteilt werden. Zum einen mfissen die Daten auf dem Weg zum Endger~it, also im Transfer, geschfitzt werden, um Vertraulichkeit zu wahren Zum anderen mfissen die Daten nach dem Transfer auf dem Endger~it gegen unerlaubten Zugriff gescht~tzt werden. Dies ist von praktischer Bedeutung bei den erw~thnten E-Mail-Push Diensten, da hier die fibertragenen E-Mails auf dem Endger~it gespeichert werden. Gleiches gilt aber auch far andere Datendienste wie SMS oder gew6hnliche E-Mail-Systeme. Gegenw~irtige Ans~itze verwenden Software-Token, wie PKCS#7 Container, die die Geheimnisse zum Schutz der Kommunikation und Verwahrung speichern. Softwarel6sungen sind aber generell durch einen Angriff auf die Geheimnisse w~ihrend der Verwendung gef'~ihrdet. Hier kann ein Angreifer Schlfissel gewinnen, da der Schl%sel zur Verwendung im Arbeitsspeicher des Ger~ites ungeschfttzt vorliegt. SmartCards sind ein Ansatz dieses Problem zu 16sen. Zur Zeit hat sich jedoch noch kein Standard fl~ichendeckend durchgesetzt.

Netzbetreiber

Push-Server

Internet

Date

U ntemehmensFirewall

....

{~

~

-~- - ~

~:

Network Operation Center (aoc) tnhalts.-Server

Abb. 8: Zentralisierte Push-Architektur Abbildung 8 veranschaulicht die weit verbreitete zentralistische Push-Architektur mit dem Network Operation Center (NOC) in der Mitte, das alle Kommunikationsaufgaben mit den mobilen Endger~iten t~bernimmt. Die far die Endger~ite bestimmten Daten sind zun~ichst in Quellen wie Mail-Servern gespeichert, die zun~ichst den Push-Server kontaktieren ihm die Daten liefern. Dieser wiederum kontaktiert den NOC um entweder eine eigene Verbindung zum Zielger~it herzustellen und die Daten auszuliefern, oder der Push-Server liefert die Daten an das NOC, wo sie zwischengespeichert und schliel3Iich ausgeliefert werden. Diese Architektur ist far Unternehmen attraktiv, da sie nur geringen Aufwand erfordert, z.B. fill" eine spezielle Firewall-Konfiguration. Der dezentralisierte Gegenentwurf l~iuft fiber direkte Kommunikation zwischen Push-Server und Endgergt, was einen Netzwerkzugriff von Servern hinter einer Firmen-Firewall und somit speziellen Schutz der Firmen-Infrastruktur erfordert.

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

203

Nimmt man in solchen Architekturen auch noch einen ,,b6sartigen" Diensteanbieter an, so kommen Datenschutz-Aspekte zur Transportsicherheit hinzu. Das NOC kann potenziell jede Nachricht an ein Endger~tt abfangen, was neben dem Bruch der Vertraulichkeit ftir einzelne Nachrichten auch noch die Gefahr birgt, dass Kommunikationsprofile gebildet werden k/Snnen. In einem Sicherheitskonzept milssen beide Aspekte betrachtet werden um Ende-zu-Ende Sicherheit zu gewghrleisten, die alle sensiblen Daten vor unerlaubtem Zugriff schitzt. Das einfache TC-basierte Sicherungskonzept, dass nun vorgestellt wird, entstammt im Kern [KuSc07]. I ) Datenquell6 ~bermittelt neue Daten zum Syncs . I,

~! ii

I D~'~n

1

I

L,

;,,

Pc

~er~t

I) BindingKeyerzeugen:

II & an PCA senden

2) A~bau eines sicheren Kanals

--

3) Remote Attestation des _. Endger~tes 4) Schl0sselaust~usch IOr Verschl0sselung 5) 0bertragung ats v e ~ t ~ s ~ l t e r Daten-Blob 6) Bes~tigung erfolgreicher -0bertragung

!~0n~- !

~'er

2) Remote Atlestation i des EndgerQtes L

Binding i des Erzeugung

4) Registrierung des Binding Key 5} Datenquelle 0bernlittelt neue Daten zum SyncS

i

6) 0bert~acjung al~ verschl0ssetter Daten~Blob 7) Best~tigung erfotgreicher 0bertragung

] Benutzung ~.des Binding J Key

Abb. 9: Schutzszenarien mittels Blob-Binding (links) bzw. Schltissel-Bindung (rechts) Der Schutz von Inhalten, insbesondere beim Transfer, ist einer der durch die TCG selbst angegebenen Hauptanwendungszwecke von TC, siehe [TCG05]. Die Verwendung zaar Sicherung von Datenzugriffen im Sinne eines ,,Licence Enforcement" wurde in [KiKu06] beschriebeno Schon einige Jahre zuvor haben Graeme Proudler und Siani Pearson einen TC-basierten Mechanismus zum Schutz gespeicherter Daten vorgestellt [PePr01 ]. Die einfachste M6glichkeit, den Schutz zu ftbertragender Daten mit TC umzqasetzen, ist in der linken H~ilfte von Abbildung 9 dargestellt und beruht auf der in Abschnitt 2 eingeffihrten Methode des Blob Binding. Die Datenquelle kontaktiert den Synchronisationsserver SyncS, der das Endgergt lokalisiert, einen Kanal aufbaut und die Datensynchronisation steuert, wozu beispielsweise das diesbezt~gliche OMA-Protokoll verwendet werden kanno Der Kanal kann hier noch auf der Transportebene gesichert werden. Das Endger~it ffihrt nun eine Remote Attestation gegeniber SyncS aus, woraufhin Verschl(isselungs-Schlissel ausgetauscht werden. Das Ger~it erh~ilt nun die Daten als verschlisselten Blob, dernur in dem in der Attestierung bestimmten Ger~itezustand entschlfisselt werden kann. Die Schritte 2-4 erzeugen hier eine gewisse Latenz (insbesondere Remote Attestation fir jede einzelne Datensynchronsiation ist aufwendig), was die auf der rechten Seite von Abbildung 9 gezeigte Alternative sinnvoll erscheinen lgsst. Hier verschlisselt SyncS die Daten mit einem 6ffentlichen Schlissel, dessen privater Teil nutzungsbeschr~tnkt durch einen bestimmten PCR-Wert ist. Damit dem Schlisselpaar vertraut werden kann, muss SyncS ein zugeh6riges Zertifikat einer PCA vorliegen, dass zum Beispiel das Vorhandensein einer bestimmten Mail-Anwendung in einer sicheren Systemumgebung best~ttigt. Hierbei wird das ibliche AIK Credential, das die PCA ausgibt um Information t~ber den vorliegenden PCR-Wert erweitert. Diese Variante eines AIK nennen wir hier Binding Key. In Schritt 1 wird der 6ffentliche Schlissel zur PCA ibertragen, Remote Attestation ausgeffihrt und ein Zertifikat ft'Lrihn ausgestellt, das aussagt, dass dieser Schl(issel von einer TP stammt und nur in einem bestimmten Systemzustand verwendet werden kann. Zertifikat und Binding Key werden an das Endger~it ausgeliefert und yon ihm beim SynS zur Benutzung registriert. Diese Schritte 1-4 mfissen nur einmal zoB. w~ihrend der Inbesitznahme des Ger~its durch den Benutzer ausgeffihrt werden. SyncS kann nun in Schritt 5 die Nutzdaten mit dem Binding Key oder einer hybriden Methode verschlisseln und in den weiteren Schritten an das Gergt auslieferno Diese Methode ist allerdings etwas unflexibler als die vorgenannte, da bei jener iiber die Vertrauenswfirdigkeit eines Ger~its bei jeder einzelnen Synchronisation entschieden werden kann.

204

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identit~iten

Das Key Binding kann in sinnvoller Weise mit dem in Abschnitt 4.1 entwickelten Ticket-System kombiniert werden. Das Endgergt nutzt dann ein von der PCA ausgegebenes Ticket als ein AutorisierungsToken, um auf SyncS als Dienst (oder in der Rolle von RS) zuzugreifen. Der AIK des Tickets kann zwar nicht direkt zur Verschlfisselung der Nutzdaten verwendet werden, aber die dem Ticket beigefagten Nutzdaten k6nnen den erw~ihnten 6ffentlichen Schlt~ssel zur Verschl~sselung sowie sein zugeordnetes Zertifikat beinhalten. Die PCA kann hier beide Rollen- der das Ticket ausgebende Stelle und der des Zertifizierers des Binding K e y - tibernehmen, oder diese Rollen k6nnen getrennt werden. Die Zuordnung von Gruppen und Wertigkeiten kann in diesem Szenario sinnvoll eingesetzt werden, um zum Beispiel Bandbreiten zuzuordnen.

5 Fazit und Ausblick Wir haben in diesem Artikel dargestellt welche potenziellen Einsatzm6glichkeiten Trusted Computing Plattformen speziell in mobilen Anwendungen haben~ Zum Schlug wollen wir nun noch einen - etwas spekulativen- Ausblick geben, wie die Entwicklung sowohl auf technischer, als auch Anwendungsebene in den n~ichsten Jahren weitergehen wird. Die wachsenden F~ihigkeiten mobiler Endgergte verwischen zunehmend die Grenze zwischen PC und Mobiltelefon, und Nutzer werden daher eine weitgehende funktionale Austauschbarkeit der beiden erwarten. Gleichzeitig entstehen im Web 2.0 mit AJAX Technologieplattformen, die es Diensteanbietem und sogar Endnutzern erlauben, mit geringstem Aufwand neuartige, partizipative Anwendungen zu erstellen und sogar zu vermarkten. Nokias Plattform Widsets und andere Tools zur Herstelhmg sogenannter mobiler Widgets [Wid] best~itigen diesen Trend. Haben diese Ans~itze far mobile Okosysteme zwar noch geringen kommerziellen Bezug, so wird mit sich entwickelnden M~irkten auch die Anforderung an Sicherheit far h6herwertigere Transaktionen zunehmen. Dies bezieht sich insbesondere auf die Endger~ite. Da in solch heterogenen Umgebungen erwartet wird, das auf einem Ger~it eines Nutzers viele verschiedene Dienste zu Gast sind, die verschiedenen Anbietern geh6ren, spielt die gegenseitige Abschottung sensitiver Daten und der jeweiligen Nutzeridentit~iten hier eine wichtige Rolle. Gleichzeitig ergibt sich die technische Anforderung nach Skalierbarkeit der Sicherheit auf diesen Plattformen, das heil3t einer gleichbleibenden ,Quality of Protection' unabh~ingig von Art und Anzahl der Dienste und Anwendungen auf dem Ger~it und der Transaktions- und Kommunikationspartner im Netz und seitens der Dienste. Wir glauben, das Virtualisierung von Sicherheitsfunktionen und vertrauenswttrdiger Plattformen hier ein erfolgversprechender Ansatz ist. Neu daran ist, das 1) virtualisierte sichere Umgebungen in einer transitiven Vertrauenskette auf einem einzigen, kostengfinstigen Hardwaremodul aufbauen und 2) anders als bisher tiblich, virtualisierte Umgebungen auf dem Endger~it mit netz- und serviceseitigen kooperieren k6nnten. Hierdurch kann zum Beispiel far die Nutzer eine gr6gere Verlgsslichkeit durch ,spiegeln' von virtualisierten Umgebungen garantiert werden. Dadurch kOnnen im Fall eines verlorenen oder gestohlenen Endgergts zum Beispiel Nutzeridentit~iten wiedergewonnen werden. Das Virtualisierung auf den derzeit in ihren Ressourcen noch beschr~inkten mobilen Ger~iten m6glich scheint, beweisen neuere Forschungsansgtze [Ferst]. Fazit: Die intelligente Verbindung mobiler, vertrauenswftrdiger Plattformen mit neuartigen, dem Web 2.0 entlehnten Gesch~iftsmodellen und weiteren Anwendungen mit hohem Sicherheitsbedarf bietet ggnzlich neue M6glichkeiten far die Evolution mobiler Dienste. Trusted Computing zusammen mit dem geschickten Einsatz von Virtualisierungstechniken kann hierfttr die solide (sicherheits-)technische Grundlage bilden.

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

205

Literatur [KPMG06] KPMG: Consumers and Convergence - Challenges and opportunities in meeting next generation customer need. 2006. http://www.kpmg.de/about/press_office/13611.htm [Ga06]

Annual Gartner Wireless and Mobile Summit, Detroit, MI, M~irz 2006

[TaSa06]

R~ Tafazolli, J. Saarnio, eMobility Mobile and Wireless Communications Technology Platform Staying ahead! Strategic Research Agenda Version 5, August 2006~ http://wwwoemobility.eu.org/

[LiWh02] Li, F., Whalley, J.: Deconstruction of the telecommunications industry: from value chains to value networks. Telecommunications Policy 26 (2002)451-472 [NTT04]

NTT DoCoMo, IBM, Intel Corporation: Trusted Mobile Platform Protocol Specification D o c u m e n t Revision 1.00.04/05/2004. http://www.trusted-mobile.org

[KuSch06] Kuntze, N., Schmidt, A. U.: Transitive trust in mobile scenarios. In: Proc. Internat. Conf. Emerging Trends in Information and Communication Security (ETRICS 2006), G. Mt~ller (Ed.), Lecture Notes in Computer Science, Vol. 3995 Springer-Verlag, 2006, ppo 73-85 [Ch05]

Cheney, R: How a terror group cloned Ted Rogers' cellphone. The Globe and Mail, Toronto, Canada, December 17, 2005

[BoE101 ]

Botha, R. A., Eloff, J. H. P.: Separation of duties for access control enforcement in workflow environmentso IBM Systems Journal, 40 (2001) 666-682

[NaPo90] Nash, M. J., Poland, K. R.: Some conundrums concerning the separation of duty. Proceedings of the IEEE Symposium on research in security and privacy, 7-9 May 1990, Oakland, CA [BrCaCh04] Brickell, E., Camenisch, J., Chen, L.: Direct anonymous attestation. In: Proc. 10th ACM Conference on Computer and Communications Security, Washington DC, ACM Press, 2004 [Ca04]

Camenisch, J.: Better Privacy for Trusted Computing Platforms. In: Proc. 9th European Symposium On Research in Computer Security (ESORICS 2004), Sophia Antipolis, France, September 13-15, 2004, Springer-Verlag, 2004, pp. 73-88

[Ch85]

Chaum, D.: Security without Identification: Transaction Systems to make Big Brother Obsolete; Communications of the ACM 28/10 (1985) 1030-1044

[CaVa02]

Camenisch, J., Van Herreweghen, E.. Design and implementation of the idemix anonymous credential system. Proceedings of the 9th ACM conference on Computer and communications security (CCS'02), ACM, 2002, pp. 21-30

[HoSo06] Hohl, A., Soichi, F. TC-based service Authentication. Presentation at the Internat. Conf. Emerging Trends in Information and Communication Security (ETRICS 2006), 8th June 2006. [Sa06]

Sadeghi, A.-R.: Towards an Open Trusted Computing Architecture. Presentation at the Internat. Conf. Emerging Trends in Information and Communication Security (ETRICS 2006), 8th June 2006.

[OpenTC] The Open Trusted Computing Project. http://www.opentc.net/ [ChvH91 ] Chaum, D., van Heyst, E.: Group signatures. In: Davies, D., Hrsg.: Advances in Cryptology- EUROCRYPT'91. Lecture Notes in Computer Science, Bdo 547, Springer-Verlag, 1991,257-265~ [BoE101 ]

R.A. Botha, J. H. P. Eloff, Separation of duties for access control enforcement in workflow environments. In: IBM Systems Journal 40, 2001,666-682.

[KuSc06] Kuntze, No, Schmidt, A~ Employing Trusted Computing for the forward pricing of pseudonyms in reputation systems. Erscheint in: Proceedings of the Workshop Virtual Goods at the Conference AXMEDIS 2006, Leeds, England, 13.-15. December 2006. [Bakos98] Bakos, Y.: The emerging role of electronic marketplaces on the Internet. In: Communications of the ACM 41, 1998, 35-42. [RKZF00] Resnick, R, Kuwabara, K., Zeckhauser, R., Friedman, Eo: Reputation systems. In: Communications of the ACM 43, 2000, 45 -48. [Axe184] Axelrod, R.: The Evolution of Cooperation. New York, Basic Books, 1984. [SaDW06] Salganik, M.J., Dodds, RS., Watts, D.J.: Experimental study of inequality and unpredictability in an artificial cultural market. In: Science 311, 2006, 854-856.

206

Trusted Computing in mobiler Anwendung:Von Zugangskontrolle zu Identitgten

[Dell00]

Dellarocas, C.: Immunizing online reputation reporting systems against unfair ratings and discriminatory behaviour. In: ACM Conference on Electronic Commerce, 2000, 150-157.

[Douc02]

Douceur, J.R.: The sybil attack. In: Druschel, P., Kaashoek, F., Rowstron, A., Hrsg.: Peer-to-Peer Systems: First International Workshop, IPTPS 2002. Lecture Notes in Computer Science Bd. 2429, Springer-Verlag, 2002, 251-260.

[FrRe01 ]

Friedman, E.J., Resnick, R: The social cost of cheap pseudonyms. In: Journal of Economics & Management Strategy 10, 2001, 173-199.

[Dell04]

Dellarocas, C.: Sanctioning reputation mechanisms in online trading environments with moral hazard. MIT Sloan Working Paper No. 4297-03, 2004.

[BhGo05] Bhattacharjee, R., Goel, A.: Avoiding ballot stuffing in ebay-like reputation systems. In: P2PECON '05: Proceeding of the 2005 ACM SIGCOMM workshop on Economics of peer-to-peer systems, ACM Press, 2005, 133-137. [ChFr05]

Cheng, A., Friedman, E.: Sybilproofreputation mechanisms~ In: P2PECON '05: Proceeding of the 2005 ACM SIGCOMM workshop on Economics of peer-to-peer systems, ACM Press, 2005, 128-132.

[BuHu99] Buttyan, L., Hubaux, J.R: Accountable anonymous access to services in mobile communication systems. In: Proceedings of the 18th IEEE Symposium on Reliable Distributed Systems, 1999, 384-389. [ZiFL]

Zieglera, G., Farkas, C., LSrincz, A.: A framework for anonymous but accountable self-organizing communities. In: Information and Software Technology 48, 2006~ 726-744.

[OMA06] Open Mobile Alliance: Push architecture, draft version 2.2 - 20 jan 2006. omaad-push-v2_2-20060120-d. Technical report, Open Mobile Alliance, 2006. [KuSch06] Kuntze, N., Schmidt, A. U.: Trustworthy content push. To appear in: Proc. IEEE Wireless Communications & Networking Conference (WCNC 2007), Hong Kong 11-15 M~irz 2007. [TCG05]

Trusted Computing Group: Mobile Phone Working Group Use Case Scenarios -v 2.7. Technical report, TCG, 2005.

[KiKu06] Kilian-Kehr, Ro, Kuemmerle, J.: Secure license management. European Patent Application, EP 1 674 963 A1, publication date 28.06.2006, priority date 22.12.2004 [PePr01 ]

Pearson, S., Proudler, G.: Enforcing restrictions on the use of stored data. International Patent Application under the PCT, WO 01/13198 A1, publication date 22.02.2001, priority date 13.08.99

[Wid]

Verschiedene mobile Widget Plattformen: Openwave Mobile Widgets http://www.openwave.com/ us/products/handset_products/mobile_widgets/, mojax von mFoundry http://mojax.mfoundry. corn/, Nokias Widsets http://widsets.com, Widget engine Freedom f~r die Opera Plattform http://www.mobileburn.com/pressrelease.j sp?Id=2054

[Ferst]

Ferstay, D.: Fast Secure Virtualization for the ARM Platform. Master's Thesis. University of British Columbia.M~trz 2006.

D a t e n s c h u t z - und rechtliche Aspekte

Auswirkungen von Trusted Computing auf die Privatsph ire' Markus Hansen 9Marit Hansen Unabh~ingiges Landeszentrum far Datenschutz Holstenstr. 98, 24103 Kiel {markus.hansen [ marit.hansen} @privacyresearch.eu

Zusammenfassung Welche Auswirkungen Trusted Computing auf die Privatsph/ire von Menschen haben wird, 1/isst sich zum hew tigen Zeitpunkt noch nicht abschliegend feststellen. Allerdings k6nnen aus der Spezifikation, den Best PracticeVorschl/igen sowie den mutmaglichen Szenarien, in denen Trusted Computing zum Einsatz kommen soll, bereits zahlreiche Chancen, aber auch Risiken far den Datenschutz abgeleitet werden. Dieser Beitrag gibt einen l)berblick t~ber Datenschutzaspekte von Trusted Computing und zeigt m6gliche Einsatzfelder pro und contra Schutz der Privatsph~ire auf.

1 EinKihrung Trusted Computing (TC, 0bersetzt ,,vertrauenswttrdige Datenverarbeitung") hat ein kleines Problem: Viele Nutzer m6gen Trusted Computing nicht vertrauen. Stattdessen rechnen sie mit Beschneidungen hinsichtlich dessen, was sie in Zukunfl noch mit ihren PCs anfangen dfirfen, sowie mit Anwendungen, die Eingriff in ihre Privatsph~ire nehmen und denen sie nicht entgehen k6nnen. Jegliche Versuche, sie davon zu tiberzeugen, dass Trusted Computing die Privatsph~ire der Menschen nicht verletzen wird, sondern ihnen ein m/ichtiges Werkzeug zur Erh6hung der Sicherheit ihrer IT-Systeme an die Hand gibt und so den Schutz ihrer Privatsphgre vergr613ern kann, sind bisher offensichtlich fehlgeschlagen. Als die 6ffentliche Diskussion zu Trusted Computing begann, waren fundierte Informationen zum Thema nur schwer zu finden. Fehlinformationen und Ger0chte erschwerten einen klaren Ausblick auf m6gliche und mutmal31iche Szenarien. Vom heutigen Stand verfagbarer Informationen betrachtet, ist der technische Standard von Trusted Computing recht often und bietet vielf'~iltige M6glichkeiten, TPMs datenschutzfreundlich, datenschutzgerecht oder aber auch datenschutzfeindlich einzusetzen.

2 Hintergrund und technische Grundlagen Der Begriff,,Trusted Computing" wurde yon der Trusted Computing Platform Alliance (TCPA) gepr/igt. Dabei handelte es sich um einen Zusammenschluss von EDV-Firmen, in dem Spezifikationen standardisiert werden, um eine Interoperabilit/it von vertrauenswttrdigen Systemen verschiedener Hersteller zu gew/ihrleisten. Gegrtindet wurde die TCPA im Jahre 2002 von den Firmen Compaq, Hewlett-Packard, Intel, IBM und Microsoft. Die TCPA hat derzeit ca. 200 Mitglieder. Im Sommer 2003 tibernahm die Trusted Computing Group (TCG) die Weiterentwicklung der Spezifikationen und trat die Nachfolge der TCPA an. Ein ,,trusted" System im Sinne der TCG ist im Vergleich zu einem herk6mmlichen System um 1 Dieser Text unterliegt den Bedingungen der CreativeCommons-Lizenz BY-NC-SA. N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 209-220

210

Auswirkungen von Trusted Computing auf die Privatsph~ire

ein sog. Trusted Platform Module (TPM) erweitert. Dabei ist der Einsatzbereich eines TPM nicht auf Personal Computer beschrgnkt, sondern z.B. auch far Mobiltelefone vorgesehen. Im Unterschied zu vielen Ver6ffentlichungen insbesondere aus der Anfangsphase der TC-Diskussion handelt es sich beim TPM nicht um eine Komponente, die aktiv bestimmte Aktionen des Nutzers einfordert oder verhindert, sondern ein TPM kann lediglich das Betriebssystem bei kryptographischen Funktionen unterstfitzen, einen abgesicherten Speicherbereich far kryptographische Schlt~ssel zur Verfagung stellen und den Betriebszustand eines Rechners messen sowie Jimderungen des Zustandes bemerken [ULD04a]. Dies schfitzt eine Trusted Platform gegen Manipulationsversuche, da eine Modifikation des Systems bzw. seiner Komponenten mit Hilfe des TPM vom Betriebssystem erkannt und ggf. blockiert werden kann. In jedem TPM ist ab Werk ein einzigartiges asymmetrisches Paar kryptographischer Schlfissel (Public / Private Key) enthalten. Dieser sog. Endorsement Key (engl.: Best/~tigungsschl%sel) wird dabei normalerweise direkt im TPM erzeugt und durch den Hersteller signiert, um die Echtheit des Bausteins zu zertifizieren. Aufgrund der Einzigartigkeit des Endorsement Keys, die ggf. einen Personenbezug erm6glicht, soll dieser in der Regel nicht direkt verwendet werden, sondern die Spezifikation sieht vor, mit seiner Hilfe mehrere sog. Attestation Identity Keys (engl.: Beglaubigungs- und Identit/~tsschlfissel) zu erzeugen. Diese Schlfissel erlauben es den Nutzern, unter verschiedenen Identit/~ten aufzutreten, w/ihrend gleichzeitig attestiert wird, dass es sich um Schlfissel einer Trusted Platform handelt (s.a. Abschnitt 6).

3 TCG und Privacy Die Trusted Computing Group war fiber die letzten Jahre mit Skepsis gerade im Bereich Datenschutz konfrontiert und versucht offensichtlich, das Thema offensiv anzugehen. Bereits auf der ersten Seite der TCG FAQ [TCG07] wird die Frage beantwortet: ,,What has the TCG done to preserve privacy?" Datenschutzbewusstsein ist offensichtlich vorhanden, selbst wenn auf der Ebene einer Spezifikation viele Parameter often bleiben und auch often bleiben mt~ssen, sind die Antworten, die TCG gibt, nicht zu kritisieren: "TCG believes that privacy is a necessary element of a trusted system. The system owner has ultimate control and permissions over private information and must 'opt-in' to utilize the TCG subsystem. Integrity metrics can be reported by the TCG subsystem but the specification will not restrict the choice and options of the owner preserving openness and the ability of the owner to choose. The TCG specifications support privacy principles in a number of ways: 1. The owner controls personalization. 2. The owner controls the trust relationship. 3. The system provides private object storage and digital signature capability. 4. Private personalization information is never exposed. 5. Owner keys are encrypted prior to transmission. It is also important to know what the solutions are not: 1. They are not global identifiers. 2. They are not personalized before user interaction. 3. They are not fixed functions - they can be disabled permanently. 4. They are not controlled by others (only the owner controls them)."

Auswirkungen von Trusted Computing auf die Privatsphgre

211

Der Trusted Computing Group ist bewusst, dass diese Antworten kritische Datenschfitzer noch nicht befriedigen k6nnen, denn sie sagen wenig fiber m6gliche Risiken beim tatsgchlichen Einsatz von Trusted Computing. Dies kann ein Spezifikationsgremium auch nicht vollstgndig adressieren, doch immerhin gibt die TCG im Best Practice-Dokument [TCG05] Hinweise zum Einsatzo Dieses Dokument entMlt nicht nur einen brauchbaren Datenschutz-Primer, sondern erl~iutert die TC-Funktionalit~it far verschiedene Prinzipien, die Datenschutzbezug haben, insbesondere ,,Privacy", ,,Controllability", ,,Ease-of-use" und ,,Security". Der Sicherheitsexperte Bruce Schneier hat sich kritisch mit diesem Dokument auseinandergesetzt jedoch den Datenschutzteil insgesamt gelobt [Schn05]. Will man die Auswirkungen von Trusted Computing auf den Schutz der Privatsph~ire bestimmen, muss man die jenigen Applikationen betrachten, die h6chstwahrscheinlich von TPMs Gebrauch machen werden. Dieser Text gibt einen 121berblick fiber die aus heutiger Sicht wahrscheinlichsten TC-Anwendungen und die diesbezfiglichen Datenschutzimplikationen: Schutz vor Malware, Digital Rights Management (DRM) und Identit~itsmanagement (IDM).

4 Schutz vor Malware in einer vernetzten Welt. Datenschutz basiert auf dem Recht auf informationelle Selbstbestimmung, das nach der EuropNschen Menschenrechtskonvention (Art. 8) sowie nach der UN-Deklaration der Menschenrechte (Art. 12) ein Grundrecht ist. Dennoch wird die Privatsph~ire insbesondere im Internet heutzutage nicht so respektiert, wie es sein sollte. 12Iberprfifen Nutzer ihre Computer auf unerwfinschte Software, finden sie oft Programme, die ihr Verhalten zumindest teilweise fiberwachen und auf ihre pers6nlichen Daten und Ressourcen zugreifen k6nnen. Kostenlose Versionen von kommerzieller Software etwa bringen manchmal andere Software mit, die den Nutzer zwingt, die ,,kostenlose" Software mit einer Verletzung ihrer Privatsph~ire zu bezahlen. So werden z.B. Surf-Gewohnheiten ausgesp~iht und an einen zentralen Server fibermittelt, der einzublendende Werbung entsprechend ausw~ihlt. Derartige Spionage-Software wird gemeinhin als ,,Spyware" bezeichnet, eine Unterkategorie von ,,Malware", was als lJ'berbegriff vom Betroffenen unerwfinschte Software mit Schadfunktionalit~it umfasst [Wagn05]. Moderne Computer-Viren beeintr~ichtigen nicht nur die Benutzung eines PCs, einige erlauben ihren Initiatoren zudem, infizierte Rechner fiber das Internet zu kontrollieren, sie nach E-Mail-Adressen zu durchsuchen, fiber sie Werbung und Viren per E-Mail zu senden (manchmal mit kommerziellem Hintergrund) [Heis04] und ungewfinschte Kopien urheberrechtlich geschfitzter Werke oder illegale Inhalte wie bestimmte Formen der Pornographie darfiber zu verbreiten, ohne dass der eigentliche T~iter mit herk6mmlichen Methoden leicht ermittelt werden kanno Diese Probleme betreffen nicht nur private PCs, sondern auch die von Firmen und Verwaltung, auf denen grol3e Mengen personenbezogener Daten gespeichert sind. Da immer mehr Systeme an das Internet angeschlossen werden, wirken sich zunehmend Datensicherheitsprobleme auf den Schutz der Privatsph~ire aus. Ein TPM kann dem Betriebssystem Unterstfitzung bieten, um sich gegen Manipulationen wie die Infektion mit Viren, Spyware und anderer unerwfinschter Software zu schfitzen, indem es Anderungen bestimmter Parameter meldet. Ein TPM tr~igt daher, zu einer Erh6hung des Datensicherheits- und damit auch des Datenschutzniveaus bei.

212

Auswirkungen von Trusted Computing auf die Privatsph/ire

5 Digital Rights Management (DRM) Betrachtet man Trusted Computing aus Datenschutzsicht, ist es unvermeidbar, sich auch mit DRM auseinander zu setzen: Dies wird wahrscheinlich eines der Hauptanwendungsgebiete von Trusted Computing werden, da TPMs viele Funktionen bereitstellen, die Implementierungen von DRM-Systemen erleichtern. Digital Rights Management (Digitale Rechte-Verwaltung) bezeichnet diverse Konzepte, die den freien Zugriff auf Daten einschr~inken [PfFK02]o Die folgenden DRM-Anwendungen sollen n~her betrachtet werden: 9 DRM fl~ Mediendaten, 9 DRM ffttr Software-Produkte, 9 DRM ffir pers6nliche Daten im Bereich des Nutzers, 9 DRM f'tir Betroffenendaten in Unternehmen und Verwaltung.

5.1 DRM fLir Mediendaten Anbieter von Medieninhalten m6chten DRM einsetzen, um ihre Produkte gegen unkontrollierte Verbreitung und Vervielf'~tltigung zu schfitzen. Auf herk6mmlichen PCs schlfigt ein Schutz von Mediendaten per DRM zumeist fehl, da sich dort in der Regel zu viele L6cher finden, durch die der gescht~tzte Inhalt wieder in die Freiheit entschlfipfen kann. Virtuelle Sound- oder Grafikkarten als Beispiel k6nnen unverschlfisselte Daten in eine Datei schreiben, die dann nicht mehr geschfitzt ist~ Aul3erdem k6nnen analoge Kopien des Inhalts nicht verhindert werden~ Daher gibt es ein starkes Interesse der Medienindustrie, aus PCs manipulationssichere Endger/~te zu machen~ Ein PC mit einem TPM und einem dessen Funktionalit/~t untersttitzenden Betriebssystem (also eine Trusted Platform) kann als so ein manipulationssicheres Endger/~t agieren. Die Verwendung eines eindeutigen 6ffentlichen vom TPM generierten kryptographischen Schlfissels zur Kodierung einer Mediendatei soll dann sicherstellen, dass diese nur auf demjenigen System wiedergegeben werden kann, dessen TPM fiber den zugeh6rigen geheimen Schlfissel verffigt~ Aber auch hier k6nnten Schlupfl6cher verbleiben. Ein anderer DRM-Mechanismus markiert daher die Mediendatei mit einem eindeutigen Identifikator (Fingerprinting, Watermarking) [PfFK02]. Wird eine unerwfinschte Kopie der Mediendatei gefunden, erlaubt dies den Inhaltsanbietern, sie zum ursprfinglichen Besitzer zurfickz~werfolgen~ Dies funktioniert natarlich nur, wenn es eine Datenbank gibt, in der gespeichert wird, were welche eindeutigen Kennungen zuzuordnen sind. Daraus resultiert ein grol3es Datenschutzproblem, denn um jederzeit jede ungewfinschte Kopie zurfickverfolgen zu k6nnen, muss die Information darfiber, wer welche Mediendaten erworben hat, auf Dauer gespeichert und abrufbar gehalten werden. Dies hat die Bildung umfangreicher Datenprofile der Nutzer zur Folgeo In der TPM-Spezifikation 1.2 [TCG03] wurde zwar ein Protokoll namens Direct Anonymous Attestation [BrCC04] (DAA, s. Abschnitt 6.1) zur anonymen Abwicklung von Transaktionen eingeffihrt, aber um sicherzugehen, dass die Quelle einer unerwfinschten Kopie festgestellt werden kann, sind Inhaltsanbieter nicht daran interessiert, ihren Kunden Anonymit~it zu bieten.

Auswirkungen von Trusted Computing auf die Privatsph~ire

213

Der Einsatz von DRM far Mediendaten bietet den Kunden nicht den geringsten Vorteil, sondern i s t solange DR/vi-Konzepte die Identifikation der Kunden vorsehen- eine starke Beeintrgchtigung ihrer Privatsphgre.

5.2 DRM fiJr Software-Produkte Analog zu DRM far Mediendaten soil DRM far Software-Produkte deren unkontrollierte Kopie und Verbreitung verhindern. Auf einer Trusted Platform kann Software sich selbst schfttzen, indem sie die Rechte zur Manipulation des Programms oder der Umgebung einschr~inkt. Zum Beispiel ist Schummeln bei Computer-Spielen zwar fiblich, aber in vielen F~illen von anderen Spielern nicht gem gesehen. Spiele-Entwickler versuchen daher, ihre Produkte vor Schummlern zu scht~tzen. Da sie allerdings die Umgebung (das System), in der das Spiel l~iuft, nicht kontrollieren k6nnen, finden Schummler in der Regel doch eine Manipulationsm6glichkeit. Zwar k6nnen Spiele-Entwickler eine Trusted Platform ebenfalls nicht direkt kontrollieren. Jedoch k6nnen sie das Spiel so gestalten, dass es die Funktionalit~it des TPMs nutzt, sofern vom Betriebssystem unterstfitzt, um Manipulationen festzustellen und entsprechend zu reagieren. Das Gleiche gilt far jegliche andere Software wie Textverarbeitung, Tabellenkalkulation, Medien-Player und auch das Betriebssystem selbst. Eine erh/Shte Resistenz gegen unerwt~nschte Programme wie Viren, Trojanische Pferde oder Spyware bedeutet allerdings ebenfalls, dass ein Stfick Malware, das es einmal geschafft hat, sich auf einer Trusted Platform einzunisten, ebenfalls TC-Mechanismen nutzen kann, um sich gegen Manipulationen wie Entfernung z~ scht~tzen. End User License Agreements (EULAs), die ein Nutzer wghrend der Installation einer Software zu akzeptieren hat, sind in Europa und vielen anderen Teilen der Welt derzeit nicht gt~ltig [Wiki07]. W~ihrend Nutzer aus diesen Regionen solche Lizenzen momentan einfach ignorieren k6nnen, kann Software zukfinftig die Funktionalit~it eines TPMs nutzen, um die Durchsetzung solcher Lizenzbedingungen zu erzwingen [ULD04b]. Software kann sich also nicht nur vor ungewollter Manipulation etwa durch Viren schfitzen, sondern auch vor Manipulation, die der Nutzer bewusst durchzufahren wt~nscht. So k6nnen derzeit Nutzer eines bestimmten Betriebssystems Programme wie xp-Antispy nutzen, um Mechanismen abzustellen, die eine automatische Verbindung ins Internet aufbauen und ohne Hinweis geschweige denn Kontrollm6glichkeit Daten zu entfernten Servern t~bermitteln [Taub03]. Bei Verwendung von Trusted Computing lassen sich derartige - vom Hersteller unerwfinschte - Manipulationen unterbinden, die jedoch in diesere Beispiel den Datenschutz der Nutzer unters~tzen wfirden. Hersteller von Bildbearbeitungsprogrammen k6nnten ihre Produkte auf diese Weise gegen Patches sichern, die das Modul der Central Bank Counterfeit Deterrence Group (CBCDG) entfernen, das gewghrleisten soll, dass Bilder von Banknoten nicht verarbeitet werden [Schu04]. Darfiber hinaus k6nnten sie sicherstellen, dass Programmerweiterungen von unabh~ingigen Herstellern, die keine entsprechende Gebfihr gezahlt haben, vonder Interoperation ausgeschlossen werden. Dies h~itte den gleichen Effekt wie die kleinen Chips in einigen Tintentanks, die den nachgelagerten Markt der Druckerhersteller vor Produkten von Drittanbietern sch~tzen sollen [Heis02]o Diese M6glichkeit der Hersteller, sich gegen den Wettbewerb mit Drittanbietern zu schfitzen, kann auf einer technischen Ebene zu den gleichen Monopol-Effekten fahren, die Software-Patente auf einer rechtlichen Ebene verursachen k6nnen. Dies ist zwar weniger ein Datenschutz- als ein Verbraucher-

214

Auswirkungen von Trusted Computing auf die Privatsph~ire

schutzproblem, doch aufjeden Fall kann mit Hilfe von Trusted Computing in die Autonomie der Nutzer eingegriffen werden.

5.3 DRM f~ir pers6nliche Daten Die kryptographische Unterst~tzung eines TPMs kann Anwendungen wie einer Textverarbeitung die M6glichkeit geben, die damit erzeugten Dateien gegen unautorisierten Zugriff zu scht~tzen: Daten k6nnen so verschlfisselt werden, dass sie nut auf dem Rechner, auf dem sie erstellt wurden, ge6ffnet werden k6nnen. Probleme werden auftreten, wenn ein Nutzer feststellt, dass sein TPM zerst6rt wurde oder eine Fehlfunktion aufweist. Es wird ausgesprochen schwierig werden, die Daten wieder herzustellen, wenn kein Backup der unverschltisselten Daten (Sicherheitsrisiko) oder der kryptographischen Schlfissel des TPMs vorhanden ist. Da in der TPM-Spezifikation 1.2 noch immer nicht alle Schlfissel migrierbar sind (obwohl Datenschutzbeh0rden verlangen, dass Nutzer die vollst~tndige und alleinige Kontrolle fiber ihre IT-Systeme haben [DSB03]), riskieren es Nutzer, ihre Daten unwiederbringlich zu verlieren, wenn sie TPM-gestfitztes DRM far ihre pers6nlichen Dateien verwenden. Probleme werden weiterhin auftreten, wenn ein Nutzer einen neuen Rechner erwirbt und seine Dateien auf diesen tibertragen will, da die beiden PCs unterschiedliche TPMs haben werdeno

5.4 DRM in Unternehmen und Verwaltung In Unternehmen (oder entsprechend in der 6ffentlichen Verwaltung) k6nnen Kundendaten durch den Einsatz von DRM geschtitzt werden. Als ein Beispiel bietet EPAL (Enterprise Privacy Authorization Language) Mechanismen, um Datens~itze mit einem Regelsatz zu kennzeichnen, der vorgibt, welche Formen der Datenverarbeitung erlaubt und welche verboten sind [EPAL03]o Vorausgesetzt das FirmenIT-System sorgt far die Durchsetzung solcher Regels~itze, fahrt dies zu einem deutlich h6heren Datenschutzniveau. Far eine effektive Durchsetzung k6nnen sich Trusted Platforms als n~tzlich erweisen. Eine L6sung wird in [CMPB03] skizziert, in der sog. ,,Sticky Policies"- bereits als Paradigma eingeftthrt in [KaSW02] - auf der Basis von Trusted Computing zum Einsatz kommen. Eine Sticky Policy enth~ilt die Privacy Policy der Daten verarbeitenden Stelle sowie Informationen t~ber Einwilligungen des Nutzers oder Widersprflche, wo Wahlm6glichkeiten (,,opt-in and opt-out choices") bestehen. Das Besondere an der Sticky Policy ist ihr unmittelbares ,,Kleben" an den Nutzerdaten, so dass bei jedem Zugriff auf die Daten die Policy ausgewertet wird. Sie steuert dementsprechend Zugriffskontrollmechanismen oder auch andere Datenschutzfunktionalit~it, z.B. sorgt fttr das L6schen von Daten nach der vereinbarten Zeit. Durch Trusted Computing l~isst sich die Verarbeitung der Daten an ein TPM binden. 2 Bei Einsatz von Trusted Computing kann die IT-Abteilung eines Unternehmens zudem Konfigurations~inderungen der von ihr betreuten Systeme feststellen. Ein als kompromittiert erkannter PC kann dann vonder Kommunikation im Untemehmensnetz ausgeschlossen werden, bis ein Administrator den Rechner genauer unter die Lupe genommen hat. Dies warde im Unternehmen auch den Schutz gegen Innent~iter erh6hen. Neben dem Schutz der Kundendaten k6nnte Trusted Computing ebenfalls dabei helfen, sich vor einem ungewollten Nach-Aul3en-Dringen vertraulicher Dokumente zu schtitzen. Wird die kryptographische Unters~tzung eines TPMs genutzt, w~ire ein dennoch nach auBen gelangtes Dokument auch dort vor 2 Verwandtist der Ansatz von Hohl und Zugenmaier([HoZu04, HoZu06]), in dem durch DRM-TechnikNutzerdaten auch im Pervasive Computinggeschtitztwerden sollen.

Auswirkungen von Trusted Computing auf die Privatsph~ire

215

unautorisiertem Zugriff geschtitzt, da es sich nur auf dem System mit dem entsprechenden TPM entschltisseln liege. Vorf~ille, dass ein Mitarbeiter eines Untemehmens Kundendaten an Spammer oder andere Interessierte verkauft, wtirden so unwahrscheinlicher. Kritiker argumentieren, dass die Pressefreiheit beeintr~ichtigt wfirde [ATTA05], da es dann nahezu unm6glich sei, dass Fehlverhalten eines Unternehmens oder einer Beh6rde durch nach augen gelangte Informationen aufzudecken. Gesetzt den Fall, dass die gesamte Infrastruktur an Trusted Platforms eines Landes von seiner Regierung kontrolliert wtirde, kt~nnte diese das Abrufen unabh~ingiger Informationen aus dem Intemet unterbinden. Beispielsweise liege sich ein Regelsatz definierten, der den Zugriff auf lediglich von einer bestimmten Beh6rde freigegebene Informationen beschr~inkt.

6 Identit

itsmanagement

Identit~it ist ein komplexes Gebilde, das von vielerlei Disziplinen, teilweise schon seit Jahrhunderten, untersucht wird. Im Markt werden heutzutage vielerlei Identit~itsmanagementsysteme beworben, die unterschiedliche Aspekte bedieneno In jedem Fall geht es aber bei diesen IT-Systemen um digitale Identit~iten: Digitale Identit~iten sind Sammlungen von digitalen Informationen, die zu einem Individuum gespeichert sindo Jede digitale Identit~it ist in der Regel charakterisiert durch eine Menge von Attributen (z.B. Eigenschaften einer Person) und weist h~iufig mindestens eine Kennung (,,Identifier") auf. Digitale Identit~iten sind digitale Repr~isentierungen von Teilidentit~iten, d.h. Teilen der gesamten Identit~it einer Person.

6.1 Nutzerkontrolliertes Identit itsmanagement Identit~itsmanagement bedeutet das Verwalten yon Identit~iten und/oder yon identit~itsdaten. Beim nutzerkontrollierten Identit~itsmanagement erh~ilt der Nutzer die Kontrolle tiber seine eigenen Teilidentit0.ten. In AbMngigkeit von der spezifischen Situation oder dem Kontext kann der Nutzer unter unterschiedlichen Teilidentit~iten auftreten, z.B. gekennzeichnet durch verschiedene Pseudonyme, und durch Wiederverwendung weiter ausbauen, eine Reputation erwerben o.~i. [HKK+03]. Es gibt zwei prim~ire Eigenschaften des nutzerkontrollierten Identit~itsmanagements: 9 Transparenz: Um wirklich Kontrolle tiber seine eigenen Daten haben zu k6nnen, ist es erforderlich, dass dem Nutzer bewusst ist, wer was fiber ihn weig und wie dieses Wissen verarbeitet wird. 9 Steuerbarkeit: Wo immer m6glich, sollte der Nutzer bestimmen k6nnen, an wen welche Daten gehen. Wichtig ist damit auch die Kontrolle der Verkettbarkeit der Daten: Sind Daten n~imlich erst einmal zusammengeffihrt, ist ein nachtr~igliches Herausl6sen von Informationen sehr schwierig oder sogar unm6glich. Daher sollte ein unautorisiertes Verketten yon Nutzerdaten verhindert werden. TPMs erlauben neben der Bescheinigung (Attestation) eines bestimmten Zustandes eines bestimmten Systems die Generierung von Teilidentit~iten fftr dessen Nutzer in Form von signierten kryptographischen Schliisseln oder Zertifikaten.

216

Auswirkungen von Trusted Computing auf die Privatsph~ire

Um die Sicherheit digitaler Transaktionen zu gew~ihrleisten, kann eine Trusted Platform seine Integrit~it unter Verwendung von Kryptographie attestieren. Frfihere Versionen der TPM=Spezifikationen erforderten hierffir die Einbeziehung eines vertrauenswttrdigen Dritten, einer Trusted Third Party (TTP). Vereinfacht dargestellt wfirde ein Nutzer, der eine bestimmte Transaktion fiber das Internet initiieren will, eine TTP aufsuchen, dieser attestieren, dass er t~ber eine Trusted Platform verffigt, und seine Identitgt (insbesondere den echten Namen und/oder gfiltige Adressen) offenbaren~ Die TTP wfirde ihm dann ein Zertifikat ausstellen, das er seinem Transaktionspartner vorzeigen kann. Die TTP w~ire in der Lage, die Identit~it des Nutzers auf Grundlage des pseudonymen Zertifikats aufzudecken. Der Nutzer m%ste seine echte Identit~it gegenfiber dem Transaktionspartner nicht offenbaren, w~ihrend letzterer gleichzeitig sicher sein kann, es mit einer Trusted Platform auf der anderen Seite zu tun zu haben~ Dies erscheint zun~ichst datenschutzkonform. Da es eher unwahrscheinlich ist, dass eine groge Zahl yon TTPs den Markt fiberleben wird, und TTPs in der Lage sind, ohne grogen Aufwand verschiedene Pseudonyme der gleichen Person miteinander zu verketten, wfirde dies allerdings zu detaillierten Personenprofilen an wenigen zentralen Stellen ffihren [ULD04a]. Dies ist aus Datenschutzsicht kritisch~ In den TPM-Spezifikationen 1.2 wurde das bereits erw~ihnte Protokoll Direct Anonymous Attestation (DAA) eingefahrt. DAA erlaubt die Beglaubigung einer Trusted Platform ohne Einbeziehung eines Dritten. DAA gibt dem Nutzer Zertifikate, die seine Identit~it nicht preisgeben und jedes Mal anders aussehen. Diese Zertifikate, genannt Credentials, sind unverkettbar [CHVP02] und setzen damit ein wesentliches Datenschutzprinzip um [Came04]~ Wie bereits erw~ihnt, sind Inhaltsanbieter nicht daran interessiert, ihren Kunden Anonymitgt anzubieten. Es ist daher unwahrscheinlich, dass ein datenschutzfreundlicher Mechanismus wie DAA in der Lage sein wird, sein Datenschutzpotenzial Nr die Massen zu entfalten, solange das TTP-Modell existiert. Letzteres sollte daher in kfinftigen Versionen der TPM-Spezifikation aufgegeben werden. Dies ist jedoch ebenfalls unwahrscheinlich, da es (aul3erhalb der Datenschutzbetrachtung) Anwendungen gibt, wo der Einsatz von TTPs Sinn macht~ Sog. ,,Best Practices", wie vonder Artike129-Datenschutzgruppe vorgeschlagen [Art04], mfissen definiert werden und sollten obligatorisch sein. Auf diesen Vorschlag reagierte die TCG mit einem Best Practice-Dokument [TCG05], in dem sie sich fftr eine (situationsgerechte) Anonymit~it im Zusammenhang mit den vom Endorsement Key abgeleiteten Attestation Identity Keys (und damit Teilidentit~iten) ausspricht: "This can be done in a variety of ways including the use of zero-knowledge protocols, through a Privacy Certification Authority (CA), through a combination of zero-knowledge protocols and a Privacy CA, etc. Use of such tools protects the user's privacy by making data aggregation much more difficult. TCG recommends that implementations and deployments of TCG-enabled systems enable the highest degree of anonymity appropriate for a given situation."

6.2 Gegenmal~nahme zu Identit~itsdiebstahl Transaktionen im oben genannten Zusammenhang sind nicht auf den Erwerb digitaler DRM-beschrgnkter Gfiter begrenzt, sondern umfassen auch Kommunikations- und Authentifizierungsprozesse. Werden Authentifizierungsprozesse (vorzugsweise mittels DAA) durch Trusted Computing geschfitzt, k6nnte dies Identit~itsdiebst~ihle einschr~inken.

Auswirkungen von Trusted Computing auf die Privatsphgre

217

Elektronische Signaturen sind ein weiteres Beispiel far Anwendungen von Identit~itsmanagement. Obwohl die rechtlichen Grundlagen f'tir den Einsatz elektronischer Signaturen (zumindest in der EU) vorhanden sind, findet man kaum Anwendungen daflir. Elektronische Signaturen sehen sich zahlreichen Problemen gegent~ber. In Deutschland ist ein wesentliches Problem die mangelnde Akzeptanz begrfindet durch das Haftungsrisiko ffir den Nutzer: Sofern es einem Angreifer gelingt, die elektronische Signatur eines Nutzers zu fiilschen, findet dieser sich in der Situation, dass er nachweisen muss, dass diese Signatur nicht von ihm ist. Elektronische Signaturen erfordem daher manipulationssichere Endgergte, die die Nutzer zwingen, sich eindeutig zu authentisieren. Solange diese Applikation allerdings nicht davor scht~tzt, dass ein Angreifer sich Signaturkarte und Zugangscode verschafft, hat der Nutzer immer noch das Problem der Beweislastumkehr. Ein weiteres Problem ist das des ,,What-You-See-Is-What-You-Sign", das nicht trivial zu 16sen ist. Nutzer mfissen daher ein hohes Mag an Expertise besitzen, um beurteilen zu k6nnen, ob sie in eine Falle gelockt werden oder nicht, wobei sich sogar Experten irren k6nnen. Man kann nie sicher sein, ob der Inhalt des Dokuments, das man digital signiert, mit dem Inhalt, den man sieht, fibereinstimmt, sondern muss den Anwendungen und der Hardware (und deren Entwicklern und Herstellem) trauen. Auch hier kann Trusted Computing mit dem Schutz vor Manipulation hilfreich seino

7 Handlungsempfehlungen for ein datenschutzkonformes Trusted Computing Wesentlich ftir einen datenschutzkonformen Einsatz von Trusted Computing ist eine Entwicklung und Ausgestaltung der IT-Systeme derart, dass die Eigentt~ner die vollst~indige Kontrolle fiber s~imtliche da~ber verwaltete Daten wahrnehmen k6nnen. Gem~il3 den Datenschutzgesetzen muss eine Daten verarbeitende Stelle die Kontrolle t~ber die Verarbeitung von personenbezogenen Daten haben. Dies impliziert die vollumf'~ingliche Schlftsselgewalt, wie sie auch von der Konferenz der Datenschutzbeauftragten des Bundes und der L~inder eingefordert wurde [DSB03]: Es darfkeine Schl(issel bzw. Zertifikate geben, die nicht vom Eigentttmer des Rechners ausgelesen, erzeugt, geschrieben oder migriert werden k6nnen, auch wenn dies potenziell Inkompatibilit~iten hinsichtlich einer globalen Interoperabilitgt von Trusted Platforms zur Folge hat, da sich TPMs, deren Endorsement Keys ausgewechselt wurden, gegenseitig nicht mehr als ,,echt" erkennen k6nnen. Genau dieser Effekt kann aber auch bewusst eingesetzt werden, um sicherzustellen, dass ein Datenaustausch nur mit Systemen des eigenen Einflussbereichs erfolgt~ Bereits beim Beschaffen eines PCs und der Entscheidung, ob dieser mit einem TPM ausgestattet ist, sollten Privatnutzer ebenso wie Anwender durch verst~indliche ,,(Online- und Offline-)Beipackzettel" auf Chancen und Risiken durch Trusted Computing hingewiesen werden. Ebenso wie man bei einem Online-Kauf eines Rechners diverse Komponenten auswahlen und dimensionieren oder sogar konfigurieren kann, k6nnte auch eine Erstkonfiguration des TPM erfolgen. Auch ftir den Betrieb sollten Nutzer und Anwender tiber Trusted Computing-Auswirkungen informiert werden und in ihren Handlungsoptionen angeleitet werden. Ft~r die Gestaltung von auf Trusted Computing beruhenden Anwendungen sollte m6glichst weitgehend auf die datenschutzfreundliche Direct Anonymous Attestation zurfickgegriffen werden. Zurzeit l~iuft die DAA-Funktionalit~it ziemlich leer: Zum einen ist sie erst Bestandteil nach der Spezifikation 1.2, deren TPMs noch nicht fl~ichendeckend angeboten werden. Zum anderen fehlt den Gestaltern von solchen Anwendungen teilweise Kenntnis und Wissen fiber die DAA-Funktionalit~it oder die Fantasie, wie dies in ihrem GescMftsbereich zu realisieren wgre. Und augerdem h~ilt sich das Gerficht, die Implementie-

218

Auswirkungen von Trusted Computing auf die Privatsph~ire

rungen von DAA seien zu langsam und ressourcenintensiv, obwohl die Entwickler des DAA-Konzeptes hier andere praktische (und auch theoretische) Erkenntnisse haben. Entwickler und Anwender sollten den Datenschutzteil des Best Practice-Dokuments [TCG05] studieren und beherzigen, um so das kleine 1 x 1 des Datenschutzes abzuarbeiten. Nur Daten, die nicht vorhanden sind, sind wirksam gegen Missbrauch geschtitzt. Daher ist bereits bei der Konzeption von auf Trusted Computing aufsetzenden Applikationen darauf zu achten, so wenig personenbeziehbare Daten wie m6glich t~berhaupt zu erheben. Sofern eine solche Applikation sich nicht so gestalten lgsst, dass vollst~indig auf personenbezogene Daten verzichtet wird, muss die Nutzung von Trusted Computing grunds~itzlich auch auf Anbieterseite zur Anwendung kommen und sicherstellen, dass erhobene Daten nur fOr rechtlich zul~issige und im Voraus eindeutig definierte Zwecke und Zeitrgume genutzt werden k6nnen und andere Nutzungsarten ausnahmslos unterbunden werden. Da keine Technik unfehlbar ist, sollten Anbieter zudem durch begleitende organisatorische Maf3nahmen den Schutz der Kundendaten vor Zugriffen durch Dritte unterstfitzen und sich verpflichten, im Missbrauchsfall Kunden und Datenschutz-Aufsichtsbeh6rden unverzfiglich und vollumf~inglich zu informieren und zumindest far den Kunden daraus entstehende Nachteile und Schgden finanziell zu haften. Dies k6nnte auch durch gesetzliche Regelungen umgesetzt werden.

8 Fazit Obwohl die TPM-Spezifikationen datenschutzfreundliche und -konforme Anwendungen erlaubt, liegt das gr6f3te Marktpotenzial for Trusted Computing anscheinend in datenschutzfeindlichen Anwendungen wie DRM for digitale Konsumgfiter wie Mediendaten und Software. Auf lange Sicht funktioniert DRM allerdings nur, wenn dem Nutzer die Kontrolle fiber das eigene System (und damit die eigenen Daten) genommen wird, um ein Umgehen oder Brechen der Mechanismen zu verhindem. Aus Datenschutzsicht ist dieses Szenario alles andere als wfinschenswert. Derzeit sind Trusted Platforms noch nicht sehr verbreitet. Dies kann sich allerdings bald gndern, denn das Industrie-Konsortium TCG ist mgchtig genug, das Produkt in den Markt zu dr~ingen. Die Artikel 29-Datenschutzgruppe kommt in ihrem Arbeitspapier zu dem folgendem Schluss: ,,Der yon einer derart starken Vertretung der Industrie propagierte TPM-Einsatz dttrfte zum De-facto-Standard werden, zu einer notwendigen Voraussetzung fttr die Teilhabe an der Informationsgesellschaft. Dies k6nnte sich nicht nur im Bereich des Datenschutzes, sondern auch in Bezug auf andere Menschenrechtsaspekte wie etwa die Redefreiheit auswirken." [Art04] Zwar existieren bereits Werkzeuge zur St~irkung der eigenen Sicherheit und Privatsph~ire wie PGP/ GnuPG, doch sind diese nicht weit genug verbreitet, da viele Nutzer deren Komplexitgt nicht beherrschen. W~ihrend groge Unternehmen sich das fOr den sinnvollen Einsatz von Trusted Computing notwendige Know-how gut leisten k6nnen, werden die meisten Privatnutzer bereits damit fiberfordert sein, sich einen Oberblick fiber die sicherheitsf6rdernden M6glichkeiten zu verschaffen, die ein TPM anbietet. Nur ein geringer Anteil wird es schaffen, aus einem TPM den vollen Nutzen zu ziehen, w~ihrend die Mehrheit ihre Privatsphgre ungeschfttzt vor z.B. Inhaltsanbietern vorfinden wird. Wenn Trusted Computing in den Markt gedrfickt wird, ist es daher sehr wahrscheinlich, dass DRM die Hauptanwendung ist, der Privatnutzer begegnen werden. Als Gutenberg die Druckerpresse erfand, wurde das Empfangen von Informationen pl6tzlich einfach und gfinstig wie nie zuvor und hatte einen grundlegenden Einfluss auf die Entwickhmg der Gesellschaft. Die Einfohrung des Internet hatte den gleichen Effekt for das Publizieren von Informationen. DRM ist ein Versuch, den Geist der freien Ver-

Auswirkungen von Trusted Computing auf die Privatsph~ire

219

breitung von Informationen wieder in die Flasche der Kryptographie zu sperren, um Gesch~iftsmodelle und Profit zu schtitzen. Betrachtet man Trusted Computing aus einer Datenschutzperspektive, ist die Hauptfrage ganz einfach die, wer kontrolliert, was auf dem Rechner eines Nutzers passiert [ULD04a]. Aus der Offentlichen Diskussion, die Ross Anderson mit seiner vorgenannten FAQ startete, sind Proteste gegen die Plgne der TC-Industrie hervorgegangen, da Menschen den Verlust ihrer Privatsph~ire beNrchten. Organisationen wie der Chaos Computer Club haben Forderungen an die TCG gerichtet [Pylo03], und die Electronic Frontier Foundation erstellte eine Risiko-Analyse [Scho03]. Das gr613te Datenschutzpotenzial yon Trusted Computing ist ironischerweise ebenfalls in DRM zu finden, allerdings nicht im Beschrgnken der Nutzung digitaler Konsumgfiter, sondern in der Unterstfitzung Daten verarbeitender Systeme bei der Durchsetzung gesetzlich geforderter Zweckbindung und L6schfristen. Fftr Datenschfitzer ist aber in jedem Fall noch viel zu tun, denn der rechtskonforme Einsatz ist bei TC-L6sungen alles andere als selbstverst~indlicho Fttr wirklich datenschutzf6rdernde L6sungen sollte es Datenschutzg~tesiegel geben, durch die sich die Anbieter dieser ,,Privacy-Enhancing Technologies" von dem tibrigen Markt absetzen k6nnen.

Literatur [Art04]

[ATTA05]

[BrCC04]

[Came04]

[CHVP02]

Artikel 29-Datenschutzgruppe: Arbeitspapier t~ber vertrauenswtirdige Rechnerplattformen und insbesondere die T~itigkeit der Trusted Computing Group (TCG). 11816/03/DE WP 86, angenommen am 23. Januar 2004; http ://ec.europa.eu/justice_home/fsj/privacy/docs/wpdocs/2004/wp86_de.pdf. ATTAC Osterreich: Trusted Computing- Das trojanische Pferd der digitalen Selbstbestimmung und Privatsph~tre. Positionspapier. In: CODEattac, Stand: 10. Juni 2005; http://wiki~ PosPap_TrustedComputingo BrickeI1, Ernie, Camenisch, Jan, Chen, L: Direct anonymous attestation. In: Proceedings of 11th ACM Conference on Computer and Communications Security, ACM Press, 2004; http://www.zurich.ibm. com/-~jca/papers/brcach04.pdfo Camenisch, Jan: Better Privacy for Trusted Computing Platforms. In: Proceedings of 9th European Symposium On Research in Computer Security (ESORICS 2004), Springer-Verlag, 2004; http://www. zurich.ibm.com/-j ca/papers/cameni04.pdf. Claul3, Sebastian, Hansen, Marit, Van Herreweghen, Els, Pfitzmann, Andreas: Privacy-Enhancing Identity Management. In: The IPTS Report, Special Issue: Identity and Privacy, September 2002, S. 8-16; h ttp :/ /www.j rc. es/h o m e/repo rt/ en g l i sh/ arti c l e s/v o16 7 /IP T2 E 6 7 6 .h tmo

[CMPB03] Casassa Mont, Marco, Pearson, Siani, Bramhall, Pete: Towards Accountable Management of Identity and Privacy: Sticky Policies and Enforceable Tracing Services. Trusted Systems Laboratory, HP Laboratories Bristol, HPL-2003-49; http://WWWohpl.hp~ [DSB03] Entschliel3ung der 65. Konferenz der Datenschutzbeauftragten des Bundes und der L~nder: TCPA darf nicht zur Aushebelung des Datenschutzes missbraucht werden. 27.-28~ M~irz 2003, Dresden; http:// www.datenschutz-berlinode/doc/de/konf/65/top05.htmo [EPAL03] EPAL 1.2, W3C Member Submission. 10. November 2003; http://www.w3.org/Submission/EPAL/. [Heis02] Heise online: Wettbewerb: EU-Kommission will Drucker-Markt untersuchen~ 16. Mai 2002; http:// www.heise.de/newsticker/meldung/27427. [Heis04] Heise online: Aufgedeckt: Trojaner als Spam-Roboter. 21. Februar 2004; http://www.heise.de/newsticker/meldung/44869. [HKK+03] Hansen, Marit, Krasemann, Henry, Krause, Christian, Rost, Martin, Genghini, Riccardo: Identity Management Systems (IMS): Identification and Comparison Study~Sevilla 2003. Verfagbar unter https:// www.datenschutzzentrum.de/projekte/idmanage/study.htmo

220

Auswirkungen von Trusted Computing auf die Privatsph~ire

[HoZu04] Hohl, Adolf, Zugenmaier, Alf: Safeguarding Personal Data with DRM in Pervasive Computing. In: Robinson, Philip; Vogt, Harald; Wagealla, Waleed (Hrsg.): Privacy, Security and Trust within the Context of Pervasive Computing, Proceedings of the Workshop on Security and Privacy in Pervasive Computing 2004, Springer Verlag, 2005; http://www.vs.inf.ethz.ch/events/sppc04/papers/sppc04_hohl.pdf. [HoZu06] Hohl, Adolf, Zugenmaier, All: Safeguarding Personal Data using Rights Management in Pervasive Computing for Distributed Applications. In: Technischer Report der Universit~it Freiburg; http://www. telematik.uni-freiburg.de/opendownloads/hozu06.pdfo [KaSW02] Karjoth, Gtinter, Schunter, Matthias, Waidner, Michael: Platform for Enterprise Privacy Practices: Privacy-enabled Management of Customer Data~ In: 2nd Workshop on Privacy Enhancing Technologies, Lecture Notes in Computer Science, Springer Verlag, 2002; http://www.semper.org/sirene/publ/ KaSWI_02.EP3P4PET.pdf. [PIFK02] Pfitzmann, Andreas, Federrath, Hannes, Kuhn, Markus: Anforderungen an die gesetzliche Regulierung zum Schutz digitaler Inhalte unter Berticksichtigung der Effektivit~it technischer Schutzmechanismen. Studie im Auftrag des Deutschen Multimediaverbandes (dmmv) e.Vound des Verbandes Privater Rundfunk & Telekommunikation (VPRT) e.V., 2002; http://www-sec.uni-regensburg.de/publ/2002/ copyright-studie/PfFK2002Final2002-03-13.pdf. [Pylo03] Pylon: TCPA- Whom do we have to trust today? In den anlfisslich der CCCeBIT am 18. M~irz 2003 vom Chaos Computer Club e.V. an IBM t~berreichten Forderungen zu TCPA; https://www.ccc.de/ digital-rights/forderungen. [Schn05] Schneier, Bruce: Trusted Computing Best Practices. Weblog "Schneier on Security", 31. August 2005; http://www.schneier.com/blog/archives/2005/08/trusted_computi.html. [Scho03] Schoen, Seth: Trusted Computing: Promise and Risk. Electronic Frontier Foundation (EFF), 2003; http://www, eff.org/Infrastructure/trusted_computing/2003100 l_tc.php~ [Schu04] Schulzki-Haddouti, Christiane: EU-Kommission far Banknoten-Kopierschutz. Heise online, 3. Mai 2004; http://www.heise.de/newsticker/meldung/47083 o [Taub03] Taubenheim, Christian: xp-Antispy FAQ. 11. Oktober 2003; http://xp-antispy.org/content/view/7/36/~ [TCG03] Trusted Computing Group: TCG TPM Specification Version 1.2. Verfagbar unter https ://www.trustedcomputinggroup. org/. [TCG05] Trusted Computing Group Best Practices Committee: Design, Implementation, and Usage Principles. Version 2.0, Dezember 2005; https://www.trustedcomputinggroup.org/specs/bestpractices/ Best_Practices_Principles_Document_V2_0.pdf. [TCG07] Trusted Computing Group: Trusted Computing Group Frequently Asked Questions. Mai 2007, https://www.trustedcomputinggroup.org/faq/. [ULD04a] Unabh~ingiges Landeszentrum far Datenschutz (ULD): Trusted Computing. Textziffer 11.2 im 26~ T~itigkeitsbericht, 2004; https://www.datenschutzzentrum.de/material/tb/tb26/kap 11.htm#Tzl 1.2. [ULD04b] Unabh~ingiges Landeszentrum far Datenschutz (ULD): Digital Rights Management. Textziffer 11.3 im 26~ T~ttigkeitsbericht, 2004; https://www.datenschutzzentrum.de/material/tb/tb26/kap11.htm#Tz 11.3. [Wagn05] Wagner, Christian: Spyware/Adware/Malware FAQ. Stand: 10. Oktober 2005; http://www. io.com/-cwagner/spyware.html. [Wiki07] Wikipedia- Die freie Enzyklop~idie: Lizenz/EULA. Zugriff am 19. Juli 2007; http://de.wikipedia.org/ wiki/Lizenz#EULA.

Rechtliche Chancen und Risiken des ,,Trusted Computing" Andreas Neumann Institut fttr das Recht der Netzwirtschaften, Informations- und Kommunikationstechnologie (IRNIK) Postfach 15 01 61, 53040 Bonn [email protected]

Zusammenfassung Als innovative Technologie birgt das ,,Trusted Computing" rechtliche Chancen wie Risiken. Der nachfolgende Beitrag versucht, beide Seiten der juristischen Bilanz aufzuzeigen. Im Ergebnis dt~rften die rechtlichen Chancen, die mit vertrauensw~irdigen Systemumgebungen verknt~pft sind, vor allem dort liegen, wo bestimmte rechtliche Anforderungen an die Systemsicherheit bestehen. Die rechtlichen Risiken liegen demgegent~berprim/~r im wettbewerbsrechtlichen Bereich, da ,,Trusted Computing" zahlreiche M6glichkeiten er6ffnet, um den Wettbewerb auf den M/~rkten der Informations- und Kommunikationstechnologie (IKT) zu beeintr~ichtigen. Gefahren far den Datenschutz und far die Durchsetzung urheberrechtlicher Schrankenbestimmungen sind demgegent~bernut bedingt rechtlich abbildbaro Insgesamt haben die bisherigen Erfahrungen gezeigt, dass die Entwicklung und Implementierung vertrauensw~rdiger Systemumgebungen vor allem durch technische und kommerzielle Interessen getrieben wird, wohingegen der Einfluss der rechtlichen Technikgestaltung als eher gering einzusch~itzen ist.

1 Einleitung Auch wenn das dem englischen Juristen und Philosophen Jeremy Bentham zugeschriebene Zitat, dem zufolge jedes Gesetz eine Verletzung der Freiheit sein soll, nicht berficksichtigt, dass gesetzliche Verhaltensvorgaben gerade auch Freiheitsr~iume schaffen und erhalten, wird hinsichtlich innovativer Technologien der vorgefundene Bestand rechtlicher Vorgaben doch in der Tat regelm/~Big als Behinderung der freien Entwicklung neuer technischer Verfahren und Produkte verstandeno Dieser Erfahrungssatz hat sich auch bei der Diskussion um die Einffihrung vertrauenswttrdiger Systemumgebungen, dem sogenannten ,,Trusted Computing", best/~tigt. Aus juristischer Sicht wurde fast ausschlieBlich auf rechtliche Vorgaben hingewiesen, mit denen ,,Trusted Computing" in der Entwicklung oder Anwendung zu konfligieren droht: von wettbewerbsrechtlichen Vorgaben ffir das Verhalten der beteiligten IKT-Untemehmen t~ber den datenschutzrechtlichen Schutz der Nutzer bis hin zu den urheberrechtlichen Schrankenbestimmungen. Die Chancen, die vertrauenswfirdige Systemumgebungen bieten, wurden demgegenfiber vor allem in rein tats~ichlichen Zusammenh/~ngen gesehen. Dabei kommt dem ,,Trusted Computing" auch aus rechtlicher Sicht ein nicht zu verkennendes Potential zu [Bech05]. Einige dieser rechtlichen Chancen sollen deshalb nachfolgend in konzentrierter Form dargestellt werden (dazu unter 2.), ohne dass insoweit Anspruch auf auch nur basale Vollst~tndigkeit erhoben wfirde, bevor noch einmal kurz die wesentlichen rechtlichen Gefahren zusammengefasst werden, die zurzeit im Zusammenhang mit der Entwicklung und Implementierung vertrauenswt~rdiger Systemumgebungen erkennbar sind (dazu unter 3.). Beide Aspekte werden dann in den gr6geren Zusammenhang einer Technikgestaltung durch Recht eingeordnet (dazu unter 4.). N. Pohlmann, H. Reimer, (Herausgeber): Trusted Computing, Vieweg (2007), 221-235

222

Rechtliche Chancen und Risiken des ,,Trusted Computing"

2 Rechtliche Chancen des ,,Trusted Computing" Aus technischer Sicht besteht das Grundkonzept des ,,Trusted Computing" darin, manipulationsresistente Sicherheitskomponenten in die Hardware zu integrieren, die als vertrauensw~rdige Grundlage far die Sicherheit eines Rechnersystems sorgen, indem s i e - jedenfalls in der Theorie- seine Integrit~it t~berprfifbar machen und seine Authentizit~it garantieren [Bech04]. Hieraus sind verschiedene Anwendungsszenarien ableitbar, in denen vertrauenswfirdige Systemumgebungen Bedeutung erlangen k6nnen. Da sich insoweit die tats~ichliche Entwicklung derzeit nach wie vor erst in einem ganz frfihen Stadium befindet, sind auch die mit diesen Szenarien verknt~pften Chancen aus rechtlicher Sicht erst im Ansatz erkennbar. Ausgehend von den beiden zentralen technischen Konsequenzen - d e r Erm/Sglichung von Systemintegrit~itsprfifungen und der Authentizit~itsgarantie - lassen sich auch die rechtlichen M6glichkeiten, die das ,,Trusted Computing" er6ffnen kann, in zwei hierzu korrespondierende Kategorien unterteilen.

2.1 Schutz von S y s t e m e n Die technische Grundlage aller Anwendungsszenarien, die durch ,,Trusted Computing" erm6glicht werden, liegt letzten Endes in der M6glichkeit der Integrit~itsmessung- und damit auch in der M6glichkeit, Eingriffe in die Integrit~it von Systemen zu erkennen [Bech04][Kuhl04b] [Pfit04]. Diese M6glichkeit besteht zun~ichst far den Nutzer der jeweiligen Plattform selbst und unterstfitzt somit einen sicheren Systembetrieb [Neum05][Weis04] sowie den Schutz vor unbemerkten Eingriffen durch externe Angreifer (Viren, Trojaner, Hackerangriffe etc.) [Bech05][BrRo04]. Daneben wird diese Erkennungsm6glichkeit aber auch Dritten er6ffnet (sog. ,,Attestation", im Folgenden Attestierung genannt) [Bech05][Gras04] [Neum05]. Hinzu kommt sowohl im VerMltnis zum Nutzer der Plattform als auch zu Dritten die primfir softwareseitig zu leistende M6glichkeit einer Abschottung von Speicherbereichen (,,System Compartmentalization") [Bech05], deren rechtliche Chancen ebenfalls primgr im Bereich des Systemschutzes zu verorten sind.

2.1.1 Technische Schutzmal~nahmen Ausdrfickliche gesetzliche Verpflichtungen zur Einhaltung bestimmter technischer Schutzvorgaben finden sich vor allem in w 9 des Bundesdatenschutzgesetzes (BDSG) und in w 109 des Telekommunikationsgesetzes (TKG). Erstgenannte Vorschrift gilt allgemein far alle 6ffentlichen und nicht 6ffentlichen Stellen, die selbst oder im Auftrag personenbezogene Daten erheben, verarbeiten oder nutzen. Nach w 9 S. 1 BDSG mftssen solchen Stellen- und damit der ganz ftberwiegende Teil aller Unternehmen und Beh6rden - u. a. die technischen Mal3nahmen treffen, die erforderlich sind, um die Ausfahrung der Vorschriften des BDSG zu gew~ihrleisten. Hierzu sind in der Anlage zum BDSG acht Schutzanforderungen genannt, die diese abstrakte Vorgabe weiter konkretisiereno Vorgesehen ist in dieser Anlage u. a. eine Zugangskontrolle, mit der verhindert werden soll, dass Datenverarbeitungssysteme von Unbefugten genutzt werden k6nnen. Das kann insbesondere mit Blick auf sensible Daten auch bedeuten, dass entsprechende Systeme wirkungsvoll vor dem Zugriff durch (externe) Dritte gescht~tzt werden mftssen. Die Integrit~itsmessung, die im Rahmen einer vertrauenswftrdigen Systemumgebung m6glich ist, kann dazu beitragen, eine solche unerlaubte Nutzung zu verhindern. Auch die ebenfalls in der Anlage zum BDSG vorgesehene Zugriffskontrolle kann mit Hilfe der ,,Trusted Computing"-Mechanismen auf kostengfmstige Weise technisch wirksam umgesetzt werden: Die Bindung bestimmter Inhalte an eine spezifische Systemintegrit~it und die Abschottung von Speicherbereichen kann verhindern, dass die Nutzer eines Datenverarbeitungssystems aufDaten zugreifen k6nnen, die nicht ihrer Zugriffsberechtigung unterliegen, oder dass personenbezogene Daten bei der Verarbeitung, Nutzung und nach der Speicherung unbefugt gelesen, kopiert, ver~indert oder entfernt werdeno

Rechtliche Chancen und Risiken des ,,Trusted Computing"

223

Angelehnt an die in w 9 BDSG allgemein geltenden Vorgabe werden Anbieter von Telekommunikationsdiensten durch w 109 Abs. 1 TKG zus~itzlich verpflichtet, angemessene technische Vorkehrungen oder sonstige MaBnahmen zum Schutze des Fernmeldegeheimnisses und personenbezogener Daten und zum Schutze der Telekommunikations- und Datenverarbeitungssysteme gegen unerlaubte Zugriffe zu treffen. Die Schutzmechanismen eines ,,Trusted Computing"-Systems k6nnen dazu beitragen, unter Einsatz standardisierter Systemkomponenten diesen sektorspezifischen Schutzanforderungen zu gent~geno Sowohl f~r w 9 BDSG als auch ffir w 109 Abs. 1 TKG gelten zwei grundsgtzliche Feststellungen: Zum einen sind die konkreten Konsequenzen, die aus den allgemein gehaltenen gesetzlichen Vorgaben abzuleiten sind, von den spezifischen Umst~inden des Einzelfalls abh~ingig [GoSc07][Kles06]. Und zum anderen steht der Inhalt beider Verpflichtungen unter einem expliziten Vorbehalt der Angemessenheit, in dessen Rahmen auch der (finanzielle bzw. wirtschaftliche) Aufwand ffir technisch m6gliche SchutzmaBnahmen zu berficksichtigen ist [GoSc07][Kles06]. In diesem Kontext erweist sich, dass die Verffigbarkeit vertrauenswfirdiger Systemumgebungen nicht nur den jeweiligen Verpflichteten die M6glichkeit er6ffnen kann, die gesetzlich vorgesehenen SchutzmaBnahmen verh~iltnism~iBig kostengfinstig umzusetzen. Vielmehr ffthrt die Verffigbarkeit von standardisierten SchutzmaBnahmen auf Grundlage von ,,Trusted Computing"-Funktionalit~iten spiegelbildlich dazu, dass deren Umsetzung in weitaus st~rkerem MaBe noch als angemessen und damit jedenfalls bei Neuanschaffungen von Gesetzes wegen geboten erscheinen wird, als wenn ein vergleichbares Schutzniveau nur unter gr6Berem Kapitaleinsatz erreichbar w~ire.

2.1.2 Einhaltung vertraglicher Nebenpflichten, von Verkehrssicherungspflichten und von Pr~fungspflichten Jenseits des Umgangs mit personenbezogenen Daten bzw. des Angebotes yon Telekommunikationsdiensten spielt die technische Absicherung von Systemen aus rechtlicher Sicht vor allem auch im Rahmen der Haftung nach allgemeinen Regeln eine Rolle, insbesondere also im Rahmen von Schadensersatzsansprfichen, die sich aus dem Bfirgerlichen Gesetzbuch (BGB) ergeben k6nneno Zu einer Verpflichmng zu Schadensersatz kann es - unter bestimmten weiteren Voraussetzungen- u. a. im Rahmen vertraglicher Beziehungen aus der Verletzung entsprechenden Nebenpflichten kommen sowie gegent~ber jedermann aus der Verletzung sogenannter Verkehrssicherungspflichten oder als St6rerhaftung bei einer Verletzung von Prfifungspflichten. Letzten Endes geht es insoweit um eine Produktverantwortung im weiteren Sinne~ Die so definierte Produktverantwortung geht fiber die eng begrenzte Produkthaftung hinaus, die gesetzlich im Produkthaftungsgesetz (ProdHaftG) ausgestaltet isto Diese Produkthaftung ist im vorliegenden Kontext von untergeordnetem Interesse, da sie insbesondere reine Verm6genssch~iden fiberhaupt nicht (w 1 Abs. 1 S. 1 ProdHaftG) und Sachsch~iden im Wesentlichen nur im privaten Bereich erfasst (w 1 Abs. 1 S. 2 ProdHaftG). Der genaue Inhalt der weitergehenden Produktverantwormngspflichten ist i. d. Ro gesetzlich nicht vorgegeben und muss letzten Endes durch die Gerichte konkretisiert werdeno Auch hier spielen Erw~igungen der jeweils gebotenen Sorgfalt eine Rolle sowie die Frage, welche Schutzvorkehrungen bzw. PrfifungsmaBnahmen nach den konkreten Umst~nden erforderlich und zumutbar sind [Hein07][Spra07]~ Insoweit kommt gerade auch den berechtigten Sicherheitserwarmngen der jeweils betroffenen Verkehrskreise eine maBstabsgebende Funktion zu. In der Rechtsprechung wurde insoweit beispielsweise die haftungsausl6sende Verletzung einer Prafungspflicht in dem Fall bejaht, in dem der Betreiber eines funkges~tzten Netzwerks (,,Wireless Local Area Network", WLAN) den Zugang hierzu nicht abgesichert hatte, so dass Dritte Urheberrechtsverletzungen fiber dieses Netzwerk begehen konnten (LG Hamburg, Urt. v. 26.7.2006 - A z . 308 O 407/06).

224

Rechtliche Chancen und Risiken des ,,Trusted Computing"

Im vertraglichen Bereich sind Nebenpflichtverletzungen uo a. flu" den Fall denkbar, dass Daten eines Nutzers auf dem Rechner eines Anbieters gel6scht werden, weil der Anbieter zumutbare Schutzvorkehrungen unterlassen hat und auf diese Weise entsprechende Angriffe externer Dritter erm6glicht wurden. Der Einsatz yon ,,Trusted Computing"-Technologien kann dazu fahren, dass die mal3geblichen Schutzerwartungen insoweit als eingehalten anzusehen sindo Wird durch eine Integrit~itsmessung sichergestellt, dass Dritte nicht in ein System eindringen k6nnen, kann sich der Betreiber des Systems darauf berufen, entsprechende Kontrollmagnahmen vorgenommen zu haben. Selbst wenn Dritten jedoch ein Zugriff auf eine vertrauenswfirdige Systemumgebung gelingen sollte, wird sich der Systembetreiber vor dem Vorwurf einer Pflichtverletzung scht~tzen k6nnen, wenn sein System abgeschottete Speicherbereiche aufweist, so dass der Zugriff auf die dort gespeicherten Daten Dritter auch bei einem erfolgreichen Systemangriff ausgeschlossen wirdo ,,Trusted Computing" kann somit Schutz vor Schadensersatzansprfichen gew~ihren, selbst wenn es im Einzelfall dennoch zu entsprechenden Sch~iden kommen sollte. Auch in diesem Bereich der Haftung nach den allgemeinen Vorschriften zeigt sich jedoch eine gewisse Wechselwirkung zwischen den Vorteilen, die ,,Trusted Computing" den potentiell Schadensersatzpflichtigen als Mittel zur Erfallung ihrer Vorkehrungspflichten bietet, und dem Umfang dieser Pflichten: In dem Mage, in dem die betroffenen Verkehrskreise davon ausgehen dt~rfen, dass Integrit~itsmessung und abgeschottete Speicherbereiche zu den fiblichen Vorkehrungen geh6ren, werden sich die entsprechenden Schutzm6glichkeiten der Betreiber zu Schutzpflichten verdichten.

2.1.3 Einhaltung unternehmerischer Sorgfaltspflichten Die Verpflichtungen, die jedermann nach den allgemeinen Vorschriften treffen k6nnen, werden far unternehmerische T~itigkeiten in bestimmten Vorschriften des Gesellschaftsrechts konkretisiert. So muss ein Gesch~iftsft~rer einer GmbH nach w 43 Abs. 1 des Gesetzes betreffend die Gesellschaften mit beschrgnkter Haftung (GmbHG) in den Angelegenheiten der Gesellschaft die Sorgfalt eines ordentlichen Gesch~iftsmannes anwenden; anderenfalls haftet er der Gesellschaft far den entstandenen Schaden (w 43 Abs~ 2 GmbHG). Entsprechendes gilt far die Vorstandsmitglieder einer Aktiengesellschaft: Nach w 93 Abs. 1 S. 1 des Aktiengesetzes (AktienG) haben sie bei ihrer Gesch~iftsfahrung die Sorgfalt eines ordentlichen und gewissenhaften Gesch~iftsleiters anzuwenden; anderenfalls haften auch sie der Gesellschaft far den entstandenen Schaden (w 93 Abs. 2 S. 1 AktienG). Diese unternehmerischen Sorgfaltspflichten beziehen sich auch auf die Ausgestaltung der gesellschaftseigenen EDV. Im Anwendungsbereich von w 43 GmbHG und w 93 AktienG spiegeln sich somit die rechtlichen M6glichkeiten (und Wechselwirkungen) auf gesellschaftsrechtlicher Ebene wider, die sich durch ,,Trusted Computing" aufEbene der allgemeinen Gesetze ergeben: Wenn durch die Geschfiftsfahrung einer GmbH oder den Vorstand einer Aktiengesellschaft auf den Einsatz von vertrauenswfirdigen Systemumgebungen im eigenen Unternehmen hingewirkt wird, kann so den unternehmerischen Sorgfaltspflichten im Bereich des Schutzes der IKT-Infrastruktur gengge getan werden. Zugleich kann aber auch die zunehmende Verbreitung von ,,Trusted Computing"-Systemen auf mittlere Sicht dazu fahren, dass jedenfalls in Unternehmen, deren Gesch~iftsbetrieb gerade auch den Umgang mit schfttzenswerten Daten umfasst, solche Systeme Einsatz finden mt~ssen oder zumindest ein vergleichbares Sicherheitsniveau sicherzustellen ist.

2.1.4 Urheberrecht Schutzmal3nahmen, die ausschliel31ich dem eigenen (wirtschaftlichen) Interesse dienen, spielen schlieglich im Urheberrecht eine bedeutende Rolle. Durch die M6glichkeit, bestimmte Funktionalitgten an definierte Systemzustgnde zu binden, k6nnen vertrauenswfirdige Systemumgebungen als Grundlage f'~

Rechtliche Chancen und Risiken des ,,Trusted Computing"

225

Mal3nahmen der digitalen Rechteverwaltung verwendet werden (sog. ,,Digital Rights Management", DRM) [BrRo04][Bech04][GKSS04][Gras04] [KoNe04a][Pfit04]. ,,Trusted Computing" kann somit die Entwicklung und den Einsatz wirksamer technischer Maf3nahmen zum Schutz eines nach dem Urheberrechtsgesetz (UrhG) gesch~tzten Werkes (Filme, Musikst(icke, Texte etc.) f'6rdern. Ergreift ein Urheber bzw. Rechtsinhaber solche Mal3nahmen, geniegt er besonderen rechtlichen Schutz, der den ohnehin bestehenden Urheberrechtsschutz flankiert: Nach w 95a Abs. 1 UrhG ist die Umgehung derartiger technischer Mal3nahmen ohne Zustimmung des Rechtsinhabers grunds~.tzlich nicht erlaubt, wenn sie dem Zugang zu einem gesch~tzten Werk oder seiner Nutzung dient. w 95a Abs. 3 UrhG verbietet zusgtzlich diverse Vorbereitungshandlungen, etwa die Herstellung oder den Verkauf von Vorrichtungen, deren Verwendungszweck in der Umgehung wirksamer technischer Mal3nahmen liegt. Ob diese Verbote zugunsten der Rechtsinhaber greifen, h~ingt mal3geblich davon ab, ob die von ihnen getroffenen Mal3nahmen ,,wirksam" sind. Das ist nach w 95 Abs. 2 S. 2 UrhG der Fall, soweit durch die Mal3nahme, bei der es sich z. B. um ,,eine Zugangskontrolle, einen Schutzmechanismus wie Verschlfisselung, Verzerrung oder sonstige Umwandlung oder einen Mechanismus zur Kontrolle der Vervielf'~iltigung" handeln kann, die Nutzung eines geschfitzten Werkes tats~ichlich ,,unter Kontrolle gehalten wird" und wenn die betreffenden Magnahmen die ,,Erreichung des Schutzziels sicherstellen". Bei allen Unklarheiten im Einzelnen kommt es deshalb auf eine gewisse praktische Effektivit~tt der technischen Magnahmen an. Diese kann etwa durch die besonderen Attestierungsmechanismen vertrauenswt~rdiger Systemumgebungen und die Abschottung von Speicherbereichen ggf. sichergestellt werden [Bech04] [Bech05][Gras04][KoNe04a][SaSP04]~

2.2 Authentifizierung elektronischer Transaktionen Neben der Integrit~itsmessung - und z. T. auf ihr aufbauend - erm6glichen vertrauenswttrdige Systemumgebungen aber auch eine in technisch definierten Grenzen sichere Authentifizierung. Dies gilt ohne weiteres dann, wenn dem Gesch~iftspartner die Identit~it des Inhabers der ,,Trusted Computing"Plattform gleichgffltig ist u n d e r nur sicherstellen m6chte, dass diese Plattform bestimmten Konfigurations- und/oder Sicherheitsanforderungen gent~gt [KoNe04a]. Solche Szenarien sind beispielsweise innerhalb einer bereits bestehenden vertraglichen Beziehung oder hinsichtlich solcher Produkte und Dienstleistungen von Relevanz, die im Voraus bezahlt wurden [Neum05]. Fttr daNber hinausgehende elektronische Transaktionen ist neben einer solchen abstrakten Authentifizierung aber in der Praxis vor allem auch die M6glichkeit von Bedeutung, den Inhaber der Plattform sicher identifizieren zu k6nnen. Auch diese konkrete Authentifizierung kann in einer vertrauensw~rdigen Systemumgebung geleistet werden. Grundlage dieser Funktion ist die Einzigartigkeit und strikte Systemgebundenheit, die hinsichtlich des privaten Teils des zentralen Schlfisselpaares (,,Endorsement Key") vorausgesetzt wird [BrRo04] [KoNe04a][Neum05][Pfit04]. Zwar steht sowohl im Rahmen der direkten anonymen Best~itigung als auch bei Einsatz eines Attestierungsidentitgtsschl~ssels (,,Attestation Identity Key") die M6glichkeit einer pseudonymen Nutzung im Vordergrund [Neum05], die zumindest durch den Gesch~iftspartner des Nutzers der ,,Trusted Computing"-Plattform gerade nicht reindividualisiert werden kann [Bech05] [KoNe04a]. Allerdings kann der Nutzer eines solchen Systems den 6ffentlichen Teil des zentralen Schlfisselpaars unmittelbar oder mittelbar - fiber hierauf rfickfahrbare weitere Schl~ssel - dazu verwenden, um sich gegen(iber Dritten als Nutzer der betreffenden Plattform zu identifizieren [Bech05]. Dies er6ffnet aus rechtlicher Sicht neue M6glichkeiten der Teilnahme am elektronischen Gesch~iftsverkehr.

226

Rechtliche Chancen und Risiken des ,,Trusted Computing"

2.2.1 AIIgemeine Identifikationsfunktion Die Abgabe rechtlich beachtlicher Erkl~irungen, die u. a. Voraussetzung ffir den Abschluss von Vertr~igen ist, kann grunds/~tzlich formfrei erfolgen, wenn nicht das Gesetz in besonderen FNlen wegen erh6hter Schutz- und/oder Dokumentationsbedfirftigkeit (etwa bei Vertr/~gen fiber die 12Ibertragung des Eigentums an einem Grundstt~ck, w 311b Abs. 1 S~ 1 BGB, oder bei der Testamentserrichtung, w167 2231 ff. BGB) eine andere Form vorsieht [Hein07]. Der Abschluss solcher Vertr/~ge, die zumindest derzeit den ganz ~berwiegenden Teil der rechtlichen Transaktionen im elektronischen GescMftsverkehr ausmachen, ist hiervon jedoch nicht betroffen. Diese Vertr/~ge k6nnen deshalb i. d. R. auch durch Erkl~irungen abgeschlossen werden, die in einer E-Mail enthalten sind oder die sogar nur in der Bet~itigung einer Schaltfl~iche bzw. im Absenden eines WWW-Formulars zum Ausdruck kommen. Problematisch ist a11erdings, dass unter den bisherigen Bedingungen der Nutzung von Datennetzen der Urheber solcher Erkl~irungen oftmals nicht hinreichend sicher festgestellt werden kann. Dies ist eine erhebliche Belastung ffir den elektronischen Gesch~iftsverkehr. Grunds~itzlich muss ngmlich derjenige, der einen Anspruch geltend macht, die Voraussetzungen daffir darlegen und beweisen, dass dieser Anspruch auch besteht [Reich07]. Kommt es zu einer gerichtlichen Auseinandersetza.mg um den Zahlungsanspruch eines Anbieters von Produkten oder Dienstleistungen, muss dieser also u. a. gerade auch nachweisen, dass der elektronisch erfolgte Aufrag tatsgchlich vonder Person erteilt wurde, die in einer elektronischen Nachricht (E-Mail), einem WWW-Formular oder in einer anderen elektronischen Willenserkl~irung als Besteller angegeben ist. Ob dieser Beweis gelingt, entscheidet nach w 286 Abs. 1 S. 1 der Zivilprozessordnung (ZPO) das Gericht gmndsgtzlich nach ,,freier 12Iberzeugung". Im Rahmen dieser freien Beweiswfirdigung haben sich die deutschen Zivilgerichte aber bislang tendenzieI1 sehr skeptisch gegent~ber der M6glichkeit gezeigt, elektronische Willenserkl~irungen ihrem vermeintlichen Urheber zuzurechnen. So wird etwa far elektronische Nachrichten (E-Mail) von der ganz fiberwiegenden Zahl der Gerichte eine allgemeine Vermutung daf'ar abgelehnt, dass Nachrichten von einer bestimmten Absenderadresse auch tats~ichlich von dem Inhaber der E-Mail-Adresse stammen. Das wird u. a. mit der generell beachtenswerten Einsch~itzung begrfindet, dass der Sicherheitsstandard im Internet derzeit nicht ausreichend sei, um aus der Verwendung eines geheimen Passworts auf denjenigen als Verwender zu schliel3en, dem dieses Passwort ursprfinglich zugeteilt worden ist (OLG K/51n, Urto v. 6.9.2002 - Az. 19 U 16/02). Entsprechende Entscheidungen finden sich f-firandere Identifizierungsmechanismen, die auf einer Kombination aus einem Benutzernamen und einem Passwort beruhen. In diesem Kontext wird u. a. auch auf die Gefahr hingewiesen, dass Passw6rter durch Trojaner ausgesp~iht werden k6nnen (LG Konstanz, Urt. v. 19.4.2002 - Az. 2 0 141/01)~ Der Einsatz yon vertrauenswt~rdigen Systemumgebungen kann zum einen rein faktisch dazu ffihren, dass der Sicherheitsstandard im Internet angehoben und die Bedrohung durch Trojaner verringert wird. Inwieweit dieser Aspekt des ,,Trusted Computing", der letzten Endes dem Systemschutz zuzurechnen ist, Auswirkungen auf das (gerichtliche) Vertrauen in die Sicherheit elektronischer Identifizierungsmechanismen haben wird, dfirfte nicht unerheblich vonder Sicherheit der tats~ichlichen Implementierung in Endnutzerprodukten und von deren Verbreitung abh~ingen. Ob die generelle Skepsis der Rechtsprechung alleine dadurch entfallen wird, dass sich die Sicherheit der Endnutzersysteme im Rahmen des technischen Fortschritts verbessern wird, ist jedoch nicht ohne weiteres zu erwarten, zumal die T~iuschbarkeit des Endnutzers selbst, das sogenannte. ,,Social Engineering", als erheblicher Unsicherheitsfaktor technisch kaum beeinflussbar ist. Die Nutzung von vertrauenswfirdigen Systemumgebungen k6nnte allerdings zum anderen auch dazu ffihren, dass elektronische Willenserkl~irungen mit Hilfe des zentralen Schl~sselpaars gewissermal3en in

Rechtliche Chancen und Risiken des ,,Trusted Computing"

227

dem jeweiligen Endnutzersystem verankert werden. Hierzu mt~ssten entsprechende Authentifizierungsmechanismen etabliert werden, die - etwa in Form einer Signatur [BrRo04] oder unter Einbindung externer Instanzen [BrRo04] - sicherstellen, dass eine Erklgrung auf einem System mit einem bestimmten ,,Endorsement Key" abgegeben wurde. Dann entsprgche die Situation anderen technischen Bereichen, in denen der Zugang zu einem IKT-Netz an einen bestimmten physikalischen Ort gebunden ist, wie z. B. beim frfiheren Bildschirmtextsystem oder auch im klassischen Telefonnetz. Aus einer solchen Bindung an einen bestimmten physikalischen Zugang wird von der Rechtsprechung in diesen FNlen eine tats~ichliche Vermutung dafar abgeleitet, dass auf diesen Zugang zm'fickt'dhrbare Erkl~irungen auch vom Inhaber des jeweiligen Zugangs abgegeben wurden (LG Bonn, Urt. v. 19.12.2003 - A z . 2 0 472/03 mit weiteren Nachweisen). Wegen der Einmaligkeit des zentralen Schlftsselpaares besteht aus rechtlicher Sicht daher eine Chance vertrauenswardiger Systemumgebungen darin, neben der IP-Adresse, die nicht zwingend nur einem einzigen System zuzuordnen ist, ein weiteres physikalisch gebundenes Identifikationsmerkmal far Transaktionen im elektronischen Gesch~iftsverkehr nutzbar zu machen. Neben der Implementierung entsprechender technischer LOsungen setzt dies jedoch auch voraus, dass im Falle einer gerichtlichen Auseinandersetzung die Zuordnung zu einer bestimmten ,,Trusted Computing"-Plattform m6glich ist. Da diese Zuordnung- anders als etwa im Falle von Telefonnummern, IP-Adressen etc. - grundsfitzlich nur mit Hilfe des Inhabers der jeweiligen Plattform erfolgen kann, wenn der entsprechende Mechanismus keine Einbindung einer externen Instanz vorsieht, mt~ssten die Gerichte hier ggf. eine gewisse Mitwirkungspflicht des Plattforminhabers annehmen. Denkbar w~ire etwa die Annahme einer sogenannten sekund~iren Darlegungslast. Bei dieser wfirde es nicht ausreichen, wenn die in Anspruch genommene Person lediglich bestreitet, dass sie Inhaber des Rechnersystems mit dem betreffenden Schlfisselpaar ist. Vielmehr mfisste sie die Informationen zu dem Schlt~sselpaar ihrer ,,Trusted Computing"-Plattform selbst zur Verfagung stellen. Sollten sich die Gerichte nicht zu einer solchen Verteilung der Darlegungs- und Beweislast bewegen lassen, bliebe der Mehrwert far den elektronischen Gesch~iftsverkehr gering und auf solche FNle beschr~inkt, in denen der Anbieter bereits vor der umstrittenen Auftragserteilung in Gesch~iftskontakt mit dem betreffenden Nutzer stand. In diesen FNlen verfagt der Anbieter ggf. aufgrund frttherer Transaktionen bereits fiber die notwendigen Informationen, um die Zuordnung zu einer bestimmten ,,Trusted Computing"-Plattform selbst vorzunehmen. Auch dies wird jedoch i. d. R. mal3geblich von der konkreten technischen Implementierung abh~ingen und mit erheblichen Unsicherheitsfaktoren behaftet sein.

2.2.2 Besondere Identifikationsfunktion: elektronische Form Die Schwierigkeiten, die an der Schnittstelle zwischen modernen IKT-Netzen und den rechtlichen Beweisnotwendigkeiten bestehen, haben allerdings bereits zu gesetzgeberischen Mal3nahmen gefahrt. Mit der elektronischen Form ist eine rechtliche Form far Willenserkl~irungen geschaffen worden, die spezifisch auf die technischen Rahmenbedingungen des elektronischen Gesch~iftsverkehrs Bezug nimmt. Sie ist allerdings ihrerseits technisch so voraussetzungsvoll, dass s i e - von wenigen Ausnahmen abgesehen - gesetzlich weitgehend der Schriftform gleichgestellt ist (w 126a Abs. 1 BGB), in der selbst besonders sensible Rechtsgesch~ifte abgeschlossen werden k6nnen. Die elektronische Form geht dabei mit erheblichen Beweiserleichterungen zugunsten des Erkl~irungsempf~ingers gegen•ber formlosen Erkl~irungen einher [Hein07]. Die elektronische Form ist jedoch nur gewahrt, wenn die elektronische Erkl~irung mit einer qualifizierten elektronischen Signatur nach dem Signaturgesetz (SigG) versehen ist. Solche Signaturen mfissen u. a~ ,,mit einer sicheren Signaturerstellungseinheit erzeugt werden" (w 2 Nr. 3 lit. b SigG). FOr die Erfallung dieser Anforderung k6nnen die besonderen technischen Funktionen vertrauenswttrdiger Systemumgebungen genutzt werden [Bech05]: Namentlich durch die Integrit~itsmessung und die Abschottung von Speicherbereichen kann die Sicherheit einer Signaturerstellungseinheit gew~ihrleistet werden.

228

Rechtliche Chancen und Risiken des ,,Trusted Computing"

Allerdings betrifft dies erneut nur den Aspekt des Systemschutzes, der ~berdies zu keinen rechtlichen Konsequenzen fahrt, die spezifisch Nr vertrauenswttrdige Systemumgebungen wgren. Die besonderen Funktionalit~iten von ,,Trusted Computing" dienen hier nur der technischen Unterstatzung von Identifikationsmechanismen im elektronischen Gesch~tftsverkehr und erNllen damit selbst keine Identifikationsfunktion.

3 Rechtliche Risiken des ,,Trusted Computing" W~ihrend die rechtlichen Chancen des ,,Trusted Computing" prim~ir durch die jeweiligen Funktionalit~iten dieser Technologie charakterisiert werden, was eine entsprechende Kategorisierung nahe legt, lassen sich die rechtlichen Risiken, die von der Entwicklung und Implementierung vertrauenswt~rdiger Systemumgebungen ausgehen, eher anhand der potentiell betroffenen Schutzgfiter erfassen.

3.1 Datenschutzrecht Das Datenschutzrecht schfttzt die informationelle Selbstbestimmung, also die aus dem Gedanken der Selbstbestimmung folgende Befugnis des Einzelnen, grunds~itzlich selbst zu entscheiden, wann und innerhalb welcher Grenzen pers6nliche Lebenssachverhalte offenbart werden. Die datenschutzrechtlichen Bedenken gegen~ber ,,Trusted Computing"-Systemen ergeben sich, soweit sie noch von aktueller Relevanz sind, vor diesem Hintergrund vor allem aus der potentiellen Komplexit~it vertrauenswftrdiger Systemumgebungen und der MOglichkeit der Attestierung bestimmter Systemzust~inde gegent~ber externen Nachfragern [Hans04][Pfit04][Weis04]: Hier droht - rein faktisch - die Kenntnisnahme personenbezogener Daten durch Dritte ohne Einwilligung des betroffenen Nutzers und ohne sonstige Rechtsgrundlage und damit zugleich ein Verstof3 gegen w 4 Abs. 1 BDSG. Insoweit ist allerdings zu berficksichtigen, dass das allgemeine Datenschutzrecht ausweislich der Erlaubnistatbest~inde in w167 28 ft. BDSG den Umgang mit personenbezogenen Daten in erheblichem Umfang auf Grundlage einer Abw~igung der - berechtigten bzw. schutzwttrdigen- Interessen der datenverarbeitenden Stelle einerseits und des Betroffenen andererseits zul~isst. Eine pauschale Aussage, welche konkreten Datenverarbeitungsvorggnge im Rahmen nicht n~iher definierter ,,Trusted Computing"-Anwendungsszenarien nicht nur aus datenschutzpolitischen Grt'mden unerwfinscht, sondern darfiber hinaus auch datenschutzrechtlich unzul~issig sind, ist demzufolge kaum m6glich.

3.2 Wettbewerbsrecht Die Entwicklung und Implementierung vertrauenswfirdiger Systemumgebungen betrifft allerdings nicht nur den einzelnen Nutzer, sondern mit der IKT-Industrie die Schl~isselbranche moderner Industrie- bzw. Informationsgesellschaften, die einen erheblichen Beitrag zu der volkswirtschaftlichen Wertsch6pfung leistet. Da nach europ~iischem und deutschem Ordnungsverst~indnis der wettbewerbliche Auswahlprozess wohlfahrtsoptimierend wirkt, Wettbewerb also die volkswirtschaftlich w~nschenswertesten Ergebnisse erzielt, ist dessen Schutz gerade in einem derart bedeutsamen Sektor von besonderer Relevanz. Damit ist aus rechtlicher Sicht das Wettbewerbsrecht angesprochen, das insbesondere in Art. 81, 82 des EG-Vertrages und auf nationaler Ebene in w167 1, 19 und 20 des Gesetzes gegen Wettbewerbsbeschrgnkungen (GWB) den Wettbewerb vor Beeintr~ichtigungen und Verfiilschungen schfitzt. Dieser Schutz richtet sich zum einen gegen Gefahren, die von kollektiven Magnahmen mehrerer Unternehmen ausgehen (Kartellverbot, Art. 81 EG, w 1 GWB), zum anderen aber auch gegen Gefahren, die von einer besonders fiberm~ichtigen Marktposition ausgehen (Missbrauchsverbot, Art. 82 EG, w167 19, 20 GWB). ,,Trusted Computing" berfihrt beide Aspekte.

Rechtliche Chancen und Risiken des ,,Trusted Computing"

229

Kartellisierungseffekte drohen insbesondere bei der Entwicklung der technischen Standards im Rahmen der Trusted Computing Group (TCG)~ Mitglieder der TCG geniegen einen privilegierten Zugriff auf die (auch k~inftigen) technischen Spezifikationen vertrauenswttrdiger Systemumgebungen und auf die zu ihrer Implementierung erforderlichen Schutzrechte (Patente) [KoNe04a][Neum05]. Unternehmen, die nicht Mitglieder der TCG sind, sehen sich deshalb jedenfalls in dem Moment einem erheblichen Wettbewerbsnachteil ausgesetzt, in dem sich vertrauenswfirdige Systemumgebungen am Markt durchgesetzt haben und die Einhaltung der entsprechenden Standards zu einem entscheidenden Wettbewerbsfaktor wird [KoNe04a][KoNe04b]. Vor diesem Hintergrund mfissen zumindest die Bedingungen, zu denen die Mitgliedschaft zur TCG er6ffnet wird, gesteigerten wettbewerbsrechtlichen Ansprachen gent~gen [KoNe04a][KoNe04b][Neum05]. Wettbewerbsrechtlich kaum reversibel dt~rfte schliel31ich die Tatsache sein, dass wesentliche Standardisierungsentscheidungen durch die kleine Gruppe der TCG-Grfindungsmitglieder getroffen wurden [KoNe04a][KoNe04b] [Neum05]o Darfiber hinaus besteht aber auch die Gefahr einer Beeintr~ichtigung des Wettbewerbs durch die Ausnutzung einer fiberm~tchtigen Marktposition, also durch den Missbrauch einer marktbeherrschenden Stellungo Dies gilt zun~ichst allgemein vor dem Hintergrund der M6glichkeit, Daten an bestimmte Systemzust~inde zu binden. Hierdurch wird die M6glichkeit geschaffen, die Datenbest~inde der Anwender an bestimmte Hardwarekonfigurationen, bestimmte Betriebssysteme oder bestimmte Applikationen zu binden. Insbesondere Unternehmen, die ohnehin keinem wirksamen Wettbewerb ausgesetzt sind, h~itten auch erhebliche Anreize, ihre marktbeherrschenden Stellungen auf diese Weise zu festigen. Durch ,,Trusted Computing" k6nnten sie entsprechende Produktbindungen der Anwender (Pfadabh~ingigkeiten) erheblich verst~irken [Bech04][Bech05][KoNe04b]. Vor allem aber ist auf den Softwarem~irkten mit Microsoft ein Unternehmen t~itig, das jedenfalls auf dem Markt fill" PC-Betriebssysteme t~ber eine beherrschende Stellung verffigt und fiberdies in erheblichem Mage vertikal integriert ist, also auch auf nachgelagerten Applikationsm~irkten t~itig ist, auf denen es mit anderen Anbietern konkurriert. Das ffihrt u. ao zu besonderen M6glichkeiten und Anreizen, den Zugang solcher Wettbewerber auf den Applikationsmgrkten zu den ,,Trusted Computing"spezifischen Schnittstellen des Betriebssystems zu beschr~inken [KoNe04a][KoNe04b]o Darfiber hinaus ist die TCG wegen der herausgehobenen Marktpr~isenz von ,,Windows" auf eine Unterstfitzung der ,,Trusted Computing"-Funktionen durch Microsoft faktisch angewiesen, so dass Microsoft m6glicherweise in der Lage ist, als Mitglied der TCG den dortigen Standardisierungsprozess einseitig zugunsten eigener Interessen zu steuern [KoNe04a][KoNe04b][Neum05]. Und schliel31ich kann die im Rahmen einer vertrauenswfirdigen Systemumgebung notwendige Verschr~inkung mit Betriebssystemfunktionalit~tten dazu fahren, dasses im Hinblick auf die Umsetzung einer digitalen Rechteverwaltung (DRM) zu neuen Interdependenzen zwischen Microsoft und den Anbietern von Inhalten kommto Diese k6nnten wiederum Aussperrungseffekte zulasten kleinerer Applikations- und Inhalteanbieter zur Folge haben [KoNe04a][KoNe04b]. Bietet Microsoft selbst Inhalte an, besteht auch insoweit das besondere Diskriminierungspotential vertikaler Integration [Bech05].

3.3 Urheberrecht Obwohl das Urheberrecht von seinem Grundansatz der rechtlichen Monopolisierung der Werknutzung eigentlich den Interessen der Rechtsinhaber dient, gestaltet es zugleich die Grenzen dieser Monopolisierung aus und dient insoweit der Durchsetzung potentiell konfligierender Interessen [Gras04]. Diese ,,Schranken des Urheberrechts" sind in w167 44a ffo UrhG normiert. Sie erlauben u. a. bestimmte Werknutzungen zugunsten der Rechtspflege, zugunsten behinderter Menschen, zugunsten von Sammlungen ffir Kirchen-, Schul- oder Unterrichtsgebrauch, zugunsten von Zeitungsartikeln und Rundfunkkommentaren sowie zugunsten des privaten und sonstigen eigenen Gebrauchs.

230

Rechtliche Chancen und Risiken des ,,Trusted Computing"

Vertrauenswttrdige Systemumgebungen k6nnen es technisch unm6glich machen, dass diese Schranken und damit die dahinter stehenden Nutzungsinteressen tats~ichlich durchgesetzt werden k6nnen [Gras04] [SaSP04]. So kann insbesondere die Bindung von Inhalten an einen spezifischen Systemzustand einer konkreten ,,Trusted Computing"-Plattform dazu Nhren, dass diese nicht migrierbaren Inhalte digital nicht vervielf~iltigt oder auch nur fibertragen werden k6nnen [Bech04][Bech05]o Hierbei handelt es sich aber letztlich um ein generelles Spannungsverh~ilmis zwischen den Schrankenbestimmungen des w 53 UrhG einerseits und dem Schutz technischer Mal3nahmen nach w 95a UrhG andererseits [Bech04] [Bech05]. Das Gesetz trifft hier in w 95b UrhG eine Ausgleichsregelung, die eine Durchsetzung der meisten Schrankenbestimmungen auch gegenfiber technischen Schutzmal3nahmen vorsieht [Bech05]. Diese Regelung sieht aber (derzeit) ein Zurficktreten einzelner Schrankenbestimmungen vor, etwa der Vervielf~iltigung zum eigenen Gebrauch (,,Privatkopie") jenseits photomechanischer oder ~ihnlicher Vervielf'~iltigungsverfahren (w 95b Abs~ 1 Nr. 6 lit. a UrhG). Diese rechtliche Einschrgnkung der urheberrechtlichen Schrankenbestimmungen kann durch vertrauenswfirdige Systemumgebungen praktische Wirksamkeit erfahren.

4 M6glichkeiten und Grenzen einer rechtlichen T e c h n ik g e s t a l t u n g Die spezielle Frage nach den rechtlichen Chancen und Risiken des ,,Trusted Computing" betrifft nicht lediglich einen konkreten technischen Einzelfall. Sie kann vielmehr vor dem Hintergrund der fiber den konkreten Fall weit hinausgehenden allgemeinen Frage nach M6glichkeiten und Grenzen einer rechtlichen Technikgestaltung gesehen werden [Bech05], wurde die Entwicklung vertrauenswfirdiger Systemumgebungen doch schon zu einem verh~iltnism~igig frtthen Zeitpunkt durch eine rechtswissenschaftliche und rechtspolitische Debatte begleitet.

4.1 Mechanismen der rechtlichen Technikgestaltung Rechtliche Technikgestaltung ist dabei zun~ichst selbst ein wenig konturierter Begriffo Grunds~itzlich entfaltet Recht bereits vor seiner reaktiven Durchsetzung p e r s e auch eine in die Zukunft gerichtete Gestaltungswirkung: Gesetzliche Vorgaben beanspruchen allgemeine Geltung, so dass bereits ihre bloge Existenz auch technische Entwicklungen beeinflusst. Dies gilt in negativer wie in positiver Hinsicht: Negative Gestaltungswirkung entfalten Rechtsnormen dann, wenn sie bestimmte Verhaltensweisen oder Zust~inde verbieten. So enthglt beispielsweise das Gesetz fiber die elektromagnetische Vertr~iglichkeit von Ger~iten (EMVG) bestimmte Vorgaben zur Einhaltung basaler elektromagnetischer Schutzanforderungen (w 3 Abs. 1 EMVG). Werden diese Vorgaben nicht eingehalten, dfirfen die entsprechenden Ger~ite nicht in Verkehr gebracht werden. Diese Vorschriften entfalten ganz offensichtlich bereits im Bereich der Technikgestaltung eine erhebliche Steuerungswirkung. Aber die allgemeinen Gesetze k6nnen auch eine positive Gestaltungswirkung entfalten. Das betrifft die F~ille, in denen an die Einhaltung bestimmter allgemeiner Vorgaben rechtliche Vorteile geknfipft sind. Auch hierffir kann das EMVG ein anschauliches Beispiel liefem: Nach w 3 Abs. 2 Nr. 1 EMVG wird die Einhaltung der gesetzlichen Schutzvorgaben uo a. ffir solche Ger~ite vermutet, die mit den auf das jeweilige Ger~it anwendbaren harmonisierten europ~iischen Normen t~bereinstimmen. Dies setzt einen positiven Anreiz ffir Ger~itehersteller, bei der technischen Gestaltung ihrer Ger~ite auf solche technischen Normen zurfickzugreifen. Aber auch jenseits solcher direkten positiven Anreize k6nnen sich aus allgemeinen gesetzlichen Vorgaben positive Gestaltungsanreize ergeben: So legen etwa die gesetzlichen Vorgaben aus w 9 BDSG und w 109 TKG eine Berficksichtigung der dort vorgesehenen technischen

Rechtliche Chancen und Risiken des ,,Trusted Computing"

231

Schutzanforderungen schon bei der Gestaltung entsprechender technischer Ger~ite nahe (siehe dazu ausfahrlich oben unter 2o1.1)~ Von allgemeinen Rechtsvorschriften k6nnen darfiber hinaus aber auch gleichermagen positive wie negative Anreize ffir die Technikgestaltung ausgehen~ Ein praktisch besonders relevantes Beispiel hierffir bilden die gesetzlichen Sorgfaltspflichten und Verkehrssicherungspflichten, die sich im vorliegend interessierenden Kontext als rechtliche Normierung einer allgemeinen Produktverantwortung darstellen (dazu oben unter 2.1.2). Negative Anreize gehen von diesen Vorschriften aus, da Herstellern wirtschaftliche Nachteile (in Form einer Schadensersatzzahlung) drohen, wenn sie durch ihre Technikgestaltung der entsprechenden Produktverantwortung nicht gent~gen. Da der genaue Inhalt solcher Pflichten i. d. R. erst nachtr~iglich im Einzelfall - durch die Gerichte - konkretisiert wird, wird zugleich ein positiver Anreiz geschaffen, den berechtigten Verkehrserwartungen bereits durch die Produktgestaltung selbst zu gent~gen. Angesichts der Unbestimmtheit dieser rechtlichen Pflichten sind allerdings auch derartige positive Gestaltungsanreize mit einem nicht zu vemachl~issigenden Unw~igbarkeitsrisiko behafteto In gewissem Umfang kann diese Unsicherheit durch eine vertragliche Risikoverteilung beseitigt werden. So kann z~ B. die Haftung durch eine vertragliche Vereinbarung in gewissem Umfang ausgeschlossen werden, wenn bestimmte technische Standards eingehalten werdeno Ein solches Vorgehen w~ire im Ansatz auch hinsichtlich der TCG-Spezifikationen denkbar, durch deren korrekte Einhaltung sich ein Hersteller von einer Haftung ffir korrespondierende Sicherheitsrisiken in gewissem Umfang freizeichnen k6nnte. Dies w~ire freilich nicht prim~tr als Technikgestaltung in dem Sinne zu verstehen, dass technologische Entwicklungen durch rechtliche Vorgaben beeinflusst werden. Vielmehr ginge es in erster Linie um die Auswahl zwischen verschiedenen bereits existierenden Technologien, also um die rechtlichen Vorteile einer bestimmten Technologiewahl~ Aul3erdem bliebe der Effekt einer derartigen rechtlichen Produktgestaltung begrenzt: Sie kann fiberhaupt nur dort Wirkung entfalten, wo eine vertragliche Sonderbeziehung zwischen dem Hersteller und dem potentiell Gesch~idigten besteht. Verkehrssicherungspflichten gegen~iber beliebigen Dritten k6nnen durch eine derartige Risikoverteilung in vertraglichen Regelungen grunds~itzlich nicht modifiziert werden, also insbesondere auch nicht in Allgemeinen Gesch~iftsbedingungen (AGB). Daraber hinaus setzt das Zivilrecht der Modifikation der allgemeinen Haftungsmagst~ibe aber auch in vertraglichen Sonderbeziehungen Grenzen. Allgemein kann man sich vonder Haftung ffir eine vors~itzliche Schadenszuffigung nicht im Voraus freizeichnen (w 276 Abs. 3 BGB). Viel bedeutsamer ffir die typischen Massengesch~ifte des Alltags ist aber, dass in AGB auch die Haftung ffir grobe Fahrl~issigkeit grunds~itzlich nicht ausgeschlossen werden kann (w 309 Nr. 7 lit. b BGB)~ Ob Sch~iden, zu denen es trotz des Einsatzes von ,,Trusted Computing"-Technologien kommt, auf einer groben Fahrl~issigkeit des Herstellers beruhen, ist aber wiederum eine Frage, die der nachtr~iglichen (gerichtlichen) Konkretisierung im Einzelfall unterliegt. Unzul~issig w~ire es jedenfalls, in AGB - oder auch individualvertraglich -jegliche Produktverantwortung auf die Nichteinhaltung bestimmter technischer Vorgaben zu beschr~inken. Die gesetzlichen Verhaltensmagst~ibe stehen insoweit nicht zur Disposition der technischen Normung. ,,Code" ist eben nicht ,,Law". Das herstellerseitige Bekenntnis, eine bestimmte Technologie korrekt zu implementieren, ist vor diesem Hintergrund weniger von rechtlichem Mehrwert als eine vertrauensbildende Mal3nahme gegent~ber den (potentiellen) Kunden. Diesen wird mit der herstellerseitigen Zusicherung, sich an bestimmte technische Vorgaben zu halten, ein konkreter Referenzmal3stab an die Hand gegeben~ Ist dieser Referenzmal3stab vertrauenswfirdig- was bereits das terminologisch erkl~irte Ziel der TCG-Technologie ist-, kann so ein wichtigerfaktischer Beitrag zur Akzeptanz des Einsatzes von IT-Technologie auch in sensiblen Anwendungsszenarien geleistet werden~ Hierin liegt sicherlich eine groge Chance der ,,Trusted Computing"Technologie, die allerdings nicht in erster Linie in rechtlichen Koordinaten abgebildet werden kann.

232

Rechtliche Chancen und Risiken des ,,Trusted Computing"

Jenseits dieser allgemeinen Technik- und Produktgestaltung durch gesetzliche Vorgaben kann das Recht Technik aber auch ganz konkret gestalteno Denkbar sind bier Regelungen, die sich spezifisch auf konkrete technologische Vorgaben beziehen. Dies geschieht nur selten in Form allgemeiner Vorgaben auf Gesetzesebene, wobei dann zumeist auch lediglich normative Kompatibilit~itsanreize zugunsten bereits vorgefundener Technologien geschaffen werden [KoLN03]. Vielmehr werden Maf3nahmen der konkreten rechtlichen Technikgestaltung in der Regel durch beh6rdliche Entscheidungen getroffen~ So kann beispielsweise die Bundesnetzagentur mittels einer Technischen Richtlinie technische Einzelheiten festlegen, die von den Betreibern von Telekommunikationsanlagen bei der technischen Umsetzung von 121berwachungsmaf3nahmen einzuhalten sind (w 110 Abs. 3 S. 1 TKG). Ein weiteres Beispiel for konkrete administrative Vorgaben flu" die Gestaltung technischer Einrichtungen findet sich im Gebiet der Funkfrequenzverwaltung, auf dem u. a. die Kommission der Europgischen Gemeinschaften auf Grundlage von Art. 4 der Frequenzentscheidung 676/2002/EG z. T. detaillierte Vorgaben for einzelne Parameter der Frequenznutzung durch entsprechende Gergte macht, etwa hinsichtlich der in bestimmten Frequenzbereichen durch Ultrabreitbandgergte einzuhaltenden Signalstgrken. Nicht ganz ausgeschlossen, im Rahmen des europgischen Binnenmarktes und weltweiter Handelsbeziehungen in den IKT-M~trkten aber nicht sonderlich praxisrelevant ist schliel31ich die M6glichkeit administrativer Technikgestaltung durch Importbestimmungen [GKSS04]. Alle der vorgenannten Formen der rechtlichen Technikgestaltung basieren auf der Vorgabe verbindlicher rechtlicher Verhaltensregeln. Dieser Aspekt der Technikgestalmng entspricht dem tradierten Verst~indnis rechtlicher Steuerungswirkung. Gerade im Bereich der rechtlichen Technikgestaltung wird diese Steuerungswirkung jedoch zunehmend auch im eher rechtspolitischen Bereich gesehen. Eine solche rechtliche Technikgestaltung kann insbesondere darin bestehen, die Wertungen hinter den gesetzlichen Vorgaben for die Gestaltung technischer Entwicklungen nutzbar zu machen [Bech05]o Dies geht t~ber die ohnehin erforderliche Konkretisierung rechtlicher Vorgaben for den jeweiligen technischen Einzelfall noch deutlich hinaus. Durch eine solche proaktive Technikgestaltung wird sichergestellt, dass Technik auch in den Bereichen, die bislang noch nicht Gegenstand rechtlicher Normierung sind, den gmnds~itzlichen Wertungen der jeweiligen Rechtsordnung entspricht, etwa indem den Belangen des Datenschutzes oder der urheberrechtlichen Schrankenbestimmungen bereits im Rahmen der Produktgestaltung Rechnung getragen wurde. Dieser Ansatz rechtlicher Technikgestaltung ist eher dialogischer Natur und erfordert eine enge Zusammenarbeit zwischen Technikem und Juristen [Bech05]. Anders als rechtlich bindende Vorgaben in hoheitlichen Akten der Gesetzgebung oder der Exekutive steht ein solcher Ansatz rechtlicher Technikgestaltung vor allem auch auf3erhalb demokratischer Legitimationszusammenh~inge, so dass er eher als pragmatischer Ansatz denn als Verwirklichung des demokratischen Willensbildungsprozesses in innovativen M~irkten einzustufen ist. Die Annahme, Technik und Recht seien zumindest teilweise substituierbar [Bech05], erweist sich vor diesem Hintergrund m6glicherweise als etwas zu pragmatisch. Ein Kompromiss zwischen Pragmatik und Legitimation k6nnte insoweit in einer frOhzeitigen Einbindung staatlicher Stellen liegen, etwa im Zuge der Aufnahme von behOrdlichen Vorermittlungen durch Wettbewerbs- oder DatenschutzbehOrden [Neum05].

4.2 Erfahrungen im Fall der vertrauenswLirdigen

Systemumgebungen

Im besonderen Anwendungsfall der vertrauenswOrdigen Systemumgebungen haben die rechtlichen Vorgaben insbesondere hinsichtlich des Datenschutzes erhebliche Auswirkungen auf die Gestaltung der technischen Spezifikationen gehabt- und zwar auf allen Ebenen der rechtlichen Technikgestaltung. Von Anfang an war konzeptionell die M6glichkeit vorgesehen, dass jeder lokale Nutzer einer Plattform

Rechtliche Chancen und Risiken des ,,Trusted Computing"

233

das ,,Trusted Platform Module", und damit den zentralen Anker jeder vertrauenswfirdigen Systemumgebung, deaktivieren kann, um so dem Nutzer die letzte Entscheidung fiber den Zugriff auf seine Daten und deren Nutzung zu belassen [Pfit04]. Dass vertrauenswfirdige Systemumgebungen sich im Prinzip anonym bzw. pseudonym authentifizieren, nicht aber identifizieren sollen, ist ebenfalls eine grundlegende Systementscheidung, die mit Blick auf Datenschutzbelange getroffen wurde [Bech05]. Abet auch im Laufe der 6ffentlichen Diskussion ~iber die rechtlichen Risiken des ,,Trusted Computing" entfaltete das Datenschutzrecht bzw. der Datenschutz die st~irkste Wirkmacht [BrRo04]o So war beispielsweise die Einffihrung der M6glichkeit einer direkter anonymen Bestgtigung eine unmittelbare Reaktion auf Bedenken hinsichtlich m6glicherweise unzuI~inglicher Datenschutzvorkehrungen [Kurs04][Neum05]. Diese besondere Bedeutung, die der Datenschutz bei der Entwicklung vertrauenswfirdiger Systemumgebungen bislang erfahren hat, steht nicht nur in einem gewissen Widerspruch zu der generell eher untergeordneten Rolle, die dem Schutz personenbezogener Daten in den real existierenden IKT-Umgebungen trotz anspruchsvoller gesetzlicher Vorgaben zukommt. Sie lgsst sich auch durch die technischen Gegebenheiten nur schwer rechtfertigen, da die datenschutzrechtlichen Risiken letzten Endes keinen spezifischen Bezug zum ,,Trusted Computing" haben. So ist es beispielsweise far die Gefahr far die informationelle Selbstbestimmung v611igunerheblich, ob die M6glichkeit, pseudonyme Identit~iten aufzudecken, bei Authentifizierungsinstanzen besteht, die im Kontext vertrauenswfirdiger Systemumgebungen operieren, oder ob andere Stellen in Transaktionsnetzwerken fiber entsprechende Missbrauchsbzw. Erkennmism6glichkeiten verffigen - wie z. B. Zugangsanbieter, Abrechnungsdienstleister oder auch grol3e Plattformbetreiber. Dass der Datenschutz im Falle der vertrauenswfirdigen Systemumgebungen dennoch erhebliche technikgestaltende Kraft entfalten konnte, dfirfte neben einer gewissen Offentlichkeitswirksamkeit des Themas nicht zuletzt auch darin begrt~ndet sein, dass das Vertrauen der Nutzer in eine datenschutzfreundliche Gestaltung als Voraussetzung far einen kommerziellen Erfolg entsprechender Anwendungsszenarien empfunden wird [Neum05]. Es besteht somit ein eigener Anreiz der Anbieter von ,,Trusted Computing"-Produkten, diese datenschutzfreundlich zu gestalten. Auch dieser kommerzielle Anreiz zur datenschutzfreundlichen Technikgestaltung ist jedoch kein Spezifikum vertrauensw~rdiger Systemumgebungeno Weitaus weniger Konsequenzen hatten bislang indes die Bedenken, die gegenfiber der Entwicklung und Implementierung vertrauenswfirdiger Systemumgebungen aus urheber- und wettbewerbsrechtlicher Sicht vorgebracht wurden. Nennenswerte prozedurale oder konzeptionelle Anpassungen, die auf entsprechende Einw~inde zurfickgeftthrt werden k6nnten, sind praktisch nicht ersichtlich. Die einzigen Ausnahmen darften insoweit in der Schaffung von Regeln ffir die rechtzeitige Ver6ffentlichung neuer Spezifikationsentwfirfe [Kuhl04b], in der Verabschiedung unverbindlicher Verhaltensregeln durch die TCG [Bech05] und in einer geringfagigen Anderung der Voraussetzungen ffir eine Mitgliedschaft in der TCG zu sehen sein. Hier wurde innerhalb der unteren Mitgliedschaftskategorie (,,Adopter Members") eine besondere Mitgliedschaftsoption far Untemehmen mit weniger als 100 Angestellten geschaffen (,,Small Adopters") [Bech05], mit der die vorher bestehende erhebliche Benachteiligung kleinerer und mittlerer Unternehmen zumindest partiell verringert wurde [Neum05]. Unabhgngig vonder Frage, ob die Zahl der Angestellten fiberhaupt ein aus wettbewerbsrechtlicher Sicht taugliches Kriterium ist, k6nnen hierdurch die grunds~itzlichen wettbewerbsrechtlichen Bedenken auch gegenfiber der TCG nicht ausger~iumt werden [Neum05], zumal die Mitgliedschaftsrechte der unteren Mitgliedschaftskategorie nach wie vor sehr beschrgnkt sind- und die Mitgliedsgebfihren im l~rigen weiter angehoben wurden, insbesondere also auch far die h6heren (und hinsichtlich ihrer Einfluss- und Einblicknahmem6glichkeiten interessanteren) Mitgliedschaftskategorien.

234

Rechtliche Chancen und Risiken des ,,Trusted Computing"

5 Fazit ,,Trusted Computing" bietet aus rechtlicher Sicht vor allem dort Chancen, wo die Sicherheit technischer Systeme eine besondere Rolle spielt. Geht es dabei um eine entsprechende Verantwortlichkeit, die den Systembetreiber gegent~ber Dritten trifft, besteht jedoch eine bemerkenswerte Wechselwirkung: Der Einsatz vertrauenswfirdiger Systemumgebungen erweist sich zun~ichst als besondere Schutzmal3nahme, auf die sich der Betreiber des jeweiligen Systems hinsichtlich der ihn treffenden Verpflichtungen berufen kann. Mittelfristig kann jedoch auf diese Weise der Einsatz yon ,,Trusted Computing"-Technologie selbst verkehrs~blich werden. Aus rechtlicher Sicht kann dann das besondere Sicherheitsniveau, das durch den Einsatz von vertrauenswfirdigen Systemumgebungen erm6glicht wird, selbst zum Mal3stab far normgerechtes Verhalten werden. Jenseits des Systemschutzes sind die unmittelbaren rechtlichen Chancen, die ,,Trusted Computing" er6ffnet, demgegent~ber derzeit als t~berschaubar einzusch~itzen. Insbesondere wird der elektronische Gesch~iftsverkehr voraussichtlich prim~ir vonder M6glichkeit profitieren, die Nutzung digitaler Inhalte von bestimmten Systemzust~inden abh~ingig zu machen. Das Problem der Gew~ihrleistung rechtssicherer Kundenkontakte wird ,,Trusted Computing" alleine jedoch voraussichtlich nicht 16sen k6nnen~ Der Schwerpunkt der origin~tr rechtlichen Risiken vertrauenswt~rdiger Systemumgebungen liegt im wettbewerbsrechtlichen Bereich. Als potentielle Grundlage einer kfmftigen Informationsgesellschaft kumulieren bei ,,Trusted Computing" wettbewerbsrechtliche Gefahren, die f'~ IKT-M~irkte typisch sind [Bech05]. Insbesondere die Standardisierungsdebatte und die Schnittstellenproblematik gewinnen durch die Tgtigkeit der TCG und durch die Implementierung von ,,Trusted Computing"-Elementen in das marktbeherrschende PC-Betriebssystem neue rechtswissenschaftliche Relevanz. Obwohl die Verbreitung vertrauenswfirdiger Systemumgebungen darfiber hinaus erhebliche tatsgchliche Implikationen far den Datenschutz und auch far die urheberrechtlichen Schrankenbestimmungen haben kann, handelt es sich hierbei demgegent~ber nicht vorwiegend um rechtliche Risiken. Vielmehr werden hier grunds~itzliche Interessenkonflikte offenbar, die auch Gegenstand der rechtspolitischen Diskussion um Inhalt und Dichte der jeweiligen gesetzlichen Grundlagen sind, dort aber bereits normativen Ausdruck gefunden haben. Hier aktualisieren sich somit lediglich die gesetzlichen Wertungen, droht aber kein spezifischer Verstol3 gegen rechtliche Vorgaben. Als ein Beispiel ffir rechtliche Technikgestaltung kann ,,Trusted Computing" vor diesem Hintergrund nur in sehr engen Grenzen dienen. Das gilt gleichermagen in positiver wie in negativer Hinsicht. So haben die Anreize far die Entwicklung und Implementierung vertrauenswfirdiger Systemumgebung ihren Ursprung in allererster Linie im rein tats~ichlichen Bedfirfnis nach einer Verbesserung der allgemeinen Systemsicherheit [Kuhl04a] und in den darauf aufbauenden kommerziellen Interessen [Neum05]. Rechtliche Vorteile, die mit dem Einsatz entsprechender Systeme genutzt werden k6nnten, sind demgegent~ber bislang nicht als zentraler Treiber der ,,Trusted Computing"-Entwicklung hervorgetreten. Darfiber hinaus waren rechtliche Einfl~sse aber auch far die Implementierung technologieimmanenter Beschr~inkungen von nur untergeordneter Bedeutung. Sowohl im Bereich des Datenschutzes als auch des Wettbewerbsrechts blieb die Steuerungswirkung der rechtlichen Vorgaben in erster Linie auf symbolhafte Konsequenzen beschr~inkt. Dabei d~rften ~berdies insbesondere aus Datenschutzsicht erhebliche kommerzielle Anreize zur Erh6hung der Produktakzeptanz die rechtliche Steuerungswirkung ~berlagert haben.

Rechtliche Chancen und Risiken des ,,Trusted Computing"

235

Literatur [Bech05]

Bechtold, Stefan: Trusted Computing: rechtliche Probleme einer entstehenden Technologie. In: Preprints of the Max Planck Institute for Research on Collective Goods, 2005.

[Bech04]

Bechtold, Stefan: Trusted Computing Initiatives - Protecting Virtual Troy or Creating a Trojan Horse? In: Koenig/Neumann/Katzschmann: Trusted Computing, Verlag Recht und Wirtschaft, 2004, S. 77-99~

[BrRo04]

Brandl, Hans und Rosteck, Thomas: Technik, Implementierung und Anwendung des Trusted Computing Group-Standards (TCG). In: Datenschutz und Datensicherheit 2004, S. 529-538~

[GKSS04] Gt~nnewig, Dirk, Rannenberg, Kai, Sadeghi, Ahmad-Reza und Stable, Christian: Trusted Computing Platforms- Zur technischen und industriepolitischen Situation und Vorgehensweise. In: Koenig/Neumann/Katzschmann: Trusted Computing, Verlag Recht und Wirtschaft, 2004, S~ 154-162. [GoSc07] Gola, Peter und Schomerus, Rudolf: BDSG - Bundesdatenschutzgesetz, 9. Auflage, Verlag C. H. Beck, 2007. [Gras04]

Grassmuck, Volker: Vom PC zum TC - Trusted Computing und Digital Restrictions Management. In: Koenig/Neumann/Katzschmann: Trusted Computing, Verlag Recht und Wirtschaft, 2004, S. 143-153.

[Hans04]

Hansen, Markus: A Double-Edged Blade. In: Datenschutz und Datensicherheit 2004, S. 525-528.

[Hein07]

Heinrichs, Helmut: Kommentierungen zu w167 125, 126a, 242 BGB. In: Palandt: Bt~rgerliches Gesetzbuch, 66. Auflage, Verlag C. H. Beck, 2007.

[Kles06]

Klesczewski, Diethelm: Kommentierung zu w 109 TKG. In: S~icker: Berliner Kommentar zum Telekommunikationsgesetz, Frankfurt am Main, 2006.

[KoLN03] Koenig, Christian, Loetz, Sascha und Neumann, Andreas: Innovation im SpannungsverhNmis von Markt und Regulierung. In: Klumpp/Kubicek/Rof3nagel: next generation information society?, M6ssingen-Talheim, 2003, S. 403-412o [KoNe04a] Koenig, Christian und Neumann, Andreas: Wettbewerbsrechtliche Aspekte vertrauensw~irdiger Systemumgebungen. In: Koenig/Neumann/Katzschmann: Trusted Computing, Verlag Recht und Wirtschaft, 2004, S. 100-140. [KoNe04b] Koenig, Christian und Neumann, Andreas: Neue wettbewerbspolitische und rechtliche Entwicklungen zum ,,Trusted Computing". In: Datenschutz und Datensicherheit 2004, S. 555-560. [Kuhl04a] Kuhlmann, Dirk: Open Trusted Computing als technopolitische Herausforderung. In: Koenig/Neumann/Katzschmann: Trusted Computing, Verlag Recht und Wirtschaft, 2004, S. 163-179~ [Kuhl04b] Kuhlmann, Dirk: Vertrauenssache Trusted Computing. In: Datenschutz und Datensicherheit 2004, S. 545-547. [Kurs04]

Kursawe, Klaus: Ausblick aufTPM 1.2. In: Koenig/Neumann/Katzschmann: Trusted Computing, Verlag Recht und Wirtschaft, 2004, S. 70-74.

[Neum05] Neumann, Andreas: Entwicklung einer IT-Sicherheitsarchitektur im Wege koordinativer Standardisierung. In: Taeger/Wiebe: Mobilit~it - Telematik - Recht, K61n, 2005, S~ 187-217~ [Pfit04]

Pfitzner, Roy: TCPA, Palladium und DRM - Technische Analyse und Aspekte des Datenschutzes. In: Koenig/Neumann/Katzschmann: Trusted Computing, Verlag Recht und Wirtschaft, 2004, S. 29-60~

[Reich07] Reichold, Klaus: Vorbemerkung zu w 284 ZPO. In: Thomas/Putzo, Zivilprozessordnung, 28. Auflage, Verlag C. H. Beck, 2007. [SaSP04]

Sadeghi, Ahmad-Reza, S~ble, Christian und Pohlmann, Norbert: European Multilateral Secure Computing Base. In: Datenschutz und Datensicherheit 2004, S. 548-554o

[Spra07]

Sprau, Hartwig: Kommentierung zu w 823 BGB. In: Palandt: Bfirgerliches Gesetzbuch, 66. Auflage, Verlag C. H. Beck, 2007.

[Weis04]

Weis, Rt~diger: Schlt~sselfragen zu ,,Trusted Computing". In: Koenig/Neumann/Katzschmann: Trusted Computing, Verlag Recht und Wirtschafl, 2004, S. 61-69.

Biographien der Autoren

A m m a r Alkassar ist Vorstandsvorsitzender des Kryptospezialisten Sirrix AG, Saarbrtickeno Er studierte Informatik und Nachrichtentechnik an der Universit/~t des Saarlandes und schloss sein Doppelstudium mit den Schwerpunkten Sicherheit und Kryptographie ab und wurde for seine Abschlussarbeit mit dem VDI-Saar ausgezeichnet~ Herr Alkassar hatte mehrere Forschungsaufenthalte u.a. am Stevens Institut of Technology, NJ sowie an der Technical University of Helsinki (HUT). Herr Alkassar ist Herausgeber und Autor zahlreicher Publikationen und Studien. Hierzu geh6ren die BSI-Studien zu Kommunikations- und Sicherheitstrends 2010+3 und VoIPSEC 2005. Ammar Alkassar ist General Chair der Sicherheit 2008 und geh6rt als Fachexperte dem Leitungsgremium des Fachbereichs Sicherheit der Gesellschaft fi~ Informatik ano Dr. Gunter Bitz (CISSP) ist derzeit fOr die Entwicklung der Sicherheitsstrategie der SAP Produkte und den Schutz firmeninterner Informationen verantwortlich. Andrey Bogdanov studierte Informationssicherheit, theoretische Informatik und Mathematik an der Russischen Staatlichen Universit~it Moskau, an der Humboldt-Universit~it zu Berlin und an der Universit~it Duisburg-Essen. Seit 2005 ist er als Mitarbeiter bei der escrypt- Embedded Security GmbH t~itig. Seit 2006 promoviert er am Lehrstuhl fOr Kommunikationssicherheit der RuhrUniversit~it Bochumo Hans Brandl befasst sich seit 1984 mit der Realisierung yon Sicherheitsl6sungen und der Anwendung yon Kryptographie, zllerst bei der Siemens AG fOr Beh6rdenanwendungen und ab 1998 bei Infineon Technologies im Bereich Chipkarten und Sicherheits-ICs. Im Rahmen des Technischen Marketing ist er dort for Trusted Computing und andere Sicherheits-ICs zust~indig. Er halt in der TCG die Funktion des Co-Chair des Certification Programm Committees (CPC), das derzeit Prozeduren fOr die l]berprfifung yon Produkten nach dem TCG-Standard und die Einhaltung yon Compliance (l]bereinstimmung mit der Spezifikation) und Conformance (ErfOllung der Sicherheitsanforderungen gem~iB dem Common Criteria Protection Profiles) erarbeitet und einfohrt. Dr. Markus Diirig: Nach dem Studium der Rechtswissenschaften 1992 Eintritt in das Bundesministerium des Innern, 2002 Obernahme der Leitung des Referates IS 4 - ,Angelegenheiten des Verfassungsschutzes im Bereich Linksextremismus, Geheimschutz, nationale Sicherheitsbeh6rde", seit 2006 Leiter des Referates IT 3 -,,Sicherheit in der Informationstechnik"

238

Biographien der Autoren

Thomas Eisenbarth studierte Elektrotechnik und Informationstechnik an der Ruhr-Universit/~t Bochum und an der Technischen Universit~it yon Navarra, Spanien. Seit 2006 promoviert er am Lehrstuhl fOr Kommunikationssicherheit der Ruhr-Universit~it Bochum. Florian Gawlas, Dr. rer. nat, ist seit 2001 bei der Giesecke & Devrient GmbH in Mfinchen besch/iftigt. In seiner Position als Smart Card Security Consultant ist er verantwortlich for die DurchfOhrung der Sicherheitsevaluierungen yon Smart Card Produkten. AuBerdem repr~isentiert er Giesecke & Devrient in nationalen und intemationalen Experten- und Standardisierungsgremien wie z.B. in Eurosmart und der Trusted Computing Group. David Grawrock is a Senior Principle Engineer and Security Architect for the Initiatives, Technology Pathfinding and Planning group. His role is the End to End security architect for the Digital Enterprise Group~ David continues as the LaGrande Technology lead security architect. Outside of Intel David is the Chair of the Trusted Computing Group TPM workgroup and Intel's representative to the TCG Technical Committee. David has worked in the computer industry for 28 years holding positions with Central Point Software, Symantec, and Lotus. David is the holder of 20 patents with many more pending. David does have a life outside of Intel; he is a proud father and husband, dedicated soccer coach, fly fisherman, and long suffering family genealogist. Marit Hansen beendete 1995 das Studium der Informatik an der Christian-Albrechts-Universit~it zu Kiel mit dem Diplom. Seitdem ist sie verantwortlich for den Bereich ,,Privacy-Enhancing Technologies" beim Unabh~ingigen Landeszentrum for Datenschutz Schleswig-Holstein (ULD) und hat Projekte zu Anonymit~it, Biometrie, P3P, Datenschutz-Giitesiegel sowie das Vimtelle Datenschutzbfiro betreut. Zurzeit leitet sie das Innovationszentrum Datenschutz 8: Datensicherheit ( U L D - i - http://www.uld-i.de/). Ihre Arbeitsschwerpunkte sind Privacy-Enhancing Technologies, Identit~itsmanagement, Anonymit~it, Pseudonymit~it, Datensicherheit und technischer Datenschutz sowie Privacy Seals.

Markus Hansen ist seit 1997 beim UnabMngigen Landeszentrum for Datenschutz Schleswig-Holstein (ULD) im Technikbereich t/itig. Zu seinen Schwerpunkten z/ihlt es, neue Technologien wie Trusted Computing, DRM, RFID und VolP und deren Auswirkungen auf Datenschutz und Datensicherheit zu analysieren. Er ist Mitautor der BMBF-Studie TAUCIS zu Ubiquitous Computing und war im Rahmen des Projektes SPIT-AL an der Konzeption und Entwicklung eines datenschutzgerechten Filters gegen SPIT (SPAM over Internet Telephony) beteiligt. Michael Hartmann ist bei der SAP AG zust/~ndig fOr die externen Kommunikationsprozesse des SAP CERT und fOr den Aufbau eines Product Security Bulletin Service. FOr TeleTrusT ist er als Leiter der AG ,,Personal Security Environment-PSE" t~itig. Niklas Heibel hat das Diplom des Ingenieurs in Gelsenkirchen im Bereich Mikroinformatik abgeschlossen. Seit 2005 arbeitet er am Institm fOr Internet-Sicherheit an der Fachhochschule Gelsenkirchen als wissenschaftlicher Mitarbeiter im Bereich Trusted Computing. Axel Heider, Diplom Informatiker, begann 2005 als Diplomand bei Giesecke & Devrient. Nach seinem Abschluss an der TU Miinchen befasst er sich heute im Bereich Forschung und Entwicklung mit der Entwicklung yon Chipkarten der n/~chsten Generation und deren Einsatzgebieten sowie dem Trusted Computing.

Biographien der Autoren

239

Marian Jungbauer studiert Angewandte Informatik an der FH Gelsenkirchen mit dem Studienschwerpunkt Internet und mobile Netzeo Im Rahmen seiner Diplomarbeit forscht er im Bereich ,,Integrit~itsprfifung entfernter Rechnersysteme". Peter Kraaibeek studierte Elektrotechnik mit dem Schwerpunkt Nachrichtentechnik in Mfinster. Er arbeitet seit 1983 an der Entwicklung bzw. Anwendung yon IT-Systemen (embedded systems, Entwicklung Betriebssysteme) und deren Infrastrukturen, seit 1989 ist sein Arbeitsschwerpunkt die IT-Sicherheito Seit 2002 ist er bei der secunet Security Networks besch~ifligto Hans Marcus Kriiger studierte von 2000 bis 2007 an der TU Dresden Diplominformatik mit den Vertiefungsrichtungen Betriebssysteme und Kryptographie. Seit 2001 ist er bei der secunet Security Networks AG besch~iftigt. Sein Aufgabenbereich ist insbesondere die Entwicklung und Implementierung yon hochsicheren Systemen. Nicolai Kuntze schloss das Studium der Informatik an der Technischen Universit~it Darmstadt im FrOhjahr 2005 ab. Daran anschliel3end nahm er seine Arbeit als Wissenschaftler am Fraunhofer-Institut fOr sichere Informationstechnologie SIT auf, an dem er mit einem Schwerpunkt im Bereich mobiler Systeme forscht. Sein Hauptarbeitsgebiet besteht im Einsatz yon Trusted Computing in mobilen Szenarien.

Markus Linnemann hat das Diplom der Informatik in Gelsenkirchen im Bereich Identity Management abgeschlossen. Seit 2005 arbeitet er am Institut fOr Internet-Sicherheit an der Fachhochschule Gelsenkirchen als wissenschaftlicher Mitarbeiter im Bereich Trusted Computing. Dr. Kai Martius studierte und promovierte an der TU Dresden im Bereich Nachrichtentechnik / Informationstechnik. W~ihrend und nach seinem Studium besch~iftigte er sich bereits mit InternetSicherheitstechnologien, insbesondere IPSec und war mehrere Jahre in der IETF aktiv. Seit 1999 ist er bei der Firma secunet Security Networks AG t~itig, zun~ichst in der Entwicklung und Projektleitung for die Hochsicherheitsarchitektur SINA, seit 2007 leitet er den Gesch~iftsbereich Hochsicherheit. Gisela Meister, Dr. rero nat, studierte Mathematik und Volkswirtschaft an der Universit~it Mfinster. Seit Ende 1989 arbeitet sie als Sicherheitsexpertin in der Division fOr Chipkarten bei Giesecke & Devrient Mtinchen. Sie ist sowohl Leiterin der Abteilung ,,Sicherheit und Evaluierung" als auch verantwortlich fOr die Koordinierung der Standardisierung von Giesecke & Devrient. Gisela Meister ist Mitglied nationaler und internationaler Standardisierungsgruppen und koordiniert nationale und europ~iische Standards. Sie ist z.B. Obmann des DIN NI 17.4- ,,Austauschprotokolle bei Chip-Karten" und Vorsitzende des europ~iischen Standardisierungsgremiums CEN TC224 WG 16 fOr PKI. 2004 wurde sie mit dem SIT Fraunhofer Smart Card Preis ausgezeichnet. Andreas Neumann: Stadium der Rechtswissenschaften an der Philipps-Universit~it Marburg, danach t~itig an der Forschungsstelle for Rechtsinformatik der Philipps-Universitgt Marburg und von 1999 bis Ende 2006 wissenschaftlicher Mitarbeiter am Zentrum for Europ~iische Integrationsforschung (ZEI) der Rheinischen Friedrich-Wilhelms-Universit~it Bonn, zuletzt als Leiter der Forschungsgruppe Telekommunikationsrecht, seitdem ,,Senior Fellow" am ZEI. Seit 2006 Rechtsanwalt in Bonn in der Kanzlei Koch & Neumann und gesch~iftsfohrender Direktor des Instituts fOr das Recht der Netzwirtschaften, Informations- und Kommunikationstechnologie.

240

Biographien der Autoren

Christof Paar ist Inhaber des Lehrstuhls fOr Kommunikationssicherheit am Bochumer Eurobits-Kompetenzzentrum fOr IT-Sicherheit. Von 1994 bis 2001 war er als Professor am Worcester Polytechnic Institute in Massachusetts (USA) t~itig. Er besch~iftigt sich seit tiber fonfzehn Jahren mit Embedded Security und ist Mitbegrfinder des CHES (Cryptographic Hardware and Embedded Systems) und ESCAR Workshops (Embedded Security in Cars). DarOber hinaus ist er Gesch~iftsftihrer der escrypt- Embedded Security GmbH. Norbert Pohlmann ist seit 2003 Informatikprofessor fOr Verteilte Systeme und Informationssicherheit

im Fachbereich Informatik und gesch~iftsfohrender Direktor des Instituts for Internet-Sicherheit an der Fachhochschule Gelsenkirchen (www.internet-sicherheit.de). Vorher war er yon 1988 bis 1999 gescMftsfOhrender Gesellschafter der Firma KryptoKom, Gesellschaft fOr kryptographische Informationssicherheit und Kommunikationstechnologie mbH. Nach der Fusion der KryptoKom mit der Utimaco Safeware war er yon 1999 bis 2003 Mitglied des Vorstandes der Utimaco Safeware AG. Seit April 1997 ist Prof. Pohlmann Vorstandsvorsitzender von TeleTmsT e.V., der sich zur Aufgabe die Etabliemng yon vertrauenswfirdigen IT-Systemen gemacht hat (www~ teletrust.de). Prof. Pohlmann ist Mitinitiator und Vorsitzender des Programmkomitees der ,,Information Security Solutions Europe"-Konferenz (ISSE), die j~ihrlich in unterschiedlichen europNschen St~idten (Berlin, Barcelona, London, Paris, Wien, Berlin, Budapest, Rom, Warschau) stattfindet. AuBerdem ist Prof. Pohlmann Mitglied der ,,Permanent Stakeholders' Group" der ENISA (European Network and Information Security Agency), die Sicherheitsagentur der europ/~ischen Gemeinschaft (www.enisa.europa.eu) und Mitglied des wissenschaftlichen Beirates der GDD (Gesellschaft fOr Datenschutz und Datensicherung e.V.). Zahlreiche Fachartikel und mehrere Bticher, Vortr~ige und Seminare auf dem Gebiet der Informationssicherheit dokumentieren seine Fachkompetenz und sein Engagement auf dem Gebiet IT-Sicherheit. Helmut Reimer studierte an der Technischen Universit~it Ilmenau und promovierte sich 1964 zum Dr.-Ing. Von 1971 bis 1990 war er dort Universit~itsprofessor for Mikroelektronik. Daneben war seit 1980 auch in der Mikroelektronik-Industrie t~itig und ab 1991 Leiter eines MikroprozessorEntwicklungsbereiches. Von 1992 bis 2007 war Helmut Reimer Gesch~tftsfohrer von TeleTrusT Deutschland e.V. In dieser Zeit hat er den Verein zur F6rderung der VertrauenswOrdigkeit von Informations- und Kommunikationstechnik zum Kompetenzverbund fOr Angewandte Kryptographie und Biometrie profiliert. Sein besonderes Augenmerk lag auf der FOrderung von interdisziplin~iren Aktivit~iten im Zusammenhang mit regulatorischen Rahmenbedingungen for IT-Sicherheitstechnologien. Seit 1999 hat er als Mitinitiator der EuropNschen IT-Sicherheitskonferenz ISSE und Organisation der Beteiligung von TeleTrusT an den RSA-Konferenzen in den USA maBgeblich zum internationalen Dialog der IT-Sicherheitsexperten beigetrageno Helmut Reimer ist Mitherausgeber der Fachzeitschrift ,Datenschutz und Datensicherheit (DUD)' des Verlages Vieweg und zahlreicher Publikationen. Sebastian Rohr ist Chief Security Advisor bei der Microsoft GmbH und betreut Kunden hinsichtlich ihrer Sicherheitsstrategie, dem Datenschutz und den technischen MOglichkeiten zur Umsetzung yon organisatorischen Policies. Er ist seit 1998 als Netzwerk- und Sicherheitsspezialist t~ttig und hNt regelm~il3ig Vortr~ige und Vorlesungen zur Netzwerktechnik, zur IT-Sicherheit und Mobilfunksicherheito Vor seiner T~itigkeit for Microsoft war er als strategischer Sicherheitsberater bei CA und der Siemens AG sowie als Wissenschaftlicher Mitarbeiter und Doktorand am Fraunhofer Institut for Sichere Informationstechnologie besch~iftigt.

Biographien der Autoren

241

Thomas Rosteck ist nach seiner T~itigkeit in der Siemens Unternehmensberatung seit 1999 bei Infineon Technologies fth" Sicherheitsthemen verantwortlich. In seiner Verantwortung far Infineon's Trusted Computing Aktivit~iten h~ilt er seit 2005 einen Sitz im Board of Directors der TCG. Zurzeit ist er als Vice President ADS Security Solutions far die Entwicklung und Vermarktung yon Trusted Computing L6sungen sowie far kundenspezifischen Sicherheitsl6sungen verantwortlich. Carlos Rozas is a Senior Staff Security Researcher in Intel's Trust & Identity Lab. He leads the research efforts in combining virtualization and trusted computing to improve platform trustworthiness. Carlos has worked for 12 years in the computer industry with prior experience in content protection, tamper resistant software, and run-time software integrity. Carlos has a BS in Computer Engineering and Mathematics and a MS in Computer Engineering from the University of Michigan. Vinnie Scarlata is a Senior Security Researcher in Intel's Trust and Identity Lab. Vinnie's research focus is on measurement, attestation, and the TPM use in apply to virtualized environments. He has worked for 5 years in the industry after receiving a BS in Computer Science from the University of Massachusetts, Amherst and an MS in Information Security from Georgia Institute of Technology. Andreas U. Schmidt studierte Mathematik und Physik an der Johann-Wolfgang Goethe Universit~it Frankfurt am Main und promovierte dort 1999 mit einer Arbeit aus der mathematischen Physik. Forschungsaufenthalte fahrten ihn far zwei Jahre nach Durban, Siidafrika und Pisa. Er arbeitet nun als Wissenschaftler am Fraunhofer-Institut far sichere Informationstechnologie SIT. Er koordiniert die Trusted Computing Aktivit~iten des SIT. Seine Haupt-Arbeitsgebiete sind Anwendungen yon Trusted Computing und die Langzeit-Sicherheit elektronisch signierter Dokumente, sowie Fragen der Internet- und Informations6konomie. Mehr Informationen unter http://www. math.uni-frankfurt.de/-aschmidt. Christian Stable arbeitet seit 1996 im Bereich IT-Sicherheit mit dem Schwerpunkt Betriebssysteme und vertrauenswfirdige Rechnersysteme. Nach dem Studium der Informatik in Hildesheim und Dortmund schloss er Mitte 2000 dieses mit einer Arbeit fiber sichere mobile Endbenutzerger~ite ab und initiierte bzw. leitete danach an der Universit~it des Saarlandes am Lehrstuhl far Sicherheit und Kryptographie von Prof. Dr. Birgit Pfitzmann das PERSEUS Projekt. Seit Mitte 2003 leitet Herr Stiible den Bereich ,,Verl~issliche IT-Systeme" der Sirrix AG. Herr Sttible ist technischer Gesamtprojektleiter des EMSCB-Projektes und verantwortet den far dieses Vorhaben relevanten technischen Teil des OPEN-TC Projektes im Auftrage der Ruhr-Universit~it Bochum. Claire Vishik received her PhD from the Univeristy of Texas at Austin. She studied electronic commerce, security, and networking technologies in Schlumberger Research Labs, AT&T (SBc) Labs and now at Intel. Claire is the author of many papers and 20+ current and pending US patents. Sebastian Wallner, Dr.-Ing studierte Informatik und Ingenieurswissenschaffen an der Universitgt Hamburg und der Technischen Universit~it Hamburg-Harburg. Er ist seit 2006 bei der Giesecke & Devrient GmbH in Miinchen als Systemarchitekt in der Business Line ,,Secure Embedded Solution" besch~iftigt. Sebastian Wallner repr~isentiert Giesecke & Devrient in nationalen und internationalen Experten- und Standardisierungsgremien z.B. der Trusted Computing Group. Er ist Autor yon zahlreichen wissenschaftlichen Beitr~igen im Bereich ,,Eingebettete Sicherheit".

242

Biographien der Autoren

Bernhard Weiss schloss das Studium der Nachrichtentechnik (TH) an der Universit~tt-Gesamthochschule Siegen im Jahr 1995, einschlieglich eines einj~ihrigen Auslandsaufenthaltes an der University of Nottingham, als Diplom-Ingenieur ab. Im direkten Anschluss wechselte er zur KryptoKom GmbH, welches nun Teil der Utimaco Safeware AG ist. Im Rahmen seiner T~itigkeiten bei zwei der f'tihrenden Unternehmen im IT-Security Bereich war er als Berater, Schulungsleiter, IT Projektmanager sowie im Bereich Design und Entwicklung von IT-Security L6sungen t~itig. Als Projektverantwortlicher in komplexen nationalen und internationalen Projekten zeichnete er fi.tr die Konzeption, Entwicklung, Aufbau und Inbetriebnahme von Firewall- und VPN-L6sungen, Public-Key-Infrastrukturen (PKI), Security Gateway und Payment L6sungen, L6sungen auf Basis der Hardware-Sicherheitsmodul Technologie sowie Signaturl6sungen ffir die elektronische Rechnungsstellung (eInvoice) verantwortlich. Zahlreiche Seminare und Schulungen, die Mitarbeit in den verschiedenen nationalen und internationalen Gremien wie TeleTrust, Bitkom, CEN/ ISSS, UNECE-CEFACT, sowie Vortr~ige bei nationalen und internationalen Kongressen und Messen belegen sein umfangreiches Fachwissen. Monty Wiseman is currently a Security Architect for Intel's Digital Enterprise Group~ His current projects include architecture for TCG, Intel's LaGrande Technologies and other security initiatives. Monty chairs the TCG PC Client working group which defines how the TPM attaches to the PC Client Platform. He is also involved in the TCG Server and Conformance working groups and the Technical Committee. Monty has 20 years experience in Desktop, Network and Mainframe environments holding security related and other engineering positions at Novell, Fujitsu, and Control Data. Monty has been developing hardware and software for computers ranging from mainframe to microcomputers since 1975. Marko Wolf smdierte Elektrotechnik und Informationstechnik mit dem Nebenfach Informatik an der

Purdue University, USA und an der Ruhr-Universit~it Bochum. Seit 2005 promoviert er am Lehrstuhl ffir Kommunikationssicherheit der Ruhr-Universit~it und ist zudem als Berater ffir die escr y p t - Embedded Security GmbH t~itig.

Glossar Attestation Mit Hilfe der Attestierung kann der Zustand eines Rechnersystems fiberprfift werden. So kann vor dem Versand von Daten an ein anderes Rechnersystem zum einen sichergestellt werden, dass dieses Rechnersystem wirklich das System ist, was es vorgibt zu seino Zum anderen kann ftberprfift werden, ob die Konfiguration der Hard- und Software die gewfinschte Vertrauenswfirdigkeit besitzt.

Attestation Identity Key (AIK) Der Attestation Identity Key (AIK) ist ein von einem TPM erzeugtes Schltisselpaar, das zur Beglaubigung der Vertrauenswfirdigkeit gegenfiber Dritten genutzt und dessen 6ffentlicher Teil an diese weitergegeben wird. Es sind keine Rackschlasse auf den Endorsement Key m6glich, aus dem es erzeugt wurde. 2048 Bit RSA Schltisselpaar (6ffentlich/privat) mit einem fixierten 6ffentlichen Exponenten (e = 216 + 1). Jeder Besitzer des TPMs erzeugt den AIK neu. Dieses Schlfisselpaar ist nicht migrierbaro

Authenticated Boot Beim Start eines Rechnersystems wird die Konfiguration beginnend beim BIOS, der Hardware und des Bootloaders gemessen. Anschliegend fibemimmt dieser den Messvorgang auf Sicherheitsplattformoder Betriebssystemebene. Wird bei einer auff~illigen Konfiguration der Startvorgang nicht abgebrochen (Secure Boot) sondern fortgesetzt, aber eine Information fiber den nicht einwandfreien Startvorgang gegeben, spricht man von Authenticated oder Trusted Boot~

Binding Das TPM kann Schlftssel auch aul3erhalb des Trust Storage (im TPM), z.Bo auf der Festplatte speichem. Diese werden ebenfalls in einem Schlfissel-Baum organisiert und deren Wurzel mit einem Key im TPM verschlfisselt. Somit ist die Anzahl der sicher gespeicherten Schlfissel nahezu unbegrenzt.

Core Root of Trust for Measurement (CRTM) Die erste Instanz, die unmittelbar zu Beginn des Bootvorgangs eingreift, ist das Core Root of Trust for Measurement (CRTM), das zusammen mit dem TPM den Trusted Building Block (TBB) bildet~ Der CRTM ist ein ausR~hrbarer Code, der einen Messvorgang fiber einzelne Systemzust~inde durchffihrt und dann die Ergebnisse in den PCR hinterlegto

Direct Anonymous Attestation (DAA) Die Direct Anonymous Attestation bietet dieselbe Funktionalit~t wie die Remote Attestation, mit dem Unterschied, dass hier bei der Attestierung keine dritte Instanz ben6tigt wird. DAA wurde durch die TCG mit der TPM-Spezifikation 1.2 eingeffthrto

244

Glossar

EMSCB Das Ziel des EMSCB-Projekts (European Multilaterally Secure Computing Base) ist, basierend auf Trusted Computing Technologie, die Entwicklung einer vertrauenswfirdigen Sicherheitsplattform mit offenen Standards. Das EMSCB Projekt wird durch das Bundesministerium fOr Wirtschaft und Technologie gef6rdert und besteht aus einem Konsortium aus deutschen Hochschulen (Institut fOr IntemetSicherheit der FH Gelsenkirchen, Ruhr-Universit~it Bochum und TU Dresden) sowie aus Firmen (escrypt GmbH und Sirrix AG). Als strategische Firmenpartner sind SAP und Bosch~laupunkt mit vonder Partie.

Endorsement Key (EK) Schltisselpaar im TPM: Bei dem Endorsement Key (EK) handelt es sich um ein RSA-Schlfisselpaar (2048-Bit), das dem TPM eindeutig zugeordnet ist. Das heif3t, dass tiber diesen Key ein bestimmtes TPM eindeutig identifiziert werden kann. Aus Sicherheitsgrfinden verl~isst dieser Schlt'~ssel nie das TPM. Mit Hilfe des EKs werden die Attestation Identify Keys erzeugt.

Endorsement Zertifikat Dieses Zertifikat best~itigt die Echtheit des TPM. Genau genommen wird sichergestellt, dass das TPM yon einem autorisierten Hersteller bereitgestellt wurde.

Enterprise Rights Management (ERM) ERM sorgt dafor, dass gesch~iftskritische Informationen nur nach vorgegebenen Regeln von den deftnierten Akteuren auf definierten Rechnersystemen eingesehen oder bearbeitet werden k6nnen~ Daten wie Dokumente k6nnen durch ERM in ihrer Verwendung eingeschr~inkt werden. So kann beispielsweise ein Ausdrucken oder ein Weiterversenden fiber E-Mail von Daten eingeschr~inkt werden~

Fritz Chip Synonym fOr das TPM. Entstanden in Anlehnung an den US-Senator Ernest Frederick (,,Fritz") Hollings, durch seine Lobbyarbeit fOr die TCPA~

Integrit~itsmessung Eine Integrit~itsmessung umfasst sowohl die Ermittlung von Integrit~its-bestimmenden Eigenschaften einer Plattform als auch die Speicherung dieser ermittelten Werte in die geschtitzten PCRs des TPMs

Microkernel Ein Mikrokemel (oder auch Mikrokem) bezeichnet einen Betriebssystemkem mit einem deutlich reduzierten Funktionsumfang wie z.B. Funktionen zur Speicher- und Prozess-Verwaltung, sowie Grundfunktionen zur Synchronisation und Kommunikation. Der dazu notwendige vertrauenswfirdige Code ist im Vergleich zu konventionellen monolithischen Betriebssystemen relativ klein und somit einfacher zu verifizieren.

Migrierbarer Schl/Jssel - Migratable key Unter migrierbaren Schltisseln versteht man Schlfissel, die nicht an ein bestimmtes TPM gebunden sind (wie z.B. der EK), sondem auch auf3erhalb eines TPMs genutzt oder yon einem TPM zu einem anderen migriert werden.

Glossar

245

Mobile Trusted Module (MTM) Bei einem Mobile Trusted Module handelt es sich um die Abbildung der TPM-Spezifikation auf die Anforderungen mobiler Endger~ite wie Handy und PDA. Die Funktionen des TPMs sind somit kompatibel zu denen des MTMs.

Nicht-migrierbarer SchlOssel - Non-migratable key Nicht-migrierbare Schltissel sind Schlfissel, die direkt an ein bestimmtes TPM gebunden sind. Eine Migration auf ein anderes TPM ist nicht m6glich. Zu den Nicht-migrierbaren Schltisseln geh6ren unter anderem der Endorsement Key, der Storage Root Key sowie die Identity Attestion Keys (AIK).

Platform Configuration Register (PCR) Die Platform Configuration Register (PCR) sind Teil des fltichtigen Speichers innerhalb eines TPMs und dienen zur vertrauenswtirdigen Speicherung von 160-Bit Hashwerten, die die Systemkonfiguration widerspiegeln. PCRs dienen zur Speicherung von Zustandsabbildern der aktuellen Konfiguration von Soft- und Hardware (siehe Trusted Boot). Jedes TPM muss ein Minimum von 16 PCRs (Version 1.1) und 32 PCRs (Version 1.2) bereitstellen, wobei etwa die HNfle davon ftir Integrit/~tsprfifungen der Hardware belegt wird. Die Ergebnisse der Integrit~itsmessungen, die in den PCRs gespeichert werden, werden verwendet, um eine Aussage dartiber zu treffen, ob ein Rechnersystem kompromittiert wurde. Wurde ein Rechnersystem von einem Virus oder Trojanischem Pferd befallen, ver~indert sich das Ergebnis der Integrit~itsmessungen. Mit Hilfe einer Trusted-Third-Party k6nnen z.B. Integritgtsmessungen geprtift und mit gtiltigen Systemzust~inden verglichen werden (Attestierung). Platform Zertifikat Das Plattform-Zertifikat wird vom Hersteller der Plattform- also etwa eines PCs, Notebook oder Mobiltelefons- ausgestellt. Es bestgtigt, dass alle Plattform-Komponenten der TCG-Spezifikation gentigen und dass die Plattform ein gtiltiges TPM enthNt. Es wird also bescheinigt, dass das aktuelle Rechnersystem eine vertrauenswardige Plattform darstellt.

Policy Eine Policy enth~lt z.B. Regeln, die angeben, auf welche Art die Daten verarbeitet oder Software ausgeffihrt werden sollen.

Policy Enforcement Das Policy Enforcement ist eine Instanz, die dafiir sorgt, dass in einem Rechnersystem nur die Aktionen (Regeln) durchgefiihrt werden, die in einer vorgegebenen Policy erlaubt sind~

Remote Attestation Remote Attestation ist die Bet~itigung der Integrit~it der Systemkonfiguration eines Rechnersystems gegenfiber externen Kommunikationspartnern. Durch Remote Attestation kann eine entfernte Partei davon fiberzeugt werden, dass die Trusted Computing Plattform fiber bestimmte F~ihigkeiten verffigt und dass sich das Rechnersystem in einem wohldefinierten Zustand (entsprechende PCR-Werte) befindet. Diese TPM-Funktionalit~it hat erhebliche Auswirkungen auf die Privatsph~ire eines Nutzers, weshalb zur Beglaubigung der Plattformkonformitfit (also F~ihigkeiten und Zustand) niemals der EK direkt verwendet wird, sondern m6glichst nur ein neu erzeugter AIK. Ferner sollte eine Attestation immer auch die explizite Zustimmung des TPM-EigentOmers erfordern. Zurzeit sind zwei verschiedene Attestationsverfahren vorgesehen: Privacy CA (Trusted-Third-Party) und Direct Anonymous Attestation.

246

Glossar

Sealing Mittels Sealing k6nnen Daten an eine Systemkonfiguration gebunden werden. Durch Bilden eines HashWertes aus der Systemkonfiguration (Hard- und Software) k6nnen Daten an ein einziges TPM gebunden werden~ Hierbei werden die entsprechenden Daten und die Hash-Werte aus den PCRs (Systemkonfiguration) zusammen verschlfisselt~ Eine Entschlfisselung gelingt nur, wenn der gleiche Hash-Wert wieder ermittelt wird, was nur auf dem gleichen und unver~tnderten Rechnersystem mit dem entsprechenden TPM gelingen kann. Bei Defekt des TPM muss die Anwendung, die Sealing-Funktionen nutzt, daffir sorgen, dass die Daten nicht verloren sind. Auf diese Weise wird sichergestellt, dass auf versiegelte Daten nur wieder zugegriffen werden kann, wenn das Rechnersystem sich in einem bekannten Zustand (Systemkonfiguration) befindet.

Secure Boot Beim Start eines Rechnersystems wird die Konfiguration beginnend beim BIOS gemessen. Danach werden die Hardware und der Bootloader gemessen. Dieser tibemimmt den Messvorgang far die Betriebssystemebene. Soll eine falsche Konfiguration zu einem Startabbruch ffihren, so spricht man vom Secure Boot.

Sicherheitsplattform Im Wesentlichen bietet eine Sicherheitsplattform ein eigenst~indiges, sicheres kleines Betriebssystem, z.B. einen mikrokembasierten Sicherheitskem, der unterhalb von herk6mmlichen Betriebssystemen agiert. Die gesamte Ressourcenverwaltung, die Kontrolle fiber Funktionen und Prozesse im Hinblick aufTC-Funktionalit~iten und die Rechteverwaltung werden vonder Sicherheitsplattform (ibernommen. Das Konzept der Isolation durch Virtualisierung erm6glicht den Einsatz herk6mmlicher Betriebssysteme neben hoch sicher gescht~tzten Anwendungen. Das TPM bietet die M6glichkeit, sicherheitsrelevante Prozesse durch Hardwaresicherheit zu stfitzen.

Storage Root Key (SRK) Der Storage Root Key (SRK) ist ein RSA-Schl~issel innerhalb des TPM, auf dem die lokale Verschltisselung von Daten aufbaut. Der Storage Root Key (SRK) ist ein 2048 Bit langer RSA=Schlfissel. Der SRK wird beim TPM TakeOwnership Kommando generiert. Der 6ffentliche Schltissel kann exportiert werden, der private Schltissel bleibt im TPM. Der private Schltissel verl~isst das TPM nie, kann jedoch vom Benutzer gel6scht werden. Wechselt der Besitzer des Rechners, wird ein neuer SRK erzeugt. Dieses Schlftsselpaar ist migrierbar, und kann somit in einen Backupprozess einbezogen werden Der SRK dient allein dem Zweck, weitere benutzte Schl~ssel zu verschl~isseln und stellt somit die Wurzel des TPM-Schlt~sselbaumes dar.

Take Ownership Bei Auslieferung eines Rechnersystems mit TPM ist dieses nicht aktiviert und besitzt nur einen Endorsement Key. Das ,,TakeOwnership" Kommando ben6tigt als erstes Argument einen 160-Bit SHA-1 Hashwert eines Passwortes, das der Besitzer als Authentifizierungs-Passwort festlegt. Falls das TPM bereits im Besitz eines Benutzers ist, bleibt die Ausfahrung des ,,Take_Ownership" Kommandos wirkungslos. Ein Besitzerwechsel ist nur dadurch m6glich, dass eine spezielle Reset-Sequenz aktiviert wird. Nachdem das ,,TakeOwnership" Kommando ausgefahrt wurde, wird auch der Storage Root Key generiert.

TrouSerS Bei TrouSerS handelt es sich um eine Open Source-Implementation des TCG Trusted Software Stacks.

Glossar

247

Trusted Computing (TC) Einen neuen, innovativen Ansatz, um das Vertrauen und die Sicherheit yon IT-Systemen zu erh6hen, bietet Trusted Computing (TC). Dazu werden Trusted-Computing-Plattformen (PCs, aber auch andere computergesttitzte Systeme wie Mobiltelefone usw.) mit einem zus~itzlichen Chip, dem Trusted Platform Module (TPM), ausgestattet, der mittels kryptographischer Ver-fahren die Integritgt der Soft- und Hardware-Konfiguration messen kann und diese Hashwerte (Prtifwerte) nachprOfbar im TPM abspeichert. Eine Sicherheitsplattform kann dann diese Messwerte tiberprtifen und damit entscheiden, ob die Soft- oder Hardware-Konfiguration ge-gebenenfalls ver~indert wurde und darauf entsprechend reagieren~ Dies kann von einer War-nung an den Benutzer bis hin zum Programmabbruch fohren. Trusted Computing ben6tigt als unbedingte Voraussetzung eine Sicherheitsplattform, welche diese Integrit~itstiberprtifungen anst6sst und auch auswertet. Ftir das derzeitig meist verbreitete Trusted-ComputingVerfahren definiert die Trusted Computing Group die Standards fOr die beteiligten Hardwaremodule und die entsprechenden SW-Schnittstellen.

Trusted Computing Group (TCG) Die TCG ist ein Industriekonsortium weltweiter Hersteller mit dem Ziel, offene Spezifikationen for vertrauenswtirdige Rechnersysteme zu entwickeln, um die Sicherheit verteilter Anwendungen mit vertretbarem Aufwand zu erh6hen. Aktuell sind in der TCG fiber 170 Firmen aus aller Welt vertreten. Darunter befinden sich alle "Global Player", wie SUN, Intel, AMD, Microsoft, HP, IBM sowie Infineon als Promoter, aber auch weitere deutsche Hersteller wie Fujitsu Siemens, Utimaco Safeware AG, Sirrix AG und andere.

Trusted Computing Platform Alliance (TCPA) Die Trusted Computing Platform Alliance (TCPA) ist der Vorg~inger der Trusted Computing Group und wurde im Jahr 1999 durch Compaq, HP, IBM, Intel und Microsoft gegrandet und bestand bis zum Jahr 2003. Ab 2003 hat die Trusted Computing Group (TCG) die Weiterentwicklung der Spezifikationen iibemommen.

Trusted Network Connect (TNC) Spezifikation der TCG TNC-Subgroup aus dem Bereich Network Access Control (NAC). Ziel ist die Entwicklung einer offenen, herstellerunabh~ingigen Spezifikation zur Uberprfifung der Endpunkt-Integrit/~t. TNC baut dabei auf vorhandenen Technologien wie 802.1x, VPN und RADIUS auf und kann optional Funktionen des TPMs nutzen.

Trusted Platform Module (TPM) Unter dem BegriffTrusted Platform Module versteht man einen in einem Rechnersystem fest verbauten, nicht austauschbaren und passiven Chip, der die Funktionen der gleichnamigen TPM-Spezifikation der TCG erfollt. Das TPM kann als eine mit dem System fest verbundene Smartcard angesehen werden. Der Unterschied zur herk6mmlichen Smartcard stellt sich durch die Verwendung dar. W~thrend Smartcards an eine Person gebunden sind und diese authentifizieren k6nnen, ist das TPM an das Rechnersystem gebunden. Das TPM besteht aus mehreren Ftmktionsbl6cken: 9 Sicherer Zufallszahlen-Generator 9 Platform Configuration Register (PCRs) 9 Spezialisiertes Kryptorechenwerk zur schnellen Berechnung von RSA-Kryptographie bis zu 2048 Bits. 9 Schltisselerzeugung fOr RSA-Schltissel bis 2048 Bits 9 Hardware-Hash-Rechenwerk fOr den SHA-1 Algorithmus

248

Glossar 9 Echter Hardware Rauschgenerator als Input zur Schlfisselerzeugung 9 Interner Prozessor mit der entsprechenden Firmware, um die kritischen Funktionen (z.B. RSA mit dem geheimen Schlfisselteil) in einer sicheren Umgebung vertrauens-w~rdig berechnen zu k6nnen. ~ Monotone, geschfitzter Ereignis- und Zeit-Z/~hler, urn Reply-Attacken zu erkennen. ~ Nichtflfichtiger Speicher (EEPROM) zum Erhalten der TPM-(Schlfissel)-Daten auch beim Ausschalten der Betriebsspannung ~ Sensoren und interne Sicherheitsstrukturen (z.B. aktiver Schirm fiber der obersten Verdrahtungslage des Chips), um physikalische Angriffe zu erkennen und diesen zu begegnen. 9 Low-Pin-Count (LPC)-Interface zur Verbindung mit dem Prozessor des Mainboards. ~ TPM Selbsttest Funktion

Trusted Software Stack (TSS) Das TPM ben6tigt wie jedes andere Hardware-Element auch, eine spezielle Treiber- und Service-Provider-Schnittstelle, um vom Betriebssystem und den Applikationen aus angesprochen werden zu k6nnen. Dieser Trusted Plattform Support Service stellt eine Sicherheits-API dar, die dem jeweiligen Betriebssystem die Funktionen des TPM auf einer hohen abstrakten Ebene bereitstellt.

Trusted Viewer Ein Trusted Viewer ist ein Programm, das sowohl eine vertrauenswfirdige Anzeige von Daten erm6glicht, als auch die Durchsetzung von Lizenzbedingungen in ERM und DRM-Umgebungen. In heutigen Betriebssystemen existieren keine vertrauenswfirdigen Anzeigen, das heil3t, dass beispielsweise die Anzeige eines Text-Dokumentes in einem Textverarbeitungsprogramm dm:ch eine andere Software/ Hardware ver~indert werden kann. Die angezeigten Daten entsprechen so nicht den eigentlichen Daten im Dokument. Ein Trusted Viewer erm6glicht dagegen eine vertrauenswfirdige, also eine nicht manipulierbare, Anzeige. In DRM und ERM-Umgebungen ist es wichtig, dass die zu den Daten geh6renden Lizenzen nicht umgangen werden k6nnen. Hier bietet ein Trusted Viewer die Durchsetzung der Lizenzeno Darf beispielsweise ein Dokument nicht kopiert werden, verhindert der Trusted Viewer nicht nur ein Ausdrucken fiber einen Drucker, sondem auch die Anfertigung von Screenshots.

Turaya Turaya ist die Umsetzung einer Sicherheitsplattform der durch das EMSCB-Projekt entwickelten Sicherheitsarchitektur.

Validation Zertifikat Dieses Zertifikat stellt mr Komponenten oder Komponentengruppen die Ubereinstimmung und Korrektheit der Implementierung gegenfiber der TCG-Spezifikation sicher.

Vertrauen Die Definition der TCG von Vertrauen ist: ,,Man kann jemanden oder etwas vertrauen, wenn es sich ffir einen bestimmten Zweck jedes Mal erwarmngsgem~il3 verhNt."

Sti chwortverzeich

n is

A Access Requestor

101,102, 104

Active Directory

61, 62, 69, 134

Administrationsrollen Attestation

142

25, 29, 30, 44,-47, 52-55, 75, 84, 86, 92, 96, 114, 121, 126, 130-133, 158, 169, 189-193, 200-205,212, 215-219, 222, 241,243-245

Attestation Identity Key

29, 45, 54, 114, 190, 210, 216, 225,243

Direct Anonymous Attestation

30, 114, 121,191,193,205,212, 216-219, 243,245

Remote Attestation

86, 126, 130, 132, 158, 190, 191,200, 203,243,245

Authenticated Boot

159, 184, 242

B Benutzerautorisierung

111,112

C Certifiable Migration

146, 147

Common Criteria

17, 92, 111,178, 180, 185,237

Core Root of Trust for Measurement

243

credentials

30, 45, 48, 50,-56, 189, 191,195,216

D Datenschutz Digital Rights Management

11, 12,25,30,37,38,57-59,68,69,85,89,92,96, 109, 111,114, 139, 190, 196, 198, 201,203, 207, 209-220, 221-235,238, 240 11, 19, 40, 59, 88, 118, 127, 211,212, 220, 225

250

Stichwortverzeichnis

elektronische Signatur

22,39,42,87, 111,191,198,217

Embedded Security

95, 96, 170, 185, 186, 237, 240, 242

Embedded System

12, 23, 89, 121,239, 240

Endorsement Key

28-32, 45, 49, 51, 54, 59, 114, 143,144, 189, 210, 216, 217, 225, 227 243-246

Endorsement Zertifikat

244

Enterprise Rights Management

12, 80, 86, 94, 107, 126, 127, 139, 244

Fritz Chip

140, 244

Full Volume Encryption Key

60

Haftung

9, 107, 217, 223,224, 231,

Hardware Security

Identit~itsmanagement

187, 197, 211-217, 238

Integrit~itsmessung

26, 102, 113,114, 132, 133,222-227,244,245

Integrit~itsprfifung

23, 81, 86, 100, 117, 139, 222, 239, 245

LaGrande

43, 46, 63, 90, 155,238,242

N Microkernel

33, 34, 244

Migration Authority

147, 150, 152-154

Migration Packages

152, 153

Stichwortverzeichnis

251

Migrationsdienste

152

migrierbarer Schlfissel

32, 37, 39, 144-151,244, 245

Mikrocontroller

140, 178-182

Mobile Trusted Module

188,245

N Network Access Control

100, 125,247

nicht-migrierbarer Schlfissel

32, 144, 145,244

Platform Configuration Register

49, 190, 245,248

Platform Zertifikat

245

Policy Decision Point

102, 103

Policy Enforcement

93, 103, 126, 131,244

Privatkopie

157,230

Public Key Infrastructure

62, 84, 148-153, 189,239,242

R Recovery Key

61

S Schutzmal3nahmen Sealing Secure Boot Security Modul Service Provider Sicherheitsplattform Smart Card

8, 73, 87, 94, 98, 172, 222, 223,230, 234 26, 74, 77, 84, 159, 246 86, 158-161,243,246 4, 150, 185 35, 36, 68, 69, 73, 152, 248 3-11, 73-85, 86-96, 106, 129, 139m 178, 243,-248 4-6, 11, 16, 44, 49, 59, 60, 68, 82, 95, 110-121,144, 158, 165, 179, 185, 202, 238, 248

252

Stichwortverzeichnis

Standardisierung

5, 10, 16,20,22,40, 107, 108, 139, 180,229,235,238-241

Storage Root Key

29, 32, 37, 49, 60, 115, 143, 145,245,246

Take Ownership

29, 37, 189, 246

Trustcenter Trusted Computing Group

24, 29, 30, 84, 142 6, 11, I5-22, 42, 43, 44, 56, 84, 89, 100, 108-110, 121, 126, 130, 155, 158, 179, 188, 206, 209-211, 219,229, 238, 241,247

Trusted Computing Platform Alliance

16, 57, 209,247

Trusted Network Connect

11, 76, 97-109, 126, 139,246

Trusted Platform Module

5, 6, 17, 18,31,42-44, 56, 59, 88,90, 104, 110, 116, 140, 143, 158, 169, 188, 210, 233,247, 248

Trusted Software Stack

247

Trusted Viewer

80, 88, 247, 248

I.I Urheberrecht

88, 92, 157, 168, 211,224, 229, 230, 234

User Account Control

64, 65

V Validation Zertifikat

247

virtualization

43-56, 206, 241

I/7 Wettbewerbsrecht

221,228,229, 233-235