Eine Studie im Auftrag des

Bundesamtes für Sicherheit in der Informationstechnik (BSI)

Ergänzende und alternative Techniken zu Trusted Computing

(TC-Erg./-A.)- Teil 1 -

Eine Analyse von Sicherheitstechniken

als Ergänzung zu Trusted Computing

Version 1.0 / 29.01.2010

Zusammenfassung:

Die vorliegende Studie „Ergänzende und alternative Techniken zu Trusted Computing (TC-Erg./-A.)“ erläutert Sicherheitskonzepte, Sicherheitsmodelle und Vertrauensmodelle, die in informationsverarbeitenden Computersystemen verwendet werden. Diese werden anhand ihrer Unterschiede und ihrer Kombinationsmöglichkeiten miteinander verglichen und eingeordnet. Schwerpunkt dieser Studie ist das Konzept des „Trusted Computings” in bekannte Strukturen einzugliedern, das Verhältnis zwischen „Trusted Computing” und den klassischen Sicherheitstechniken, sowie mögliche und sinnvolle Kombinationen aus Trusted Computing und anderen Sicherheitstechniken zu untersuchen.

Autoren:

Thomas Quirin, Lothar Fritsch, Rani Husseiki

Sirrix AG security technologiesLise-Meitner-Allee 444801 BochumDeutschland

Florian v. Samson

Bundesamt für Sicherheit in der Informationstechnik (BSI)Postfach 20036353133 BonnDeutschland

Lizenzbedingungen:

Diese Arbeit wird unter den Lizenzbedingungen der „Creative Commons” Lizenz „Na-mensnennung - Keine Bearbeitung 3.0 (CCPL-by-ND 3.0)“ veröffentlicht. Im Detail be-deutet dies:

● Vervielfältigen: Sie dürfen das Werk vervielfältigen, verbreiten und öffentlich zu-gänglich machen.

● Namensnennung: Sie müssen den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen (wodurch aber nicht der Eindruck entstehen darf, dass Sie oder die Nutzung des Werkes durch Sie entlohnt würden).

● Keine Bearbeitung: Dieses Werk darf nicht bearbeitet oder in anderer Weise verän-dert werden.

Die komplette Lizenzvereinbarung befindet sich im Anhang 8.1.

2

Inhaltsverzeichnis

Einführung....................................................................................................................................6

Definitionen und Taxonomie.........................................................................................................82.1 Definition...........................................................................................................................82.2 Konflikte..........................................................................................................................102.3 Verbreitete Missverständnisse..........................................................................................11

Sicherheitskonzepte.....................................................................................................................133.1 Mehrschichtige und multilaterale Sicherheitskonzepte....................................................13

3.1.1 Mehrschichtige Sicherheit - „Multi Level Security“ (MLS).....................................133.1.2 Multilaterale Sicherheit - „Multilateral Security“.....................................................14

3.2 Regelbasiertebasierte und Benutzerbestimmbare Zugangskontrolle.................................143.3 Sicherheitskonzepte in heutigen Betriebssystemen..........................................................15

3.3.1 Mehrschichtige Sicherheit........................................................................................153.3.2 Regelbasierte Erzungene Zugangskontrolle - „Mandatory Access Control“............163.3.3 Benutzerbestimmbare Zugriffskontrolle - „Discretionary Access Control“..............16

Sicherheitsmodelle......................................................................................................................174.1 Zugangskontrolle, Informationsflusskontrolle und „Type Enforcement“.........................17

4.1.1 Zugangskontrolle.....................................................................................................174.1.2 Informationsflusskontrolle.......................................................................................194.1.3 „Type Enforcement“.................................................................................................21

4.2 Grundlegende Sicherheitsmodelle....................................................................................234.2.1 Besitzerbasierte Sicherheitsrichtlinien......................................................................234.2.2 Zugangskontrolllisten - „Access Control Lists“.......................................................23

4.3 Vertraulichkeitsorientierte Modelle..................................................................................244.3.1 Zugangsmatrixmodell/Zugangskontrolllisten...........................................................254.3.2 Gitterbasiertes Zugangskontrollmodell....................................................................264.3.3 Dynamisches Zugangskontrollmodell (HRU)..........................................................274.3.4 Einfache Sicherheitsplattformen..............................................................................284.3.5 Bell-LaPadula Modell..............................................................................................284.3.6 Rollenbasierte Zugangskontrolle..............................................................................304.3.7 „Chinese-Wall“-Modell (Brewer-Nash)...................................................................31

4.4 Integritätsorientierte Modelle...........................................................................................324.4.1 Biba Modell.............................................................................................................324.4.2„Low-Watermark“-Zugangskontrollmodell...............................................................334.4.3 Clark-Wilson („kommerzielle Integrität“)................................................................34

4.5 Sonstige Modelle..............................................................................................................374.5.1 „British Medical Association“-Sicherheitsmodell (BMA)........................................374.5.2 Sicherheitsbereiche / „Compartmented/Multi-Category Security (MCS)“...............384.5.3 „sHype“-Modell.......................................................................................................39

4.6 Sicherheitsmodelle in heutigen Betriebssystemen............................................................42

Vertrauensmodelle.......................................................................................................................435.1 Taxonomie von Vertrauensmodellen................................................................................43

5.1.1 Vertrauen gegenüber Reputation..............................................................................43

3

5.1.2 Vertrauensmodelle....................................................................................................445.1.3 Objekte in einem Vertrauensmodell..........................................................................495.1.4 Subjekte in Vertrauensmodellen...............................................................................51

5.2 Vertrauen in verteilten Computersystemen.......................................................................525.2.1 Einführung von verteilten Vertrauensanforderungen................................................525.2.2 Techniken für verteiltes Vertrauen............................................................................53

5.3 Vertrauensbeziehungen.....................................................................................................545.3.1 Hierarchisches Vertrauensmodell.............................................................................545.3.2 „Web of Trust“.........................................................................................................555.3.3 Diskussion des „Hierarchischen Vertrauens“ gegenüber „Web of Trust“.................55

5.4 Implementieren des Vertrauensmodells und des Vertrauensankers...................................565.4.1 Zentrale vertrauenswürdige Dritte............................................................................565.4.2 Vertrauenswürdige Dritte.........................................................................................575.4.3 Vertrauensanker........................................................................................................57

Alternativen und Kombinationen................................................................................................596.1 Trusted Computing und seine Klassifizierung..................................................................59

6.1.1 Die „Trusted Computing Group“ (TCG)..................................................................596.1.2 Trusted Computing Funktionen................................................................................626.1.3 Vertrauenswürdige Computerarchitektur..................................................................646.1.4 Betriebssysteme, die Trusted Computing unterstützen.............................................67

6.2 Kombination von Trusted Computing mit ähnlichen Sicherheitskonzepten.....................696.2.1 Vertrauensanker........................................................................................................706.2.2 Plattformintegrität mit Trusted Computing..............................................................706.2.3 Verteiltes Vertrauen mit Trusted Computing.............................................................716.2.4 Klassische Sicherheitsmodelle und Trusted Computing...........................................716.2.5 Herausforderungen...................................................................................................726.2.6 Interoperabilität........................................................................................................72

Schlussfolgerung.........................................................................................................................747.1 Entwicklungspfade von sicheren Computersystemen basierend auf Trusted Computing. 74

7.1.1 Klassische Sicherheitsmodelle.................................................................................747.1.2 Sicheres Anzeigeprogramm und sichere Ein-/Ausgabe............................................767.1.3 Sicherer richtlinienbasierter Datenfluss....................................................................767.1.4 Vertrauenswürdige Computersysteme......................................................................76

7.2 Trusted Computing innerhalb eines Sicherheitskonzeptes................................................777.3 Die Nutzung von Trusted Computing Funktionalitäten und Unterstützungen komplementärer oder alternativer Techniken.........................................................................77

Literaturverzeichnis......................................................................................................................80

Glossar.........................................................................................................................................87

Anhang........................................................................................................................................96„Creative Commons” Lizenz.................................................................................................96

4

Abbildungsverzeichnis Abbildung 2.1: Grundlegende Begriffe der IT-Sicherheit und ihre Beziehungen zueinander.............9

Abbildung 4.1: Schalenmodell für Zugangskontrollbereiche auf Computersystemen......................18

Abbildung 4.2: Schutz von Daten mittels „Sticky Policies".............................................................21

Abbildung 5.1: Direktes Vertrauen...................................................................................................46

Abbildung 5.2: Hierarchisches Vertrauen.........................................................................................47

Abbildung 5.3: Indirektes Vertrauen oder „Web of Trust“................................................................48

Abbildung 7.1: Mögliche Entwicklungspfade des Trusted Computing............................................75

Abbildung 7.2: Trusted Computing, Alternativen und unterstützte Sicherheitstechniken.................79

TabellenverzeichnisTabelle 3.1: Beispiele für Sicherheitsebenen: Sicherheitsüberprüfungsgesetz (SÜG), §4................14

Tabelle 4.1: Die Implementierung von Sicherheitsmodellen nach [Wiki0001].................................41

5

Kapitel 1

EinführungDie vorliegende Studie bietet eine Einführung in die Thematik von Sicherheitskonzepten, Sicher-heitsmodellen und Trusted Computing. Die Zielgruppe sind Leser, die über grundlegende Kennt-nisse der Informatik, aber nicht notwendigerweise über Kenntnisse im Bereich der IT-Sicherheit verfügen. Im Rahmen dieser Studie werden grundlegende Begriffe und Konzepte der Informations-sicherheit, Zugangskontrolle und Sicherheitsziele erläutert. Weiterhin wird ein Überblick über Si-cherheitsmodelle und ihre Vertrauensannahmen gegeben sowie Trusted Computing erläutert und in Beziehung mit Sicherheits- und Vertrauensmodellen gesetzt. Darüber hinaus werden Betriebssys-teme angesprochen, die diese Sicherheitsmechanismen verwenden. Gleichzeitig werden Referenzen zu technischer und wissenschaftlicher Literatur gegeben, die die Inhalte der Studie abrunden.

Die Bedeutung von sicheren Betriebssystemen hat als Basis für Anwendungsprogramme in den letzten Jahren stark zugenommen. Während immer komplexere Abläufe rund um die Informations-verarbeitung in private und öffentliche Umgebungen Einzug halten, wird der Informationsaustausch über das Internet abgewickelt. Damit sind diese Arbeitsabläufe einem Angriffspotential durch Schadprogramme (z. B. Viren, Würmer oder Trojaner) ausgesetzt. Als Konsequenz daraus ergibt sich ein erhöhter Bedarf, die Informationsflüsse zwischen miteinander vernetzten Plattformen zu si-chern und zu kontrollieren. Um hier die Zugriffskontrolle auf eine einheitliche Basis zu stellen, sind in den letzten Jahrzehnten diverse Konzepte in Betriebssystemen implementiert worden, z. B. mehr-schichtige Sicherheit (engl. „Multi-Level Security“, MLS), „Compartmented Mode Security“ (CMS), „Mandatory Access Control“ (MAC), „Discretionary Access Control“ (DAC). Darüber hin-aus wurden weitere Sicherheitsmodelle, wie z. B. Bell-LaPadula oder rollenbasierte Zugriffskon-trolle (engl. „Role-Based Access Control“, RBAC) spezifiziert und auch implementiert. Derzeit werden in der Forschung weitere Sicherheitskonzepte vorgeschlagen und untersucht, wie z. B. multilaterale Sicherheit (Multilateral Security) und das sHype-Sicherheitsmodell. Gleichzeitig ver-ändern Hardware-Erweiterungen, z. B. das „Trusted Platform Module“ (TPM) der „Trusted Computing Group“ (TCG), die Sichtweise auf das Thema Computersystemsicherheit. Diese Hardware-Erweiterungen haben einen erheblichen Einfluss auf die praktische Nutzbarkeit und Effektivität der genannten Sicherheitskonzepte.

Viele der Entwicklungen sind aus dem Bereich der Sicherheitsmodelle und des Trusted Computing als FLOSS-Programme („Free, Libre, Open Source Software“) verfügbar. Allerdings werden sie hauptsächlich in Spezialprogrammen eingesetzt. Daher werden in dieser Studie die folgenden Themen näher behandelt:

1. Analyse von bestehenden Sicherheitskonzepten sowie Sicherheits- und Vertrauensmodellen in Bezug auf ihre Unterschiede und ihre Kombinierbarkeit in der Praxis

2. Untersuchung möglicher Anwendungsprogrammfelder der Sicherheitskonzepte, Sicher-heits- und Vertrauensmodelle sowie der entsprechenden Sicherheitsebenen hinsichtlich Ef-fektivität in der Nutzung und in Kombinationen untereinander.

6

Einführung

3. Bewertung der genannten Sicherheitskonzepte, Sicherheits- und Vertrauensmodelle in freien Implementierungen1, wobei auf die praktische Anwendbarkeit und Effektivität des jeweiligen Programms geachtet wird.

1 „Frei“ bezieht sich hier auf eine FLOSS-Lizenzierung, wie von der OpenSource-Initiative http://www.opensource.org/docs/definition.php definiert.

7

Kapitel 2

Definitionen und TaxonomieIn diesem Kapitel werden die Terminologien und Taxonomien aus dem Bereich der IT-Sicherheit2 erläutert, die im Zusammenhang mit dieser Studie verwendet werden. Die Bereiche der Sicherheits-konzepte, Sicherheitsmodelle und Vertrauensmodelle können für Verwirrung sorgen. In der Einlei-tung des aktuellen Kapitels werden diese drei Bereiche und andere relevante Fachbegriffe definiert, klassifiziert und ihre Unterschiede dargestellt. Anschließend werden weitere Details erläutert.

Die Sicherheit von Daten, die auf Computersystemen vorgehalten werden, liegt im Fokus dieser Studie. Der Einfachheit halber betrachten wir in dieser Studie nur die drei Sicherheitseigenschaften Vertraulichkeit, Integrität und Authentizität3. Die weitere Sicherheitseigenschaft Verfügbarkeit [Rann1994] basiert auf einem anderen Ansatz und ist daher nicht im Fokus dieser Studie.

2.1 Definition

Hier werden wichtige Begriffe und ihre Beziehung zueinander definiert und, falls erforderlich, mit Referenzen untermauert (siehe auch Abbildung 2.1). Die Begriffe werden alphabetisch eingeführt, wobei Querverweise ggf. auf andere Stellen verweisen. Die hier definierten Begriffe werden fett dargestellt.

Als Grundlage der IT-Sicherheit können die Definitionen von Sicherheitskonzept, Sicher-heitsmodell und Vertrauensmodell angesehen werden. Darüber hinaus sollte auch das Kapitel über Konflikte und Missverständnisse der IT-Sicherheit nicht außer Acht bleiben.

In der IT-Sicherheit werden allgemein Datenobjekte betrachtet, die von Subjekten auf Grundlage von Sicherheitszielen geschützt werden sollen. Eine grundlegende Schutzmethode nennt man ein Sicherheitskonzept. Innerhalb des Konzepts implementieren ein oder mehrere bestimmte Sicherheitsmodelle die Mechanismen, die IT-Sicherheit durchsetzen.

Aktion: siehe Operation.

Integrität: Daten bleiben in ihrem ursprünglichen Zustand. Sie können ohne passende Autorisation nicht modifiziert oder gelöscht werden. Weitere Einzelheiten hierzu finden sich in [PfKo2001].

Objekt: Als Objekt wird eine Menge von Daten (etwa eine Datei, ein Datenbankeintrag oder ein Webobjekt) bezeichnet, die in einem Computersystem gespeichert wird. Die Handhabung von Objekten ist der Fokus von Sicherheitskonzepten und Sicherheitsmodellen.

2 Sicherheit in der Informationstechnik

3 Wird auch als Nachvollziehbarkeit oder Nicht-Abstreitbarkeit mit leicht unterschiedlicher Interpretation bezeichnet.

8

Definitionen und Taxonomie

Operationen: Der Begriff Operationen4 beinhaltet alle Operationen auf einem Objekt, die für die Sicherheit des Objektes relevant sind. Beispielsweise sind die Operationen wie lesen, schrei-ben, löschen, überschreiben, kopieren, verschieben, versenden und drucken (engl. „read“, „write“, „delete“, „overwrite“, „copy“, „move“, „mail“, „print“).

Richtlinie: siehe Sicherheitsrichtlinie.

Sicherheitsanker: Ein Sicherheitsanker ist ein Mechanismus in einer Implementierung eines Si-cherheitsmodells, der einen sicheren und vertrauenswürdigen Startpunkt für Vertrauensbezie-hungen bietet. Dies kann beispielsweise ein manipulationssicherer Chip sein, der eine Startsoft-ware für einen Computer enthält.

Sicherheitskonzept: Ein Ansatz ist, ein Computersystem derart zu strukturieren, dass die Sicher-heit von Daten kontrolliert werden kann.

Sicherheitsziel: Eine Spezifikation der Sicherheitseigenschaften, die ein Computer oder eine Da-tenbank besitzen sollte. Das ist ein wichtiger Teil eines Sicherheitsmodells. Typische Sicherheitsziele sind Vertraulichkeit, Integrität und Verfügbarkeit von Daten. Bei Operationen kann noch das Sicherheitsziel der Verbindlichkeit hinzugefügt werden. Nach der Spezifikation der Sicherheitsziele folgt eine genauere Analyse unter Beachtung der Nutzungsfälle.

4 Im Zusammenhang mit dieser Studie

9

Abbildung 2.1: Grundlegende Begriffe der IT-Sicher-heit und ihre Beziehungen zueinander

Definitionen und Taxonomie

Sicherheitsmodell: Ein detailliertes Modell, wie Sicherheitsrichtlinien definiert, implementiert und verwaltet werden können. Ein Sicherheitsmodell schließt Subjekte, Objekte, Operationen und Sicherheitsziele mit ein.

Sicherheitsrichtlinie (engl. „Security Policy“): Eine Menge an Regeln, die spezifiziert, welche Subjekte sicherheitsrelevante Operationen und Objekte beeinflussen oder ausführen dürfen.

Subjekt: Eine Person (z. B. der Benutzer) oder ein Programm, das im Auftrag der Person arbeitet. Ein Subjekt arbeitet auf durch Sicherheitsrichtlinien geschützten Objekten. Subjekte sollten nicht mit Datensubjekten, wie sie in [PfKo2001] verwendet werden, verwechselt werden.

Trusted Computing: Eine Spezifikation zu Plattformen und Sicherheitsprotokollen durch die „Trusted Computing Group“ [TCG0001]. Es dient der Bereitstellung von hardwaregesicherten Komponenten und einer Menge von Algorithmen für Computersysteme, die einen Sicher-heitsanker für den sicheren Systemstart und vertrauenswürdige Informationsverarbeitung auf-bauen.

Unbeobachtbarkeit: Hierbei handelt es sich um die Anforderung, dass nicht erkennbar ist, ob eine Kommunikation stattfindet oder bestimmte Daten vorhanden sind.

Vertrauensmodell: Ein Vertrauensmodell ist eine Spezifikation der Vertrauenswürdigkeit techni-scher Komponenten in einem Sicherheitsmodell. Es dient der Herausstellung wichtiger Kom-ponenten, die nicht versagen dürfen, sowie dazu, Hinweise mit Relevanz für die allgemeine Si-cherheit zu geben. Beispielsweise muss bei einem passwortbasierten Computersystem das Pro-gramm, welches das Passwort mit der Datenbank abgleicht, vertrauenswürdig sein. Wenn es versagt, ist die Sicherheit eines Computersystems kompromittiert.

Zugangskontrolle: Zugangskontrolle ist eine Technik zur Verwaltung der Zugangsrechte von Sub-jekten zu Daten oder Systemfunktionen.

2.2 Konflikte

Viele der oben eingeführten Begriffe sind in der Praxis mehrdeutig. Die Definitionen wurden daher mit Bezug auf den Gegenstand dieser Studie ausgewählt. In Bezug auf Sicherheitsterminologie be-ziehen sich die Begriffe auf die Verwendung innerhalb des Bereichs der Informationssicherheit (engl. „Information Security“). Es gibt ein anderes Sicherheitsfeld, das ebenfalls mit „Sicherheit“ bezeichnet wird (engl. „Safety“) und sich auf Zuverlässigkeit, Schutz vor Fehlern, Systemstabilität und Ähnliches spezialisiert. Dabei können gleiche Begriffe oder ähnliche Bezeichnungen mit ande-rer Bedeutung verwendet werden.

Darüber hinaus können im Bereich Datenschutz und Privatsphäre im Internet (engl. „Online-Privacy“) einige Begriffe anders verwendet werden. Falls diesbezüglich Zweifel auftreten, können in [PfKo2001] bestimmte Fachbegriffe aus dem Bereich des Datenschutzes nachgelesen werden.

Eine sorgsame Prüfung ist erforderlich, falls Begriffe aus den Bereichen Sicherheitskonzept, Sicher-heitsmodell, Vertrauensmodell und ihre Implementierungen in Betriebssystemen und Anwendungs-programmen verwendet werden. Einige Quellen verwechseln diese Begriffe miteinander. Deshalb ist große Vorsicht geboten, wenn ein Autor Begriffe wie beispielsweise Angriffsmodelle und Bedro-hungsmodelle in Artikeln verwendet.

10

Definitionen und Taxonomie

2.3 Verbreitete Missverständnisse

Dieser Teil der Studie beschreibt und löst allgemeine Missverständnisse auf, die in der öffentlichen Debatte um Informationssicherheit anzutreffen sind. Einige dieser Missverständnisse haben großen Einfluss auf die Wahrnehmung der IT-Sicherheit und werden im Nachfolgenden zur Klassifizierung und Aufklärung aufgeführt.

● Digitales Rechtemanagement (DRM) und Trusted Computing: Ein modernes Konzept zur Computersicherheit ist Trusted Computing [Pear2002]. Trusted Computing bezieht sich auf die Spezifikation der „Trusted Computing Group“ über die Unterstützung der Hardware für sichere Computersysteme. Dieser Ansatz verwendet einen Sicherheitsbaustein innerhalb der Rechner, welcher dem Betriebssystem die Prüfung ermöglicht, ob geladene Software verän-dert wurde.

Es gab erhebliche Diskussionen über Trusted Computing, als Microsoft und andere Her-steller weitere mögliche Nutzungsfälle des Trusted Computing im Bereich der Medien-kontrolle durch digitales Rechtemanagement diskutierten. Dabei sollte mittels Trusted Computing erzwungen werden, dass eine bestimmte „Mediaplayersoftware” verwendet wird, die bestimmte Nutzungsrechte durchsetzt. Dieses Konzept hat für eine große Zahl ne-gativer Schlagzeilen gesorgt. Tenor war dabei die Befürchtung, dass nicht-konforme Com-puter vom Internet ausgeschlossen werden und dass Firmen die Kontrolle über Privatcom-puter erlangen können. Diese negativen Debatten haften dem Begriff Trusted Computing teilweise noch immer an. Trusted Computing kann das sichere und korrekte Laden jeglicher Sicherheitssoftware garantieren. Welche Restriktionen damit genau verbunden sind, hängt vom verwendeten Betriebssystem sowie dem Administrator ab. Abschnitt 6.1 behandelt dieses Thema näher.

● Vertrauen ist ein häufig verwendeter Begriff im Bereich der IT-Sicherheit. Unglücklicher-weise wird Vertrauen in Menschen oft mit Vertrauen in Sicherheitsmodelle oder Sicherheitssysteme verwechselt. In der IT-Sicherheit wird Vertrauen üblicherweise im technischen Sinne als „Vertrauen in das spezifikationskonforme Funktionieren von IT“ verwendet. Beispielsweise das Vertrauen gegenüber einem Antivirenprogrammhersteller, der automatische Aktualisierungen der neuen Virus-Signaturen für ein Antivirenprogramm bereitstellt und sicherstellen muss, dass die zur Aktualisierung nötigen Daten nicht verfälscht wurden. Man geht normalerweise davon aus, dass Hersteller von Antivirenpro-grammen ein großes Interesse daran haben, im Markt zu bleiben und daher ihre Software unter Sicherheitsaspekten entwerfen und entwickeln. Daraus leitet sich das folgende Vertrauensmodell für Anitvirenprogramme ab: Der Aktualisierungsdienst des Herstellers ist vertrauenswürdig, da der Hersteller in der freien Wirtschaft überleben will. Vertrauen in Menschen ist eine problematische Sache. Normalerweise muss man Menschen immer vertrauen. Sie können Informationen beabsichtigt oder unbeabsichtigt weiter geben, Bildschirme fotografieren, gedruckte Dokumente stehlen oder Daten in Computersystemen verändern. Daher besteht ein direkter Zusammenhang zwischen Vertrauensmodell und der Vertrauenswürdigkeit der technischen Infrastruktur. Mehr über Vertrauensmodelle findet sich in Kapitel 5. Zu beachten ist, dass Vertrauen manchmal mit „Reputation Management“ verwechselt wird, welches sich auf Anwender einer Internet-Plattform fokussiert (siehe auch Kapitel 5.1).

11

Definitionen und Taxonomie

● Um Gene Spaffort zu zitieren: „The only truly secure system is one that is powered off, cast in a block of concrete and sealed in a lead-lined room with armed guards.“ („Das einzig wirklich sichere Computersystem ist abgeschaltet, eingeschlossen in Beton und steht von bewaffneten Wachen geschützt in einem mit Blei ausgegossenen Raum“) [Spaf1989]. Tat-sächlich ist Sicherheit relativ. Forscher und Hollywood betrachten unknackbare Programme aus unterschiedlichen Blickwinkeln. In der Praxis lassen sich im Allgemeinen die meisten Sicherheitsmaßnahmen mit entsprechend großen finanziellen Mitteln und angemessener Zeit umgehen. Trotzdem hängt es stark von den individuellen Sicherheitsbedürfnissen ab, ob ein „absolut unknackbares“ Sicherheitssystem gebraucht wird oder nicht. In der Sicher-heitspraxis ist die Frage oft folgende: „Wie lange sollen die Daten sicher sein?“, was die Lage eher aus dem Blickwinkel der Versicherung betrachtet. Sicherheitsmaßnahmen sind dazu da, um den durch einen Angriff auf ein IT-System entstandenen Schaden zu minimieren - oder um den Angriff gegen ein Computersystem teurer zu machen, als den möglichen Nutzen den der Angreifer daraus ziehen kann. Beispielsweise wird niemand auf die Idee kommen, einen militärischen Sicherheitszaun um ein Erdbeerfeld zu errichten. Der Grund hierfür ist, dass auch ohne Sicherheitszaun der Aufwand Erdbeeren zu stehlen höher ist, als Erdbeeren für einen geringen Betrag legal zu erwerben. Daher ist die wichtige Erkenntnis folgende: Man muss den Wert der Information und das Risiko des unerlaubten Zuganges dazu kennen. Danach kann man erst entscheiden, welche Ressourcen aufgewendet werden, um diese Daten angemessen zu schützen.

12

Kapitel 3

SicherheitskonzepteDieses Kapitel liefert einen Überblick über bisher entwickelte generische Sicherheitskonzepte, die hier von Bedeutung sind. Es stellt Sicherheitskonzepte, ihre Annahmen und Nutzungsszenarien sowie relevante Implementierungen in Betriebssystemen vor. Darüber hinaus wird dargestellt, wie sich die IT-Landschaft weg von zentralisierten, hoch gesicherten Servern hin zu verteilten Computersystemen und fließenden Informationen entwickelt und wie sich dies auf die Sicherheitskonzepte auswirkt.

3.1 Mehrschichtige und multilaterale Sicherheitskonzepte

Dieser Abschnitt präsentiert und vergleicht mehrschichtige und multilaterale Sicherheitskonzepte. Mehrschichtige Sicherheitskonzepte stammen ursprünglich aus militärischen und anderen hierar-chisch aufgestellten Organisationen, in denen Vertraulichkeit oder Sicherheitsebenen für Sicher-heitsentscheidungen verwendet werden. Multilaterale Sicherheitskonzepte definieren Sicherheits-richtlinien gemäß einer Menge von Regeln. Sie können Sicherheitsregeln auf einer „Ebene“ zwi-schen Individuen oder Rollen ausdrücken. Beide Konzepte werden nachfolgend eingeführt, ein-schließlich der wichtigsten Sicherheitsmodelle, welche die beiden Konzepte repräsentieren.

3.1.1 Mehrschichtige Sicherheit - „Multi Level Security“ (MLS)

Mehrschichtige Sicherheit implementiert eines von zwei Sicherheitszielen: Entweder Vertraulichkeit oder Integrität. Der Name ist abgeleitet von den vielen Schichten aus Privilegien, die von Subjekten für den Datenzugriff genutzt werden. MLS ist ein etabliertes und gut untersuchtes Sicherheitskonzept, das für öffentliche und militärische Verwaltung und ihre Bedürfnisse hinsichtlich Vertraulichkeit entwickelt wurde. Die Grundannahme ist, dass es Sicherheitsebenen von öffentlich („Public“) bis streng geheim („Top Secret“) gibt, die Dokumenten und Datenmengen zugeordnet werden. Der Zugang zu Dokumenten wird nur Benutzern, Programmen oder Computersystemen gewährt, die mindestens den gleichen (oder einen höheren) Sicherheitsstatus haben, als das Objekt, auf das zugegriffen wird. Solche Klassifizierungen gibt es in vielen Bereichen der Verwaltung und Regierung. Ein Beispiel wird in Tabelle 3.1 gezeigt.

MLS zielt auf die Implementierung von Sicherheitsebenen in einem Computersystem in folgender Weise ab:

Wahrung der Vertraulichkeit: Keine Information einer höheren Ebene kann aus einer tieferen Ebene eingesehen werden.

Wahrung der Integrität: Kein Subjekt einer niedrigeren Ebene kann Daten mit einer höheren Klassifizierung schreiben.

Diese beiden Eingenschaften lassen sich zusammenfassen zu:Kein Subjekt einer niedrigeren Ebene kann auf Daten mit einer höheren Klassifizierung zugreifen.

13

Sicherheitskonzepte

STRENG GEHEIM

GEHEIM

VS-VERTRAULICH

VS-NUR FÜR DEN DIENSTGEBRAUCH

(Öffentlich)

Tabelle 3.1: Beispiele für Sicherheitsebenen: Sicherheitsüberprüfungsgesetz (SÜG), §4

MLS wird in mehreren Sicherheitsmodellen genutzt und spezifiziert. Zu den wichtigsten Repräsen-tanten gehören die Modelle nach Bell-LaPadula [BeLa1973], Biba [Biba1977] und Lomac [Fras2000]. Sie werden im Kapitel zu Sicherheitsmodellen (Kapitel 4) näher betrachtet.

3.1.2 Multilaterale Sicherheit - „Multilateral Security“

Multilaterale Sicherheit befasst sich im Gegensatz zu mehrschichtiger Sicherheit nicht mit der Rei-henfolge der Sicherheitsebenen. Multilaterale Sicherheit befasst sich mit der Implementierung der Sicherheit zwischen unterschiedlichen Akteuren (Benutzer, Computersysteme und Prozesse), die im Vergleich zur mehrschichtigen Sicherheit in der gleichen Sicherheitsebene liegen können. Dazu wird die Beziehung zwischen unterschiedlichen Computersystemen untereinander in Bezug auf deren Sicherheitskriterien modelliert. Die Ziele der multilateralen Sicherheit können sehr komplex und teilweise gegensätzlich sein.

Wichtige Modelle der multilateralen Sicherheit sind Clark-Wilson [ClWi1987], Compartment / Lattice [Sand1993], Chinese-Wall [BrNa1989] und BMA [Ande1996]. Diese werden im Kapitel über Sicherheitsmodelle (Kapitel 4) besprochen.

3.2 Regelbasiertebasierte und Benutzerbestimmbare Zugangskontrolle

Dieser Abschnitt gibt einen Überblick über die grundlegenden Konzepte der Zugangskontrolle. Er fokussiert auf die traditionelle Unterscheidung zwischen der regelbasierten Zugangskontrolle (ge-nannt „Mandatory Access Control“) und der benutzerbestimmbaren Zugangskontrolle („Discretionary Access Control“). Historisch bedingt haben die zwei Konzepte einen unterschiedlichen Sicherheitsansatz. Heutzutage betrachten die meisten Zugangskontrollsysteme Regeln sowie die persönliche Identität eines Subjektes.

Regelbasierte Zugangskontrolle („Mandatory Access Control“, MAC) ist eine Art der Zugangskon-trolle, die durch die „Trusted Computer System Evaluation Criteria“ [TCSEC1985] als „Mittel zur Einschränkung des Zugangs zu Objekten, basierend auf der Klassifizierung der in ihnen enthaltenen Informationen (was durch eine Kennzeichnung dargestellt wird) und der formalen Autorisierung, d. h. Freigabe von Subjekten zum Zugriff auf Informationen dieser Klassifizierung“ definiert wurde.

14

Sicherheitskonzepte

„Mandatory Access Control“ definiert Zugangskontrollrichtlinien für Objekte, ausgehend von dem Sicherheitsstatus der Objekte. Der Zugang wird gewährt, falls die Zugangsberechtigung der Subjek-te mit den Maßgaben, mit denen die Objekte gekennzeichnet sind, übereinstimmt.

Benutzerbestimmbare Zugangskontrolle („Discretionary Access Control“, DAC) ist auch durch die „Trusted Computer System Evaluation Criteria“ [TCSEC1985] definiert als „Mittel zur Einschrän-kung des Zugangs zu Objekten, basierend auf der Identität von Subjekten und/oder Gruppen, zu de-nen sie gehören. Die Kontrollen sind frei in dem Sinne, dass ein Subjekt mit bestimmten Zugangs-rechten die Fähigkeit besitzt, diese Zugangsrechte (ggf. indirekt) an jedes andere Subjekt weiterzu-geben (sofern nicht eingeschränkt durch „Mandatory Access Control“)“.

„Discretionary Access Control“ wird üblicherweise als Gegensatz zu „Mandatory Access Control“ angesehen, welche manchmal auch als „Non-Discretionary Access Control“ bezeichnet wird.

3.3 Sicherheitskonzepte in heutigen Betriebssystemen

Dieser Abschnitt behandelt allgemeine Architekturen (z. B. FLASK oder sHype) für sichere Betriebssysteme. Er bietet eine Übersicht, die die Verwendung von Sicherheitskonzepten in heutigen Betriebssystemen aufzeigt, einschließlich SELinux und Trusted Solaris. Dabei werden SELinux und Linux verglichen, sowie andere Betriebssysteme besprochen. Die resultierende Liste kann als eine Kurzreferenz zur Sicherheitstechnik in der Praxis dienen.

3.3.1 Mehrschichtige Sicherheit

● Frei erhältliche Implementierungen von Betriebssystemen mit begrenzter MLS-Anwendbarkeit beinhalten SE-(„Security-Enhanced“)-Linux (Linux mit erweiterten Sicherheitsfunktionen) und „Trusted BSD“.

● Sun Microsystems bietet Trusted Solaris an, eine kommerzielle Version des Solaris Be-triebssystems, das Funktionen zur Sicherheitskennzeichnung von Daten enthält. Es ist aller-dings nicht für MLS zugelassen. Frühere Versionen wurden mit TCSEC B1 bewertet (die für MLS niedrigste erlaubte Ebene), während neuere Versionen unter „Common Criteria” nach EAL4+, „Controlled Access Protection Profile“ (CAPP) und „Labeled Security Protection Profile“ (LSPP) evaluiert wurden.

● BAE-Systems bietet XTS-400, ein kommerzielles MLS-unterstützendes Betriebssystem, welches vom Hersteller als „hochsicher“ bezeichnet wird. Frühere Versionen waren MLS-fähig, was durch ihre Evaluierung gemäß TCSEC B3 bewiesen wurde, jedoch wurden neuere Versionen unter den „Common Criteria“ EAL5+ evaluiert. Die genutzten Schutzprofile sind „Controlled Access Protection Profile“ (CAPP) und „Labeled Security Protection Profile“ (LSPP) beide auf der Ebene EAL3.

● IBM z/OS Version 1 Release 5 und spätere Versionen bieten eine Unterstützung mehr-schichtiger Sicherheit in z/OS. Vorgesehen für die Verwendung zusammen mit dem Datenbanksystem DB2 Version 8, bietet z/OS eine Lösung für mehrschichtige Sicherheit auf „System Z Mainframes“. Dazu wird die Möglichkeit geboten, in DB2 zeilenweise Sicherheitskennzeichnungen vorzunehmen. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) vergab an IBM im März 2006 das Zertifikat über EAL4+ für z/OS 1.7 mit der RACF-Zusatzfunktionalität.

15

Sicherheitskonzepte

3.3.2 Regelbasierte Erzungene Zugangskontrolle - „Mandatory Access Control“

● SELinux erweitert den Linux Betriebssystemkern um eine Architektur für „Mandatory Access Control“. Diese Funktionalität wurde im August 2003 in die Hauptlinie des Betriebssystemkerns eingefügt. Die RedHat Enterprise Linux Version 4 (und spätere Versionen) haben einen SELinux-fähigen Betriebssystemkern. SELinux benutzt die Linux Sicherheitsmodule („Linux Security Modules“, LSM) des Linux-Betriebssystemkerns 2.6.

● Die SUSE GmbH entwickelte eine MAC-Implementierung mit dem Namen „AppArmor“.

● Trusted Solaris von Sun verwendet einen verbindlichen und vom Betriebssystem durchge-setzten Zugangskontrollmechanismus, bei dem Freigaben und Bezeichnungen zur Durchsetzung einer Sicherheitsrichtlinie verwendet werden.

3.3.3 Benutzerbestimmbare Zugriffskontrolle - „Discretionary Access Control“

Benutzerbestimmbare Zugriffskontrolle (engl. „Discretionary Access Control“, DAC) wurde in vie-len Betriebssystemen implementiert. Hier sind insbesondere die Unix-artigen Betriebssysteme sowie diejenigen der WindowsNT-Familie zu nennen.

16

Kapitel 4

SicherheitsmodelleDieses Kapitel behandelt Sicherheitsmodelle, wobei der erste Abschnitt auf grundlegende Ansätze zur Datensicherheit eingeht und die folgenden Abschnitte spezifische Sicherheitsmodelle der wis-senschaftlichen Literatur und Praxis zusammenfassen. Am Ende dieses Kapitels werden die Imple-mentierungen der Sicherheitsmodelle in relevanten Betriebssystemen betrachtet.

4.1 Zugangskontrolle, Informationsflusskontrolle und „Type Enforcement“

In diesem Abschnitt werden die grundlegenden Ansätze der Zugangskontrolle und ihre Unterschie-de vorgestellt. Die drei Ansätze zur Zugangskontrolle (Schutz der Zugangsrechte von Daten), Infor-mationsflusskontrolle (Schutz, wohin Daten bewegt werden können) und „Type Enforcement“ (bei dem Objekte zu Typen gehören, die nur von Subjekten einer bestimmten Gruppe manipuliert wer-den können, die Rechte zu diesem Typ von Daten haben) werden besprochen und zusammengefasst. Darüber hinaus werden etablierte Modelle zu diesen drei Ansätzen vorgestellt und ihre Eigenschaften näher erläutert.

4.1.1 Zugangskontrolle

Die Zugangskontrolle ist eine Technik, um Zugangsrechte zu Daten oder Systemfunktionen zu ver-walten. Dies impliziert das Erstellen und Pflegen der Rechte von Subjekten, um auf Daten oder Systemressourcen zuzugreifen. Aus technischer Sicht kann die Zugangskontrolle das Recht eines Prozesses sein, um Zugang zu Daten zu erhalten, Programme zu starten oder Dienste auf anderen Computersystemen, Webseiten oder Datenbanken eines Computernetzes zu benutzen.

Zugangskontrolle ist eine der ältesten Methoden der Computersicherheit. Üblicherweise wird davon ausgegangen, dass der Computer physikalisch vor dem Zugang durch nicht autorisierte Personen geschützt ist. Hieraus entstand eine unüberschaubare Anzahl an Zugangsberechtigungstechniken, die in allen Ebenen der Computersysteme eingesetzt werden. Zum besseren Verständnis wird nachfolgend ein Schalenmodell von Schutzbereichen genutzt, das ein IT-System von außen nach innen durchzieht. Ein Beispiel dafür ist in Abbildung 4.1 dargestellt.

Im äußersten Bereich werden Zugangsmechanismen wie Passwörter, „Single Sign On“ (Einmalan-meldung), Zugang durch Smartcards, Firewalls, sichere Bildschirme und weitere Maßnahmen als Schnittstellen zum Computer gezeigt. Je weiter man in tiefere Bereiche kommt, umso detaillierter und systemnaher wird die Zugangskontrolle.

17

Sicherheitsmodelle

Zu beachten ist, dass einige der geschützten Ressourcen in unterschiedlichen Bereichen auf unter-schiedliche Art und Weise gehandhabt werden: beispielsweise kann Speicher außerhalb des Be-triebssystemkerns auf Basis von Nutzern oder Programmen verwaltet werden. Von der Hardwareseite her betrachtet, ist Speicherverwaltung die Durchsetzung einer geeigneten elektroni-schen Zugangskontrolle für den Datenfluss zwischen Chips.

Zusätzlich können sich einige der Funktionen zu anderen Ebenen bewegen, sofern das Computer-system Teil eines verteilten Computersystems in einem Netz ist.

Die meisten Aktivitäten der Zugangskontrolle haben mit Maßnahmen zu tun, die Zugang zu Subjekten gewähren. Mechanismen zur Zugangskontrolle beinhalten die folgenden drei Funktionalitäten:

1. Authentisierung: Unter Authentisierung versteht man eine Maßnahme zur Identifikation von Subjekten und Sicherung dieser Information. Dies reicht von einfachen Geheimnissen (etwa Passwörter oder Kenntnis einer IP-Adresse) bis hin zu beispielsweise biometrischen Überprüfungen.

2. Autorisieren: Der Zugang zu Daten oder Ressourcen wird durch Autorisieren geregelt. Da-bei wird z. B. ein temporäres Passwort, ein kryptographischer Schlüssel oder eine andere Berechtigungsbeglaubigung genutzt, um den Zugang zu erhalten.

18

Abbildung 4.1: Schalenmodell für Zugangskontrollbereiche auf Computersystemen

Sicherheitsmodelle

3. Audit: Die Erzeugung von Protokolldateien oder anderen Protokollen für Prüfungen wird als Auditzweck bezeichnet (Beispiele: Verantwortlichkeitsprüfung, Sicherheitsaudits oder Erkennung von Eindringlingen).

Einige Sicherheitsmodelle, die in diesem Kapitel vorgestellt werden, beruhen hauptsächlich auf Zu-gangskontrolle, beispielsweise Verwaltung der Zugangsrechte. Sie werden in Kapitel 4.3 erläutert.

4.1.2 Informationsflusskontrolle

Im Gegensatz zur Zugangskontrolle fokussieren einige Sicherheitsmodelle den Informationsfluss in oder aus einem Computersystem oder einem bestimmten Zustand. Dies ist ein wesentlicher Unter-schied zur Zugangskontrolle, bei der die Formulierung von Zugangssicherheitsrichtlinien im Vor-dergrund steht. Bei der Informationsflusskontrolle werden die Sicherheitsrichtlinien dahingehend formuliert, dass die genauen sicherheitskritischen Aktionen definiert werden, die für die Ein- oder Ausgabe von Daten relevant sind. Sicherheitsrichtlinien regeln insbesondere die mögliche Über-mittlung von Daten zwischen Computersystemen oder unterschiedlichen Sicherheitsbereichen. Die nachfolgend vorgestellten Modelle unterscheiden sich allerdings in ihren Ansätzen der Flusskon-trolle.

In der Informationsflusskontrolle wird oftmals davon ausgegangen, dass mehrere Zonen mit Sicher-heitsstufen assoziiert werden können. Oftmals wird dabei auf eine Kontrolle in den Datenbewegun-gen von einer Zone in die andere abgezielt. Eine Netzfirewall ist ein Beispiel einer Technik zur In-formationsflusskontrolle, die Sicherheitsregeln bei der Bewegung von Daten in einem Netz durch-setzt, etwa der öffentlichen Zone zur internen Zone. Ein weiteres Beispiel ist ein „E-Mailsystem“, das Kennzeichnungen zur Vertraulichkeit von Daten auswertet, bevor die „E-Mails“ weitergeleitet werden.

Das Rushby-Modell

Eines der ersten Informationsflussmodelle ist das von John Rushby [Rush1992], das die folgende Sicherheitsrichtlinien unterstützt:

1. Störfreiheit („Noninterference“): ist ein formal nachweisbarer Zustand, in dem das Beob-achten von Aktivitäten von einer Zone in eine andere nicht möglich ist. Ist dieser Zustand gegeben, sind keine versteckten Kanäle möglich. Störfreiheit wird als Relation von Grup-pen, Benutzern und Befehlen dargestellt. Benutzer einer Gruppe G stören nicht die Benut-zer der Gruppe G’, wenn Befehle der Mitglieder von G nicht den Zustand, den G sieht, ver-ändern.

2. Transitivität („Transitivity“): bezieht sich auf den Informationsfluss zwischen den Objek-ten, A, B und C. Wenn sowohl zwischen A und B als auch zwischen B und C Informationen fließen können und daraus folgt, dass auch Informationen zwischen A und C fließen, ist Transitivität gegeben.

3. Kanalsteuerung („Channel-Control“): ist die Verwendung einer Menge von Befehlen, die als Kanal bezeichnet wird, um Informationen zwischen störfreien Gruppen auszutauschen (Kommunikation).

Das Rushby-Modell ist für Betriebssysteme oder Programmumgebungen wichtig, die auf virtuellen Maschinen basieren.

19

Sicherheitsmodelle

Digitales Rechtemanagement

Informationsflusskontrolle erlangte durch die Verfügbarkeit großer Bandbreiten bei Internetverbin-dungen großes Interesse. Insbesondere entwickelte die Medienindustrie ein starkes Interesse an dem Aufbau einer Kontrolle über die Verwendung von digitalen Medien, was an dem Modell des „Digit-al Rights Management“ (digitales Rechtemanagement, DRM) endete. Hierbei ist eine technolo-gische Basis gemeint, die die Verteilung, medialer Inhalte (z. B. Audio, Videos, Texte), sowie deren Abspieleinrichtungen (z. B. DVD-Spieler, PC, Handy und MP3-Spieler) einschließt, um die Sicher-heitsrichtlinie des Herstellers und die Verbraucherlizenz bei der Nutzung der digitaler Inhalte durch-zusetzen. Insbesondere ermöglicht DRM technisch die Durchsetzung eines Kopierschutzes und von „Pay-per-View“-Sicherheitsrichtlinien („Bezahlfernsehen“).DRM verlangt eine Anzahl an anspruchsvollen kryptographischen Hilfsmitteln. Es baut normaler-weise auf Hardware mit Schutz gegen Manipulationen auf. Genutzt werden Protokolle, die Wasser-zeichen, Fingerabdruck-Techniken, Identitätsmanagement und Verschlüsselung mit Schlüsselver-waltung verwenden.

DRM beschwor eine öffentliche Debatte über faire Verwendung, Informationskontrolle und Nut-zungsrechte (engl. „Copyright“) herauf. Hierbei ging es um Befürchtungen in Richtung einer tota-len Kontrolle der Rechteinhaber über Privatrechner und Medienkonsum.

In der Praxis wurden jedoch viele DRM-Verfahren gebrochen. Ein Kopierschutz auf CDs oder ähn-lichen Medien hält typischerweise nicht lange. So werden DVDs mit PCs gelesen und anschließend digital verbreitet. Der erfolgreichste kommerzielle Online-Vertrieb für digitale Musik ist Apples iTunes. Der Kopierschutz der dort erworbenen Lieder lässt sich jedoch mit kostenlos erhältlicher Software aus dem Internet entfernen. Die Entwicklung von sicheren DRM-Plattformen in allen Be-reichen führt zu großen Kosten in der Herstellungskette der Medien, wie Lewis in [Lewi2003] be-merkte.

„Sticky Policies“ (anhaftende Sicherheitsrichtlinien)

Ein zeitgenössischer Ansatz zur Informationsflusskontrolle ist das Modell der anhaftenden Sicher-heitsrichtlinien (engl. „Sticky Policies“) [CPB2003]. Die grundlegende Idee dabei ist, dass eine Si-cherheitsrichtlinie an das passende Datenobjekt angeheftet wird. Solange das Datenobjekt dabei auf Rechnern mit sicherer Hardware, sicheren Betriebssystemen und Anwendungsprogrammen genutzt wird, kann das Datenobjekt nur gemäß der angehefteten Sicherheitsrichtlinie verwendet werden. Um ein intaktes Betriebssystem und die korrekte Anwendungssoftware zu garantieren, vertraut das „Sticky Policy“-Paradigma auf Trusted Computing [TCG0001] als eine sichere Hardwareplattform. Um Sicherheit zu erlangen, müssen „Sticky Policies“ bei jedem Schritt zusammen mit den Daten verarbeitet werden, wie in Abbildung 4.2 dargestellt.

„Sticky Policies“ stellen einige Anforderungen. Um die Sicherheitsrichtlinie auf eine Art und Weise an den Daten zu befestigen, dass sie nicht mehr entfernt werden kann, sind fortschrittliche krypto-graphische Techniken erforderlich. Die komplette Infrastruktur muss auf Trusted Computing basie-ren. Wenn ein Datenbesitzer jemals eine Sicherheitsrichtlinie ändern will, erfordert es einen nicht unerheblichen Aufwand, um das Objekt zu aktualisieren. Das zugrunde liegende kryptographische Verfahren weist eine komplizierte Schlüsselverwaltung auf.

20

Sicherheitsmodelle

4.1.3 „Type Enforcement“

„Type Enforcement“ (TE) ist eine Sicherheitsmethode, die Systemressourcen und Datenobjekte in Metagruppen einordnet, die Typen genannt werden. Gleichzeitig werden Subjekte in Domains über-tragen. Die Sicherheitsrichtlinie definiert nun, welche Domain welche Aktion auf welchen Typ aus-üben darf.

„Type Enforcement“ organisiert ein Computersystem ähnlich wie eine Firma. Finanzdateien werden dem Typ „Finanzen“ zugeordnet. Mitarbeiter von Buchhaltung und Controlling gehören demnach in die Domain „Finanzabteilung“. Die Sicherheitsrichtlinie erlaubt nur der Domain „Finanzabteilung“ einen Zugang zum „Typ Finanzen“.

Geschichte

„Type Enforcement“ wurde 1985 [BoKa1985] als eine Methode zur Implementierung von integeren Betriebssystemen (engl. „Integrity Systems“) ohne vertrauenswürdige Benutzer eingeführt. Es kennzeichnet Objekte genauso wie Subjekte und spezifiziert den Zugang von Subjekten zu Objek-ten und Subjekten zu Subjekten in zwei Matrizen. Gekennzeichnete Subjekte wurden Domains ge-nannt und gekennzeichnete Objekte nannte man Typen. Der Zugang von Subjekten an Objekte er-folgte mit Lesen, Schreiben und Ausführen. „Type Enforcement“ wurde zuerst im „Secure Ada Pro-ject“ (LOCK) implementiert und später bei TIS in „Trusted XENIX“ verwendet. „Domain and Type Enforcement“ (DTE) wurde erstmals 1991 vorgestellt [BrRo1991] und ist eine Erweiterung von TE, welche von vielen Forschern angepasst wurde [BSSW1995]. Im Gegensatz zur Darstellung mit zwei Matrizen wird die Spezifikation der Sicherheitsrichtlinien in Form einer intuitiven Sprache realisiert. Übergänge zwischen unterschiedlichen Domänen (engl. „Domain-to-Domain transitions“) werden mittels Programmen abgewickelt, die quasi als Eingangspforten auf der Empfängerseite fungieren.

Forscher der „Information Assurance Research Group“ der NSA arbeiteten mit der „Secure Computing Corporation“ (SCC), um eine starke, flexible Architektur für „Mandatory Access Con-trol“, basierend auf „Type Enforcement“, zu entwickeln. Dieser Mechanismus wurde zuerst für das LOCK-System entwickelt. Die NSA und SCC entwickelten zwei Mach-basierte Prototypen der Ar-

21

Abbildung 4.2: Schutz von Daten mittels „Sticky Policies"

Sicherheitsmodelle

chitektur: DTMach und DTOS [Smal2000]. Später arbeiteten die NSA und SCC zusammen mit der „Flux“-Forschungsgruppe der Universität von Utah daran, die Architektur auf das „Fluke Research OS“ zu übertragen. Dabei wurde die Architektur erweitert, um eine bessere Unterstützung für dyna-mische Sicherheitsrichtlinien zu bieten. Diese Erweiterung wurde „FLASK“ genannt [Smal2000]. Die NSA hat die FLASK Architektur in das Linux-Betriebssystem als SELinux integriert, um die Technik einer größeren Entwickler- und Nutzergemeinde zur Verfügung zu stellen.

Diskussion

„Domain“ und „Type Enforcement“ basiert auf einer erweiterten Version des „Type Enforcement“ (TE). Die wesentlichen Zusätze zum Originalmodell sind eine Spezifikationssprache für Sicher-heitsrichtlinien, die auf einem hohen Abstraktionsniveau angesiedelt ist und ein lesbares Format für Attributwerte in der Laufzeit-Datenbank für Sicherheitsrichtlinien. „Type Enforcement“ ist ein ta-bellenbasiertes Zugangskontrollmodell. Aktive Entitäten, die Subjekte, haben ein Attribut „Do-main“, während passive Entitäten, die Objekte, ein Attribut „Type“ besitzen. Mögliche Zugänge von Subjekten zu Objekten werden in dem Zugangsmodell nach Lesen, Schreiben, Ausführen undÜbertragen eingruppiert.

Eine globale Bereichs-Definitionstabelle (engl. „Domain Definition Table“, DDT) enthält die er-laubten Interaktionen für den Bereich und darüber hinaus Typen, die wiederum Zeilen und Spalten bilden. Jede Zelle enthält eine Menge an Zugangsmodellen.

Subjekt-zu-Subjekt-Zugangskontrolle basiert auf einer globalen Bereichs-Interaktionstabelle (engl. „Domain Interaction Table“, DIT) mit Subjekten als Deskriptoren und einer Menge an Zugangs-modi wie Signalisieren, Erstellen oder Zerstören in den Zellen.

Im Gegensatz zu dem originalen TE-Modell unterstützt DTE implizit die Pflege von Eigenschaften. Das bedeutet, dass Eigenschaften einer höheren Ebene eines Verzeichnisses in der Datenhierarchie gehalten und auf alle niedrigeren Ebenen vererbt werden, solange explizit keine anderen Eigen-schaften definiert wurden. Auch die Spezifikation der Sprache erlaubt es, Typen bestimmten Objek-ten anhand ihrer Pfadpräfixen zuzuordnen.

Dem initialen Prozess eines Betriebssystems wird eine vordefinierte initiale „Domain“ zugewiesen. Jeder Prozess kann eine andere „Domain“ betreten, indem er ein Programm ausführt, das wiederum an diese gebunden ist. Diese Programme werden Eingangspunkte (engl. „Entrypoints“) genannt. Ein solcher „Entrypoint“ kann ausgeführt werden, um explizit eine ihm zugehörige „Domain“ zu betreten, wenn die „Domain“ des Subjekts ausführbare Rechte auf der Zieldomain hat. Das automa-tische Zugangsrecht zu der Domain wählt automatisch diese Domain, wenn einer ihrer Eingangs-punkte ausgeführt wird.

Die User-Domain-Beziehung baut komplett auf Eingangspunkten (engl. „Entrypoints“), wie zum Beispiel einer Eingabeaufforderung (engl. „Command-Shell“), auf. Ein Anmeldeprogramm, wel-ches DTE unterstützt, kann aus allen Domains auswählen, die mit einem „Entrypoint“ assoziiert sind, um individuelle Kopien jeder Domain zu vermeiden.

Bedeutung

Der Hauptbeitrag von „Type Enforcement“ zur Informationssicherheit ist seine Fähigkeit, das Risi-ko von stark privilegierten Prozessen zu reduzieren, z. B. auf einem Unix-System, das von einem Angreifer übernommen wurde. „Type Enforcement“ kann dazu verwendet werden, um einen sol-chen Angriffsprozess dazu zu zwingen, sich der Typensicherheitsrichtlinie des Datenobjekts ent-

22

Sicherheitsmodelle

sprechend zu verhalten, selbst wenn der Prozess normalerweise eine deutlich größere Macht über das Datenobjekt besitzt. „Type Enforcement“ wurde in FLASK5, Microsofts „Active Directory“ und SELinux implementiert. „Type Enforcement“ ist eine eingetragene Handelsmarke der „Secure Computing Corporation“, die eine „Firewall“ mit „Type Enforcement“ („Sidewinder G2 Security Appliance“) nach „Common Criteria” EAL4+ mit Basic und Medium Protection Profiles evaluiert hat.

4.2 Grundlegende Sicherheitsmodelle

Die Modelle, die in diesem Abschnitt vorgestellt werden, sind bereits gut etabliert und leicht ver-ständlich. Sie wurden in der einen oder anderen Form in nahezu allen Betriebssystemen von „Main-frames“ bis hin zu Mobiltelefonen implementiert. Im Nachfolgenden werden die einzelnen Modelle vorgestellt, um die Unterschiede zu den fortgeschrittenen Sicherheitsmodellen besser heraustreten zu lassen.

4.2.1 Besitzerbasierte Sicherheitsrichtlinien

Besitzerbasierte Sicherheitsrichtlinien sind Sicherheitsschemata, in denen der Besitzer eines Daten-objekts eine Sicherheitsrichtlinie definieren kann, die Zugangsrechte zu anderen Objekten gewährt oder verweigert.

Geschichte

Die meisten Betriebssysteme für Mehrbenutzersysteme setzten eine Form der besitzerbasierten Si-cherheitsrichtlinien ein, um Gruppenarbeit zu ermöglichen.

Diskussion

Besitzerbasierte Sicherheitsrichtlinien können in Sicherheitsmodellen wie HRU (Harrison, Rurro, Ulman) formuliert werden.

Bedeutung

Besitzerbasierte Sicherheitsrichtlinien lassen sich in vielen heutigen Computersystemen wiederfin-den, beispielsweise gemeinsame Arbeitsumgebungen oder Datenzugriff in lokalen „Adhoc“-Netzen. Besitzerbasierte Sicherheitsrichtlinien können in größeren Sicherheitsmodellen mit eingeschlossen werden, solange sie durch diese anderen Modelle ausgedrückt werden können.

4.2.2 Zugangskontrolllisten - „Access Control Lists“

Zugangskontrolllisten („Access Control Lists“, ACL) sind eine der ältesten Formen eines Sicher-heitsmodells. Dabei werden für jedes Subjekt in einer Liste die Objekte und Aktionen definiert, die ausgeführt werden dürfen.

5 FASK ist eine Sicherheitsarchitektur für Betriebssysteme, die Sicherheitsrichtlinien flexibel unterstützt. Es ist ein Akronym für „Flux Advanced Security Kernel“ [SSLHAL1999]. „Type Enforcement“ ist ein „Kernframework” in sicherheitsorientierten Betriebssystemen, wie dem „Security-Enhanced Linux“ (SE-Linux) der NSA und „Trusted BSD“.

23

Sicherheitsmodelle

Diskussion

Zugangskontrolllisten gewähren Zugangsrechte. Sie formulieren eine bestimmte Sicherheitsrichtli-nie für Objekte, Subjekte und Aktionen. Eine Zugangskontrollliste für eine Datei „salaryfile“ könn-te wie folgt aussehen:

John „salaryfile“ „read“

Jane „salaryfile“ „read“, „write“

Ben „salaryfile“ „read“, „write“, „move“, „delete“

Hierbei ist Ben der Geschäftsführer mit der Erlaubnis, die Datei „salaryfile“ zu verschieben oder zu löschen. Jane darf auf sie schreiben, sie ist die Sekretärin. John (als Buchhalter) darf sie nur lesen.

Diese Art der Zugangskontrolle ist im Detail sehr wartungsintensiv bei Änderungen an Daten, Per-sonal oder Zugangsregeln.

Bedeutung

ACLs sind allgegenwärtig. Man kann relativ sicher annehmen, dass sie nie aus Computersystemen verschwinden werden. Der Grund dafür liegt darin, dass ihr einfaches und intuitives Konzept leicht definiert und implementiert werden kann, beispielsweise in Prototypen oder Anwendungsprogram-men, die nicht für hohe Sicherheitsanforderungen entwickelt wurden.

Beispiele von Zugangskontrolllisten in heutigen Computersystemen sind:

● Zugang zu Webservern: Die Dateien „.htaccess“ und „.htpasswords,“ die in vielen Web-ser-vern zur Zugangskontrolle verwendet werden, bieten durch die Möglichkeit der Gruppen-definition Unterstützung für ACLs. Bei Webservern sind die Grenzen des ACL-Konzepts gut erkennbar. Ein großer Online-Verleger wird seine Zugangskontrolle für tausende seiner Kunden mit anderen Mechanismen als durch „.htaccess“-Dateien realisieren.

● „Firewall“ und „Routing-Equipment“: Hier werden einfache Listen des erlaubten Datenver-kehrs mit Quell- und Zieladresse (Subjekte) und Protokolle (Objekte) benutzt, um grundle-gende Netzsicherheit zu konfigurieren.

Zur komfortablen Verwendung von ACLs sind für den jeweiligen Anwendungsfall meist auch pas-sende Managementprogramme verfügbar. Zusammenfassend lässt sich festhalten, dass ACLs durch den Einsatz von Werkzeugen zum Sicherheitsrichtlinienmanagement, die komplexe Listen bearbei-ten können, sehr praktisch sind.

4.3 Vertraulichkeitsorientierte Modelle

Dieser Abschnitt enthält eine Übersicht über Sicherheitsmodelle, die sich auf die Vertraulichkeit des Zugangs von Subjekten zu Datenobjekten in einem Betriebssystem befassen. Strenge Vertraulich-keit bedeutet hierbei, dass keine Daten gegenüber nicht autorisierten Subjekten offen gelegt werden. Die Modelle beinhalten teilweise genaue Regeln, wie eine Zugangsrichtlinie für unterschiedliche Subjekte oder Gruppen von Subjekten beschrieben wird.

24

Sicherheitsmodelle

Unterschiedliche Ansätze zur Durchsetzung von Vertraulichkeitsregeln wurden entwickelt. Nachfol-gend wird jeweils ihr Ansatz erläutert und ihre Haupteigenschaften zusammengefasst. Dabei wird mit den klassischen Modellen der statischen Zugangskontrolle begonnen und anschließend zu den mehr dynamischen Ansätzen und komplexeren Sicherheitsrichtlinien übergegangen.

4.3.1 Zugangsmatrixmodell/Zugangskontrolllisten

Das Zugangsmatrixmodell und seine Instantiierung, die Zugangskontrollliste (ACL), ist eines der ältesten Sicherheitsmodelle. Es geht von einer Aufteilung des Computersystems in Datenobjekte,Subjekte und Operationen aus. Um festzustellen, ob ein bestimmtes Subjekt eine bestimmte Opera-tion auf einem Objekt ausführen darf, zieht das Sicherheitsmodell die Berechtigungen in einer Zu-gangsmatrix oder Zugangskontrollliste zurate.

Dort wird entweder eine Auflistung aller Objekte und aller Subjekte als Matrix mit allen möglichen Operationen oder eine Liste aller Objekte und Subjekte mit ihren spezifischen Sicherheitsrichtlinien dargestellt. ACL ist eine speicherschonende Darstellung der Matrix, die nur positive Einträge er-laubter Operationen enthält, wobei hier die ohnehin nicht erlaubten negativen Einträge weggelassen werden.

Geschichte

Sicherheit auf Basis von Zugangsmatrizen wurde 1971 [Lamp1971] eingeführt. Als intuitives Sche-ma wurde es in vielen Bereichen, z. B. in Betriebssystemen wie Unix oder in der Zugangskontrolle für Datenbanken, verwendet. Es wird bis heute z. B. bei der Konfiguration von „Firewalls“ oder beim Filtern unerwünschter E-Mails (engl. „Spam“) eingesetzt.

Diskussion

Obwohl sie ein intuitives Modell ist, hat die Zugangsmatrix ein inhärentes Problem. Die Matrix re-präsentiert den Status des Sicherheitsmodells zu einem ganz bestimmten Zeitpunkt. Bei jeder Ände-rung eines Benutzers, jeder Hinzunahme neuer Objekte oder Änderungen an der Sicherheitsrichtli-nie muss die gesamte Matrix neu erstellt werden, was mühsam und fehleranfällig ist.

Bedeutung

Teile des Zugangsmatrixmodells existieren in Unix-Systemen. Einige Produkte, die auf Filter spe-zialisiert sind, wie „Firewalls“ und „Spam“-Filter, erlauben die Konfiguration von Listen für Aus- und Einschluss (engl. „Black“ / „White Lists“), die eigentlich ACLs sind. Bei Mobiltelefonen können Anruferlisten verwaltet werden, die ACLs von Anrufern darstellen, bezogen auf die Erreichbarkeit der Ressource „Telefonbesitzer“.

Mit der Verbreitung von „Instant Messaging“, „Voice over IP“ und web-basierten „Communities“ erscheinen ACLs wieder als „Buddylists“ oder Kontaktlisten, in denen der Grad der Kommunikati-on und Information bestimmt wird, den man mit anderen Teilnehmern eines Kommunikationssys-tems teilt.

Bestehende Implementierungen von ortsbasierten Diensten im Bereich der Mobiltelefonie erfordern das Management von Zugangskontrollmatritzen der Telefonbenutzer [Snek2001]. Dabei wird vom Benutzer die Aktualisierung und Pflege seiner Matrix erwartet, welche Dienstleister die Erlaubnis

25

Sicherheitsmodelle

haben, seine Position im Mobilfunknetz zu ermitteln. Die Anbieter bezeichnen dies als ein sicheres Modell der Privatsphäre, dem Benutzer jedoch bleibt das Problem des hohen Verwaltungsaufwan-des.

4.3.2 Gitterbasiertes Zugangskontrollmodell

In der Computersicherheit ist eine gitterbasierte Zugangskontrolle (engl. „lattice-based access con-trol“, LBAC) eine komplexe Methode, um den Zugang zu Daten zu beschränken, basierend auf je-der Kombination von Objekten (wie Ressourcen, Computer und Anwendungsprogrammen) und Subjekten (wie Individuen, Gruppen oder Organisationen) [Sand1993].

In diesem Typ der Zugangskontrolle wird ein Gitter verwendet, um die Sicherheitsebenen zu defi-nieren, die einem Objekt zugeordnet sind und zu denen ein Subjekt Zugang haben kann. Das bedeu-tet, man definiert eine partielle Ordnung der Sicherheitsebenen derart, dass jeweils zwei Sicher-heitsebenen immer eine größte untere Schranke („meet“) und kleinste obere Schranke („join“) ha-ben. Wenn zwei Objekte A und B kombiniert werden, um ein Objekt C zu bilden, wird dieses Ob-jekt einer Sicherheitsebene zugewiesen, die durch die Verbindung der Ebenen A und B entsteht. Wenn zwei Subjekte gemeinsam Zugang zu sicheren Daten erlangen wollen, wird ihr Zugangslevel als „meet“ der beiden Subjekte definiert. Ein Subjekt darf nur Zugang zu einem Objekt erhalten, wenn die Sicherheitsebene des Subjekts größer oder gleich der Ebene des Objektes ist, wie in der partiellen Ordnung des Gitters definiert.

Geschichte

Gitterbasierte Zugangskontrollmodelle wurden 1976 erstmals formal definiert [Denn1976]. Sie wurden für das komplexe Rechtemanagement entwickelt.

Diskussion

LBAC ist bekannt als eine spezifischere Menge an Zugangskontrollbeschränkungen und wird allge-meiner als rollenbasierte Zugangskontrolle bezeichnet. Sie erlaubt die Definition von komplexen Sicherheitsrichtlinien. LBAC ist eines der wenigen Modelle, das sich um die Erstellung des Sicher-heitsstatus zusammengefügter Daten kümmert und führt deshalb zur Idee, das „Data Life Cycle Management“ mit IT-Sicherheit zu versehen. Ein Gittermodell ist eine mathematische Struktur, die größte untere Schranken und kleinste obere Schranken für ein Paar aus Elementen wie Subjekte und Objekte definiert.

Jedoch erfordert das Gittermodell komplexe Gitterstrukturen, die wiederum frei von Fehlern sein müssen. Zusätzlich muss das Gitter bei Veränderungen neu erstellt werden (z. B. nach dem Löschen von Benutzern oder dem Wechsel von Sicherheitsebenen).

Bedeutung

Die wahre Stärke des Gittermodells ist seine Fähigkeit, komplexe Informationsflüsse und zugehöri-ge Sicherheitseigenschaften zu modellieren. In der wissenschaftlichen Literatur wurden zwei Nut-zungsbereiche des Gittermodells identifiziert und veröffentlicht:

26

Sicherheitsmodelle

● Zugangskontrolle zu Dokumenten: Mit der Entwicklung des „World Wide Web“ wurde der Zugang zu Dokumenten über Webserver für die Sicherheitsfachleute interessant [Dr-Ne1998]. Strategien zur Handhabung der Zugangskontrolle im Lesen, Schreiben, Bewegen und Zusammenfügen von Dokumenten wurden entwickelt und als gitterbasiertes Sicher-heitsmodell gestaltet.

● Sicherheitsrichtlinienmangement (engl. „Policy Management“) für computerunterstützte Zusammenarbeit (engl. „Computer supported cooperative work“, CSCW): In Verallgemei-nerung des obigen Themas sind CSWS-System Plattformen für computerbasierte Kommu-nikation, Dokumentmanagement und Gruppenzusammenarbeit (z. B. Verzeichnisse, Datei-en, Nachrichten). Zum Modellieren von Zugangssicherheitsrichtlinien wurde das Gittermo-dell erfolgreich eingesetzt.

4.3.3 Dynamisches Zugangskontrollmodell (HRU)

Das dynamische Zugangskontrollmodell erweitert das statische Konzept der Zugangskontrolllisten, Matrizen oder gitterbasierter Modelle durch die Fähigkeit der dynamischen Vergabe und Entfernung von Rechten. In statischen Zugangsmodellen ändert der Systemadministrator für eine Menge an Rechten die Liste oder Tabelle mit den Definitionen. Bei Änderungen der Bedingungen muss der Systemadministrator die Definitionen einiger Subjekte anpassen. Dies ist auf Plattformen mit vielen Benutzern ineffizient und fehleranfällig, was die Sicherheit kompromittieren kann.

Die dynamische Zugangskontrolle bietet Mechanismen, um Sicherheitsprivilegien dynamisch zu anderen Subjekten zu delegieren, ohne dabei die Hilfe des Systemadministrators zu beanspruchen oder ohne eine Aktualisierung der Systemkonfiguration durchzuführen. Dieses Modell wurde nach seinen Erfindern Harrison, Rurro und Ulman HRU benannt [HaRU1976].

Geschichte

Das dynamische Zugangskontrollmodell wurde 1976 durch Harrison, Rurro und Ulman eingeführt [HaRU1976]. Als Grundlage des Modells dient die Verwendung einer mathematischen Reduktion zur Überprüfung, ob eine neue Regel die Sicherheit eines Computersystems kompromittiert.

Diskussion

HRU beinhaltet grundlegende Befehle zur Beschreibung von Änderungen in Zugangskontrollmatri-zen. Sie basiert auf sechs Basisoperationen: „ENTER“-Regel, „DELETE“-Regel, „CREATE“-Sub-jekt, „DESTROY“-Subjekt, „CREATE“-Objekt, „DESTROY“-Objekt. Durch die Verwendung von HRU können Subjekte Regeln mit der Delegation von Rechten in die Zugangskontrollmatrix einge-ben. Harrison, Rurro und Ulman modellierten HRU als Automat. Sie zeigten, dass unter bestimmten Bedingungen die Maschine immer entscheiden kann, ob die Plattform sicher ist. Einer ihrer Haupt-beiträge war der Nachweis, dass unter bestimmten Bedingungen für ein Zugangskontrollmatrixsys-tem mit Delegieren algorithmisch nicht effizient entscheidbar ist, ob das Regelwerk sicher ist oder nicht. Der Grund liegt dabei in der Komplexität der resultierenden Regeln.

27

Sicherheitsmodelle

Bedeutung

HRU war ein wichtiger Beitrag zur Computersicherheit. Ihre nachgewiesenen Sicherheitsfunktio-nen und bekannten Schranken führten zu HRU-ähnlichen Implementierungen in Betriebssystemen, beispielsweise im „Type Enforcement“-Konzept, wo temporäre Privilegien gebraucht werden.

4.3.4 Einfache Sicherheitsplattformen

Sicherheitsplattformen reflektieren eine einfache, plattformbasierte Klassifikation von Daten, wie z.B. anhand eines Mehrebenen-Schemas, wie in Abbildung 3.1 gezeigt. Die Ebenen werden mit Zu-gangsregeln verbunden, die definieren, wie ein Benutzer Zugang zu Dokumenten auf unterschiedli-chen Ebenen erhalten kann. Beispielsweise impliziert ein bestimmter militärischer Rang Zugriff auf eine bestimmte Zugangsebene.

Geschichte

Sicherheitsebenen kommen aus dem Umgang mit militärischen Dokumenten. Die Ebenen korre-spondieren normalerweise mit einer Hierarchie, in der die Position eines Subjekts in der Hierarchie auch die Zugangsebene des Dokuments definiert.

Diskussion

In einfachen Sicherheitsplattformen können viele Sicherheitsrichtlinien zur Zugangskontrolle definiert werden. Lesen (Vertraulichkeit) und Schreiben (Integrität) werden normalerweise getrennt behandelt. Probleme treten auf, falls sich die Ebene eines Dokuments beim Verbinden mit Informationen aus einer anderen Ebene ändert. Sichere Plattformen können jedoch den Lebenszyklus von Dokumenten nicht abbilden.

Bedeutung

Während die meisten Regierungen Dokumente nach Sicherheitsebenen einstufen, wurden viele Pro-bleme in dem originalen Modell der Sicherheitsplattform gefunden. Nach Anderson [Ande2001] wurden Dokumente nach und nach in immer höhere Sicherheitsebenen eingestuft. Darüber hinaus schien der Sicherheitszugang von älteren Angestellten über die Jahre hinweg immer weiter ausgeweitet zu werden in Richtung höherer Sicherheitsstufen. Damit verwandelten sie sich in ein Sicherheitsrisiko, weil sie Zugang zu immer mehr geheimen Dokumenten erlangten. Eine Aufgabentrennung zwischen unterschiedlichen Arbeitsgruppen kann mit einfachen Sicherheitsplattformen nicht modelliert werden. Ermöglicht wurde dies durch eine Aufteilung in einzelne Sicherheitsbereiche (siehe Abschnitt 4.5.2). Das Bell-LaPadula Modell (Abschnitt 4.3.5) zielt hier auf eine Verbesserung ab.

4.3.5 Bell-LaPadula Modell

Das Bell-LaPadula Modell (BLP) [BeLa1973] ist ein formales Modell zum Statusübergang einer Sicherheitsrichtlinie eines Computers. Es beschreibt eine Menge an Regeln zur Zugangskontrolle, die Sicherheitskennzeichnungen an Objekten und Freigaben für Subjekte verwenden. Das Modell geht davon aus, dass jeder Zugang zu Daten eines Computersystems durch Sicherheitszugangsfunk-tionen erfolgt, die Teil des Sicherheitssystems selbst sind.

28

Sicherheitsmodelle

Geschichte

Das Bell-LaPadula Modell wurde 1973 vorgestellt. Die Autoren formalisierten Computersysteme unter Verwendung der Systemtheorie und boten ein komplettes Modell, das Subjekte, Objekte, Si-cherheitsebenen und Aktionen beinhaltet.

Diskussion

In diesem formalen Modell werden die Entitäten in einem Informationssystem in Subjekte und Ob-jekte eingeteilt. Die Bezeichnung eines „sicheren Status“ wird definiert, und es wird bewiesen, dass jede Umwandlung des Status die Sicherheit dadurch gewährt, indem von einem sicheren in einen anderen sicheren Status gewechselt wird. Dabei wird induktiv bewiesen, dass die Sicherheit eines Computersystems die Sicherheitszielsetzung erfüllt. Das Bell-LaPadula-Modell basiert auf dem Konzept eines Automaten (engl. „State Machine“) mit einer Menge an erlaubten Zuständen. Der Übergang von einem Zustand zu einem anderen ist durch die Übergangsfunktion (engl. „Transition Function“) definiert.

Das Sicherheitsmodell ist auf Zugangskontrolle ausgerichtet und wird durch folgende Formulierung charakterisiert: „Lesen in eine höhere Ebene verweigern“, „schreiben in eine tiefere Ebene verwei-gern“ (engl. „no read up“, „no write down“). Mit Bell-LaPadula können Benutzer Inhalte oder Da-ten nur in oder oberhalb ihrer eigenen Sicherheitsebene erzeugen und Subjekte können den Inhalt nur in oder unter ihrer Sicherheitsebene lesen.

Hierzu sind im Bell-LaPadula-Modell eine einfache Sicherheitseigenschaft und eine Sterneigen-schaft (*) folgendermaßen definiert:

1. Die einfache Sicherheitseigenschaft definiert, dass ein Subjekt einer Sicherheitsebene kein Objekt einer höheren Ebene lesen kann (engl. „no read-up“).

2. Die Sterneigenschaft (*) definiert, dass ein Subjekt einer Sicherheitsebene kein Objekt ei-ner niedrigeren Sicherheitsebene schreiben kann (engl. „no write-down“).

Bedeutung

Das Modell nach Bell-LaPadula hat das Modellieren von IT-Sicherheit seit seiner Vorstellung stark beeinflusst. Eine angepasste Implementierung im „Mainframe Timesharing Operating System“ MULTICS6, die 1965 begonnen wurde, brachte das Modell erstmals in die Praxis. Bald wurde Bell-LaPadula durch die TCSEC „Trusted Computer System Evaluation Criteria“ referenziert7.

Heutige Betriebssysteme wie Windows NT/Vista und Trusted Solaris mit Evaluierung nach TC-SEC implementieren Versionen des Modells (eine Liste der Betriebssysteme findet sich in [Bell2005]).

Heutige Forschungsansätze basieren noch immer auf dem Bell-LaPadula-Modell. In [Snek2001] wird beispielsweise ein Modell einer Zugangsmatrix bei der Zugangskontrolle zu Ortsinformatio-nen bei ortsbezogenen Diensten für Mobiltelefone mit dem BLP-Modell kombiniert.

6 Zur Geschichte von MULTICS, siehe http://www.multicians.org/history.html, Stand November 2007

7 Die „Trusted Computer System Evaluation Criteria“ (TCSEC) wurden in den USA entwickelt und 1983 veröffentlicht, um Sicherheitseigenschaften von Computersystemen zu evaluieren. Sie werden auch auf-grund der Farbe des Heftes, in dem sie veröffentlicht wurden, als „Orange book“ bezeichnet. http://csrc.nist.gov/publications/history/dod85.pdf.

29

Sicherheitsmodelle

4.3.6 Rollenbasierte Zugangskontrolle

Die Rollenbasierte Zugangskontrolle (RBAC) hat einen einzigartigen Ansatz. Das grundlegende Konzept ist die Steuerung des Zuganges zu Objekten durch genau definierte Rollen. Deshalb ist nicht eine bestimmte Identität des Benutzers für die Zugangsentscheidung von Bedeutung, sondern seine Rolle. Das auf dem RBAC-Modell aufbauende Sicherheitsmanagement ist das Managementder Möglichkeit von Subjekten, bestimmte Rollen anzunehmen. Subjekte werden Gruppen zugeord-net, Zugangsrechte werden nach Rollen gruppiert und die Verwendung von Ressourcen wird auf Benutzer beschränkt, die die jeweils zugehörige Rolle einnehmen können. Beispielsweise kann die Rolle eines Arztes in einem Krankenhaussystem die Erstellung von Diagnosen beinhalten, sowie Medikamente zu verordnen und Labortests anzuordnen. Die Rolle eines Forschers kann darauf be-schränkt sein, anonymisierte medizinische Informationen für Studien zu sammeln.

Eine Rollenhierarchie definiert Rollen, die eindeutige Attribute besitzen, die wiederum andere Rol-len beinhalten können. Das bedeutet, dass eine Rolle möglicherweise Operationen beinhaltet, die auch einer anderen Rolle zugeordnet sind.

Geschichte

Die rollenbasierte Zugangskontrolle (RBAC) wurde 1992 in [FeKu1992] veröffentlicht.

Diskussion

RBAC erlaubt es einem Subjekt, viele Rollen zu haben. Eine Rolle kann durch unterschiedliche Subjekte angenommen werden. Eine Bedingung setzt eine einschränkende Regel auf das potentielle Vererben von gegensätzlichen Rollen. Das kann verwendet werden, um eine angemessene Trennung der einzelnen Aufgaben zu erreichen. Beispielsweise kann es derselben Person nicht erlaubt sein, ein Nutzerkonto für jemanden zu erstellen und gleichzeitig die Erlaubnis dieser Erstellung an die zweite Person weiter zu vererben.

In einer Organisation, die Anforderungen an hunderte von Computersystemen und Anwendungspro-grammen stellt, wird die Verwendung von RBAC ohne eine hierarchische Erstellung von Rollen und Abgrenzungsprivilegien extrem komplex.

Seit seiner ersten Veröffentlichung wurde das Modell immer weiterentwickelt. Seither gewann es in modernen Betriebssystemen stark an Bedeutung. Eine Referenz ist das Buch „Role Based Access Control“ des Entwicklers [FKC2003].

Bedeutung

Die Verwendung von RBAC zur Verwaltung von Nutzerrechten in einzelnen Betriebssystemen oder einem Anwendungsprogramm wird im Allgemeinen heutzutage als „best practice“ angesehen. Viele Datenbanksysteme, unter ihnen Microsoft „Active Directory“, SELinux, FreeBSD, Solaris, Oracle DBMS, PostgreSQL 8.1, SAP R/3 und viele andere implementieren effektiv eine Form der RBAC.

Unterschiedliche Organisationen experimentieren mit der Erstellung von RBAC-Spezifikationen. RBAC ist ein integrierter Bestandteil der Datenbanksprache SQL3 und des Sicherheitsmodells, das von „Secure European System for Applications in a Multi-vendor Environment (SESAME)“ ver-breitet wird. Zusätzlich verwendet die Sicherheitsspezifikation der „Common Object Request Broker Architecture“ (COBRA) der „Object Management Group“ (OMG) RBAC als Beispiel für einen Zugangskontrollmechanismus für die Verwendung zusammen mit der „Distributed Object

30

Sicherheitsmodelle

Technology“ der OMG.

Laufende Entwicklungen im Bereich RBAC und entsprechender Implementierungen werden auf ei-ner Webseite des US-amerikanischen National Institute of Standards and Technology NIST zusam-mengefasst und gepflegt [NIST0001].

4.3.7 „Chinese-Wall“-Modell (Brewer-Nash)

Das „Chinese-Wall“-Sicherheitsmodell [BrNa1989] wurde entwickelt, um kommerzielle Sicher-heitsinteressen in geschäftlichen Datenbanken durchzusetzen. Die Annahme dabei ist, dass es inner-halb der Finanzindustrie Interessenkonflikte, Insiderwissen und Geschäftsgeheimnisse geben kann, wenn eine Firma Geschäftsbeziehungen zu Kunden unterhält, die in gegenseitigem Konkurrenz-kampf stehen. Das „Chinese-Wall“-Modell stellt eine Chinesische Mauer zwischen sensiblen Infor-mationen konkurrierender Kunden dar. Dazu werden Kundendaten unterschiedliche Geschäftsklas-sen zugeordnet und Subjekte werden an Datenmengen gebunden. Durch eine Menge an Regeln wird durchgesetzt, dass ein Subjekt keinen Zugang zu Daten einer Firma bekommt, wenn das Sub-ject bereits Daten einer anderen konkurrierenden Firma zugeordnet ist.

Geschichte

Chinesische Mauern sind Trennmechanismen, die in Firmen verwendet werden, um Personen, die Investmententscheidungen treffen, von Personen, die Informationen besitzen, die diese Entschei-dungen beeinflussen können, zu trennen.

In den USA wurde dieser Ausdruck nach dem Börsenkrach von 1929 verwendet, als die Regierung der USA einen Erlass zur Trennung von Banken und Brokern verordnete. Anstatt einer Firma zu un-tersagen, sich in mehreren Geschäftsbereichen zu betätigen, erlaubte die Regierung die Implemen-tierung von Maßnahmen nach der „Chinese-Wall“-Methode.

Der Begriff Chinesische Mauer bezieht sich nach Wikipedia8 auf die Chinesische Mauer, ihr Aus-maß und ihre Effektivität, zwei Seiten voneinander zu trennen. Eine Alternativerklärung ist, dass der Begriff von chinesischen Stehwänden abgeleitet wurde, die zur temporären Abtrennung in Räu-men verwendet wurden. Dieser Ursprung erscheint passend in der Verwendung für Organisationen wie juristische Kanzleien, die Schranken zwischen Büros oder Anwälten aufbauen, um sich vor In-teressenkonflikten zu schützen.

In der Computersicherheit ist das „Chinese-Wall“-Modell ein Sicherheitsmodell, bei dem Lese- und Schreibrechte auf Daten durch eine Klassifizierung der Daten in Interessenkonfliktklassen geschützt werden. Dies ist das Basismodell, das verwendet wird, um sowohl Geheimhaltung als auch Integri-tät von Daten zu gewährleisten.

Die erste Veröffentlichung des „Chinese-Wall“-Modells erfolgte 1989 [BrNa1989].

Diskussion

Die Eigenschaft der Aufteilung von Aufgaben wurde als inkompatibel zum Bell-LaPadula Modellin [BrNa1989] erkannt. Jedoch schlagen die Autoren eine Erweiterung des Clark-Wilson-Modells vor, das wiederum die Sicherheitsrichtlinie der „Chinese-Wall“ implementiert.

8 Siehe http://en.wikipedia.org/wiki/Chinese_wall.

31

Sicherheitsmodelle

Das Modell enthält:

● Regeln zum Schutz vor Interessenkonflikten.

● Eine formale Beschreibung der normalen kommerziellen Praktiken zur Unterlassung von Mitteilungen.

● Die Idee, dass ein professioneller Arbeiter sich nicht mit unterschiedlichen Klienten befasst, die zueinander in Konkurrenz stehen, dass er also nicht wegen der Verwendung von Insi-derwissen belastet werden kann.

Ähnlich zum Bell-LaPadula-Modell hat das „Chinese-Wall“-Modell zwei Zugangskontrollregeln, die formal ausgedrückt werden können.

Informell kann man die Regeln folgendermaßen angeben:

1. Die einfache Sicherheitseigenschaft legt fest, dass: ein Subjekt S nur auf die Daten von C zugreifen kann, falls:

a) S schon auf die Daten von C zugegriffen hat.

b) S noch keinen Zugang zu Daten von einem Konkurrenten von C erhalten hat.

2. Die *-(Stern)-Eigenschaft legt fest, dass S nur Daten von C schreiben kann, falls S keine Daten anderer Firmen lesen kann.

Bedeutung

Sicherheitsforscher sehen das „Chinese-Wall“-Modell eher nicht als eigenständiges Modell, son-dern als ein Regelwerk, das bei der Erstellung eines Sicherheitssystems verwendet wird. Dennoch ist die Funktion für viele Geschäftsumgebungen fundamental, etwa in der Finanzwelt, der Beratung und im Gesundheitswesen.

Die Implementierung der „Chinese-Wall“-Sicherheitsrichtlinien ist sehr anwendungsabhängig.

4.4 Integritätsorientierte Modelle

Dieser Abschnitt präsentiert und bespricht integritätsorientierte Sicherheitsmodelle. Neben Vertrau-lichkeit wird ein Schutz vor unerlaubter Manipulation, Löschung oder anderen Formen des Um-gangs mit Daten in Nutzungsszenarien gefordert. Aus diesem Grund wurden integritätsorientierte Sicherheitsmodelle entwickelt. Die meisten Modelle befassen sich mit Schreibrechten entsprechend einer Hierarchie in einer Organisation, beispielsweise in der öffentlichen Verwaltung oder im Mili-tär. Weiter unten werden die drei integritätsorientierten Modelle „Biba“, „Low-Watermark“ und „Clark-Wilson“ eingeführt und miteinander verglichen. Ihre Grundannahme geht davon aus, dass jemand, der in der Hierarchie höher gestellt ist, damit auch ein kleineres Risiko für die Integrität ei-nes Dokumentes darstellt als eine Person in einer niedrigeren Position.

4.4.1 Biba Modell

Das Sicherheitsmodell von Biba sichert die Datenintegrität durch das Prüfen einer Sicherheitsricht-linie beim Schreiben von Daten [Biba1977]. Es ist ein formales Regelwerk mit Zustandsübergän-gen, das eine Menge an Regeln zur Zugangskontrolle beschreibt, die zur Sicherstellung der Daten-integrität entworfen wurden.

32

Sicherheitsmodelle

Geschichte

Das Biba-Modell wurde 1977 von Ken Biba vorgestellt. Es dient dem Schutz der Daten vor uner-laubter Manipulation.

Diskussion

Das Biba-Modell wird hier mit dem Bell-LaPadula-Modell verglichen. Während das BLP-Modell Vertraulichkeit dadurch ermöglicht, dass den Daten nur die Bewegung aufwärts oder innerhalb der-selben Sicherheitsebene erlaubt wird, garantiert das Biba-Modell, dass keine in niedrigere Sicher-heitsklassen eingruppierten Subjekte Daten in eine höhere Sicherheitsebene bewegen können.

Ähnlich zum Bell-LaPadula-Modell definiert das Biba-Modell eine einfache Sicherheitseigenschaft (engl. „Simple Security Property“) und eine *-(Stern)-Eigenschaft. In diesem Fall ist es allerdings umgekehrt im Vergleich zu Bell-LaPadula.

1. Die einfache Sicherheitseigenschaft legt fest, dass ein Subjekt einer bestimmten Ebene der Integrität kein Objekt einer niedrigeren Integritätsebene lesen darf („no read down“).

2. Die *-(Stern)-Sicherheitseigenschaft legt fest, dass ein Subjekt einer gegebenen Integritäts-ebene nicht auf ein Objekt in einer höheren Integritätsebene schreiben darf („no write up“).

Das Biba-Modell wird oft als „write-down“-Modell bezeichnet.

Bedeutung

Das Biba-Modell war für militärische und Verwaltungsanwendungen von Bedeutung. Heute können Sicherheitsrichtlinien nach Biba in einigen speziellen Umgebungen wie Tabellen zur Konfiguration von Firewalls oder medizinischen Einrichtungen bedeutsam sein. Wird ein Computersystem neu ge-startet, darf es keine Konfigurationsdaten aus einer Datei mit niedrigerer Sicherheitsstufe lesen. Schreibt ein Benutzer eine Konfigurationsdatei, ist es ihm nicht erlaubt, sie in eine Konfigurations-datei mit höherer Sicherheitsstufe zu schreiben.

4.4.2„Low-Watermark“-Zugangskontrollmodell

„Low-Watermark“ ist ein Name für viele integritätsorientierte Modelle, die vereinfacht dargestellt dafür sorgen, dass beim Schreiben auf Daten diese in die niedrigst mögliche Sicherheitsebene ein-gestuft werden. Das „Low-Watermark-Model“ steht in Beziehung zum Biba-Modell. Im Gegensatz zu Biba, in dem keine „Write-up“-Regel oder „Read-down“-Regel vorhanden ist, wird jedoch im „Low-Watermark“-Modell „Read-down“ zugelassen, jedoch wird das Objekt temporär in die Ebene des niedriger eingestuften Subjekts eingeordnet. Eine Unterscheidung von „Subject-Low-Watermark“ und „Object-Low-Watermark“ besagt, welche beteiligten Entitäten auf die jeweilige Integritätsebene herabgestuft werden.

Geschichte

Das Biba-Modell kann als subjektzentriertes „Low-Watermark“-Modell betrachtet werden. Dieser Idee folgend wurden viele Erweiterungen veröffentlicht. Das Linux-Betriebssystem implementiert eine Form von „Low-Watermark“.

33

Sicherheitsmodelle

Diskussion

„Low-Watermark“-Ansätze können Sicherheitsprobleme auf eine niedrigere Sicherheitsebene be-grenzen oder diese Probleme vermeiden. Das resultierende Konzept ist ähnlich dem „Type Enforce-ment“, das Sicherheitsprivilegien auf eine niedrigere Stufe reduziert. Üblicherweise orientieren sich „Low-Watermark“-Ansätze an Mehrebenen-Strukturen, was dazu führt, dass ihre Sicherheitsrichtli-nien eine geringere Komplexität aufweisen.

„Low-Watermark“-Modelle weisen jedoch die gleichen praktischen Probleme auf, die auch das Biba-Modell hat. Sobald die Daten in unterschiedlichen Ebenen klassifiziert sind, ist eine Änderung der Ebene von Subjekten oder Objekten sowie eine Anpassung der Sicherheitsrichtlinien oftmals komplex.

Bedeutung

„Low-Watermark“-Ansätze werden in Betriebssystemen als ein Schutzmechanismus gegen Schad-programme eingesetzt. Beispielsweise ist LOMAC ein dynamisch ladbares Sicherheitsmodul für das Linux-Betriebssystem, das „Low-Watermark Mandatory Access Control“ (MAC) zum Schutz der Integrität eines Prozesses verwendet, wie auch zum Schutz vor Viren, trojanischen Pferden, bös-artigen Anwendern an anderen Computersystemen und kompromittierten Dämonen auf Netzser-vern.

Nach [Spar2000] teilt LOMAC Daten und Prozesse in zwei unterschiedlichen Ebenen auf: Einmal geladen spaltet LOMAC das Betriebssystem in zwei konzeptionelle Ebenen der Integrität auf: hoch und niedrig. Der Teil hoher Integrität enthält alle Prozesse und Dateien, die vor bösartigem Pro-grammen und Benutzern anderer Computersysteme geschützt werden sollen: Kernserver (z. B. kflushd), die Systembinaries (/bin/*, /lib/*), die Systemkonfigurationsdateien (/etc/*) sowie alle kri-tischen Daten (z. B. eine Webseite). Der Teil niedriger Integrität enthält die Prozesse, die mit ande-ren Benutzern oder dem Computersystem („Remote Login Sessions“, „Web-Clients/Server, Mail Delivery Agents“) interagieren müssen, sowie die Dateien, die sie aus dem Netz beziehen (Webin-halte, „E-Mail“ mit/ohne Anhang). Dies ist, verglichen mit Biba, eine relativ einfache Sicherheits-richtlinie.

Für einen genaueren Einblick in die Verfügbarkeit von Implementierungen von „Low-Watermark“ wird auf die Abhandlung von Safford und Zohar [SaZo2004] verwiesen.

4.4.3 Clark-Wilson („kommerzielle Integrität“)

Das Clark-Wilson-Integritätsmodell erlaubt es, die Integritätssicherheitsrichtline für ein informati-onsverarbeitendes Computersystem zu spezifizieren. Das Modell wurde im Kontext von Banksyste-men entwickelt und 1987 von David Clark und David Wilson in [ClWi1987] formalisiert. Das Ziel war die Entwicklung eines Modells und die Formalisierung des Begriffs der Integrität von Informa-tion sowie der Schutz von Daten sowohl vor allgemeinen Fehlern, als auch vor böswilligen Verän-derungen. Im Clark-Wilson-Modell wird Integrität durch eine Menge an Bedingungen definiert. Da-ten sind in einem gültigen Zustand, wenn sie diese Bedingungen erfüllen. Wohldefinierte Umfor-mungen bewegen das Sicherheitssystem von einem gültigen Zustand in einen anderen, und eine In-tegritätssicherheitsrichtlinie beschreibt, wie Datenelemente bei dem Wechsel gültig gehalten werden sollen.

34

Sicherheitsmodelle

Geschichte

Der Ursprung des Modells von Clark-Wilson, welches in Buchhaltungssystemen bereits praktisch angewendet wurde, bevor es durch Clark und Wilson in ihrem Artikel [ClWi1987] formalisiert wur-de, wird in [ClWi2007] wie folgt beschrieben: „Dieser Artikel entwickelt das Modell als eine Mög-lichkeit, die Notation von Informationsintegrität zu formalisieren, insbesondere im Vergleich zu den Anforderungen der mehrschichtigen Sicherheitssysteme (MLS), die im „Orange Book“ beschrieben werden. Clark und Wilson argumentieren, dass bestehende Integritätsmodelle wie Bella-LaPadula („Read-down“ / „Write-up“) und Biba („Read-up“/„Write-down“) besser für die Durchsetzung von Vertraulichkeit geeignet seien, als für die Informationsintegrität. Die Bell-LaPadula und Biba-Mo-delle sind nützlicher z. B. in militärischen Strukturen, um vor dem Diebstahl von Daten oder der Beschädigung der Informationsintegrität zu schützen. Im Gegensatz dazu ist Clark-Wilson einfa-cher für Geschäfts- und Industrieprozesse anwendbar, in welchen die Integrität des Informationsge-halts in jeder Ebene von höchstem Rang ist (obwohl die Autoren betonen, dass alle drei Modelle of-fensichtlich von Regierungs- und Industrie-Organisationen verwendet werden).

Diskussion

Das Clark-Wilson-Integritätsmodell ist ein Integritätsmodell, das auf bekannten und bewährten Buchhaltungsmethoden basiert. Dabei werden Daten in zwei Ebenen eingeordnet:

1. eingeschränkte Datenelemente (engl. „Constrained Data Item“, CDI)

2. uneingeschränkte Datenelemente (engl. „Unconstrained Data Item“, UDI)

Zugang zu CDIs kann durch Umformungsprozeduren (engl. „Transformation Procedures“, TP) ex-klusiv gewonnen werden. Die Integrität von CDIs wird durch Integritätsprüfungsprozeduren (engl. „Integrity Verification Procedures“, IVP) geprüft. Es handelt sich hierbei nicht um ein formales Mo-dell, sondern um eine Menge an Regeln, die folgendermaßen definiert werden können:

● Subjekte müssen autorisiert werden.

● TPs müssen Integrität erhalten.

● Die Aufgaben müssen durch die Sicherheitsrichtlinie getrennt werden.

Clark-Wilson ist kein mehrschichtiges Sicherheitsmodell, kann jedoch beispielsweise mit Biba kombiniert werden. Es lenkte die Aufmerksamkeit in Richtung alternativer Sicherheitsmodelle, nicht nur auf MLS-Modelle nach militärischem Vorbild. Probleme sind:

● Die Implementierung von IVPs und TPs für komplexe Sicherheitssysteme ist schwierig.

● Die interne Transaktion garantiert nicht, dass die Transaktion korrekt war (allerdings ist ein „Auditing“ möglich).

Grundlage des Modells ist der Begriff einer Beziehung zwischen einem autorisierten Auftraggeber (zum Beispiel ein Benutzer) und einer Menge an Programmen (etwa TPs), die auf einer Menge von Datenelementen (etwa UDIs und CDIs) operieren. Das Modell muss ebenfalls sicherstellen, dass unterschiedliche Entitäten für die Manipulation der Beziehung zwischen Auftraggeber, Transaktio-nen und Datenelementen verantwortlich sind. Um dies zu verdeutlichen, kann folgendes kurzes Bei-spiel betrachtet werden: Ein Benutzer, der eine Beziehung beglaubigen oder erstellen kann, sollte nicht in der Lage sein, ein Programm auszuführen, das in dieser Beziehung spezifiziert wurde.

35

Sicherheitsmodelle

Das Modell besteht aus zwei Mengen von Regeln: Zertifikatsregeln (engl. „Certification Rules“, C) und Durchsetzungsregeln (engl. „Enforcement Rules“, E). Diese Regeln sichern die externe und in-terne Integrität der Datenelemente.

Die Regeln des Modells zur Durchsetzung und Überprüfung definieren Datenelemente und Prozes-se, welche die Basis für eine Integritätssicherheitsrichtlinie bereitstellen. Die Grundlage des Mo-dells basiert auf einer Notationsform für Transaktionen.

Eine wohlgeformte Transaktion ist eine Reihe von Operationen, die ein Sicherheitssystem von ei-nem konsistenten Zustand in einen anderen konsistenten Zustand transformieren. In diesem Modell befasst sich die Integritätssicherheitsrichtlinie mit der Integrität der Transaktion.

Das Prinzip der Teilung von Aufgaben erfordert es, dass der Beglaubiger einer Transaktion und der Implementierer unterschiedliche Entitäten sind. Das Modell enthält unterschiedliche Konstruktio-nen, die sowohl Dateneinheiten als auch Prozesse repräsentieren, die auf diesen Daten operieren. Der zentrale Datentyp im Clark-Wilson-Modell ist ein eingeschränktes Datenelement. Ein Integri-täts-Prüfungsablauf (engl. „Integrity Verification Procedure“, IVP) garantiert, dass alle einge-schränkten Datenelemente in einem bestimmten Zustand gültig sind. Transaktionen, die die Integri-tätssicherheitsrichtline durchsetzen, werden durch Transformationsabläufe (engl. „Transformation Procedures“, TPs) repräsentiert. Ein TP nimmt als Eingabe ein eingeschränktes oder ein uneinge-schränktes Datenelement und liefert ein eingeschränktes Datenelement zurück. Ein TP muss den Systemstatus von einem gültigen Zustand in einen weiteren gültigen Zustand überführen. Uneinge-schränkte Daten Elemente (UDIs) stellen Eingaben an das Sicherheitssystem dar (z. B. von einem Nutzer oder Angreifer). Ein TP muss garantieren, dass es alle möglichen Werte eines uneinge-schränkten Datenelementes in ein „sicheres“ eingeschränktes Datenelement umwandelt.

Das Biba-Modell im Vergleich zu Clark-Wilson

Beide Modelle haben Integritätsebenen, allerdings besitzt nur das Clark-Wilson-Modell zwei Ebe-nen für Objekte (CDIs und UDIs) und zwei Ebenen für Subjekte (TPs und andere Prozeduren).

Das Biba-Modell bietet jedoch kein Konzept zur Überprüfung. Ebenfalls gibt es keinen Mechanis-mus zur Prüfung von Entitäten, denen vertraut werden muss.

Das Biba-Modell kann das Clark-Wilson-Modell nicht emulieren, umgekehrt kann allerdings das Clark-Wilson-Modell das Biba-Modell durch eine passende Wahl der TPs in den erlaubten Tripeln emulieren.

Bedeutung

Der Clark-Wilson-Ansatz wurde so angepasst, dass er auf Unix- oder Windows NT-Systemen arbei-tet. Einige Modelle für Datenbankintegrität basieren auf dem Clark-Wilson-Modell.

36

Sicherheitsmodelle

4.5 Sonstige Modelle

Einige Modelle passen in keine der bisher vorgestellten Kategorien, auch nicht durch eine Erweite-rung, Modifizierung oder Kombination unter ihnen. Dieser Abschnitt beschreibt deshalb wichtige Sicherheitsmodelle, die nicht in die oben genannten Kategorien einzuordnen sind. Besondere Ei-genschaften dieser Modelle werden dabei hervorgehoben.

4.5.1 „British Medical Association“-Sicherheitsmodell (BMA)

Geschichte

Das BMA-Modell entstand nach einer langen Debatte zwischen der britischen Regierung, profes-sionellen Hilfsorganisationen und Sicherheitsexperten. Ein langwieriger Kommunikationsprozess war nötig, um von einer Sichtweise analog zu militärischer Perimeterabsicherung zu einem Ansatz mit multilateraler Sicherheit für medizinische Informationssysteme zu gelangen. Das BMA-Modell analysiert ausführlich Rollen, Verantwortlichkeiten und den (medizinischen) Informationsfluss in IT-Systemen, die von unterschiedlichen Subjekten im Gesundheitswesen verwendet werden. Das Modell wurde 1996 in [Ande1996] beschrieben.

Diskussion

Das BMA-Modell folgt den Prinzipien, die in [Ande2001] beschrieben werden:

Prinzip 1 - Zugangskontrolle: Jede identifizierbare klinische Information muss mit einer Zugangs-kontrollliste versehen sein, welche die Personen oder Gruppen von Personen enthält, die sie le-sen oder die Daten eintragen dürfen. Das Zugangskontrollsystem muss jeden, der nicht auf der Zugangskontrollliste steht, davon abhalten, in irgendeiner Weise Zugang zu der Information zu erhalten.

Prinzip 2 - Öffnen einer Information: Ein Klinikmitarbeiter darf eine Informationseinheit öffnen, sofern er und der jeweilige Patient auf der Zugangskontrollliste stehen. Dort, wo ein Patient re-ferenziert wird, kann er die Informationseinheit öffnen, sofern der Patient selbst und der (die) referenzierenden Klinikmitarbeiter auf der Zugangskontrollliste stehen.

Prinzip 3 - Kontrolle: Ein Klinikmitarbeiter auf der Zugangskontrollliste muss als Verantwortlicher eingetragen sein. Nur er darf die Zugangskontrollliste abändern und, nur er darf andere Ärzte, Pfleger etc. hinzufügen.

Prinzip 4 - Zustimmung und Benachrichtigung: Der verantwortliche Klinikmitarbeiter muss dem Patienten mitteilen, welche Namen auf der Zugangskontrollliste seines Berichtes erscheinen, sobald diese geöffnet wird. Zudem muss er den Patienten über anschließende Änderungen und im Falle einer Übertragung der Verantwortlichkeit informieren. Die Genehmigung des Patienten muss immer eingeholt werden, außer in Notfällen oder im Fall festgelegter Ausnahmen.

Prinzip 5 - Nachhaltigkeit: Niemand darf die Möglichkeit haben, klinische Daten vor Ablauf einer festgelegten Zeit zu löschen.

37

Sicherheitsmodelle

Prinzip 6 - Zuordnung: Jeglicher Zugang zu klinischen Berichten muss mit dem Namen des zugrei-fenden Subjekts im Bericht eingetragen werden, zusätzlich Uhrzeit und Datum. Ein Auditproto-koll über alle Löschungen muss geführt werden.

Prinzip 7 - Informationsfluss: Informationen, die auf einen Bericht A zurückgehen, dürfen genau dann in einen Bericht B aufgenommen werden, wenn die Zugangskontrollliste von B eine Teil-menge derjenigen von A ist.

Prinzip 8 - Zusammenführungskontrolle: Es muss effektive Maßnahmen zum Schutz vor der Zu-sammenführung von persönlichen Gesundheitsdaten geben. Insbesondere Patienten Benach-richtigungen erhalten, falls eine Person, der es erlaubt ist, der Zugangskontrollliste etwas anzu-fügen, bereits Zugang zu sehr vielen Gesundheitsinformationen besitzt.

Prinzip 9 - „Trusted Computing Base“: Computersysteme, die persönliche Gesundheitsdaten verar-beiten, müssen ein Teilsystem haben, das die o.g. Prinzipien effektiv umsetzt. Seine Effektivität muss durch unabhängige Experten überprüft werden.

Bedeutung

Das BMA-Modell war eines der ersten umfangreich spezifizierten Modelle, das die Sichtweise weg von einem militärisch orientierten Schutzmodell bewegte. Es bietet ein anwendungszentriertes, multilaterales Sicherheitsmodell, das Arbeitsflüsse, ein Bedrohungsmodell und einen Schutzmecha-nismus für den Anwendungsprogrammbereich betrachtet.

Die BMA-Sicherheitsrichtlinie wird sowohl im Forschungsbereich als auch nach Anderson [An-de2001] in klinischen Umgebungen eingesetzt. Die Formulierung und Ausarbeitung seiner Sicher-heitsrichtlinien sind nach der gleichen Quelle in Arbeit.

4.5.2 Sicherheitsbereiche / „Compartmented/Multi-Category Security (MCS)“

Das Konzept der Sicherheitsbereiche basiert auf einer Philosophie der Aufgabentrennung („Separation of Duty“). Hierbei werden Objekte in Sicherheitsbereichs der gleichen Zugänglichkeit eingeteilt. Ein Subjekt wird an ein Sicherheitsbereiche gebunden und darf nur Zugang zu Objekten aus demselben Sicherheitsbereich erhalten.

Geschichte

Nach Anderson [Ande2001] wurden Sicherheitsbereiche wahrscheinlich schon lange von Geheimdiensten verwendet. Die strenge Aufteilung von Kenntnissen in verantwortliche Sicherheitsbereiche schützte Agenten und Geheimnisse.

Diskussion

Sicherheitsbereiche erstellen zwischen Gruppen von Datenobjekten sehr harte Grenzen. Allerdings müssen die Gruppen definiert werden. Probleme entstehen, wenn entweder die Trennung der Daten aufgrund von Überlappungen der Daten nicht fehlerfrei durchführbar ist oder wegen der Beteiligung eines Subjekts in unterschiedlichen Sicherheitsbereiche.

38

Sicherheitsmodelle

Bedeutung

Sicherheitsbereiche allein sind heute selten anzutreffen. Die „Chinese-Wall“-Sicherheitsrichtlinie kann als ein Algorithmus angesehen werden, der dynamisch neue Sicherheitsbereiche erstellt und die Mitgliedschaft eines Subjekts zu ihnen definiert. Manche Forscher erweitern das Gittersicherheitsmodell um Kompartmentkennzeichnungen und verwenden es unter dem Begriff „Compartmented Security“.

4.5.3 „sHype“-Modell

„sHype“ [sHype] ist eine Hypervisor-Sicherheitsarchitektur, die bei IBM Research entwickelt wur-de. Ein Hypervisor ist eine Virtualisierungsplattform, die es erlaubt, mehrere Betriebssysteme gleichzeitig auf einer Computerhardware ablaufen zu lassen [Wiki0004]. Die Hypervisor-Technik hat eine lange Tradition im Bereich der Betriebssysteme. Nach IBM9 ist das Hauptziel die Bereit-stellung einer Basis für Serverplattformen, die folgende Funktionen bereitstellen (Zitat nach [sHype]):

● Starke Isolation, „Mediated Sharing“ und Kommunikation zwischen virtuellen Maschi-nen10: Diese Eigenschaften werden durch einen Mechanismus zur flexiblen Zugangskon-trolle durchgesetzt. Dieser Mechanismus kann vorgeschriebene Sicherheitsrichtlinien, wie mehrschichtige Sicherheit, rollenbasierte Zugangskontrolle und „Type Enforcement“ durch-setzen.

● Integritätsüberprüfung und Garantien für den Hypervisor und seine virtuellen Maschinen: Wir erweitern die Spezifikation der „Trusted Computing Group“ um hypervisorbasierte Serverplattformen. Unser Ziel ist es hierbei, sicheres oder authentisiertes Starten für die Hypervisorplattform, die virtuellen Maschinen und optional für die Gastbetriebssysteme so-wie die in den virtuellen Maschinen ablaufenden Anwendungsprogramme zu garantieren. Um eine große Zahl an virtuellen Maschinen zu unterstützen, haben wir eine virtuelle TPM-Architektur entwickelt, die wir auf dem FLOSS-Hypervisor Xen umgesetzt haben.

● Ressourcenkontrolle und garantierte Buchführung: Alle Ressourcen werden strikt abgerech-net. Einfache Ressourcen sind z. B. Speicher und CPU-Zyklen. Ein ausführlicheres Res-sourcenmanagement ist für die Kontrolle der Netzbandbreite nötig, beispielsweise zur Be-grenzung der Bandbreite zu einer virtuellen Maschine.

● Sichere Dienste: „sHype“ bietet eine grundlegende Infrastruktur zur Auflösung von Diens-ten, wie das Management von Sicherheitsrichtlinien oder verteiltes Auditing in kleinere und leichter zu handhabende, geschützte Ausführungsumgebungen, wodurch die systemweite Nutzung und Sicherheit ihrer Dienste ermöglicht wird.

9 Siehe http://www.research.ibm.com/secure_systems_department/projects/hypervisor/.

10 Eines der Designprinzipien hierbei ist, dass Sicherheit durch die Isolation der Anwendungsprogramme mittels jeweils einer seperaten sicheren virtuellen Maschine erreicht wird.

39

Sicherheitsmodelle

IBM hat im Bereich der FLOSS-Software eine kleine Sicherheitserweiterung des Hypervisors Xen entwickelt. Sie erlaubt es Administratoren, einfache Sicherheitsrichtlinien zu definieren (derzeit ge-mäß einem der Modelle „Chinese-Wall“ und „Type Enforcement“), die die Fähigkeiten zur Kontrol-le und Mehrfachbenutzung von virtuellen Maschinen erlauben, die simultan auf einem einfachen Xen-System laufen.

Geschichte

Der erste „Hypervisor“ war „CP-40“ von IBM, ein Forschungsprojekt, das im Januar 1967 entstand und zur ersten Version des CP/CMS-Betriebssystems von IBM wurde. Die weitere Entwicklung der „Mainframe“-Computer bestand aus Implementierungen und Erweiterungen dieser Technik, auf der Betriebssystemkerne von IBMs Hochverfügbarkeits-„Mainframe“-Servern, beispielsweise S/360 und S/370, basieren.

Diskussion

„sHype“ ist das Ergebnis von jahrzehntelanger Erfahrung auf Seiten IBMs, was verlässliche Server-systeme, Betriebssysteme und ihre Sicherheitsbelange angeht. Die komplette Virtualisierung von Hardware unterstützt viele Sicherheitsfunktionen, angefangen bei der strikten Trennung der Anwen-dungsprogramme und Daten, bis hin zur höheren Robustheit der Plattform gegen Fehlfunktionen durch ein einzelnes fehlerhaftes Programm.

„sHype“ bietet Sicherheitsfunktionen und Schnittstellen, welche die Implementierungen von Si-cherheitsmodellen basierend auf der Verlässlichkeit von Hypervisorsystemen ermöglichen.

Jedoch benötigt „sHype“ einen starken Schutz gegen sehr gut ausgestattete Angreifer und zusätzli-che Hardewareunterstützung, um die Betriebssysteme zu schützen.

Ein Hypervisorsystem führt zu einem höheren Aufwand des Systemadministrators, da mehrere In-stanzen eines oder mehrerer Betriebssysteme und die zugehörigen Sicherheitsumgebungen adminis-triert werden müssen.

Bedeutung

Im Allgemeinen ist die Hypervisortechnik am Markt gut etabliert. Die Hauptanbieter im UNIX-Be-reich, einschließlich Sun Microsystems, HP, IBM und SGI verkauften virtualisierte Hardware schon seit Ende der 90er Jahre. Typischerweise handelt es sich dabei um leistungsstarke Computersysteme (Großrechner).

Es gibt zwei Arten der Virtualisierung: „Vollvirtualisierung“ und „Paravirtualisierung“. Bei der Vollvirtualisierung wird das Gastbetriebssystem nicht modifiziert. Weiterhin hat es keine Kenntnis darüber, dass es in einer Virtualisierungsumgebung läuft. Wird Paravirtualisierung verwendet, muss das Gastbetriebssystem auf die Virtualisierungsumgebung angepasst werden. Das Betriebssystem ist in diesem Fall Teil der Virtualisierungsebene und kann dadurch gezielt optimiert werden. Para-virtualisierung kann aufgrund der erweiterten Optimierungsmöglichkeiten, eine höhere „Perfor-mance“ erreichen als Vollvirtualisierung.

Mehrere Betriebssysteme wurden angepasst, um als Gastbetriebssystem auf Suns „Logical Domains Hypervisor“ zu laufen. Gegen Ende 2006 wurden Solaris, Linux (Ubuntu und Gentoo) und FreeBSD auf den Hypervisor portiert (die alle simultan auf dem gleichen Prozessor als paravirtua-lisierte, unabhängige Gastbetriebssysteme laufen können).

40

Sicherheitsmodelle

Ähnliche Trends wurden auf -x86/x64-Plattformen gesehen, wo Virtualisierungsanstrengungen durch FLOSS-Projekte wie Xen, VirtualBox. Und KVM („Kernel Virtual Machine“) angestoßen wurden. Da sich diese Techniken in großen Serversystemen bis hin zur Verwendung in „Desktop-PCs” finden, werden sie in dem folgenden Abschnitt beschrieben.

Proprietäre Programme, die virtuelle Maschinen bereitstellen, sind beispielsweise VMware und de-ren zugehöriges Hypervisor-Konzept. Einige dieser Virtualisierungssysteme können mit der durch „sHype“ hinzugefügten Sicherheitsfunktionalität eine hohe Sicherheit liefern.

Anbieter / Imple-mentierung

Zugrundeliegen-des Modell

Betriebssystem Evaluierung

NSA, Red Hat / SELinux

Bell-LaPadula GNU/Linux keine

Free BSD Foundation / Trusted BSD

BiBa, LoMAC Trusted BSD keine

- / Rule Set Based Access Control (RSBAC)

Bell-LaPadula GNU/Linux keine

Sun Micro-systems / Trusted Solaris

Bell-LaPadula Trusted Solaris EAL4+

Microsoft / Win-dows Vista

BiBa Windows Vista keine

Unisys / OS 2200BiBa, Lattice, Bell-LaPadula, Clark-Wilson

OS 2200 TCSEC B1

Argus Systems / Pitbull LX

LatticeAIX, Sun Solaris, Linux

ITSEC E3, TCSEC F-B1

Tabelle 4.1: Die Implementierung von Sicherheitsmodellen nach [Wiki0001]

41

Sicherheitsmodelle

4.6 Sicherheitsmodelle in heutigen Betriebssystemen

Dieser Abschnitt präsentiert eine kommentierte Tabelle, die wesentliche Implementierungen von Si-cherheitsmodellen enthält. Obwohl einige historisch wichtige Sicherheitssysteme erwähnt werden, spezialisiert sich die Tabelle auf die heutigen, öffentlich erhältlichen Betriebssysteme, die entweder kommerziell oder frei verfügbar sind.

Allgemein kann man die Implementierungen von Sicherheitsmodellen in zugelassene und nicht zugelassene Implementierungen einteilen. Zugelassene Implementierungen wurden erfolgreich daraufhin untersucht, einen bestimmten Katalog an IT-Sicherheitskriterien zu erfüllen (etwa TCSEC, [TCSEC1985], ITSEC [ITSEC1991] oder „Common Criteria” [CC1996]).

42

Kapitel 5

VertrauensmodelleDieses Kapitel stellt eine Einführung in den Zweck eines Vertrauensmodells, seine Funktionalitäten und Anforderungen sowie die zugehörigen Nutzungsfälle dar. Zentralisiertes Vertrauen und verteil-tes Vertrauen sind zwei grundlegende Bezeichnungen, die im Folgenden näher erläutert werden.

5.1 Taxonomie von Vertrauensmodellen

Dieses Unterkapitel führt Vertrauensmodelle ein. Vertrauen ist ein zentraler, jedoch doppeldeutiger Begriff in der IT-Sicherheit. Ein Vertrauensmodell ist ein wichtiger Teil in jedem IT-Sicherheitskon-zept. Es definiert den vertrauenswürdigen Teil eines Computersystems und die Regeln, nach denen dieses Vertrauen von einer Systemkomponente zur anderen weitergegeben wird. Dieses Kapitel be-handelt Fragen der Art: Was ist Vertrauen in der IT-Sicherheit? Wem oder was soll man vertrauen? Was sind die Kategorien eines Vertrauensmodells? Was sind Modellbeispiele zu jeder Kategorie? Die Übertragung von Vertrauen wird genauso eingeführt, wie die Einstufung von Vertrauensebenen. Darüber hinaus werden durch einige Beispiele die Folgen von unterschiedlichen Vertrauensmodel-len illustrieren.

5.1.1 Vertrauen gegenüber Reputation

Vertrauen in der IT-Sicherheit liest sich immer als „Vertrauen in das korrekte Funktionieren einer technischen Komponente, die sehr wichtig für die Sicherheit eines Computersystems ist“. Diese De-finition wurde in den 1990er Jahren in einigen wissenschaftlichen Arbeiten über Vertrauens-Mana-gement in IT-Systemen und verteilten Computersystemen geprägt. Im Mittelpunkt der Arbeit stand die Authentisierung vom Computersystemen und Software, um deren Vertrauenswürdigkeit zu erhö-hen.

Mit dem Aufschwung des „elektronischen Handels“ (engl. „E-Commerce“) in den späten 1990er Jahren und bis in das einundzwanzigste Jahrhundert hinein wurden viele Erkenntnisse über Vertrau-en in den „E-Commerce“ veröffentlicht. Hier war die Interpretation von Vertrauen entweder das Vertrauen der Kunden in ein „E-Commerce“-Websystem oder das Vertrauen einer Internetfirma in die Beziehungen zu ihren Kunden. Dabei bewegte sich das Vertrauenselement weg vom technologischen Fokus in das Risikomanagement, hin zur finanziellen Sicherheit und zum Betrugsmanagement.

Steigende Bedeutung von „Peer-to-Peer“-Diensten und „Web 2.0“- „Gemeinschaftsplattformen“ (engl. „Community Platforms“) führte schließlich zu einer Neudefinition von Vertrauen als ein „Peer“-kontrolliertes, gemeinschaftsbasiertes Vertrauen in das ehrliche Verhalten von Leuten in der Gemeinschaft. Es wird von Wissenschaftlern eher als „Reputationsmanagement“ denn als Vertrau-ensmanagement bezeichnet.

In unserer Studie betrachten wir Vertrauen als „Vertrauen in die korrekte Funktionsweise einer tech-nischen Komponente, die wichtig für die Sicherheit eines Computersystems ist“, wobei „korrekt“ nichts anderes spezifikationskonform bedeutet.

43

Vertrauensmodelle

5.1.2 Vertrauensmodelle

Die Terminologie, die in Vertrauensmodellen verwendet wird, ist ähnlich der in Sicherheitsmodel-len. Es gibt Objekte und Subjekte, wobei Subjekte Individuen, Organisationen oder IT-Komponen-ten (Hardware, Software) sein können. Vertrauen wird durch ein Konzept weitergegeben. Zur Wei-tergabe werden beispielsweise Techniken zur Authentisierung durch kryptographische Protokolle genutzt.

Zur Umsetzung werden kryptographische Schlüssel in Vertrauensmodellen benötigt, mit denen Zer-tifikate erzeugt werden. Schlüssel verwendet man als Teil von Zertifikaten.

Vertrauensmetriken sind Methoden, die ein Maß für Vertrauen in unterschiedlichen Systemeigen-schaften liefern. Es existieren viele Methoden und Ansätze. Die Reichweite geht dabei vom einfa-chen Zählen bis hin zu Wahrscheinlichkeitsberechnungen. Vertrauensmetriken werden der Vollstän-digkeit halber erwähnt, jedoch in diesem Text nicht detaillierter besprochen.

Vertrauensmodelle

Vertrauensmodelle sind Modelle, die beschreiben, wie Sicherheit dazu verwendet wird, um Bedro-hungen eines Computersystems abzuwehren. Nach dem ITU-T X.509 Standard, Sektion 3.3.54, wird Vertrauen wie folgt definiert: „Eine Entität vertraut einer anderen Entität, falls die erste Entität die Annahme für das Verhalten der zweiten Entität hat und die zweite Entität sich exakt so verhält, wie die Erste es erwartet“.

Vertrauensmodelle unterstützen damit die Entscheidung über das Verhalten einer anderen System-komponente. Jedes Sicherheitsmodell wird einige Vertrauensannahmen in die Funktionsfähigkeit der eingebauten Sicherheitsfunktionalitäten haben. Beispielsweise wird die korrekte Funktionswei-se von kryptographischen Algorithmen für ihre Nutzung angenommen. Der Kryptographie selbst wird in Bezug auf ihre Funktionalität vertraut. Ein anderes Beispiel ist die CPU in einem Rechner. Normalerweise gilt die Annahme, dass die CPU kein Programm oder Quelltext böswillig verändert oder löscht. Auch ihr wird vertraut, d. h. dass sie wie spezifiziert funktioniert.

Der grundlegende Ansatz von einem Vertrauensmodell ist der Aufbau von Vertrauen in wichtige Systemfunktionen. Um zu einer fundamentalen Idee zu gelangen, wie man Vertrauen in ein Compu-tersystem einbringt, sind aus Sicht eines Entwicklers z. B. folgende Fragen zu klären:

● Was sind die spezifischen Mechanismen, die notwendig sind, um einem bestimmten Bedro-hungsprofil entgegen zu wirken?

● Wie die implizite oder explizite Überprüfung der Identität einer Entität oder die notwendi-gen Charakteristika für ein bestimmtes Ereignis oder eine Transaktion erscheinen?

● Wo ist das Vertrauensmodell verankert und wie stark ist diese Verankerung?

Das Modellieren von Vertrauen ist ein von Sicherheitsarchitekten durchgeführter Prozess, in wel-chem ein Bedrohungsprofil zu einem Vertrauensmodell erstellt wird, welches auf einer von Anwen-dungsfällen geleiteten Datenflussanalyse basiert. Das Ergebnis beinhaltet Informationen über Be-drohungen, Schwachstellen und Risiken einer IT-Architektur. Ferner identifiziert Vertrauensmodell-ierung die spezifischen Mechanismen, die notwendig sind, um einem spezifischen Bedrohungspro-fil entgegenzutreten.

44

Vertrauensmodelle

Der Zweck eines Vertrauensmodells ist es, einem spezifischen Bedrohungsprofil entgegenzutreten. Ein Bedrohungsprofil ist eine Menge aus Bedrohungen und Schwachstellen, die durch eine von Nutzungsfällen geleitete Datenflussanalyse für eine bestimmte Organisation identifiziert wurde. Hauptsächlich identifiziert ein Bedrohungsprofil wahrscheinliche Angriffe und ihre Ziele. Die für eine Organisation oder einen Fall wichtige Vertrauensebene kann sich von der Vertrauensebene ei-ner anderen Organisation oder eines anderen Falles unterscheiden. Beispielsweise kann sich die Vertrauensebene, die eine Organisation bei der Authentisierung eines Benutzers benötigt, in be-stimmten Fällen unterscheiden. Daher gibt es keine allgemeingültige Lösung, und Vertrauen muss für jeden Nutzungsfall explizit definiert werden.

● Die Anforderungen an das Vertrauen müssen an einen bestimmten Bedrohungsfall und des-sen Schadensausmaß, dem eine Organisation gegenübersteht, angepasst werden.

● Es muss einen Ansatzpunkt dafür geben, um „Beglaubigungen“ (engl. „Credentials“) für Identitäten zu erstellen. Eine allgemeine Form einer solchen Beglaubigung nennt man ein Zertifikat. Ein Zertifikat wird mit Hilfe von kryptographischen Algorithmen erstellt. Es ent-hält einen öffentlichen Schlüssel, der zu dem geheimen Schlüssel des Zertifikatsbesitzers passt. Ein Zertifikat wird durch eine Zertifizierungsstelle mit einer digitalen Signatur si-gniert, um die Vertrauenswürdigkeit gegenüber Dritten zu gewährleisten.

● Vertrauen entsteht nicht spontan. Es erfordert einen methodischen Aufbau an Beglaubigun-gen und stetigen Überprüfungen.

Falls die einfache Existenz von Daten, Zugangsrechten oder die Zugänglichkeit einer Quelle direkt vorliegt, kann Vertrauen direkt vorgefunden werden. Beispielsweise kann einem auf einem Büro-computer installierten Textverarbeitungsprogramm implizit vertraut werden. Es ist installiert und für Benutzer zugänglich, da man ihm vertraut, korrekt zu funktionieren und annimmt, dass es keine Bedrohung für die Plattform darstellt oder Sicherheitsrichtlinien übertritt.

„Vertrauensverbreitung“ (engl. „Trust Propagation“) ist ein Ansatz, in dem Vertrauen nicht implizit in einem Vertrauensmodell enthalten ist, jedoch durch eine weitere Entität gesichert werden kann. Eine einfache Form der „Trust Propagation“ ist die Verwendung von Passwörtern, um sich an einem Rechner einzuloggen. Der Besitz des Passwortes zeigt dem Computersystem, dass der Systemadmi-nistrator dem Benutzer vertraut.

Allgemein gibt es drei Wege um „Trust Propagation“ durch Entitäten in einem Computersystem zu erreichen:

1. Direktes Vertrauen: Eine Entität A und eine Entität B kennen sich gegenseitig (etwa weil sie durch den gleichen Hersteller programmiert wurden). Dies bildet eine direkte Vertrauens-kette.

45

Vertrauensmodelle

2. Hierarchisches Vertrauen (auch transitives Vertrauen): Eine Hierarchie von Vertrauen wird gebildet. Eine zentrale Entität, die Zertifizierungsstelle (CA), erstellt für alle vertrauens-würdigen Entitäten Vertrauensbescheinigung z. B. Zertifikate. Die Mitglieder der gleichen Vertrauenshierarchie können sich gegenseitig durch die Überprüfung ihrer Zertifikate er-kennen. Dieser Ansatz gleicht der Idee hinter ID-Karten oder Clubkarten. Wer diese besitzt, dem wird der Zugang gewährt.

3. Indirektes Vertrauen oder „Netz des Vertrauens“ (engl. „Web of Trust“) (auch spontanes Vertrauen): Indirektes Vertrauen ähnelt dem sozialen Ansatz der Menschen bezüglich Vertrauen. Dabei erstellen Entitäten sich gegenseitig Beglaubigungen, falls sie sich gegenseitig vertrauen. Wenn jede Entität Beglaubigungen für viele andere Entitäten erstellt, entsteht ein „Web of Trust“. Die Entität, die Vertrauen zu einer anderen Entität sucht, kann eine Liste von Beglaubigungen für die gesuchte Entität von dieser direkt oder von einem Zertifikatsserver erhalten.

46

Abbildung 5.1: Direktes Vertrauen: Beide Entitäten kennen sich gegenseitig und bilden eine Vertrauensbeziehung.

Vertrauensmodelle

Die Unterscheidung zwischen hierarchischem Vertrauen und indirektem Vertrauen ist nicht immer klar. In hierarchischen Vertrauenssystemen kann gegenseitig zertifiziert und Brücken zwischen den einzelnen Hierarchien gebaut werden. Ebenso können individuelle Teile des „Web of Trust“ wie eine Hierarchie aussehen, sobald es eine stark verbundene Entität gibt, der viele andere Entitäten di-rekt vertrauen. Eine wichtige Funktionalität bei hierarchischen Vertrauenssystemen ist, dass es nach Definition genau eine zentrale Entität gibt.

47

Abbildung 5.2: Hierarchisches Vertrauen: Entitäten vertrauen sich gegenseitig, basierend auf einer unter ihnen definierten Hierarchie.

Vertrauensmodelle

Lokales Vertrauen gegenüber verteiltem Vertrauen

Eine andere wichtige Unterscheidung im Bereich der Vertrauensmodelle ist der Unterschied zwi-schen lokalem und verteiltem Vertrauen.

Lokales Vertrauen bezieht sich auf ein Computersystem, in dem alle vertrauenswürdigen Entitäten sich innerhalb der Systemgrenzen befinden. Dabei können viele vertrauenswürdige Beziehungen mit direkten Vertrauensverbindungen aufgebaut werden. Die Komponenten von Betriebssystemen können sich gegenseitig mittels Prüfsummen überprüfen. Benutzer können sich mittels biometri-schem Fingerabdruckscan authentisieren. Bei lokalen Vertrauensmodellen ist die wichtigste Frage, wie die Komponenten lokal gegen Manipulation oder Fehlfunktion abgesichert werden können.

Lokale Vertrauensmodelle behandeln hauptsächlich:

● ein sicheres Speichern von wichtigen Schlüsseln und Zertifikaten

● Schutz von Programmen, Konfigurationsdateien, Passwortlisten, etc.

● Zugangskontrollprivilegien im Computersystem

● Trennung von Benutzern oder Bereichen auf einem Computersystem

● Schnittstellen von Computersystemen

48

Abbildung 5.3: Indirektes Vertrauen oder „Web of Trust“: Ein Netz aus Beziehungen bildet Vertrauen durch mehrere indirekte Beziehungen und

individuelle Vertrauenspräferenzen.

Vertrauensmodelle

Verteiltes Vertrauen stellt sich anderen Herausforderungen, die das Modell betrachten muss. In ei-nem verteilten Netz, möglicherweise mit mobilen Komponenten wie „Notebooks”, erstellen die En-titäten Datenverbindungen durch ein nicht vertrauenswürdiges Netz. Kommunikationspartner, „Re-mote-Login“, Datenübertragungen und auch die „Remote-Login“-Daten müssen behandelt werden. Um unbefugten Zugang zu Daten zu erhalten, wird ein Angreifer einen Angriff auf die Datenfern-übertragung einem physikalischen Einbruch in ein Rechenzentrum bevorzugen. In verteilten Ver-trauensmodellen wird der Fokus auf folgende Punkte gelegt:

● die Gültigkeit einer anderen Entität

● das Sichern der Kommunikation über nicht vertrauenswürdige Kanäle

● die Administration von Schlüsseln und Beglaubigungen sowie deren sichere Verteilung an andere Entitäten

● die Überprüfung von anderen Benutzern

Im Unterkapitel wird Vertrauen in verteilten Computersystemen eingehender behandelt.

5.1.3 Objekte in einem Vertrauensmodell

Ein Vertrauensmodell umfasst viele Entitäten in einem Konzept. Objekte in einem Vertrauensmo-dell sind alle Arten von Komponenten, Softwaremodulen, Hardwaremodulen oder Beglaubigungen, die wichtige Teile des Sicherheitsmodells darstellen. Diese Darstellung orientiert sich an den Berei-chen, die in Abbildung 4.1 im Kapitel über die Zugangskontrolle eingeführt wurden, und beginnt mit dem innersten Bereich, der Hardware.

Hardware-Bereich

Im Hardwarebereich definiert das Vertrauensmodell, welchen Hardwareobjekten auf welcher Ebene vertraut werden kann und wie mit Risiken umgegangen wird. Beispielsweise können folgende Fra-gen bei sicherheitskritischer Betrachtung gestellt werden:

● Löscht eine Festplatte die Daten tatsächlich, wenn eine Datei gelöscht wird, oder sollte der Datenträger physikalisch zerstört werden, sobald er aus dem Computersystem entfernt wird?

● Kann dem Prozessor, der Funktionsweise des Mainboards oder den Schnittstellen vertraut werden? Könnte beispielsweise das BIOS der Grafikkarte bösartigen Quelltext enthalten, der Daten auf dem Bildschirm manipuliert? Kann man die Strahlung des Bildschirms ab-fangen und damit Erkenntnisse über den Bildschirminhalt erhalten?

● Bei welchen Schwachstellen kann durch die Verwendung von Sicherheitshardware vorge-sorgt werden, wie z. B. durch kryptographische Module, Smartcards oder eine vertrauens-würdige Plattform?

● Was passiert mit den vertrauenswürdigen Beziehungen in einem Computersystem, wenn eine Hardwarekomponente nicht mehr vertrauenswürdig arbeitet?

Für die Zusicherung der Hardwarefunktionalität gibt es mehrere Zertifizierungsschemata. Die Eva-luierung oder Zertifizierung nach ITSEC oder „Common Criteria” kann in mehreren Stufen der Untersuchungstiefe durchgeführt werden. Jedoch wird diese Evaluierung für einen bestimmten Nut-

49

Vertrauensmodelle

zungsfall mit seinen spezifischen Annahmen zu Vertrauen und Sicherheit durchgeführt. Beispiels-weise kann es wertlos sein, einem kryptographischen Modul zu trauen, falls ein autorisierter Benut-zer einem nicht-autorisierten Benutzer Zugang zu einem Computer ermöglicht, was dazu führt, dass dieser nun das kryptographische Modul benutzen kann. Eine sichere Autorisierung der Benutzer muss in den Bedingungen des Zertifikates gefordert werden.

Das Austauschen, Reparieren oder Aktualisieren von Hardwarekomponenten kann zu Problemen führen. Die alten Vertrauensbeziehungen in einem Computersystem können zerstört oder geändert werden. Bei Wartungen durch Techniker wird z. B. Zugang zu dem Sicherheitskern der Hardware gewährleistet. Daher sind Wartungsarbeiten oftmals vertrauenskritisch, vor allem bei hohen Vertrau-ensanforderungen [Ande1999].

Deshalb sollen Vertrauensmodelle und Sicherheitsrichtlinien nicht nur die bestmögliche Hardware-konfiguration spezifizieren, sondern auch Alternativen für Wartungsarbeiten und andere Maßnah-men bereitstellen.

Softwarebereich

Nachdem die Hardware eines Computersystems arbeitsbereit ist, muss das Betriebssystem für die Benutzer und die notwendigen Anwendungsprogramme gestartet werden. Ein Urlader (engl. „Boot-loader“) lädt das initiale Startprogramm in den Systemspeicher (es ist auf einem Chip gespeichert, einem Sektor der Festplatte oder auch einem USB-Stick). Der „Bootloader“ überzeugt sich vom ini-tialen Status der Hardware und lädt das Betriebssystem. „Bootloader“, BIOS und vergleichbare Komponenten sind sehr wichtig im Vertrauensmodell: Sie sind die Software, die alles Nachfolgende beeinflussen kann. Sie besitzen meist direkten Zugang zu Computerressourcen, was zur Folge hat, dass diese Komponenten sehr gut vor Manipulationen geschützt werden müssen.

Nach dem „Bootloader“ wird das Betriebssystem gestartet. Da das Betriebssystem die meisten Da-ten sowie die Ausführung der Anwendungsprogramme kontrolliert, müssen hier die Vertrauensbe-ziehungen garantiert und überprüft werden, was nicht einfach zu erreichen ist.

Anwendungsprogramme sind ebenso zu betrachten: Anwendungsprogramme sollen die Sicherheit nicht kompromittieren dürfen, etwa durch unsichere Kommunikation mit anderen Computersyste-men oder durch das Laden von Programmen in den Computer, wodurch letztendlich Viren installiert werden können. Es wird generell empfohlen, die verschiedenen Softwareschichten hinsichtlich ihrer Bedeutung im Bedrohungsmodell oder Vertrauensmodell zu untersuchen. Beispielhafte Fragen für die Spezifikation des Vertrauensmodells sind:

● Kann ein Programm das BIOS manipulieren?

● Wer darf unter welchen Bedingungen das Betriebssystem verändern im Sinne von Korrigie-ren oder Aktualisieren?

● Wie lange darf das Betriebssystem ohne eine Aktualisierung beschrieben werden?

● Wo und wie speichern und schützen Anwendungsprogramme anwendungsspezifische kryp-tographische Schlüssel? Kann Schadsoftware Zugang zu diesen erhalten?

50

Vertrauensmodelle

Kryptographische Schlüssel

Kryptographische Schlüssel spielen eine bedeutende Rolle im Vertrauensmanagement. Da diese Schlüssel nur eine geringe Größe aufweisen, können sie leicht kopiert und entwendet werden. Die sichere Installation, Speichern und Verwendung von kryptographischen Schlüsseln ist für ein Ver-trauensmodell essentiell. Sie können durch Hardware oder durch Software geschützt und verarbeitet werden. Abhängig vom Risiko des Einsatzes und der benötigten Sicherheitsebene ist ein Hardware-basierter Schutz der Schlüssel unvermeidbar. Man kann folgende Hierarchie in der Sicherheit der Schlüsselverwaltung aufstellen (eine höhere Zahl bedeutet eine geringere Sicherheit):

1. Schlüssel werden nur auf Hardware zur Schlüsselverwaltung („Hardware Security Module“, HSM z. B. TPM, Smartcard) erstellt, gespeichert und verarbeitet.

2. Schlüssel werden in gesicherten Bereichen der Hardware gespeichert, aber von der CPU verarbeitet und daher temporär in den Speicher geladen.

3. Schlüssel werden in verschlüsselter Form auf einem Massenspeicher gespeichert, aber von der CPU ver- und entschlüsselt, verarbeitet und daher temporär in den Speicher geladen.

4. Schlüssel liegen unverschlüsselt auf einem Massenspeicher.

Eine Verwendung hochsicheren kryptographischen Modulen ist jedoch nicht sinnvoll, wenn andere Sicherheitsrichtlinien den einfachen Zugang zu diesen Modulen erlauben, wie in [Ande1999] im Falle der kompromittierten Geldautomaten.

5.1.4 Subjekte in Vertrauensmodellen

Subjekte in Vertrauensmodellen sind Benutzer eines Computersystems oder abstrakte Entitäten, die nach einer bestimmten Rolle handeln. Dabei ist eine allgemeine Unterscheidung im lokalen wie auch im verteilten Falle hilfreich.

Im Umgang mit Subjekten befasst sich ein Vertrauensmodell mit der Authentisierung und Autorisie-rung von Benutzern, die Zugang zu einem Computersystem erhalten. Der Zugang zu einem Compu-tersystem bezieht sich nicht immer auf dessen direkte Benutzung, sondern auch auf die Möglich-keit, Zugang zu der Hardware des Computersystems zu haben, z. B. durch Systemadministratoren oder anderes Wartungspersonal.

Wenn die Annahme aufgestellt wird, dass der Computer mit der „Smartcard“, die den geheimen Schlüssel der Firma enthält, sicher ist, da er in einem Tresor sicher verwahrt wird, wird immer im-plizit angenommen, dass die Person, die den Tresorschlüssel besitzt, vertrauenswürdig ist, was je-doch explizit modelliert werden sollte.

Eine hilfreiche Unterscheidung ist die zwischen guter und bösartiger Verwendung eines Konzeptes. Ein bösartiger Benutzer versucht, Privilegien und Gelegenheiten auszunutzen, um die Sicherheits-richtlinien zu überschreiten. Ein typischer Schutz gegen bösartiges Verhalten ist die Deaktivierung der USB-Ports am PC, sodass Daten nicht mittels USB-Datenträger entwendet werden können. Wenn jedoch ein vertrauenswürdiger Benutzer schlicht vergisst, seine Ausdrucke aus dem Drucker zu holen, ist dies schwierig in einem Vertrauensmodell zu betrachten.

Entitäten sind Computer, Systemprozesse oder Dienste, die Teil des Computersystems sind. Entitä-ten handeln nicht zwingend im Interesse des realen Benutzers. Sie führen schlicht eine Aufgabe des Computersystems aus. Z. B. können regelmäßige Sicherungen von Massenspeichern durch eine En-tität „Backup Process“ (Sicherungsprozess) durchgeführt werden. Wenn diese Entität Leserechte

51

Vertrauensmodelle

auf einem Teil der Festplatte mit Geheimnissen besitzt, können diese Geheimnisse leicht auf ein Magnetband geschrieben werden, welches wiederum leicht zu stehlen ist. Die Entität „Backup Pro-cess“ verlangt ähnliche Beachtung wie ein Benutzer, der Zugang zu dem Computersystem besitzt.

Sollte die Autorisierung oder Verschlüsselung durch eine andere Entität erfolgen, muss diese Ver-trauensbeziehung zusätzlich geprüft werden, um systemweites Vertrauen gewährleisten zu können.

5.2 Vertrauen in verteilten Computersystemen

Die Erweiterung von einem lokalen Netz zu einem verteilten Computersystem erfordert eine Neu-definition des Vertrauensmodells, welches für das Sicherheitsmodell verwendet wird. Während alle vertrauenswürdigen Komponenten in einem lokalen Netz Gegenstände der physikalischen Sicher-heit, genauso wie der lokalen administrativen Kontrolle sind, kann man einem fremden Computer-system nicht per Definition vertrauen. Eine Art „Vertrauensbeglaubigung“ (engl. „Trust Certification“) wird zur Unterscheidung eines vertrauenswürdigen von einem nicht vertrauenswürdigen Computersystem benötigt. Mechanismen zum Aufbau von Vertrauen in fremden Computersystemen werden in diesem Unterkapitel erläutert, wie etwa Zertifikate und Inte-gritätsüberprüfung (engl. „Remote Attestation“).

5.2.1 Einführung von verteilten Vertrauensanforderungen

Wie zuvor erwähnt, erfordert Vertrauen in verteilten Computersystemen unterschiedliche Ansätze, im Gegensatz zu lokalem Vertrauen in einfachen Computersystemen. Eigenschaften verteilter Com-putersysteme sind:

● Mehrere Maschinen: Teile eines Computersystems sind lokal verfügbar, laufen aber auf anderen Maschinen.

● Externe Benutzer: Benutzer an verteilten Maschinen müssen identifiziert und autorisiert werden.

● Nicht vertrauenswürdige Kommunikationsnetze: Öffentliche, private oder unsichere Netze können für Systemverbindungen verwendet werden.

● (mögliche) Mobilität: Teile eines Computersystems sind mobil (z. B. mit GPRS/UMTS), nicht dauerhaft angeschaltet und haben wechselnde Netzcharakteristika.

● „Ad-hoc“-Zusammenschlüsse: Teile eines Computersystems können lokale „Ad-hoc“-Verbindungen mit anderen Computersystemen eingehen (z. B. Drucken mit Infrarotverbindung, Datenaustausch via Bluetooth).

● Ansammlung an Webdiensten: Ein Dienst wird aus modularen Webdiensten zusammen-gesetzt, die leicht auszutauschen sind, ohne dabei das komplette Anwendungsprogramm umzustellen.

● Überall vorhandene Interaktionen mit Umgebungssystemen: Die Komponenten eines Computersystems interagieren mit einer computerisierten Umgebung (z. B. ein Mobiltelefon wird fortwährend die Position des Benutzers über die umgebenden Mobil-funkstationen übermitteln, solange es nicht ausgeschaltet ist).

52

Vertrauensmodelle

Im Gegensatz zu verteilten Computersystemen stellen lokale Netze höhere Anforderungen an die Autorisierung. Zentrale Blöcke von verteilten Vertrauensmodellen sind folgende:

Sichere Netzverbindungen: Herkömmlicherweise werden für sichere Netzverbindungen Protokol-le wie SSL, TLS oder IPSec verwendet. Manchmal kann Unbeobachtbarkeit gefordert sein, was jedoch schwer zu implementieren ist.

Fernbeglaubigungen: eine Plattform, bei der sich Benutzer und Entitäten per Netzverbindung identifizieren können.

Externe Integrität: Ein Mechanismus, um die Integrität der Software von anderen Computersyste-men zu prüfen, bringt Wissen über die Software auf anderen Computersystemen.

Gewährleistung der Verfügbarkeit: Schutz vor „Denial-of-Service“-Angriffen bzw. die Erreich-barkeit wichtiger Computersysteme.

5.2.2 Techniken für verteiltes Vertrauen

Schlüsselmanagement ist die zentrale Maßnahme für Vertrauen in verteilten Computersystemen. Kryptographische Schlüssel und Algorithmen werden für viele Prozesse zur Erschaffung von Ver-trauen gebraucht. Man verwendet sie für sichere Verbindungen, zur Benutzerauthentisierung, Über-prüfung der Integrität und Identifizierung von anderen Computersystemen.

Schlüsselmanagement basiert auf einer „Public Key Infrastructure (PKI)“, bei der öffentliche Schlüssel offen verteilt werden können, die anschließend von anderen zur Verschlüsselung und Überprüfung verwendet werden können. Eine PKI hat mindestens eine Beglaubigungsinstanz (engl. „Certificate Authority“, CA), welche Zertifikate ausstellt. Diese Zertifikate enthalten öffentliche Schlüssel und zusätzliche Daten, signiert von der CA. Zertifikate können in kryptographischen Protokollen verwendet werden, um sichere Kanäle zur Kommunikation aufzubauen, Daten zu signieren, Daten zu verschlüsseln sowie um Entitäten zu authentisieren.

Zertifikate können in vielerlei Hinsicht dazu verwendet werden, in einem verteilten Computersys-tem Vertrauen zu erzeugen. Beispiele hierfür sind:

● Aufbau sicherer Kommunikationskanäle

● Authentisierung von weiteren Entitäten (z. B. Benutzeridentitäten)

● Autorisierung von Aktionen

● Überprüfung der Integrität von Daten oder Programmen

● Erstellung von sicheren Evaluierungsanforderungen

Jedoch ist das Absichern eines verteilten Computersystems, welches sichere und vertrauenswürdige Hardware, Betriebssysteme und Anwendungsprogramme verwendet, die auf Basis von Zertifikaten authentisiert werden, eine schwierige Angelegenheit: Jede Installation und jeder Änderung einer Komponente könnte ein neues Zertifikat erfordern. Dieses müsste wiederum in einem verteilten Computersystem weiterverbreitet bzw. den anderen Entitäten zugänglich gemacht werden.

Die „Remote Attestation“ (Integritätsüberprüfung) ist eine wichtige Technik für Vertrauen in ver-teilten Computersystemen. „Remote Attestation“ (RA) stellt die Fähigkeit bereit, die Hardware- und Softwarekonfiguration von einem fremden Computer sicher zu kennen. Dies ist ein auf Kryptogra-

53

Vertrauensmodelle

phie basierender Ansatz, der durch Trusted Computing Verbreitung gefunden hat. Die Basis ist eine Hardware-Unterstützung für die Überprüfung Software (beschrieben in Kapitel 6.1) sowie Soft-ware, die den Status eines anderen Computersystems überprüfen kann. Werden hierbei Zertifikate und Signaturen verwendet, so können von einem beteiligten Computersystem keine falschen Soft-warekonfigurationen unbemerkt übermittelt werden.

Während diese Fähigkeiten viel Kritik durch Aktivisten gegen digitale Rechteverwaltung erhalten hat, wurden die Vorzüge ebenso mit großem Einsatz präsentiert. Ein Computersystem, das „Remote Attestation“ verwendet, kann überprüfen, ob z. B. ein anderer Computer tatsächlich eine bestimmte Version eines „Web Shop“-Anwendungssystems installiert hat.

5.3 Vertrauensbeziehungen

Vertrauen kann als eine Beziehung zwischen Computersystemen ausgedrückt werden, wie dies bei-spielsweise zwischen Menschen oft durch ein „soziales Netzwerk“ und gegenseitige Verantwortung aufgebaut wird oder es Autoritäten in Hierarchien gibt.

Dieses Unterkapitel ist eine Einführung in die zwei grundlegenden Ansätze für den Aufbau von Ver-trauensbeziehungen: Netz des Vertrauens (indem eine Querüberprüfung von vertrauenden Entitäten durchgeführt wird) und hierarchisches Vertrauen (indem Vertrauensbeziehungen gemäß einer zen-tralen Entität in einer Hierarchie aufgebaut werden). Die Ergebnisse dieser Ansätze werden analy-siert und besprochen.

5.3.1 Hierarchisches Vertrauensmodell

Das hierarchische Vertrauensmodell erfordert die Erstellung und Überprüfung aller Zertifikate durch eine CA. Um korrekt zu funktionieren, ist Vertrauen in die CA erforderlich. Dies wiederum ist der Grund für die harten Sicherheitsanforderungen, die an CAs gestellt werden, die elektronische Signaturzertifikate erstellen, welche in der Europäischen Union nach dem Signaturgesetz rechtlich verbindlich sind.

Die CA stellt signierte Zertifikate aus, d. h., sie baut eine Vertrauensbeziehung mit dem Eigentümer der Zertifikate auf. Normalerweise wird der hierarchische Ansatz für zentralisierte Computersyste-me benutzt und spiegelt eine organisatorische Hierarchie wieder. Alle Mitglieder, die versuchen, den Besitzer eines Zertifikats auf seine Vertrauenswürdigkeit hin zu überprüfen, überprüfen, ob die-ser ein von ihrer CA gültiges Zertifikat besitzt. Vertrauen kann in diesem Modell dadurch fortge-pflanzt werden, dass Sub-CAs eingeführt werden, denen es erlaubt ist, Zertifikate für Entitäten zu erstellen (z. B. eine Abteilung kann ihre eigenen Zertifikate erstellen). Die Sub-CA wird ein signier-tes Zertifikat der zentralen CA besitzen und damit eine vertrauenswürdige Beziehung zur zentralen CA aufbauen. Ein Zertifikat von der Sub-CA wird mit dieser verkettet und wird bei Verwendung di-rekt zur CA weitergeleitet.

Ein offenes Problem bleibt: Woher weiß der Integritätsüberprüfer, dass eine Sub-CA existiert und wie kann er die Vertrauensbeziehung zur zentralen CA überprüfen? Zu diesem Zweck haben CAs ein Zertifikatsverzeichnis, das verwendet wird, um Zertifikate nachzuschlagen. Wenn ein Integri-tätsüberprüfer ein Zertifikat mit einer unbekannten Signatur einer CA erhält, kann er im Verzeichnis prüfen, ob dieses von einer Sub-CA ist, die seiner zentralen CA bekannt ist. Falls dies der Fall ist, kann er ebenfalls das Zertifikat prüfen, welches die Vertrauensbeziehung zwischen Sub-CA und CA aufbaut.

54

Vertrauensmodelle

Ein letzter wichtiger Punkt ist der Widerruf von Zertifikaten. Um eine Vertrauensbeziehung zu be-enden, wird das jeweilige Zertifikat als widerrufen (engl. „revoked“) im Verzeichnis der jeweiligen CA markiert und/oder auf die Zertifikatswiderrufsliste (engl. „Certificate Revocation List“, CRL) der CA gesetzt.

5.3.2 „Web of Trust“

Das „Web of Trust“-Modell zielt darauf ab, ein dezentralisierter Ansatz zu sein. Als Ausgangspunkt von Vertrauen wird eine vertrauenswürdige Instanz (engl. „Introducer“) benötigt, die somit eine vertrauenswürdige Entität ist. Ein „Web of Trust“ hat viele vertrauenswürdige Instanzen. Die Rolle eines „Introducers“ ist es, einer anderen Entität im „Web of Trust“ Vertrauen auszusprechen. Sei A ein „Introducer“ und B die Entität, der neu Vertrauen durch A ausgesprochen werden soll, funktioniert dies durch A’s Beglaubigung von B’s öffentlichem Schlüssel. Dazu signiert A das Zertifikat von B. Wenn man sich A als eine zentrale CA ohne weitere „Introducers“ vorstellt, so sieht dies auf den ersten Blick fast wie das hierarchische Vertrauensmodell aus. Es kann jedoch beliebig viele „Introducer“ geben, da jede Entität als vertrauenswürdige Instanz agieren kann. Das Ergebnis ist ein Netz von quervernetzten Vertrauensbeziehungen von Entitäten mit vielen direkten und indirekten Vertrauensbeziehungen.

Weil jedoch eine zentrale CA mit der Autorität Vertrauen zu erstellen fehlt, muss jeder Teilnehmer im „Web of Trust“ darüber entscheiden, wer die vertrauenswürdigen Instanzen sind. Dies geschieht, indem jedem „Introducer“ in jedem persönlichen Schlüsselordner der Entitäten ein Vertrauenslevel zugewiesen wird.

Zertifikatswiderrufe erfolgen beim „Web of Trust“ durch einen spezielles Widerrufs-„Signaturen“ (so zu sagen „Entglaubigungen“), die der Zertifikatsaussteller (meist die Entität selbst) erstellen und über das Netz der OpenPGP-„Keyserver“ verteilen kann.

Das Konzept des „Web of Trust“ wurde durch die PGP-Verschlüsselungs-Software eingeführt und später in der OpenPGP-Spezifikation dokumentiert. In vielen Nachfolgern wie PGPi und insbesondere GnuPG/GPG („GNU Privacy Guard“ [GNUP2004]) wurde OpenPGP implementiert.

5.3.3 Diskussion des „Hierarchischen Vertrauens“ gegenüber „Web of Trust“

Das „Hierarchische Vertrauensmodell“ bildet eine starke, zentralisierte Kontrolle über die Vertrau-ensbeziehungen. Bei Verwendung von Verzeichnissen können sehr große Strukturen oder Sammlun-gen aus Entitäten entstehen, welche durch die CA zertifiziert werden.

Der Vorteil für Integritätsüberprüfer in hierarchischen Vertrauensmodellen ist die Tatsache, dass sie nur das jeweilige Verzeichnis prüfen müssen, ob ein vertrauenswürdiger Pfad zur CA vorhanden ist, in dem Zertifikate miteinander verkettet werden. Die Verbindung zur zentralen CA muss aufgebaut und daraufhin überprüft werden, dass kein Zertifikat im Pfad zur CA ungültig ist.

Der Nachteil dieser hierarchischen Herangehensweise ist ihre Zentralität. Es gibt einen verwundba-ren Punkt, die CA. Wenn das Zertifikat der CA kompromittiert oder das Verzeichnis manipuliert wurde, sind die gesamten Vertrauensbeziehungen wertlos, und alle Zertifikate müssten neu erstellt werden.

Wenn ein Verzeichnisserver nicht verfügbar ist, ist keine Überprüfung möglich. Auch kann der Wi-derruf von Zertifikaten in großen Strukturen mit vielen Zertifikaten großen Aufwand verursachen. Man stelle sich ein Programm auf 12000 „Notebooks” vor, welches mittels eines Zertifikats einer

55

Vertrauensmodelle

CA signiert ist. Wenn dieses Programm einen Fehler aufweist, welcher dazu führt, dass dem Pro-gramm nicht mehr vertraut wird und daher das Zertifikat widerrufen wird, müssen alle 12000 „Notebooks” online gehen und die CA konsultieren, bevor die IT-Infrastruktur als Ganzes wieder als sicher betrachtet werden kann.

Mit dem „Web of Trust“ wird der zentralisierte Aspekt vermieden. Auch dieser Ansatz hat Vor- und Nachteile. Es ist wenig bis gar keine zentrale Verwaltung möglich, wenn das „Web of Trust“ Ver-trauensebenen zu jeder Datenbank eines teilnehmenden „Introducers“ pflegt. Das „Web of Trust“ hat keinen zentralen verwundbaren Punkt wie eine CA. Die Entscheidung, ob ein „Introducer“ ver-trauenswürdig ist oder diesem nicht länger vertraut werden kann, ist kein einfach zu lösendes Pro-blem. Ein Informationskanal ist erforderlich mit all seinen Problemen bezüglich der Vertraulichkeit und Integrität. Das „Web of Trust“ funktioniert am besten mit vielen direkten Vertrauensbeziehun-gen und einer zentralen Zertifikatswiderrufsliste (CRL).

5.4 Implementieren des Vertrauensmodells und des Vertrauensankers

Dieser letzte Abschnitt über Vertrauen in IT-Systemen behandelt Implementierungen von Vertrau-ensmodellen. Neben der Definition der vertrauenswürdigen Teile eines Computersystems in einem Vertrauensmodell ist ebenso die Implementierung dieser für die Qualität des ganzen Sicherheitssys-tems verantwortlich. Wichtig ist hier der Vertrauensanker, welcher der „erste sichere Teil“ des Kon-zeptes ist, denn auf diesen bauen alle weiteren Sicherheitsmechanismen auf (vergleichbar mit dem Fundament in einem großen Gebäude - es muss stabil und stark genug sein, um ein Gebäude dauer-haft zu tragen).

5.4.1 Zentrale vertrauenswürdige Dritte

Dieser Ansatz basiert auf dem hierarchischen Vertrauensmodell. Eine zentrale CA ist für die Aus-stellung von Zertifikaten und deren Widerruf verantwortlich. Alle Entitäten überprüfen Zertifikate vor ihrer Benutzung.

Ein weitverbreitetes Beispiel für einen zentralisierten Ansatz sind die SSL-Serverzertifikate von Webservern. Webbrowser haben eine eingebaute Liste von CA-Zertifikaten (weitere CA-Zertifikate können nachträglich installiert werden). Wenn eine Webseite ein SSL-Zertifikat benötigt, dass von einer dieser CAs ausgestellt ist, wird der Webbrowser automatisch die Vertrauensbeziehung prüfen und ggf. und eine verschlüsselte Verbindung aufbauen.

Zertifikate sind oftmals Datenstrukturen im X.509-Format. X.509-Zertifikate entsprechen dem in-ternationalen ITU-T X.509-Standard. Deshalb können X.509-Zertifikate, die durch ein Programm erstellt wurden, durch jedes Anwendungsprogramm, das zu X.509 kompatibel ist, verwendet wer-den. Leider haben in der Praxis mehrere Firmen ihre eigenen Erweiterungen zu X.509 implemen-tiert, die nicht alle zueinander kompatibel sind.

Ein Zertifikat erfordert eine Institution, die überprüft, ob ein öffentlicher Schlüssel und der Name des Schlüsseleigentümers zusammengehören. Bei X.509-Zertifikaten ist dieser Überprüfer immer eine CA oder ein von der CA autorisierter Überprüfer. Ein X.509-Zertifikat ist eine Sammlung von Informationen über einen Benutzer oder ein Gerät und dessen zugehörigen öffentlichen Schlüssel. Der X.509-Standard beschreibt, welche Informationen in das Zertifikat einfließen und wie diese zu codieren sind.

56

Vertrauensmodelle

Die Sicherheit und Verlässlichkeit der CA und ihres Verzeichnisses ist kritisch für die praktische Si-cherheit des zentralisierten Ansatzes. Die CA muss zu jeder Zeit zum Zweck der Zertifikatsüberprü-fung erreichbar sein. Wo ein hohes Maß an Vertrauen in die Zertifikate erwartet wird, wird die CA in einem Hochsicherheitsrechenzentrum untergebracht. Sie wird redundant an unterschiedlichen, gleichermaßen vertrauenswürdigen Stellen aufgebaut und verfügbar gehalten, für den Fall, dass eines der Rechenzentren versagt.

Ein praktisches Beispiel hierfür sind die CAs für rechtsverbindliche digitale Signaturen.

5.4.2 Vertrauenswürdige Dritte

Ein verteilter Vertrauensansatz basiert auf der Verteilung von sicherer Hardware mit Zertifikaten und Schlüsseln in vernetzten Computersystemen. Dabei werden mehr oder weniger direkte Vertrau-ensbeziehungen durch die installierten Zertifikate in hardwarebasierten Sicherheitsmodulen aufge-baut. Ein Sicherheitsmodul ist eine spezielle Hardware (engl. „Hardware Security Module”, HSM), die zur Kryptographie und sicheren Speichern von z. B. Schlüsseln verwendet wird. Sie ist übli-cherweise z. B. durch den Zusatz von Chemikalien gegen Manipulation geschützt, die einen wichti-gen Teil des Sicherheitsmoduls bei dem Versuch zerstört, dieses zu öffnen. Alternativ besteht die Möglichkeit, wichtige elektrische Teile, die zur Funktion notwendig sind, in das Gehäuse zu inte-grieren.

Die Sicherheitsmodule sind Komponenten der Entitäten. Die Kooperation der verteilten Entitäten wird unter Verwendung der Sicherheitsmodule und ihrer Zertifikate gewährleistet. Praktische Bei-spiele sind Geldautomaten, die mit Sicherheitsmodulen ausgestattet sind oder Geräte für verschlüs-seltes Bezahlfernsehen. Sobald ein Problem auftritt, das die Rücknahme von Schlüsseln oder den Austausch von sicherheitsrelevanten Elementen erfordert, muss oftmals das Sicherheitsmodul durch den Hersteller ausgetauscht oder aktualisiert werden. Bei Geldautomaten wird das Sicherheitsmodul ausgetauscht. Geräte für Bezahlfernsehen hingegen erhalten eine neue „Smartcard“ mit neuen Schlüsseln und Kryptoalgorithmen.

5.4.3 Vertrauensanker

Vertrauensanker sind öffentliche Schlüssel und dazugehörige Informationen, denen eine Program-manwendung oder ein Computersystem direkt vertraut, um digitale Signaturen zu überprüfen.

Die Originalität (Echtheit) einer Entität ist der Ursprung aller Vertrauensmodelle. Dies führt zu der Situation, dass alle Entitäten, bevor sie sich vertrauen, von der Identität der anderen Entität über-zeugt sein müssen, bevor sie mit dieser kommunizieren und Transaktionen durchführen. Der Grad des Vertrauens, der erforderlich ist, um die andere Entität zu überzeugen, sollte in einer öffentlichen Sicherheitsrichtlinie spezifiziert werden. Wie der Name impliziert, tritt die originale Authentisie-rung einer Entität nur einmal am Beginn einer Vertrauensbeziehung auf.

Bei der originalen Authentisierung einer Entität wird eine Beglaubigung (ein Zertifikat) erstellt, die durch eine verbundene Entität überprüft oder referenziert werden kann.

Um einen verlässlichen Prozess zur Überprüfung der Authentisierung zu ermöglichen, müssen Be-glaubigungen eindeutig und an eine Entität gebunden sein. Zudem sollte ein abgestimmtes und stan-dardisiertes Format für Vertrauensbescheinigungen vorhanden sein, genauso wie für die zum Prüfen verwendeten Protokolle.

57

Vertrauensmodelle

Das Zertifikat einer Entität ist ein kritischer Teil der Vertrauenskette und für Angreifer ein lohnens-wertes Ziel. Wie zuvor erläutert, ist der private Schlüssel der zentralen CA in einem hierarchischen Vertrauensmodell extrem kritisch. Der private Schlüssel der CA muss geschützt werden, andernfalls könnte ein Angreifer Zertifikate ausstellen und eine korrupte CA aufbauen.

Eine verbreitete Technik zur Sicherung eines Vertrauensankers ist die Aufbewahrung des Vertrau-ensankers in einem Sicherheitsmodul (HSM), z. B. in einer Smartcard oder durch Einbettung des Vertrauensankers in der Computerplattform (z. B. TPM).

Verbreitete Probleme bei der Verwendung von Vertrauensankern sind:

● die Verwaltung der Lebenszyklen von Vertrauensankern (wie sie aktualisiert, verteilt und widerrufen werden)

● die Pflege mehrerer Vertrauensanker in einer verteilten Infrastruktur

● die zum Speichern der Vertrauensanker verwendete Hardware wird durch den technischen Fortschritt unsicher

58

Kapitel 6

Alternativen und KombinationenDieser Abschnitt präsentiert alternative Konzepte und entstehende Sicherheitstechniken. Der Fokus liegt insbesondere auf Trusted Computing, einer aus Hard- und Software bestehenden Architektur, die eine vertrauenswürdige Plattform bietet. Diese wird im Folgenden eingeführt und erläutert.

Dazu werden mögliche Kombinationen beschrieben, die Trusted Computing verwenden und die im vorherigen Kapitel beschriebenen Sicherheitskonzepte und Modelle verfeinern. Viele der in Kapitel 4 vorgestellten Sicherheitsmodelle können durch die Verwendung von Trusted Computing in einem vertrauenswürdigen Computersystem verankert werden. Beispiele und Limitierungen für diesen An-satz werden in diesem Kapitel ebenso aufgezeigt.

6.1 Trusted Computing und seine Klassifizierung

Als eine Entwicklung in der IT-Sicherheit hat Trusted Computing (manchmal mit Bezug auf sichere Plattformen, engl. „Trusted Platforms“) die Schlagzeilen gefüllt mit kontroversen Debatten über Freiheiten im Zusammenhang mit der Nutzung von Computern. Wie in Unterkapitel 2.3 erwähnt, hat das Potenzial des Trusted Computing zur Bildung eines Sicherheitsankers und damit die verbun-dene Umsetzung von Sicherheitsmodellen zu einer sehr emotionalen Mediendebatte geführt. Dieses Unterkapitel ist eine Einführung in das Konzept des Trusted Computing nach der Spezifikation der „Trusted Computing Group“ [TCG0001]. Es werden grundlegende Modelle und Funktionalitäten eingeführt sowie Beispiele bereitgestellt. Auch wird eine kurze Übersicht über Betriebssysteme ge-geben, die Trusted Computing unterstützen.

6.1.1 Die „Trusted Computing Group“ (TCG)

Die „Trusted Computing Group“ entwickelte sich aus der „Trusted Computing Platform Alliance“ (TCPA), welche ein Arbeitsgruppe Industrie-Konsortium war, das sich mit der Entwicklung von Si-cherheitsmechanismen auf Computerplattformen beschäftigte. Gründungsmitglieder waren Compaq (heute ein Teil von Hewlett-Packard), Hewlett-Packard, IBM, Intel und Microsoft im Januar 1999.

Im Oktober 1999 veröffentlichte die TCPA eine vorläufige Spezifikation und eröffnete anderen Un-ternehmen die Möglichkeit, an nicht öffentlichen Arbeitstreffen teilzunehmen. Im August 2000 wur-de die erste öffentliche Version der TCPA-Spezifikation zur Kommentierung freigegeben und wurde als TCPA-Spezifikation 1.0 im Februar 2001 veröffentlicht. Diese Spezifikation war Plattform-unabhängig und definierte die wesentlichen Funktionen, die durch ein „sicheres Plattform Modul“ (engl. „Trusted Platform Module“, TPM) gegeben sein müssen.

Die TPM-Arbeitsgruppe der TCPA, die im Februar 2001 gegründet wurde, überarbeitete die Spezi-fikation hinsichtlich der Anforderungen an die praktischen Implementierungen und die Fehlerkor-rektur. Das führte zu der TCPA TPM-Spezifikation 1.1, die im August 2001 veröffentlicht wurde. Viele Anforderungen an eine „Trusted Computing Platform“, die nicht in Hardware implementiert werden, wurden in andere TCPA-Spezifikationen verschoben.

59

Alternativen und Kombinationen

Im September 2001 veröffentlichte die „TCPA PC Specific“-Arbeitsgruppe ihre erste Spezifikation. Diese Arbeitsgruppe wurde zum Entwurf einer Spezifikation für x86-Computerplattformen gegrün-det. Der nächste Meilenstein war die TCPA TPM-Spezifikation 1.1b, welche im Mai 2002 heraus-gegeben wurde. Im April 2003 wurde die TCPA in eine nicht kommerzielle Organisation, die „Trus-ted Computing Group“ (TCG), umgewandelt. Die TCG übernahm alle TCPA-Spezifikationen und setzte ihre Entwicklung fort.

Zusätzlich zur „PC Specific“-Arbeitsgruppe und der TPM-Arbeitsgruppe, welche von der TCPA übernommen wurden, gründete die TCG weitere Arbeitsgruppen. Diese befassen sich mit der Ent-wicklung von Spezifikationen für mobile Geräte, Server, Speichersysteme, Infrastrukturen zu Trus-ted Computing, „TCG-Software-Umgebung“ (engl. „TCG Software Stack“, TSS) und „sichere Netzverbindungen“ (engl. „Trusted Network Connect“, TNC).

Im November 2003 wurde die letzte bedeutende Veränderung an der TCG-Spezifikation als „TPM Main Specification 1.2“ veröffentlicht. Sie beschreibt unter anderem die Plattform-unabhängigen Funktionalitäten, die ein TPM zur Verfügung stellen muss.

Im Jahr 2007 hatte die TCG mehr als 130 Mitglieder, einschließlich Anbietern von Rechnern und deren Komponenten, Anbietern von Software und Herstellern von Netzkomponenten.

Aktivitäten

Die „TCG Work Groups“ (Arbeitsgruppen), die sich jeweils mit unterschiedlichen Aspekten des Trusted Computing befassen, erstellen die TCG-Spezifikationen.

Im Folgenden werden die wichtigsten Arbeitsgruppen näher erläutert11:

TCG: Die „Trusted Computing Group“ (TCG) ist eine nicht kommerzielle Organisation, die ge-gründet wurde, um Spezifikationen für hardwarebasierte Trusted Computing Sicherheitstechni-ken zu entwickeln, zu definieren und als öffentliche Spezifikationen zu publizieren. Hierzu zäh-len Computerhardware sowie plattformübergreifende Softwareschnittstellen. TCG-Spezifikatio-nen sollen es ermöglichen, sichere Umgebungen zu realisieren, ohne jedoch Kompromisse in den Bereichen Funktionalität, Integrität, Privatsphäre und Persönlichkeitsrechte eingehen zu müssen. Das wichtigste Ziel ist es, Benutzern zu ermöglichen ihre vertraulichen Daten wie z. B. Passwörter und kryptographische Schlüssel gegen Softwareangriffe oder Hardware-Diebstahl zu schützen.

TPM: Aufgabe der „TPM Work Group“ ist es, die Spezifikationen des „Trusted Platform Module“ (TPM) zu erstellen. Die Definition der TPM-Architektur kommt aus dem Trusted Computing Umfeld, während die „TPM Work Group“ die Implementierung der Architektur definiert.

TSS: Die „TSS Work Group“ definiert die Schnittstellen für Anwendungsprogrammhersteller, die das TPM nutzen. Die Arbeitsgruppe erstellt eine herstellerunabhängige Spezifikation, die her-stellerspezifische Hardware-Unterschiede abstrahiert, wodurch es den Anwendungsprogramm-herstellern ermöglicht wird, unabhängig von der verwendeten Hardware oder dem Betriebssys-tem zu entwickeln. Der TSS stellt zudem Werkzeuge bereit, um mit dem TPM im eigenen Com-puter zu kommunizieren.

PC Client: Die „PC Client Work Group“ bietet allgemeine Funktionalitäten und Schnittstellen an. Sie schafft grundlegende Sicherheitsvoraussetzungen auf Computersystemen, die über einen Vertrauensanker verfügen, sodass für diese eine eigene Vertrauenskette aufgebaut werden kann.

11 Übersetzung von der TCG-Webseite (http://www.trustedcomputinggroup.org/about_tcg/tcg_workgroups)

60

Alternativen und Kombinationen

Darüber hinaus koordiniert diese Arbeitsgruppe den Informationsaustausch zwischen der „TPM Work Group“ und anderen TCG-Arbeitsgruppen, um wichtige mögliche Designkriterien zu pu-blizieren, die Arbeitsgruppen-übergreifende Bedeutung haben. Die „PC Client Work Group“ be-fasst sich nicht mit Bereichen der TPM-Funktionalität, der TPM-Sicherheit, des Datenschutzes oder auch den Schnittstellen (ausgenommen der Schnittstellen, die sich zwischen dem Betriebs-system und der Plattformumgebung (engl. „Pre-OS Environment“) befinden, die von der Platt-form zur Verfügung gestellt werden.

Server: Die Aufgabe der „Server Work Group“ ist es Definitionen, Spezifikationen, Anleitungen und technische Voraussetzungen bereitzustellen, die die Implementierungen von TCG-Technik in Servern betreffen.

Mobile Phone: Die „Mobile Phone Work Group“ arbeitet an der Anpassung des TCG-Konzeptes für mobile Geräte. Die Arbeitsgruppe erweitert die Spezifikationen der TCG um Spezifiaktio-nen, die spezielle Eigenschaften von mobilen Endgeräten, wie z. B. wechselnde Netzanbin-dung, eingeschränkte Ressourcen oder auch spezielle Nutzungsmodelle berücksichtigen.

Infrastructure: Die „Infrastructure Work Group“ arbeitet an der Erweiterung und Integration der TCG-Spezifikationen für die Bereiche Internet- und Intranet-Infrastrukturen, um unterschiedli-che Geschäftsmodelle in offenen heterogenen Plattformumgebungen zu ermöglichen.

Festlegungen betreffend Repräsentation und Schnittstellen von Informationen sind notwendig, um vertrauenswürdige Entscheidungen zu treffen, die Einfluss auf bestehende Infrastrukturen und zugehörige Infrastrukturstandards nehmen. Überlegungen werden für Repräsentationen von Vertrauensankern, Vertrauensketten, Schlüsselverwaltungen (engl. „Key Lifecycle Services“), und Beziehungen, die Sicherheitsrichtlinien verwenden, gemacht. Die Arbeitsgruppe legt Rah-menbedingungen, Schnittstellen und Bedingungen fest, um Probleme in der Infrastruktur zu überwinden.

TNC: Die „Trusted Network Connect“ (TNC) Arbeitsgruppe hat eine offene Architektur zur Inte-gritätsüberprüfung via Rechnernetze spezifiziert und veröffentlicht. Die TNC-Architektur er-möglicht es Administratoren aktiver Netzkomponenten, Sicherheitsrichtlinien während oder nach Herstellung einer Netzverbindung durchzusetzen.

Storage: Die „Storage Work Group“ arbeitet basierend auf existierenden TCG-Techniken und Phi-losophien und widmet sich der Entwicklung von Spezifikationen für die Sicherheit von Massenspeichersystemen. Ein Ziel ist es, Spezifikationen zu erstellen, so dass technikunabhängige Sicherheitsdienste oberhalb eines Festplattenadapters definiert werden können, welche z. B. ATA, Serial ATA, SCSI, FibreChannel, USB-Sticks, IEEE 1394, „Network Attached Storage“ (NAS) oder Wechsel-Medien umfassen, aber nicht auf diese beschränkt sind. Diese Arbeitsgruppe der TCG arbeitet mit anderen Industrieorganisationen zur Spezifizierung von Massenspeichern zusammen, um den Einflussbereich der TCG-Technik zu vergrößern.

61

Alternativen und Kombinationen

6.1.2 Trusted Computing Funktionen

„Integrity Measurement“, überprüfbares und vertrauenswürdiges Starten

Die Integritätsmessung (engl. „Integrity Measurement“) ist eine der grundlegenden Mechanismen des Trusted Computing. „Integrity Measurement“ bedeutet, den Zustand eines Computers oder ei-nes Geräts unter gesicherten Bedingungen zu berechnen und abzuspeichern. Die Integritätsmessung während des Startens einer Plattform wird als Vertrauenswürdiges Starten (engl. „Trusted Boot“12) bezeichnet. Es ist eine Methode, bei der sicher protokolliert wird, welche Software auf welchen Computerkomponenten gestartet wird. Der Startvorgang selbst wird nicht beeinflusst. Nachdem die Startsequenz beendet ist, können diese Protokolle zur Überprüfung des Systemzustandes verwendet werden. Zu beachten ist, „Trusted Boot“ garantiert in keiner Weise, dass das Gerät sich in einem sicheren Zustand befindet. Es stellt sein Protokoll zur Verfügung und ermöglicht es weiterer Software, dieses zu nutzen. Durch die Hilfe der Protokolleinträge ist es möglich, den lokalen Gerätestatus einer weiteren Entität mitzuteilen. Durch die Analyse der Protokolle können nun andere Entitäten über die Vertrauenswürdigkeit eines Computersystems entscheiden. Dieser Ansatz ist für sichere offene Plattformen nützlich, welche auf viele Arten modifiziert werden können.

Das Konzept des „Trusted Boot“ wurde durch Arbaugh et. al. in [ArFaSm97] lange vor der TCG-Spezifikation eingeführt13. Heute erhältliche Formen des „Trusted Boot“ erfordern neue Hardware oder unterstützen nur mangelhaft nicht vertrauenswürdige Anwendungsprogramme.

Es gibt eine weitere Art und Weise, ein Computersystem in vertrauenswürdiger Weise zu starten, die Sicheres Starten (engl. „Secure Boot“) genannt wird. Sicheres Starten prüft ein auszuführendes Programm noch bevor es gestartet wird anhand von Sicherheitsrichtlinien und vermeidet so, dass unerlaubte Software auf dem Gerät gestartet wird. Die Sicherheitsrichtlinien umfassen das Identifi-zierungsmerkmal von autorisierter Software, wobei Prüfsummen als Identifikationsmerkmal ver-wendet werden können. Wenn kein passendes Identifikationsmerkmal (Prüfsumme) in der Liste der Sicherheitsrichtlinien gefunden wird, wird der Startvorgang abgebrochen. Gewöhnlich wird diese Technik dazu verwendet, um lokal abzusichern, dass sich die Plattform in einem sicheren Zustand befindet, jedoch nicht, um das Identifikationsmerkmal einer anderen Plattform zu beweisen. Die Technik des sicheren Startens kann dazu verwendet werden, um sichere geschlossene Plattformen aufzubauen, die nur eine beschränkte Menge an ausführbarer Software besitzen. Formen des siche-ren Startens sind schon über 15 Jahre bekannt

Eine dritte Methode zur Überprüfung ob ausführbare Programme vertrauenswürdig sind, wird durch die Signierung des ausführbaren Programms realisiert. Die meisten Implementierungen zur Si-gnierung ausführbarer Programme, liefern einen Mechanismus zur digitalen Signatur, um die Iden-tität des Autors oder Herstellers sicher zu stellen. Hiervon abhängig kann ein Benutzer oder eine Software entscheiden, ob die Quelle vertrauenswürdig ist und ob das Programm modifiziert wurde. „Proof-Carrying Code“ ist eine Technik, die eine sichere Ausführung von nicht vertrauenswürdiger Software garantiert. Der Autor des Programms fügt Informationen (genannt Annotationen) in das Programm ein. Er generiert einen Beweis, dass er die vorgegebenen Sicherheitsrichtlinien einhält. Der Empfänger erstellt eine Menge von Sicherheitsrichtlinien, die von dem Programm eingehalten werden sollen. Mit einem Überprüfungswerkzeug kann der Empfänger feststellen, ob das Pro-gramm mit dem von Autor generierten Beweis, seine Sicherheitsrichtlinien erfüllt. Passt das Pro-

12 „Trusted Boot“ wird gelegentlich als Beglaubigtes Starten (engl. „Authenticated Boot“) bezeichnet

13 Dort wurde sie Beglaubigtes Starten (engl. „Authenticated Boot“) gegenüber Sicheres Starten (engl. „Secure Boot“) genannt.

62

Alternativen und Kombinationen

gramm nicht zu dem Beweis und werden vorgegebene Sicherheitsrichtlinien vom Autor oder wer-den die Sicherheitsrichtlinien des Empfängers nicht eingehalten, schlägt die Überprüfung fehl. Das Programm kann durch den Empfänger ausgeführt werden, wenn die Überprüfung des Programms erfolgreich durchgeführt wurde. Jede Verfälschung der Software oder Änderungen an den Annota-tionen kann auf diesem Weg durch den Empfänger bemerkt werden.

Die erwähnten Methoden können kombiniert werden. Nach der Messung der Integrität werden die Ergebnisse an eine andere Plattform zur Überprüfung gesendet. Wenn die Plattform in einem ungül-tigen Zustand ist, könnte der Integritätsüberprüfer der anderen Plattform eine Nachbesserung initiie-ren. Mit dieser muss die Plattform aktualisiert werden. Danach startet sie die Integritätsmessung neu, bis sie in einem gültigen Zustand ist. Wenn eine Startsequenz überprüft wird (entfernt oder lo-kal), ist somit sichergestellt, dass Komponenten der Plattform nicht emuliert werden können, dass also eine bestimmte Hardware mit einem bestimmten Betriebssystem und bestimmten Anwen-dungsprogrammen tatsächlich in dem identifizierten Gerät läuft.

„Binding“, „Sealing“ und „Attestation“

Ein Vertrauensanker kann Methoden zum Binden (engl. „Binding“) von Daten an eine bestimmte Plattform bereitstellen, die aus spezifischer Hardware und auf ihr ausgeführter Software besteht. Dies kann durch kryptographische Operationen realisiert werden, die in einer geschützten Hard-ware-Umgebung ausgeführt und gespeichert werden. Innerhalb der TCG-Spezifikation ist das Platt-formzertifikat zur Überprüfung der Vertrauenswürdigkeit der Plattform essentiell und kann ebenso zur Authentisierung verwendet werden. Dieses Zertifikat ist die Wurzel für weitere Zertifikate die-ser Plattform.

Das „Verschließen“ (engl. „Sealing“) erlaubt es, den Zugang zu sensiblen Daten auf ein Computer-system mit dedizierter Hardware- und Software-Konfiguration einzuschränken.

Die Technik des „verschlossenen Speicherns“ basiert auf einem Schlüssel, der partiell durch die Identität der Software generiert wird, die den Schlüssel erfordert. Darüber hinaus stellt die Identität des Gerätes, welches die Software ausführt, den zweiten Anteil des Schlüssels dar. Folglich müssen diese Schlüssel nicht gespeichert werden, da sie erstellt werden können, wann immer sie benötigt werden. Wenn ein anderes Programm als das, welches die Verschlüsselung durchgeführt hat, ver-sucht, diese Daten zu entschlüsseln, wird dies nicht funktionieren, da der verwendete Schlüssel ein anderer ist als der originale. Das folgt aus den unterschiedlichen Identifizierungsmerkmalen der Software, welche die Daten „verschließt“: Konsequenterweise sind die erzeugten Schlüssel unter-schiedlich. Ein vergleichbarer Nutzungsfall liegt vor, wenn verschlüsselte Daten zu einem anderen Computer transferiert werden und dort versucht wird, diese zu entschlüsseln, was nicht möglich ist. Somit sind beispielsweise E-Mails auf einem eigenen Computer lesbar, auf einem anderen jedoch nicht. Mit Hilfe von „verschlossenem Speichern“ kann nicht verhindert werden, dass vertrauliche Daten zu anderen Computersystemen kopiert werden, jedoch wird verhindert, dass die Daten dort entschlüsselt werden können. Durch die Verwendung von „Integritätsüberprüfung“ (engl. „Attesta-tion“) ist es möglich, den Status der Hardware oder Software einer anderen Plattform zu überprü-fen. Deshalb werden die Ergebnisse der Integritätsmessung, d. h. die Prüfsummen, welche die Soft-ware und Hardware eines Computers charakterisieren, mit einem AIK-Schlüssel (siehe Unterkapitel 6.1.3) des TPMs dieser Plattform signiert. Die signierten Integritätsmesswerte können durch eine andere Plattform überprüft werden, ohne dass die prüfende Plattform Zugriff auf die zu überprüfen-de Plattform benötigt. Das Zertifikat des öffentlichen AIK-Schlüssels wird zusammen mit den si-gnierten Integritätsmesswerten versandt. Um die Überprüfung der Authentizität dieser Messwerte,

63

Alternativen und Kombinationen

die den verwendeten Schlüssel als vertrauenswürdig zu akkreditieren ermöglichen, werden diese zusammen mit den signierten beglaubigten Integritätsmesswerten versandt. Eine Integritätsüberprü-fung kann direkt oder durch einen „vertrauenswürdigen Dritten“ (engl. „Trusted Third Party“, TTP) ausgeführt werden, der die Plattform als vertrauenswürdig einstuft. Plattformen können sich jedoch nicht selbst prüfen, sondern nur von einer anderen Plattform überprüft werden.

Ein „vertrauenswürdiger Dritter“ (engl. „Trusted Third Party”, TTP) prüft die Integritätsmesswerte eines Gerätes. Sind sie gültig, bestätigt die TTP die Integritätsmesswerte als vertrauenswürdig, wo-durch die Plattform als vertrauenswürdig eingestuft werden kann.

Direkte anonyme Beglaubigung (engl. „Direct Anonymous Attestation“, DAA) ohne Verwendung einer TTP ist eine weitere Technik der Beglaubigung. Es kann bewiesen werden, dass ein gültiges Zertifikat existieren kann, ohne es zu enthüllen. Also können Zertifikate anonym generiert werden. Gruppensignaturschemata erlauben es, dass jedes Mitglied der Gruppe im Namen der Gruppe signieren kann. Dies unterstützt die Anonymität der Gruppenmitglieder und liefert eine gültige Signatur.

Eine dritte Technik zur Überprüfung, ob ausführbare Programme vertrauenswürdig sind, wird durch die Signierung des ausführbaren Programms realisiert. Die meisten Implementierungen zur Signierung ausführbarer Programme, liefern einen Mechanismus zur digitalen Signatur, um die Identität des Autors oder Herstellers sicher zu stellen. Hiervon abhängig kann ein Benutzer oder eine Software entscheiden, ob die Quelle vertrauenswürdig ist und ob das Programm modifiziert wurde. „Proof-Carrying Code“ ist eine Technik, die eine sichere Ausführung von nicht vertrauenswürdiger Software garantiert. Der Autor des Programms fügt Informationen (genannt Annotationen) in das Programm ein. Er generiert einen Beweis, dass er die vorgegebenen Sicherheitsrichtlinien einhält. Der Empfänger erstellt eine Menge von Sicherheitsrichtlinien, die von dem Programm eingehalten werden sollen. Mit einem Überprüfungswerkzeug kann der Empfänger feststellen, ob das Programm mit dem vom Autor generierten Beweis seine Sicherheits-richtlinien erfüllt. Passt das Programm nicht zu dem Beweis und werden vorgegebene Sicherheits-richtlinien vom Autor oder die Sicherheitsrichtlinien des Empfängers nicht eingehalten, schlägt die Überprüfung fehl. Das Programm kann durch den Empfänger ausgeführt werden, wenn die Überprüfung des Programms erfolgreich durchgeführt wurde. Jede Verfälschung der Software oder Änderungen an den Annotationen kann auf diesem Weg durch den Empfänger bemerkt werden.

6.1.3 Vertrauenswürdige Computerarchitektur

Dieser Abschnitt gibt einen kurzen Überblick über die wichtigsten Funktionalitäten einschließlich der „Integritätsüberprüfung“ (engl. „Attestation“) und des „Verschließens“ (engl. „Sealing“) der Spezifikationen 1.1b und 1.2 der TCG.

Die primären Komponenten der Spezifikation der TCG sind das: „Trusted Platform Module“ (TPM) und ein geschütztes „pre-BIOS14“ (auch bezeichnet als „Vertrauensanker zur Integritätsmessung“; engl. „Core Root of Trust for Measurement“, CRTM).

14 Das BIOS regelt das Starten des Computersystems durch die Initialisierung der Hardware und das Laden des Urladers / „Bootloaders“

64

Alternativen und Kombinationen

„Trusted Platform Module“ (TPM) Spezifikationsübersicht

Die Spezifikation des TPM ist der Hauptteil der TCG-Spezifikation. Sie definiert alle plattformun-abhängigen Aspekte und Funktionen, die von einer vertrauenswürdigen Plattform bereitgestellt wer-den müssen. Alle plattformspezifischen Aspekte wurden zu den plattformspezifischen Dokumenten ausgelagert, wie der „PC Client Specification”.

Komponenten

Die TCG-Spezifikation schreibt nicht vor, dass ein TPM in Hardware implementiert werden muss. Die meisten TPM-Implementierungen befinden sich aber in Hardware. Das TPM bietet einen RSA-Algorithmus zur Schlüsselerzeugung, kryptographische Funktionen wie Signieren und Überprüfung durch asymmetrische Kryptographie, einen Zufallszahlengenerator (engl. „Random Number Generator“, RNG), einen nicht flüchtigen Speicher und die Prüfsummenfunktion SHA-115.

Hardware-Sicherheitsmodule (HSM) wie ein TPMs können mit Smartcards verglichen werden, die eine CPU, Speicher und Anwendungssoftware enthalten. Es wird angenommen, dass der Chip si-cher (vgl. Abschnitt 3.1.2) in der Plattform (z. B. auf dem Motherboard) befestigt ist, so dass Manipulation oder Entfernung bemerkbar sind.

Den Funktionalitäten eines TPMs muss vertraut werden. Dieses Vertrauen soll durch die Evaluie-rung nach „Common Criteria” gestärkt werden.

TPM Schlüsselarten und Berechtigungsbeglaubigung

Ein TPM enthält einen „Vertrauensanker für Datenspeicher“ (engl. „Root of Trust for Storage“ (RTS) oder auch „Storage Root Key“ (SRK)), der Daten mithilfe des TPM schützt. Der RTS verwaltet einen kleinen flüchtigen Speicher innerhalb des TPMs, der dazu verwendet wird, um derzeitig verwendete Schlüssel zu speichern („Key Slots“). Nicht verwendete Schlüssel können mit dem „Speicherwurzelschlüssel“ (engl. „Storage Root Key“) verschlüsselt und aus dem TPM-Chip verschoben werden, z. B. auf eine Festplatte, was zu einer Schlüsselhierarchie mit dem SRK als Wurzel führt. Die „Key Slots“ des TPM werden durch einen vertrauenswürdigen Dienst außerhalb des TPMs verwaltet, welcher „Schlüsselzwischenspeicher Verwalter“ (engl. „Key Cache Manager“, KCM) genannt wird.

Jeder durch ein TPM geschützter Schlüssel wird mit unterschiedlichen Attributen gespeichert, die den Typ des Schlüssels und seinen Verwendungszweck beinhalten. Die Attributwerte werden bei der jeweiligen Schlüsselerzeugung generiert und können nachträglich nicht mehr verändert werden.

„Storage Root Key“

Der „Storage Root Key“ (SRK) wird dazu verwendet, um TPM-geschützte Schlüssel so zu ver-schlüsseln, dass sie außerhalb des TPMs aufbewahrt werden können. Dies erzeugt eine Schlüssel-hierarchie auf einem Speichermedium, wie beispielsweise einer Festplatte. Der SRK kann das TPM nicht verlassen (da er ein nicht migrierbarer Schlüssel ist; ein NMK) und wird bei der Inbesitznahme der Plattform (engl. „Take Ownership“) erzeugt. Er kann bei einer erneuten Inbesitznahme der Plattform neu erzeugt werden, was allerdings die gesamte alte Schlüsselhierarchie zerstört, und somit sowohl alle „Storage Keys“ wie auch die damit verschlüsselten Daten unbrauchbar macht.

15 Siehe http://en.wikipedia.org/wiki/SHA-1

65

Alternativen und Kombinationen

„Endorsement-Key“

Jedes TPM wird mit einem „eingebauten“ nicht-migrierbaren Schlüssel, dem so genannten „Endorsement Key“ (EK) ausgeliefert, welcher beim Herstellungsprozess innerhalb oder außerhalb des TPMs generiert wurde. „Eingebaut“ meint, dass es unmöglich ist, diesen Schlüssel des TPMs zu löschen oder zu kopieren. Dadurch kann das TPM und die zugehörige Plattform eindeutig identifiziert werden. Die Entität, die den EK erzeugt, erzeugt eine Berechtigungsbeglaubigung (engl. „Endorsement Credential“), welche den Beweis liefert, dass der EK ordentlich erstellt und in einem echten TPM integriert wurde.

Neben den zwei oben beschriebenen Schlüsseln kann ein TPM vier unterschiedliche Arten von asymmetrischen Schlüsseln erzeugen:

„Migratable Keys“: „Migrierbare Schlüssel“ (engl. „Migratable Keys“, MK) sind kryptographi-sche Schlüssel, denen nur durch die Beteiligten vertraut wird, die sie erstellt haben (also die Plattformbenutzer). Eine dritte Stelle hat keinerlei Garantie darüber, dass so ein Schlüssel tat-sächlich auf dem TPM erzeugt wurde.

„Non-migratable Keys“: Im Gegensatz zu den MKs garantieren „nicht-migrierbare Schlüssel“ (engl. „Non-migratable Keys“, NMK) sich innerhalb der TPM-geschützten Umgebung zu be-finden. Es können damit nur kryptografische Operationen innerhalb des TPMs durchgeführt werden.

„Certified-migratable Keys“: „Überprüfbar migrierbare Schlüssel“ (engl. „Certified-migratable Keys“, CMK) wurden in der Version 1.2 der TCG-Spezifikation eingeführt und erlauben eine flexiblere Schlüsselhandhabung. Die Entscheidung ob migriert wird und die Migration selbst, wird an zwei vertrauenswürdige Entitäten delegiert, die durch den Besitzer des TPMs nach der Erstellung des CMK gewählt werden. Die „Autorität der Migrationsauswahl“ (engl. „Migra-tion-Selection Authority“, MSA) kontrolliert die Migration des Schlüssels, handhabt den mi-grierten Schlüssel aber selbst nicht. Im Gegensatz dazu handhabt die „Autorität der Migration“ (engl. „Migration Authority“, MA) die Migration des Schlüssels. Um einen CMK zu einer an-deren Plattform zu migrieren, erwartet das TPM ein Zertifikat einer MSA mit der Aussage, dass der zu migrierende Schlüssel durch die MA in ein anderes TPM transferiert werden kann.

„Attestation Identity Keys“: Identitätsschlüssel für die Integritätsüberprüfung (engl. „Attestation Identity Keys“, AIK) sind nicht-migrierbare Signaturschlüssel und bieten Pseudonymität der Plattform. AIKs werden lokal durch ein TPM erstellt. Der öffentliche Teil wird durch eine „Privatsphäre schützende CA“ (engl. „Privacy Certification Authority“, Privacy CA) mit der Bedeutung beglaubigt, dass dieser Signaturschlüssel sich tatsächlich unter der Kontrolle eines sicheren TPMs befindet. Um das Problem zu bewältigen, dass diese Stelle Transaktionen einer bestimmte Plattform verfolgen kann, definiert Version 1.2 der TCG-Spezifikation ein „direktes anonymes Beglaubigungsprotokoll“ (engl. „Direct Anonymous Attestation“, DAA) welches die „Privacy CA“ nicht benötigt. AIKs können zur Integritätsüberprüfung einer spezifischen Platt-formkonfiguration verwendet werden (vgl. 6.1.3). Eine Plattform kann mehrere AIKs besitzen, um Pseudonymität zu ermöglichen. Um AIKs zu erzeugen, sind Bestätigungs-, Konformitäts- und Plattform-Beglaubigung (engl. „-Credentials“), welche mit der Plattform geliefert werden, der EK und die Autorisation durch den Plattformbesitzer erforderlich.

66

Alternativen und Kombinationen

TPM Vertrauensbeglaubigung

Eine vertrauenswürdige Plattform wird mit Vertrauensbeglaubigungen (digitalen Zertifikaten) ausgeliefert, die eine Aussage darüber treffen, dass ihre Komponenten unter Einhaltung der TCG-Spezifikationen konstruiert wurden.

„Endorsement Credential“: Wie schon erwähnt, solle die „Berechtigungsbeglaubigung“ (engl. „Endorsement Credential“) einen Beweis dazu liefern, dass der „Endorsement Key“ (EK) or-dentlich erzeugt und in ein echtes TPM eingebettet wurde. Dieses wird durch die Entität ange-fertigt, die den EK erzeugte. Diese Berechtigungsbeglaubigung enthält den Namen des TPM-Herstellers, die TPM-Seriennummer, die TPM-Version und den öffentlichen Teil des EK. Der „Endorsement Key“ (EK) ist ein RSA-Schlüsselpaar, das zum Ver- und Entschlüsseln verwendet wird, um einen Beweis der Identität einer Plattform zur Erstellung von AIKs zu liefern.

„Conformance Credential“: Die Konformitätsbeglaubigung (engl. „Conformance Credential“) wird ausgestellt, für Plattformen, die einen TPM enthalten. Sie soll aufzeigen, dass der „vertrauenswürdige Basisblock“ (engl. „Trusted Building Block“ (TBB)) und dessen Implementierung der Prüfung vertrauenswürdig ist. Die Konformitätsbeglaubigung enthält keine sensiblen Informationen oder Informationen, die dazu verwendet werden können, eine spezifische Plattform eindeutig zu identifizieren.

„Platform Credential“: Die Plattform-Vertrauensbeglaubigung (engl. „Platform Credential“) wird durch den Plattformhersteller, Anbieter oder eine unabhängige Entität erteilt. Sie solle aufzeigen, dass die Plattform ein TPM, wie durch das „Endorsement Credential“ beschrieben, sowie einen TBB, wie durch das „Conformance Credential“ beschrieben, enthält. Die Plattform-Vertrauensbeglaubigung enthält den Namen des Herstellers der Plattform, die Plattform-Modellnummer und -Modellversion und Referenzen auf das „Endorsement Credential“ und die „Conformance Credentials“. Das „Platform Credential“ ist kritisch bezüg-lich der Privatsphäre, da es Informationen enthält, die zur eindeutigen Identifizierung einer spe-zifischen Plattform verwendet werden können.

„TCG Software Stack“

Der „TCG Software Stack“ (TSS) ist eine plattformunabhängige Schnittstelle, um TPM-Funktionen benutzen zu können. Der TSS ermöglicht die Erstellung von Schnittstellen für bestehende krypto-graphische APIs wie z. B. MS-CAPI8 oder PKCS#119. Dies ermöglicht für Anwendungsprogram-me eine TPM-Unterstützung, die diese APIs verwenden. Um die Funktionen eines TPMs vollständig nutzen zu können, müssen Anwendungsprogramme den TSS direkt unterstützen.

6.1.4 Betriebssysteme, die Trusted Computing unterstützen

Microsoft Windows Vista

Microsoft Corporation [Micr2007] ist ein Gründungsmitglied der TCPA. Das Betriebssystem Win-dows Vista kann ein TPM 1.2 zur Partitionsverschlüsselung (genannt BitLocker16) nutzen.

16 Siehe http://technet2.microsoft.com/WindowsVistaa/en/library/c61f2a12-8ae6-4957b031-97b4d762cf31 1033-.mspx

67

Alternativen und Kombinationen

Im Mai 2007 kündigten Microsoft und die TCG die Interoperabilität mehrerer Protokolle an, die eine Integritätsüberprüfung erlaubt (bei der TCG „TNC“ genannt und „NAP“ bei Microsoft).

Unterhalb der Anwendungsprogrammebene enthält Vista Microsoft17 zufolge eine TPM-Manage-ment-API, welche „TPM Base Service“ (TBS) genannt wird. Ihre Funktionalitäten werden von Mi-crosoft18 wie folgt beschrieben:

● effektives Teilen von begrenzten TPM-Ressourcen, wie „Key Slots“, „Authorization Ses-sion Slots“ und „Transport Slots“

● priorisierter und synchronisierter Zugang zu TPM-Ressourcen zwischen mehreren Instan-zen von „TPM Core Services“ (TCS)

● angemessenes Management von TPM-Ressourcen über Energiezustände

● Schutz der „TPM Core Services“ (TCS) vor dem Zugang zu TPM-Befehlen, die beschränkt werden sollen, entweder wegen Einschränkung der Plattform oder administrativer Anforderungen

Xen

Xen ist ein „virtueller Maschinenverwalter“ (engl. „Virtual Machine Monitor“ (VMM)), der von der Universität Cambridge entwickelt wurde und unter der „GNU General Public License“ (GPL) ver-breitet wird. Xen kann mehrere Gastbetriebssysteme in virtuellen Maschinen (VM) ausführen. Xen regelt den Zugriff auf die Ressourcen, wie den Prozessor, Hauptspeicher und Ein-/Ausgabe für die Gastsysteme. IBM Research integrierte die Sicherheitsarchitektur sHype in Xen. sHype bietet eine flexible Durchsetzung der Zugangskontrolle zur strikten Trennung und Kontrolle über die Auftei-lung der Hardware-Ressourcen und der Kommunikation zwischen unterschiedlichen VMS.

Da ein TPM nicht dafür entwickelt wurde, gleichzeitig von mehreren Betriebssystemen benutzt zu werden, entwickelt IBM eine virtuelle TPM-Architektur, um TPM-Unterstützung für alle Betriebs-systeme zu bieten, die auf Xen laufen. Um dies zu realisieren, wurde die Menge an TPM-Kommandos, die in der TCG 1.2 Spezifikation definiert werden, durch Kommandos erweitert, welche mehrere logische Instanzen von TPMs ermöglichen, die durch Gastbetriebssysteme transparent verwendet werden können. Damit kann eine Software, die beabsichtigt ein TPM zu be-nutzen, ohne eine Änderung weiterarbeiten, wenn sie auf Xen ausgeführt wird.

PERSEUS-Architektur und Turaya Sicherheitskern

Das PERSEUS-Projekt stellt eine offene Plattform zur Verfügung, die die Realisierung einer multi-lateralen Sicherheitsbasis für Trusted Computing bietet. Es ist beabsichtigt, einen weiten Bereich an Hardware-Plattformen wie PC, PDA und eingebetteten Computersystemen zu unterstützen. PER-SEUS verwendet einen Mikrokern, der nur elementare Funktionen wie Prozessmanagement, Spei-chermanagement und Interprozesskommunikation enthält und damit die sicherheitsrelevanten Teile der Betriebssystemkomponenten minimiert, was eine formale Überprüfung seiner Implementierung erlaubt. Die PERSEUS-Architektur realisiert sicherheitskritische Anwendungsprogramme wie digi-tale Signaturen oder DRM-Anwendungsprogramme und konventionelle Betriebssysteme als ge-

17 Siehe http://technet2.microsoft.com/WindowsVista/en/library/29201194-5e2b-46d0-9c77-d17 c25c56af31033-.mspx

18 Siehe http://msdn2.microsoft.com/en-us/library/aa446796.aspx

68

Alternativen und Kombinationen

trennte Prozesse, die nur miteinander oder mit den Rechnerkomponenten kommunizieren können, wenn der PERSEUS-Sicherheitskern dabei involviert wird.

PERSEUS ermöglicht die Realisierung von „Richtliniendurchsetzung“ (engl. „Policy Enforce-ment“), d. h. z. B. die Durchsetzung von DRM oder die Möglichkeit des Zuganges zu kostenpflich-tigen Informationsdiensten; gleichzeitig wird aber verhindert, dass Anbieter mehr private Informa-tionen über den Benutzer sammeln, als nötig ist, um den Dienst zur Verfügung zu stellen. Damit kann PERSEUS als eine Basis für DRM-Lösungen dienen und bietet Sicherheit im Sicherheitsbereichsmodus, um den Zugang zu einem Dokument außerhalb des erforderlichen Arbeitsflusses zu verwehren. PERSEUS kann ebenfalls dazu verwendet werden, ein sicheres Mehrbenutzersystem zu realisieren, welches unterschiedliche isolierte Dienste wie einen Webserver, eine Datenbank oder eine Firewall parallel auf der gleichen Hardware laufen lassen kann.

Die Sicherheitssoftwareschicht PERSEUS setzt auf einem L4-Mikrokern auf, welcher an der Uni-versität Karlsruhe und der Technischen Universität Dresden entwickelt wurde. Über dem L4-Mikro-kern sind ein Ressourcenmanagement und eine Zugangskontrollschicht platziert, welche die Vertei-lung von den Ressourcen der Rechnerkomponenten zu dem konventionellen Betriebssystem und al-len sicherheitrelevanten Anwendungsprogrammen darüber regeln. PERSEUS bietet auch einen ver-trauenswürdigen Urlader (engl. „Bootloader“), der als Trusted Computing-unterstützende Version des GRUB („Grand Unified Bootloader“) implementiert wurde, um sicher zu stellen, dass eine spezifische Betriebssystemkonfiguration gestartet wird. Eine „sichere Benutzerschnittstelle“ (engl. „Secure GUI“) bietet vertrauenswürdige Schnittstellen zwischen dem Anwender und sicheren An-wendungsprogrammen. Der Anwendungsprogrammmanager von PERSEUS sichert die kontrollierte Installation und Aktualisierung von Software.

Konventionelle Betriebssysteme lassen normalerweise Anwendungsprogramme mit den gleichen Rechten der Benutzer ablaufen, welche diese gestartet haben. Dies führt dazu, dass Anwendungs-programme mit mehr Privilegien laufen, als sie tatsächlich benötigen. Der Anwendungsprogramm-manager von PERSEUS minimiert Privilegien von Anwendungsprogrammen.

Turaya

Turaya ist die vermarktete Fassung der Sicherheitssoftwareschicht PERSEUS auf einem L4-Micro-kern.

6.2 Kombination von Trusted Computing mit ähnlichen Sicher-heitskonzepten

Der vorhergehende Abschnitt führte Trusted Computing (TC) als ein Konzept ein, das Sicherheit verankert und Vertrauen aufbaut. Diese Eigenschaften sind eine wichtige Grundlage für die in Kapi-tel 4 eingeführten Sicherheitsmodelle. Der nächste Abschnitt zeigt auf, wie die beschriebenen Si-cherheitsmodelle mit Trusted Computing kombiniert werden können.

Herausforderungen zu diesem Ansatz, wie etwa die Grenzen eines vertrauenswürdigen Computer-systems und die Besonderheiten des Schlüsselmanagements in Trusted Computing werden in die-sem Abschnitt abschließend behandelt.

69

Alternativen und Kombinationen

6.2.1 Vertrauensanker

Der grundlegende Vertrauensanker im Trusted Computing ist das TPM.

Um einen verwendbaren Vertrauensanker zu erstellen, muss nicht nur ein TPM in einer Plattform vorhanden sein, sondern es muss auch ihre korrekte Nutzung in den Startroutinen der Plattform (CRTM) erfolgen. Auf dieser Basis können entsprechende Beglaubigungen (Zertifikate) ausgestellt werden.

6.2.2 Plattformintegrität mit Trusted Computing

Die Eigenschaft von TC, überprüfbar eine Plattform zu starten (engl. „to boot“) zu können, schafft eine Umgebung, in der das Laden und Starten von Software auf einem Computersystem überprüft und durchgesetzt werden kann. Diese Eigenschaft stellt sicher, dass auf einem Computer eine bestimmte Software-Konfiguration nach dem Startvorgang läuft.

Softwareintegrität beruht üblicherweise auf dieser Annahme. Während Ansätze wie „Type Enforce-ment“ (vgl. Abschnitt 4.1.3) und „Hypervisor“ (siehe 4.5.3) versuchen, Anwendungsprogramme zu isolieren, kann eine TC-basierte Integritätskontrolle eine höhere Anwendungsprogrammsicherheit bringen.

Mithilfe eines sicheren Ladevorgangs (der wiederum durch den „Bootloader“ unter Verwendung des TPM-Vertrauensankers überprüft wird) werden alle Teile des Betriebssystems und der Software nach dem Laden überprüft. Konfigurationsdateien, Richtlinien oder Anwendungsprogrammdaten können die sichere Ladefunktion durchlaufen. Auf diese Art erkennt das Computersystem den Inte-gritätszustand aller Komponenten, Anwendungsprogramme und falls nötig, der zugehörigen Daten. Vertrauensentscheidungen können auf dem beim Laden vorliegenden Plattform-Zuständen aufbauen und getroffen werden.

Ein praktisches Beispiel hierfür könnte ein PC in einem Privathaushalt sein. Heutzutage teilen sich die meisten Anwendungsprogramme Daten untereinander. Textverarbeitung, „Homebanking“, E-Mail, Spiele, Anwendungsprogramme aus dem Internet usw. können auf die Daten der jeweilig an-deren Programme zugreifen. Viele der Angriffe durch bösartige Programme wie Viren, Trojaner, Spyware und automatisiertes Phishing funktionieren durch das Manipulieren von Programmteilen, eines Anwendungsprogramms oder des Betriebssystems. In einer durch Integritätskontrolle geschützten Plattform könnte man sich folgendes Szenario vorstellen. Unter Kombination mit dem Isolations- / Hypervisoransatz würde ein Computer nach dem Urladen („Booten“) mehrere virtuelle Maschinen starten. Eine virtuelle Maschine ist beispielsweise eine vertrauenswürdige Umgebung, die nur Anwendungsprogrammen mit absoluter Integrität die Ausführung oder den Zugang zu kritischen Daten erlaubt. Hier könnte eine „Homebanking-Software“ oder Programme zum Signieren von Dokumenten installiert werden. Eine zweite virtuelle Maschine stellt Speicherplatz zur Installation von Programmen und zum Testen von neuen Anwendungsprogrammen der „mittleren“ Vertrauensebene bereit. Diese Umgebung erlaubt bei Integritätsverletzungen nur nach einer expliziten Benutzerprüfung Zugang zu kritischen Daten. Auf dieser „mittleren“ Vertrauensebene kann experimentiert werden, aber Verletzungen der Sicherheitsrichtlinien werden durch das Sicherheitssystem berichtet. Eine dritte virtuelle Maschine wäre eine „Spielwiese“, auf der alles erlaubt ist. Hier ist kein Zugang zu lokalen Daten außerhalb der virtuellen Maschine möglich. Beliebige heruntergeladene Software oder Aktive Inhalte dürfen dort ablaufen. Durch die

70

Alternativen und Kombinationen

Verwendung des TPM und dem darauf aufbauenden sicheren Ladevorgang kann das Betriebssystem immer zu einer vertrauenswürdigen virtuellen Maschine wechseln, falls es Aktionen durchführen will, die eine höhere Sicherheit erfordern.

6.2.3 Verteiltes Vertrauen mit Trusted Computing

Integritätsüberprüfungen, die auf Trusted Computing und einem Vertrauensanker basieren, können für das Vertrauensmanagement in verteilten Computersystemen von wichtiger Bedeutung sein. Zu beachten ist, dass verteilte Computersysteme aus einer Ansammlung an entfernbaren Geräten (wie USB-Sticks oder Festplatten) bis hin zu einem Netz aus GRID-Rechnern oder Webservern und Datenbanken bestehen können.

Der Aufbau von verteiltem Vertrauen beruht auf der Verbindung der einzelnen Geräte untereinander. Grundsätzlich funktioniert dies durch den Einsatz eines Schlüssels oder eines Zertifikates, das in dem TPM eines jeden Gerätes gespeichert ist. Durch die Protokolle zur Integritätsüberprüfung können Geräte / Computer sich gegenseitig davon überzeugen, dass sie zur gleichen Vertrauenszone gehören.

Diese Funktionalität ist eine Erweiterung von heutigen Protokollen, die Zertifikate und Schlüssel zur Vertrauenserzeugung verwenden, beispielsweise für X.509-Zertifikate für „Single Sign On“ zur Authentisierung, welche auch auf Smartcards abgelegt werden können. Was durch Trusted Computing hinzukommt, ist ein sicheres Speichern der Zertifikate und ein hardwaregeschützter, standardisierter Vertrauensanker für das Prüfungsschema in allen Teilen des verteilten Computersystems. Der Hauptnutzen der Verwendung von Trusted Computing hierfür sind interoperable Verfahren für den Vertrauensanker und die Integritätsüberprüfung.

6.2.4 Klassische Sicherheitsmodelle und Trusted Computing

Viele der klassischen Sicherheitsmodelle werden als Softwarekomponenten in Betriebssystemen oder Datenbankprogrammen implementiert. Ein verbreitetes Konzept ist, eine Entscheidungsinstanz (engl. „Reference Monitor“) zur Zugriffskontrolle einzusetzen. Diese Entscheidungsinstanz ist ein Softwaremodul, das kritische Funktionen in einem Sicherheitssystem durchführt. Die meisten der Sicherheitsmodelle, die in dieser Studie vorgestellt werden, verwenden eine solche Entscheidungs-instanz, beispielsweise für den Datenzugang oder für das Gewähren von weiterführenden Privilegi-en.

Bei der Erweiterung oder Kombination der klassischen Sicherheitsmodelle mit Trusted Computing ist die Entscheidungsinstanz eine anzupassende Schlüsselkomponente, um einen Vorteil aus dem TPM zu ziehen. Die Entscheidungsinstanz kann mit dem TPM und dem sicheren Ladevorgang in mehreren Arten zusammenarbeiten:

● Durchsetzung von Richtlinien zur Programmintegrität

● Durchsetzung von Richtlinien zur Datenintegrität

● Absicherung der Integrität von Identitäten, Vertrauensbescheinigungen und Schlüsseln

Durch die Erweiterung um die Entscheidungsinstanz können Modelle wie „Typ-Durchsetzung“ (engl. „Type Enforcement“) eine Anwendungsprogrammintegrität verlässlich vor ihrem Zugriff auf eine höhere Sicherheitsebene überprüfen.

Durch das Hinzufügen von Trusted Computing zu einem klassischen Sicherheitsmodell erwartet

71

Alternativen und Kombinationen

man eine Steigerung der Robustheit und Effektivität des klassischen Sicherheitsmodells. Auch kann ihre Funktionalität durch sicheres Laden, Integritätskontrolle und Integritätsüberprüfung erweitert werden.

6.2.5 Herausforderungen

Obwohl die grundlegenden Spezifikationen und die Hardware-Integration von Trusted Computing heute schon abgeschlossen sind, bleiben Herausforderungen für ihre Weiterentwicklung bestehen. Diese Herausforderungen werden in den folgenden Abschnitten zusammengefasst.

6.2.6 Interoperabilität

Da die effektive Verwendung von Trusted Computing in Kombination mit anderen Sicherheitsmaßnahmen in Betriebssystemen und Anwendungsprogrammen nach Erweiterungen verlangt, müssen Protokolle und Prozeduren für die interoperable Verwendung von Trusted Computing gefunden werden.

Es bleibt abzuwarten, wie schnell die Anbieter von Betriebssystemen bereit sind, interoperable Sicherheitsmodelle zu implementieren, sowie einheitliche Schnittstellen für die Integritätsüberprüfung und generische Methoden für die Kontrolle der Integrität, Konfiguration, Schlüsselverwaltung usw..

Kritische Masse

Jede neue Technik, die erfolgreich sein soll, muss eine kritische Masse auf dem Markt erreichen. Wie in der Diffusionstheorie beschrieben [Roge2003], muss eine große Zahl an sogenannten „early Adopters“ Kenntnisse über die Nützlichkeit der neuen Sicherheitstechnik verbreiten. Nur wenn ein anfänglicher Erfolg bei einer normalerweise kostenintensiven Einführung gelingt, ist auch die Chance auf einen breiten Einsatz gegeben.

Oftmals erfordert dies bei Produkten in der Informationstechnik starke Netzwerkeffekte. Netzwerkeffekte können nur aufgebaut werden, wenn viele Anbieter gemeinsam neue Plattformen unterstützen. Dies kann durch offene Schnittstellen und offene Spezifikationen erreicht werden.

Flexibilität und Verwaltung der Schlüssel

Wenn viele Trusted Computing-Plattformen eingesetzt werden, rücken die Flexibilität der sicheren Maschinen und die Schlüsselverwaltung ins Blickfeld. Eine der Kernanforderungen von Verbrau-cherorganisationen ist die Möglichkeit, einen Computer so zu starten, dass er nicht durch andere Computersysteme kontrolliert werden kann. Dies führt notwendigerweise zu Plattformen mit vielen alternativen Konfigurationen unterschiedlicher Freiheitsgrade. Anstatt der Konfiguration eines ein-zigen PCs zu verwalten, muss der Benutzer die Administration von mehreren virtuellen Maschinen übernehmen. Dies erfordert Kenntnis und Praxis, was die Verbreitung verlangsamt.

Eine andere wichtige Frage ist die der Schlüsselverwaltung in großen Infrastrukturen, welche auf Trusted Computing-Plattformen basieren. Um eine globale Infrastruktur der Integritätsüberprüfung zu ermöglichen, ist nicht nur eine interoperierende Computer- und Softwarebasis nötig, sondern

72

Alternativen und Kombinationen

auch eine Möglichkeit, mit einer Menge an überprüfbaren Werten der Systemkonfiguration, der Zertifikate, der Schlüssel und mit anderen Vertrauensbeglaubigung umzugehen, die in dieser Infrastruktur verwendet werden.

Monopole und Oligopole

Die letzte Herausforderung ist die der Wettbewerbsaufsicht. Schon sehr früh in der Einführung von Trusted Computing entstand die Gefahr der Bildung von monopolisierenden Kräften oder die ver-hängnisvolle Festlegung auf bestimmte Plattformen, Anbieter oder Techniken. Dies führt normalerweise zu Preissteigerungen, weniger Wettbewerb und behindert Innovationen. Eine Maßnahme, die in diesem Fall hilfreich ist, ist die Entwicklung von offenen Schnittstellen und Lösungen, beispielsweise durch offene Standards, FLOSS-Entwicklungen oder notfalls durch staatliche Regulierung.

Der Einsatz von Trusted Computing sollte deshalb mit großer Sorgfalt vorgenommen werden. Un-terschiedliche Schnittstellen in der Infrastruktur, die den Austausch von Komponenten erlauben, müssen betrachtet werden. Beispielsweise sollte es eine Schnittstelle geben, die das Betriebssystem von der vertrauenswürdigen Plattform trennt (z. B. ein Hypervisor). Das Gleiche könnte mit der Schlüsselverwaltung und der Integritätsüberprüfung gemacht werden.

73

Kapitel 7

SchlussfolgerungDieses Kapitel fasst die Ergebnisse der Studie hinsichtlich der Kombination der klassischen Sicher-heitsmodelle mit Trusted Computing zusammen. Es analysiert die Anwendbarkeit, die Reife und die Verfügbarkeit der Technik und bietet einen Überblick über neue Entwicklungen.

Um die Analyse der klassischen Sicherheitsmethoden und neuer Konzepte abzuschließen, befasst sich dieser Abschnitt mit der Sicherheit von Computersystemen mit hardwarebasierten Vertrauensankern. Dieser Abschnitt nennt exemplarisch Trends der Entwicklungen, die auf Trusted Computing basieren. Er zeigt auch den Platz der Trusted Computing-Komponenten und Funk-tionalitäten mit anderen unterstützenden oder alternativen Konzepten, Modellen und Mechanismen innerhalb des Bereiches der sicherheitskritischen Nutzung.

7.1 Entwicklungspfade von sicheren Computersystemen basie-rend auf Trusted Computing

Wie in 6.2.1 erläutert, bietet Trusted Computing die Möglichkeit des Aufbaus eines Vertrauensan-kers, welche die Wurzel einer Vertrauenskette zwischen dem „Hardware Security Module” (HSM, z. B. TPM) und der Plattform ist, sowie einem Mechanismus der Richtliniendurchsetzung. Dies erlaubt einen Nutzungsbereich, den wir in vier Kategorien einteilen. Abbildung 7.1 zeigt welche die möglichen Entwicklungspfade von Trusted Computing sind.

7.1.1 Klassische Sicherheitsmodelle

„Mandatory Access Control (MAC)“ und „Discretionary Access Control (DAC)“, mehrschichtige Sicherheit („Multilevel Security“, MLS), „Chinesische Mauer“ („Chinese Wall“), „Type Enforcement“ und Spaltung der Aufgaben („Rule Set Based Access Control“, RBAC) basieren alle auf dem Konzept einer Zugangskontrollmatrix mit unterschiedlichen Eigenschaften und erlaubten Operationen. Der Matrix liegt normalerweise eine Sicherheitsrichtlinie zugrunde, die wiederum Mechanismen zur Durchsetzung der Sicherheitsrichtlinie benötigt. Üblicherweise ist hier eine weitere Entscheidungsinstanz nötig, die die laufenden Operationen nicht vertrauenswürdiger Programm überprüft, ob diese den gegebenen Sicherheitsrichtlinien entsprechen. Die Vertrauenswürdigkeit der Entscheidungsinstanz ist damit entscheidend für die Durchsetzung einer solchen Zugangskontrollrichtlinie in dem ausführenden Computersystem verantwortlich.

74

Schlussfolgerung

75

Abbildung 7.1: Mögliche Entwicklungspfade des Trusted Computing

Schlussfolgerung

Ein TPM-basierter Vertrauensanker kann dabei helfen, Vertrauen in Mechanismen der Richtlinien-durchsetzung, z. B. Vertrauen gegenüber einem Überwachungsprogramm aufzubauen.

Ist die Vertrauenswürdigkeit eines Überwachungsprogramms durch seine Integrität garantiert, die dadurch erreicht werden kann, dass das Überwachungsprogramm mit dem zum Vertrauensanker ge-hörenden privaten Schlüssel signiert wird. Beispielsweise kann eine Plattform, welche ein TPM als Vertrauensanker besitzt, eine Prüfsumme des Überwachungsprogramms erzeugen und diese per In-tegritätsüberprüfung an andere Computersysteme senden. Letzteres kann die Integrität der Entschei-dungsinstanz basierend auf dem Vertrauensanker überprüfen, was dem anderen Computersystem er-laubt, dem auf dieser Plattform laufenden Überwachungsprogramm und damit verbunden wiederum der Durchsetzung des Zugangskontrollmodells zu vertrauen.

7.1.2 Sicheres Anzeigeprogramm und sichere Ein-/Ausgabe

Diese Kategorie umfasst die sichere Ein-/Ausgabe eines Anwendungsprogramms und zieht unter-schiedliche, zu diesem Zweck genutzte Peripheriegeräte wie Bildschirme, Tastaturen und Fingerab-druckscanner in Betracht. Ein auf Trusted Computing basierter Ansatz wird eine Benutzerschnittstelle unterstützen, die der vollständigen Kontrolle der „Trusted Computing Base“ (TCB) unterliegt. Die TCB selbst ist durch eine auf der Vertrauenskette basierten Integritätsprüfung überprüfbar, die bis zum Vertrauensanker führt.

7.1.3 Sicherer richtlinienbasierter Datenfluss

Diese Kategorie, die zuvor als Informationsflusskontrolle betrachtet wurde, kann durch einen TPM-basierten Vertrauensanker beträchtlich erweitert werden. Ähnlich dem Überwachungsprogramm, baut der richtlinienbasierte Datenfluss auf einem Richtliniendurchsetzungsmechanismus auf. Dies können „Durchsetzer“ (engl. „Enforcer“) von Zugriffsbeschränkungen einer Softwareanwendung sein, wie im Falle von DRM oder „Sticky Policies“ (Richtlinien, die für bestimmte Datensätze gelten) oder Überprüfer der Integrität für sichere Softwareaktualisierung. Diese „Durchsetzer“ oder Überprüfer können ihrerseits wiederum Subjekte einer Integritätsüberprüfung sein, welche auf Zertifikaten basiert, die mit einem privaten Schlüssel im TPM generiert werden. Deshalb kann eine andere Plattform die Vertrauenswürdigkeit der Mechanismen überprüfen, die auf der lokalen Plattform ausgeführt werden. Das erlaubt einer entfernten Plattform, Daten an die lokale Plattform des Benutzers zu senden und dabei sicherzustellen, dass die verwendeten Richtlinien korrekt durchgesetzt werden, die den Datenfluss kontrollieren. Anwendungsmöglichkeiten dieses Schemas sind Bezahlfernsehen, Softwareverleih und kopiergeschützte Medien. Das hat für Inhalte-Anbieter, welche die Kontrolle über die Verwendung ihrer Produkte durch die Konsumenten durchsetzen möchten, entscheidende Vorteile.

7.1.4 Vertrauenswürdige Computersysteme

Diese Kategorie beinhaltet alle Szenarien, die eine Integritätsüberprüfung von Software auf einer anderen Plattform ermöglichen. Dies erlaubt eine Plattform eine Aussage zu treffen über das Verhalten des korrespondierenden Computersystems, aber auch jedes Programm, das der Benutzer der Plattform nutzt. Das TPM als die Wurzel der Vertrauensverankerung kann ein gültiges Integritätsüberprüfungszertifikat ausstellen, das die Software, die auf der Plattform läuft, identifziert. Die Vertrauenswürdigkeit der Plattform bezüglich seines Verhaltens wird an den Vertrauensanker gebunden. Übliche Anwendungsfälle sind die Prüfung von Softwareintegrität, die

76

Schlussfolgerung

Absicherung der Fälschungssicherheit, vertrauenswürdige Plattformkonfigurationen, sowie eine zusätzliche sichere Authentisierung der Benutzer auf dem Computersystem, die Auswertung von „Audit-Logs“ und die Unterstützung der forensischen Analyse.

7.2 Trusted Computing innerhalb eines Sicherheitskonzeptes

Trusted Computing kann eine große Rolle bei der Herstellung von Sicherheit in einem Computersystem spielen. Durch die Bereitstellung eines Vertrauensankers sichert es die Vertrauenswürdigkeit der Implementierung des Vertrauensmodells.

Anders dargestellt unterstützt Trusted Computing ein Sicherheitskonzept, welches die Im-plementierung des Vertrauensmodells durch einen TPM-basierten Vertrauensanker absichert. Beispielsweise ist das Erreichen eines Sicherheitsziels, wie der Vertrauenswürdigkeit, direkt abhängig von dem Sicherheitsmodell, welches definiert, wo die Verschlüsselung angewendet wer-den soll. Das Sicherheitsmodell selbst hängt vom Vertrauensmodell ab. Es leitet sich von dessen Spezifikation und der Vertrauenswürdigkeit seiner technischen Komponenten ab. Deshalb verbes-sert die Integration der Trusted Computing-Technik in Computersystemen das Sicherheitskonzept durch die vertrauenswürdige, kostengünstige und vielseitige Lösung des TPM-basierten Vertrau-ensankers.

Trusted Computing ist nicht nur auf einen Vertrauensanker beschränkt. Tatsächlich spielen Funktio-nen, die auf Trusted Computing basieren, wie etwa „Attestation“, „Sealing“, oder „Trusted Boot“ (basiert auf CRTM), eine wichtige Rolle bei dem Aufbau von Vertrauen in andere Computersyste-me, ihrer Komponenten oder deren Verhalten.

7.3 Die Nutzung von Trusted Computing Funktionalitäten und Un-terstützungen komplementärer oder alternativer Techniken

Die Abbildung 7.2 gibt eine Übersicht über die Eignung der Sicherheitskonzepte, Modelle, Mecha-nismen und Hardware-Komponenten, die in dieser Studie erwähnt werden für mehrere Anwendnungsszenarien. Sie werden nach ihren Nutzungsfällen und Trusted Computing unterstützenden Funktionen kategorisiert. Die für Trusted Computing relevanten Nutzungsfälle sind Informationsflusskontrolle, Datenzugangskontrolle, sichere elektronische Signaturen, Schutz medialer Inhalte (DRM), sichere virtuelle Maschinen, sichere Authentisierung und vertrauenswürdige Software. Trusted Computing unterstützt Funktionalitäten, wie Vertrauenswürdigkeit zwischen Computersystemen, das Durchsetzen von Sicherheitsrichtlinien und sichere Ein-/Ausgabe, die je nach Bereich unterschiedlich wichtig sein können. Sicherheitsmodelle, Mechanismen oder Komponenten sind einer bestimmten Trusted Computing unterstützenden Funktionalität innerhalb eines relevanten Nutzungsfalls zugeordnet.

Die Elemente in dieser Abbildung sind nicht nur Trusted Computing-Komponenten oder Funktiona-litäten, sondern auch unabhängige Modelle, Mechanismen und Konzepte, die diese Komponenten oder Funktionalitäten unterstützen.

Beispielsweise kann der Schutz medialer Inhalte (engl. „Digital Rights/Restrictions Management“, DRM) als Anwendungsbereich von unterschiedlichen Funktionen profitieren, die durch Trusted Computing unterstützt werden. Entfernte Vertrauenswürdigkeit ist eine wichtige Funktionalität, auf der basiert, dass ein Medienanbieter auf ein bestimmtes Verhalten einer Benutzerplattform vertrauen kann, welches zum Schutz von Inhalten gewünscht ist, damit diese nicht an unautorisierte

77

Schlussfolgerung

Benutzer verteilt werden. Insbesondere ist die Integritätsüberprüfungsfunktionalität, die durch Trusted Computing bereitgestellt wird, für den Schutz medialer Inhalte bedeutsam. Mit der Integritätsüberprüfung kann ein Benutzer die Konfiguration und Eigenschaften dieser Plattform dem Anbieter berichten, der sie mit definierten Werten vergleicht. Der Anbieter überzeugt sich vom Verhalten der Benutzerplattform und kann auf diese Weise einen zuverlässigen Schutz der medialen Inhalte gewährleisten. Das Integritätsüberprüfungs-Zertifikat selbst kann nur auf dem „Attestation Identity Key“ (AIK) basierend überprüft werden, der exklusiv zu einem bestimmten TPM gehört. Deshalb stellt ein in die Benutzerplattform integriertes TPM den Vertrauensanker seiner Plattform dar. Es wird eine fein abstufbare Zugangskontrolle zu Medieninhalten mit der Durchsetzung einer bestimmten Richtlinie auf der Benutzerplattform erreicht. Richtliniendurchsetzung ist damit notwendig und kann in diesem Fall durch Sicherheitskonzepte erreicht werden, die auf „Sticky Policy“ oder DRM-Implementierungen basieren. Ein „Trusted Viewer“ (sicheres Anzeigeprogramm) ist zum Schutz von Medieninhalten vor einem Abfangen und Manipulieren der Ein-/Ausgabe notwendig. Dies kann durch das Einbinden von grundlegenden Sicherheitsfunk-tionalitäten des „Trusted Viewers“ in die „Trusted Computing Base“ garantiert werden (deren Integritätsmesswerte zur Überprüfung gespeichert werden).

Diese Kombination der Sicherheitsmechanismen, Modelle und Komponenten, werden in der Kategorie „Schutz medialer Inhalte“ in Abbildung 7.2 repräsentiert.Ein anderes Beispiel ist die Datenzugriffskontrolle (engl. „Data Access Control“). Sie zeigt, wie die durch Trusted Computing unterstützten Funktionalitäten auch durch alternative Mechanismen reali-siert werden können. In diesem Fall kann die Vertrauensverankerung durch die Verwendung von Smartcards umgesetzt werden. Dabei ist Authentizität und Autorisation des Benutzers das ultimati-ve Sicherheitsziel, das Vertrauenswürdigkeit erfordert. Darüber hinaus wird Richtliniendurchset-zung durch Sicherheitsmodelle wie Bell-LaPadula oder Chinesische Mauer („Chinese Wall“) rea-lisiert.Die Kombination von Trusted Computing-Komponenten und anderen Mechanismen oder Konzep-ten kann eine hohe Sicherheitsebene erreichen, wie im Falle von sicheren virtuellen Maschinen (VMs), die auf der Isolation der virtuellen Maschinen, sowie eines TPM als Vertrauensanker und der Integritätsüberprüfung der Konfiguration der virtuellen Maschine durch eine andere Plattform, basiert.

Deshalb sind alternative Lösungen zu Trusted Computing hauptsächlich solche, die Vertrauenswür-digkeit von technischen Komponenten behandeln. Meist wird ein hardwarebasiertes Sicherheitsmo-dul (engl. „Hardware Security Module“, HSM) bei diesem Ziel benutzt: Trusted Computing ist die am weitesten verbreitete, relevante und offen spezifizierte Technik in diesem Bereich.

78

Schlussfolgerung

79

Abbildung 7.2: Trusted Computing, Alternativen und unterstützte Sicherheitstechniken

Literaturverzeichnis

Literaturverzeichnis

[Ande1996] Anderson, R. (1996) A security policy model for clinical information systems. In Proceedings of the 15th IEEE Symposium on Security and Privacy. IEEE Comp. Society Press, 1996.

[Ande1999] Anderson, R. (1999) Why cryptosystems fail, University Computer Laboratory, Cambridge, UK.

[Ande2001] Anderson, R. (2001) Security Engineering, Wiley Publishers, New York.

[ArFaSm97] Arbaugh W. A., Farber D. J., Smith J. M. (1997) A Secure and Reliable Bootstrap Architecture, Proceedings of the IEEE Symposium on Research in Security and Privacy, Oakland, Mai 1997.

[Bell2005] Bell, D. E. (2005) Looking back at the Bell-LaPadula security model, Proceedings of the Annual Computer Security Applications Conference (ACSAC) 2005, Marriott University Park, Tucson, Arizona.

[BSSW1995] Badger, L., Sterne, D. F., Sherman, D. L., Walker, K. M., Haghighat, S. A. (1995)Practical Domain and Type Enforcement for UNIX, Proceedings of the IEEE Symposium on Security and Privacy 1995.

[BeLa1973] Bell, D. E., LaPadula, L. J. (1973) Secure Computer Systems: Mathematical Foundations, MITRE Corp Bedford MA Report AD0770768, Nov. 1973, Seite 42.

[Biba1977] Biba, K. J. (1977) Integrity Considerations for Secure Computer Systems, MITRECorp MA Report MTR-3153, April 1977.

[BoBo1995] Borcherding, B., Borcherding, M. (1995) Covered trust values in distributed systems, In: Communications and multimedia security. Proceedings of the IFIP TC6, TC11 and Austrian Computer Society Joint Working Conference on Communications and Multimedia Security, 1995. Ed.: R. Posch. London 1995. Seite 24-31.

[BoKa1985] Boebert, W. E. and R. Y. Kain (1985) A Practical Alternative to HierarchicalIntegrity Policies, Proceedings of the National Computer Security Conference, Vol. 8, Num. 18, 1985.

[BrNa1989] Brewer, D. F. C., Nash, M. J. (1989) The chinese wall security policy, In: Proceedings of the IEEE Symposium on Security and Privacy, IEEE Press, Seite 206-214.

[BrRo1991] O’Brien, R. and C. Rogers (1991) Developing Applications on Lock, Proceedings of the National Computer Security Conference, Vol 14, 147-156, Oktober 1991.

[Bund2007] Bundesamt für Sicherheit in der Informationstechnik (2007), Sichere Plattformen und die Trusted Computing Group (TCG), http://www.bsi.bund.de/sichere_plattformen/trustcomp/infos/tcgi.htm)

[CC1996] Common Criteria Portal (1996) Common Criteria (CC), http://www.com moncriteriaportal.org/ .

80

Literaturverzeichnis

[ClWi1987] Clark, D., Wilson, D. (1987) A Comparison of Commercial and Military Computer Security Policies, In: Proceedings of the IEEE Symposium on Security and Privacy,1987, Seite 184, http://doi.ieeecomputersociety.org/10.1109/SP.1987.10001.

[ClWi2007] Clark-Wilson Model, Wikipedia, 15-Nov-2007, http://en.wikipedia.org/wiki/Clark- Wilson_model .

[CPB2003] Cassa Mont, M., Pearson, S. and Bramhall, P. (2003) Towards Accountable Management of Identity and Privacy: Sticky Policies and Enforceable Tracing Services, Proceedings of the 14th International Workshop on Database and Expert Systems Applications (DEXA’03), IEEE Computer Society, Seite 377.

[Denn1976] Denning, D. E. (1976) 4, Communications of the ACM, v.19 n.5, Mai 1976, Seite 236-243.

[Dix2003] Dix, A. (2003) Trusted Computing und Datenschutz in Deutschland, DuD - Datenschutz und Datensicherheit 27(2003)), Seite 561-562.

[DrNe1998] Dridi, F., Neumann, G. (1998) Towards Access Control for Logical Document Structures, Proceedings of the Ninth International Workshop on Database and Expert Systems Applications, DEXA 98, Seite 322-327, Vienna, Austria, August 1998.

[FeKu1992] Ferraiolo, D. F., Kuhn, D.R. (1992) Role Based Access Control, Proceedings of the15th National Computer Security Conference 1992.

[FKC2003] Ferraiolo, D. F., Kuhn, D. R., Chandramouli, R. (2003) Role Based Access Control, Artech House publishers, 338 Seiten.

[Fras2000] Fraser, T. (2000) LOMAC: Low Water-Mark Integrity Protection for COTS Environments, Proceedings of the IEEE Symposium on Security and Privacy, 2000.

[GNUP2004] GNU privacy guard, 15-Nov-2007, http://www.gnupg.org/

[GS2003] Günnewig, D. and Stüble, C. (2003) Trusted Computing ohne Nebenwirkungen Spezifikationen der Trusted Computing Group, DuD - Datenschutz und Datensicherheit 27(2003), Seite 556-560.

[HaRU1976] Harrison M. A., Ruzzo, W. L., Ullman, J. D. (1976) Protection in Operating Systems, Communications of the ACM 19/8, Seite 461-471.

[ITSEC1991] Commission of the European Communities (1991) Information Technology Security Evaluation Criteria (ITSEC): Preliminary Harmonised Criteria, Document COM(90) 314, Version 1.2, Jun-1991.

[Lamp1971] Lampson, B. W. (1971) Protection, Proceedings of the 5th Princeton Conference onInformation Sciences and Systems, Seite 437.

[Lewi2003] Lewis, S. R. (2003) How much is stronger DRM worth? 2nd Annual Workshop ’Economics and Information Security’; University of Maryland, Mai 2003.

[Micr2007] Microsoft Corporation, 15-Nov-2007, http://www.microsoft.com

[Muel2007] Müller, Thomas (2007) Trusted Computing mit Windows Vista und Windows Server ’Longhorn’, 10. Deutscher IT-Sicherheitskongress des Bundesamtes für Sicherheit in der Informationstechnik, 22.-24. Mai 2007, Bonn-Bad Godesberg. In: Innovationsmotor IT-Sicherheit, ISBN 978-3-922746-98-0, Secumedia Verlag Wiesbaden, 2007, http://www.xnos.org/fileadmin/labs/tc/TrustedVistaTM06.pdf

81

Literaturverzeichnis

[NIST0001] Role Based Access Control, National Institute of Standards and Technology, NIST,08-Aug-2007, http://csrc.nist.gov/rbac/

[Pear2002] Pearson, S. (2002) Trusted Computing Platforms: TCPA Technology in Context, Prentice Hall International.

[PfKo2001] Pfitzmann, A. and Khntopp, M. (2001) Anonymity, Unobservability, and Pseudonymity - A Proposal for Terminology: In: H. Federrath (Eds.): Designing Privacy Enhancing Technologies, Heidelberg, Springer Verlag, Seite 1-9. Latest version at: http://dud.inf.tu-dresden.de/Anon_Terminology.shtml

[Rann1994] Rannenberg, K. (1994) Recent Development in Information Technology Security Evaluation - The Need for Evaluation Criteria for Multilateral Security, in: R. Sizer; L. Yngström; H. Kaspersen and S. Fischer-Höbner (Eds.): Security and Control of Information Technology in Society - Proceedings of the IFIP TC9/WG 9.6 Working Conference 1993, August 12-17, 1993, onboard M/S Ilich and ashore at St. Petersburg; Russia.

[Roge2003] Rogers, E. M., Diffusion of innovations. New York: Free Press, 2003.

[Rush1992] Rushby, J.(1992) Noninterference, Transitivity, and Channel-Control Security Policies, SRI Computer Science Laboratory Technical Report CSL-92-02,http://www.csl.sri.com/papers/csl-92-2/.

[Sand1992] Sandhu, R. S. (1992) The Typed Access Matrix Model, Proceedings of the 1992 IEEE Symposium on Security and Privacy, Mai 04-06, 1992, Seite 122.

[Sand1993] Sandhu, R. S. (1993) Lattice-Based Access Control Models, ACM Computer Journal, 26, 11, Nov. 1993, Seite 9-19.

[SaZo2004] Safford, D., Zohar, M. (2004) A Trusted Linux Client (TLC), T.J. Watson ResearchCenter IBM, http://www.research.ibm.com/gsal/tcpa/tlc.pdf

[sHype] IBM sHype security hypervisor, 30-Aug-2007,http://www.research.ibm.com/se cure_systems_department/projects/hypervisor/

[Smal2000] Smalley, S.(2000) Flask: Flux Advanced Security Kernel, http://www.cs.u tah.edu/flux/flask/

[Smal2000] Smalley, S.(2000) The Distributed Trusted Operating System (DTOS) Homepage, http://www.cs.utah.edu/flux/dtos/

[Snek2001] Snekkenes, E. (2001) Concepts for personal location privacy policies, 3rd ACMConference on Electronic Commerce, Tampa, Florida, USA, Seite 48-57.

[Spaf1989] Spafford, G. (1989) Quotable Spaf, Gene Spafford’s Personal Pages, http://homes.cerias.purdue.edu/~spaf/quotes.html.

[Spar2000] SPARTA - information Systems Security Operations (2000) LOMAC: MAC You Can Live With, http://www.isso.sparta.com/opensource/lomac/index.html

[SSLHAL1999] Spencer, R., Smalley, S., Loscocco, P., Hibler, M., Andersen, D., Lepreau, J. (1999) The Flask Security Architecture: System Support for Diverse Security Policies, Proceedings of the Eighth USENIX Security Symposium, Aug. 1999, Seite 123-139.

[TCG0001] The Trusted Computing Group, 10-Aug-2007,http://www.trustedcomput inggroup.org/ .

82

Literaturverzeichnis

[TCSEC1985] United States Department of Defence (1985) Trusted Computer System EvaluationCriteria, DoD Standard 5200.28-STD, Dec-1985.

[Wiki0001] Mandatory Access Control, Wikipedia, 08-Aug-2007,http://de.wikipedia.org/wiki/Mandatory_Access_Control

[Wiki0002] Discretionary Access Control, Wikipedia, 08-Aug-2007,http://de.wikipedi a.org/wiki/Discretionary_Access_Control .

[Wiki0003] Role Based Access Control, Wikipedia, 08-Aug-2007,http://de.wikipedia.org/wiki/Role_Based_Access_Control .

[Wiki0004] Hypervisor, Wikipedia, 09-Sep-2007, http://en.wikipedia.org/wiki/Hypervisor .

[Wiki0007] Low watermark (computer security), Wikipedia, 15-Nov-2007, http://en.wikipedi a.org/wiki/Low_watermark_(computer_security ) .

83

Literaturverzeichnis

Index

A

„Access Control Lists“....................................23ACL................................................................24anhaftende Sicherheitsrichtlinie......................20

B

Bell-LaPadula Modell.....................................28BenutzerbestimmbarePersonengebundene Zugangskontrolle............................................15Biba Modell....................................................32BMA Modell...................................................37

C

„Chinese-Wall“-Modell..................................31Clark-Wilson Sicherheitsmodell.....................34Creative Commons Lizenz..............................96

D

Definitionen......................................................8Digitales Rechtemanagement..........................20DRM...............................................................20Dynamisches Zugangskontrollmodell.............27

F

FLASK...........................................................22„Flux Advanced Security Kernel“...................23

G

Gitterbasiertes Zugangskontrollmodell...........26GnuPG............................................................55GPG................................................................55

H

HRU...............................................................27

I

Informationsflusskontrolle..............................19Integrität.............................................................

Definition.....................................................8Integritätsorientierte Modelle..........................32

K

Klassische Sicherheitsmodelle........................74Kryptographische Schlüssel............................51

L

„Low-Watermark“-Zugangskontrollmodell....33

M

MAC...............................................................14„Mandatory Access Control“..........................14Mehrschichtige Sicherheit.........................13, 15Microsoft Windows Vista...............................67Missverständnisse...........................................11MLS................................................................13MULTICS.......................................................29Multilaterale Sicherheit...................................14

O

Objekt.................................................................Definition.....................................................8

OpenPGP........................................................55Operation..........................................................9

P

PERSEUS.......................................................68Personengebundene........................................15Plattformintegrität...........................................70„Public Key Infrastructure (PKI)“..................53

R

RBAC.............................................................30RegelbasierteRollenbasierte Zugangskontrolle........................................................................14Reputation.......................................................43

84

Literaturverzeichnis

Reputationsmanagement.................................43Rollenbasierte.................................................14Rushby-Modell...............................................19

S

Schlüssel.........................................................51Schlüsselmanagement.....................................53sHype-Sicherheitsmodell................................39Sicherer richtlinienbasierter Datenfluss..........76Sicheres Anzeigeprogramm............................76Sicherheitsanker.................................................

Definition.....................................................9Sicherheitsbereiche / „Compartmented/Multi-Category Security (MCS)“..............................38Sicherheitskonzept..............................................

Definition.....................................................9Sicherheitsmodelle..........................................17

ACL.....................................................24, 25Besitzerbasierte Sicherheitsrichtlinien.......23Biba Modell...............................................32„Chinese-Wall“-Modell.............................31Clark-Wilson.............................................34„Compartments“........................................38Definition...................................................17Gitterbasiertes Zugangskontrollmodell......26Integritätsorientierte Modelle.....................32„Low-Watermark“-Zugangskontrolle........33RBAC........................................................30RegelbasierteRollenbasierte Zugangskontrolle.......................................14Rollenbasierte............................................14Rollenbasierte Zugangskontrolle...............30sHype.........................................................39Vertraulichkeitsorientierte Modelle............24Zugangskontrolllisten................................25Zugangsmatrixmodell................................25

Sicherheitsrichtlinie............................................Definition...................................................10

Sicherheitsziel.....................................................Definition.....................................................9

„Sticky Policies“.............................................20Subjekt................................................................

Definition...................................................10

T

TCG................................................................59

Terminologie.......................................................Konflikte....................................................10

„Trusted Computer Evaluation Criteria“.........29Trusted Computing.............................................

Architektur.................................................64„Attestation“..............................................63authentisiertes Starten................................39„Binding“...................................................63Definition...................................................10„Endorsement-Key“...................................66Herausforderungen....................................72Integritätsmessung.....................................62Integritätsüberprüfung...............................63„Root of Trust for Storage“........................65„Sealing“...................................................63Sichere Ein-/Ausgabe................................76Sicherheitsmodelle.....................................71Storage Root Key.......................................65TCG...........................................................59TPM...........................................................65TPM Schlüsselarten...................................65„TPM-Credentials“....................................67„Trusted Computing Group“......................59„Trusted Platform Module“.......................65Verteiltes Vertrauen....................................71Vertrauensanker.........................................70vertrauenswürdiges Starten........................62

„Trusted Computing Group“...........................59Turaya.............................................................69„Type Enforcement“.......................................21

V

Vertrauensmodelle..............................................Definition...................................................10Direktes Vertrauen.....................................45Hierarchisches Vertrauen...........................46Im Gegensatz zu verteilten Computersystemen....................................53Implementieren..........................................56Indirektes Vertrauen...................................46Integritätsüberprüfung...............................53Kryptographische Schlüssel.......................51Lokales Vertrauen gegenüber verteiltem Vertrauen...................................................48Objekte in einem Vertrauensmodell...........49„Remote Attestation“.................................53Reputation.................................................43

85

Literaturverzeichnis

Reputationsmanagement............................43Schlüsselmanagement................................53Subjekte.....................................................51Taxonomie.................................................43verteiltes Vertrauen....................................53Vertrauen in verteilten Computersystemen 52Vertrauensanker.........................................57Vertrauensbeziehungen..............................54Vertrauensmetriken....................................44Vertrauensverankerung..............................56Vertrauensverbreitung................................45von Zertifikaten.........................................55„Web of Trust“...........................................55Widerruf ...................................................55

Vertrauensmodellierung..................................44Vertrauensverbreitung.....................................45Vertrauenswürdige Computersysteme.............52Vertraulichkeitsorientierte Sicherheitsmodelle24

W

„Web of Trust“................................................55Windows Vista................................................67

X

X.509-Format.................................................56X.509-Standard...............................................44X.509-Zertifikate............................................56Xen.................................................................68

Z

Zertifikate.......................................................45Zugangskontrolle............................................17

Definition...............................................8, 10Zugangskontrolllisten...............................23, 25Zugangsmatrixmodell.....................................25Zusicherung....................................................49

86

Glossar

Glossar

„Attestation Identity Key“ (AIK)

Ein nicht migrierbarer Schlüssel („Non-Migratable Key“), der lokal von einem „Trusted Plattform Module“ (TPM) erzeugt wird und Pseudonymität, der durch das TPM gesicherten Plattform erzielt. Der öffentliche Teil eines „Attestation Identity Key“ (AIK) wird von einer „Privacy Certification Authority“ („PrivacyCA“) beglaubigt, die darlegt, dass dieser Signa-turschlüssel tatsächlich von einem TPM kontrolliert wird. Um das Problem zu umgehen, dass die „PrivacyCA“ dadurch Transaktionen einer bestimmten Plattform zuordnen kann, ist in der Version 1.2 der „Trusted Computing Group“ (TCG)-Spezifikation ein kryptogra-phisches Protokoll namens „Direct Anonymous Attestation“ (DAA) definiert, welches die Notwendigkeit einer „PrivacyCA“ vermeidet.

„Attestation Kernel“

Ein „Low-Level“-Betriebssystemkern, der hauptsächlich Integritätsüberprüfung als Schnittstelle zur Verfügung stellt.

Authentisierungsdaten

Daten, die ausschließlich für Zwecke der Authentisierung verwendet werden (z. B. ein Passwort).

„Basic Input Output System“ (BIOS)

Ein Programm, das auf einer PC-Plattform die Hardware initialisiert.

Berechtigungsnachweis für andere Plattformen

Ein Berechtigungsnachweis, der zur Identifikation zu einer anderen Plattform benötigt wird.

„Binding“

Beim „Binding" von Daten werden diese an eine Konfiguration kryptographisch gebunden, dass ausschließlich die Konfiguration, die zur Zeit des „Binding“ angegeben wurde, später zum „Unbinding“ der kryptographisch geschützten Daten verwendet werden kann.

„Certificate Authority“ (CA)

Ein vertrauenswürdiger Dritter (engl. „Trusted Third Party“), der bestimmte Angaben über-prüft und beglaubigt.

87

Glossar

„Certified Migratable Key“ (CMK)

Ein in der Version 1.2 der TCG-Spezifikation eingeführter Typ von kryptographischen Schlüsseln, der mehr Flexibilität in der Handhabung von Schlüsseln ermöglicht. Die Ent-scheidung, einen Schlüssel zu migrieren sowie die Migration selbst werden an zwei vertrau-enswürdige Entitäten delegiert, die vom Eigentümer des TPMs ausgewählt werden.

„Compartment“

Eine logische oder physikalische Trennung von Softwarekomponenten.

„Container“

Ein Objekt, beispielsweise eine Datei, dass zum Abspeichern von Informationen benutzt wird (siehe auch „Sicherer Container”).

„Core Root of Trust for Measurement“ (CRTM)

Eine von der TCG spezifizierte PC-Komponente, die das „Basic Input Output System“ (BIOS) misst, bevor dieses ausgeführt wird .Siehe auch „Root of Trust for Measurement“ (RTM)

„Direct Anonymous Attestation“ (DAA)

Ein kryptographisches Protokoll, das im Zusammenhang mit der TCG-Spezifikation entwi-ckelt wurde, um das Problem zu umgehen, dass eine dritte Partei Transaktionen zu einer be-stimmten Plattform zuordnen kann; vermeidet die Notwendigkeit einer TTP durch Verwendung eines „Zero Knowledge“-Protokolls.

„Domain“

Eine Menge von „Compartments“, die einen gleichen Grad an Vertrauenswürdigkeit besit-zen.

„Dynamic Root of Trust for Measurement“ (D-RTM)

Das „Dynamic Root of Trust for Measurement“ (dynamisch ladbarer RTM) ist ein „Root of Trust for Measurement“ (RTM), welches durch Intels Hardware-Erweiterung TXT oder AMDs Presidio unterstützt wird. Hierbei läuft das D-RTM in einer isolierten Umgebung des Prozessors, so dass dieser die Basis der Vertrauenskette bildet. Virtuelle Maschinen erhalten dadurch jeweils ein eigenes RTM. Die Integritätsmesswerte eines D-RTM werden im TPM abgelegt.

88

Glossar

„Endorsement Key“ (EK)

Ein asymmetrisches 2048-Bit-RSA-Schlüsselpaar, welches eindeutig einem TPM zugeord-net ist. Der EK verbleibt permanent im TPM und kann genutzt werden, um ein TPM und seine Plattform zu authentisieren.

Gesicherte Kommunikationsnetze

Gesicherte Netzverbindungen nutzen Protokolle wie SSL, TLS oder IPSec für die Sicher-heitsschicht oder zur Realisierung virtueller privater Netze (engl. „Virtual Private Net-works“, VPN). Manchmal kann Unbeobachtbarkeit gefordert sein, welche schwer zu imple-mentieren ist.

„General Public License“ (GPL)

Die am weitesten verbreitete Lizenz für FLOSS („Free“, „Libre“ und „Open Source“ Software).

„GNU’s Not Unix“ (GNU)

Das GNU-Projekt wurde 1984 mit dem Ziel ins Leben gerufen, ein vollständiges Unix arti-ges Betriebssystem, das auf FLOSS basiert, zu entwickeln. Varianten des GNU-Betriebssys-tems, welche einen Betriebssystemkern namens Linux verwenden, werden heutzutage viel verwendet; obwohl diese Betriebssysteme häufig als Linux bezeichnet werden, ist die ge-nauere Bezeichnung GNU/Linux-System. GNU ist ein rekursives Akronym für „GNU is Not Unix“; es wird „guh-noo“ ausgesprochen. Für weitere Informationen siehe http://www.gnu.org/.

„Grand Unified Bootloader“ (GRUB)

Ein Urlader-Paket des GNU-Projekts, welches die „Multiboot“- Spezifikation implementiert, die es Nutzern erlaubt, mehrere Betriebssysteme gleichzeitig auf ihrem Computer zu installieren.

Hardware

Als Hardware werden alle physikalischen Funktionsbestandteile eines Computers bezeich-net (beispielsweise eine CPU/Prozessor).

„Hypervisor“

Siehe „Virtual Machine Monitor“.

89

Glossar

Integritätsüberprüfung (engl. „Attestation“)

Wenn von der Integritätsüberprüfung eines „Compartments“ A die Rede ist, so ist damit ge-meint, dass die Konfiguration des „Compartments“ A und seiner „Trusted Computing Base“ (TCB) bewiesenermaßen in einer Hardware-RTM verwurzelt ist. Die Integritätsüberprüfung kann als ein vertrauenswürdiger Kanal (engl. „Trusted Channel“, siehe auch „Kanal“) ange-sehen werden, über den keine Daten gesendet werden. Es sollte beachtet werden, dass eine Integritätsüberprüfung nur dann sinnvoll ist, wenn ein Überprüfer den kryptographischen Beweis überprüfen kann (z. B. eine Signatur). Dazu muss sich der Überprüfer entweder auf einer anderen vertrauenswürdigen Plattform befinden oder seine Integrität muss lokal per „Sealing” überprüfbar sein.

„Integrity Measurement Architecture“ (IMA)

Eine von IBM entwickelte Architektur, die es erlaubt, Integritätsmesswerte von einer Linux -Installation zu generieren. Dadurch kann ein anderer Teilnehmer anhand dieser Informatio-nen die Integrität des Linux-Systems zur Laufzeit überprüfen.

Kanal

Ein Kommunikationsweg zwischen „Compartments“. Unser Sicherheitsmodell unterschei-det zwischen sicheren, vertrauenswürdigen (engl. „Trusted Channel”) und gewöhnlichen Kanälen. Ein gewöhnlicher Kanal sorgt für keinerlei Sicherheit der kommunizierten Daten. Ein sicherer Kommunikationskanal gewährleistet die Vertraulichkeit und Integrität der kommunizierten Daten sowie die Authentisierung des Endpunktes des Kanals. Ein „Trusted Channel“ ist ein sicherer Kommunikationskanal, der eine Authentisierung durch Überprü-fung der Konfiguration des Endpunktes des Kanals erweitert.

Konfiguration

Eine eindeutige Beschreibung des Verhaltens einer Softwarekomponente, die auf dessen Programmcode, dem internen Status und der Konfiguration der zugrunde liegenden Platt-form basiert.

Linux

Ein Synonym für den Linux Betriebssystemkern; wird normalerweise immer mit der Versi-onsnummer angegeben. Beispiel: Linux-2.6.22.1. Oftmals wird mit „Linux“ in der Um-gangssprache das GNU/Linux Betriebssystem gemeint.

„Mandatory Access Control“ (MAC)

Ein Konzept für die Kontrolle und Steuerung von Zugriffsrechten. Die Entscheidung über Zugriffsberechtigungen werden nicht nur auf der Basis der Identität des Subjects (Benut-zers, Prozesses) und des Objektes (die Ressource auf welche zugegriffen werden sollen) ge-fällt, sondern aufgrund zusätzlicher Regeln und Eigenschaften (wie Kategorisierungen, Eti-

90

Glossar

ketten und Passwörtern). In den „Trusted Computer System Evaluation Criteria“ (oft auch als „Orange book“ des Verteidigungsministeriums bezeichnet) ist der Begriff wie folgt defi-niert: „Mandatory Access Controls“ beschränken den Zugriff auf Objekte zum einen anhand der Sensitivität der Daten, die in dem Objekt enthalten sind - welche durch ein „Label“ re-präsentiert wird - und zum anderen durch formale Berechtigung von Subjekten, um an In-formationen mit der gleichen Sensitivität zu gelangen.

„Migratable Key“ (MK)

Der Migratable-Schlüssel ist ein kryptografischer Schlüssel, der vom TPM verwendet wird, aber dem nur die Person vertraut, die ihn erstellt hat (zum Beispiel der Benutzer des Com-putersystems).

„Migration Authority“ (MA)

Ein Teilnehmer, der ein CMK migriert; siehe auch „Migration Selection Authority“.

„Migration Selection Authority“ (MSA)

Ein Teilnehmer, der die Migration eines CMK kontrolliert; siehe auch „Migration Author-ity“.

„Non-Migratable Key“ (NMK)

Im Gegensatz zu einem migrierbaren Schlüssel garantiert ein nicht-migrierbarer Schlüssel den Verbleib in einem TPM. Das TPM kann zusätzlich ein Zertifikat erzeugen, welches be-scheinigt, dass es sich um einen nicht-migrierbaren Schlüssel handelt.

„Plattform Configuration Register“ (PCR)

Ein TPM-Register, in dem die Konfigurationen von Softwarekomponenten gespeichert wer-den.

Plattform

Die der TCB zugrunde liegende Hardware.

„Privacy Certification Authority“ (Privacy CA)

Eine „Trusted Third Party“ (TTP) die angibt, ob der AIK auch tatsächlich von einem TPM kontrolliert wird.

Programm

Die binäre Repräsentation (Datei) eines ausführbaren „Compartments“.

91

Glossar

„Root of Trust for Measurement“ (RTM)

Das „Root of Trust for Measurement“ bildet die Basis der Integritätsmessungen einer Platt-form. Das RTM ist das erste Element der Vertrauenskette, welches über den „Boot-Loader“ und den Betriebssystemkern bis zu Programmen des Betriebssystems reichen kann. Der zugehörige Programmcode des RTM ist Teil des BIOS und wird nach dem Einschalten des Computersystems ausgeführt. Hierbei werden Prüfsummen der am Start des Computersys-tems beteiligten Komponenten gebildet.

„Sealing“

Mittels „Sealing“ (Versiegelung) können Daten an eine Systemkonfiguration gebunden werden. Durch Bilden eines Prüfsummenwertes aus der Systemkonfiguration (Hard- und Software) können Daten an ein einziges TPM gebunden werden. Hierbei werden die ent-sprechenden Daten und die Prüfsummenwerte aus dem „Platform Configuration Register“ (PCR) zusammen verschlüsselt. Eine Entschlüsselung gelingt nur, wenn der gleiche Prüf-summenwert wieder ermittelt wird, was nur auf dem gleichen und unveränderten Rechner-system mit dem entsprechenden TPM gelingen kann. Bei Defekt des TPMs muss das Pro-gramm, das die „Sealing“-Funktionen nutzt, dafür 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 (Systemkonfigu-ration) befindet.

„Secure Boot“

Beim Start eines Rechnersystems wird die Konfiguration beginnend beim BIOS gemessen. Danach werden die Hardware und der Urlader (engl. „Bootloader“) gemessen. Dieser über-nimmt den Messvorgang für die Betriebssystemebene. Soll eine falsche Konfiguration zu einem Startabbruch führen, so spricht man vom „Secure Boot“.

Sicherer „Container“

Ein „Container", der (sicherheitsrelevante) Eigenschaften über die in ihm abgelegten Informationen/Daten zusichern kann. Bei den (sicherheitsrelevanten) Eigenschaften kann es sich um Integrität oder Vertraulichkeit handeln.

Smartcard

Smartcards bzw. Chipkarten sind Plastikkarten mit einem eingebauten Chip, der Krypto-funktionen, Speicher und einen Mikroprozessor enthält. Eine Smartcard stellet kryptogra-phische Funktionen bereit.

Software

Software ist ausführbarer Programmcode, beispielsweise ein Computerprogramm.

92

Glossar

„Static Root of Trust for Measurement“ (S-RTM)

Das „Static Root of Trust for Measurement“ ist das statische RTM. Die Integritätsmesswer-te des S-RTM werden in den PCRs 0 bis 15 und 23 abgelegt.

„Storage Root Key“ (SRK)

Ein asymmetrischer 2048-Bit-RSA-Schlüssel innerhalb des TPMs, der für die Verschlüsse-lung von TPM-internen Daten verwendet wird. Der SRK wird durch Inbesitznahme eines TPMs erzeugt und verbleibt permanent innerhalb des TPMs, bis der derzeitige Besitzer wieder gelöscht wird.

„TCG Software Stack“ (TSS)

Der „Software Stack“, der durch die TCG spezifiziert wurde und eine Abstraktionsschicht des TPM ist. Er soll Programmen den Zugang zum TPM und dessen Funktionalität ermögli-chen und erleichtern.

Vertrauneswürdiger Kanal (engl. „Trusted Channel“)

Ein Kommunikationskanal der Integrität, Vertraulichkeit und Authentisierung bereitstellt (siehe „Sicherer Kommunikationskanal“). Des Weiteren beinhaltet er Informationen über das Verhalten des Kommunikationsendpunktes.

Trusted Computing (TC)

Komponenten und Mechanismen, die durch die TCG-Spezifikation definiert wurden, um die Vertrauenswürdigkeit von IT-Systemen zu erhöhen.

„Trusted Computing Base“ (TCB)

Der Teil eines Computersystems der verhindert, dass eine festgelegte Sicherheitsrichtlinie umgangen werden kann.

„Trusted Computing Group“ (TCG)

Ein Industriekonsortium, welches unterschiedliche Spezifikationen definiert, die benötigt werden, um eine vertrauenswürdige Rechnerplattform zu ermöglichen, u.a. die TPM-Spezi-fikation, die TCG „Software Stack“ (TSS) Spezifikation und die „Trusted Network Con-nect“ (TNC) Spezifikation.

„Trusted Computing Platform Alliance” (TCPA)

Die Vorläuferorganisation der der TCG.

93

Glossar

„Trusted Network Connect“ (TNC)

Die TNC-Architektur konzentriert sich auf Sicherheitslösungen zur Netzzugriffskontrolle mit Hilfe von Trusted Computing. Hierzu werden Integritätsmessungen als Sicherheitsbe-weis zwischen den Kommunikationsendpunkten ausgetauscht und überprüft, bevor Zugang zum Netz oder Zugriff auf Daten im Netz gestattet wird.

„Trusted Platform Module” (TPM)

Ein optional nutzbarer, manipulationsgeschützter Hardware-Baustein, der dem Benutzer ge-schützte Funktionalitäten und isolierten Speicher bereitstellt. Ein TPM verhält sich passiv und beinhaltet z. B. einen Zufallszahlengenerator, einen RSA-Schlüsselgenerator sowie eine Funktion zur Prüfsummenbildung. Damit kann eine Plattform das TPM anweisen, Schlüssel zu erzeugen und zu speichern, Daten zu signieren, diese an eine Plattform zu binden oder Messwerte über ihren Zustand zu speichern.

„Trusted Third Party“ (TTP)

Eine Instanz, der alle Teilnehmer eines Protokolls vertrauen.

Ungesicherte Kommunikationsnetze

Öffentliche oder private ungesicherte Kommunikationsnetze, für die Kommunikation zwi-schen Computersystemen verwendet werden.

Verhalten

Das Verhalten einer Maschine ist festgelegt durch ihre Konfiguration und die Konfiguration aller anderen Komponenten, die Teil des TCB dieser Maschine sind. Zum Beispiel hängt das Verhalten eines Anwendungsprogrammes sowohl von der Implementierung selbst als auch von der Implementierung des zugrunde liegenden Betriebssystems und der Hardware ab.

„Virtual Machine Monitor“ (VMM)

Ein „Virtual Machine Monitor“ (auch „Hypervisor“ genannt) erzeugt und verwaltet virtuel-le Maschinen (VMs). Er verteilt die Ressourcen der zugrunde liegenden Hardware derart, dass für den Betrieb jeder einzelnen virtuellen Maschine Ressourcen zur Verfügung stehen.

Vituelle Maschine (VM)

Eine VM ist eine Softwareimplementierung eines Computers oder einer Maschine, die sich aus der Sicht eines Betriebssystems, wie physikalische Hardware verhält. Virtuelle Maschi-nen benötigen die Präsenz einer Software-Schicht („Virtual Machine Monitor“ (VMM)), um auf die gemultiplexte physikalische Hardware zuzugreifen.

94

Glossar

Zugriffsrecht

Das Recht auf Daten eines bestimmten Bereichs zuzugreifen (z. B. lesend und/oder schreibend).

95

Anhang

Anhang

„Creative Commons” Lizenz

„Creative Commons”„Creative Commons” Legal Code Attribution-NoDerivs 3.0

Unported ://creativecommons.org/licenses/by-nd/3.0/legalco - de

„CREATIVE COMMONS“ IST KEINE RECHTSANWALTSKANZLEI UND LEISTET KEINE RECHTSBERATUNG. DIE BEREITSTELLUNG DIESER LIZENZ FÜHRT ZU KEINEM MAN-DATSVERHÄLTNIS. „CREATIVE COMMONS“ STELLT DIESE INFORMATIONEN OHNE GEWÄHR ZUR VERFÜGUNG. „CREATIVE COMMONS“ ÜBERNIMMT KEINE GEWÄHR-LEISTUNG FÜR DIE GELIEFERTEN INFORMATIONEN UND SCHLIEßT DIE HAFTUNG FÜR SCHÄDEN AUS, DIE SICH AUS DEREN GEBRAUCH ERGEBEN.

Lizenz

DER GEGENSTAND DIESER LIZENZ (WIE UNTER "SCHUTZGEGENSTAND" DEFINIERT) WIRD UNTER DEN BEDINGUNGEN DIESER „CREATIVE COMMONS“ PUBLIC LICENSE ("CCPL", "LIZENZ" ODER "LIZENZVERTRAG") ZUR VERFÜGUNG GESTELLT. DER SCHUTZGEGENSTAND IST DURCH DAS URHEBERRECHT UND/ODER ANDERE GESET-ZE GESCHÜTZT. JEDE FORM DER NUTZUNG DES SCHUTZGEGENSTANDES, DIE NICHT AUFGRUND DIESER LIZENZ ODER DURCH GESETZE GESTATTET IST, IST UNZULÄS-SIG.

DURCH DIE AUSÜBUNG EINES DURCH DIESE LIZENZ GEWÄHRTEN RECHTS AN DEM SCHUTZGEGENSTAND ERKLÄREN SIE SICH MIT DEN LIZENZBEDINGUNGEN RECHTSVERBINDLICH EINVERSTANDEN. SOWEIT DIESE LIZENZ ALS LIZENZVER-TRAG ANZUSEHEN IST, GEWÄHRT IHNEN DER LIZENZGEBER DIE IN DER LIZENZ GE-NANNTEN RECHTE UNENTGELTLICH UND IM AUSTAUSCH DAFÜR, DASS SIE DAS GE-BUNDENSEIN AN DIE LIZENZBEDINGUNGEN AKZEPTIEREN.

1. Definitionen

a. Der Begriff "Abwandlung" im Sinne dieser Lizenz bezeichnet das Ergebnis jeglicher Art von Veränderung des Schutzgegenstandes, solange die eigenpersönlichen Züge des Schutz-gegenstandes darin nicht verblassen und daran eigene Schutzrechte entstehen. Das kann ins-besondere eine Bearbeitung, Umgestaltung, Änderung, Anpassung, Übersetzung oder Her-anziehung des Schutzgegenstandes zur Vertonung von Laufbildern sein. Nicht als Abwand-lung des Schutzgegenstandes gelten seine Aufnahme in eine Sammlung oder ein Sammel-werk und die freie Benutzung des Schutzgegenstandes.

96

Anhang

b. Der Begriff "Sammelwerk" im Sinne dieser Lizenz meint eine Zusammenstellung von lite-rarischen, künstlerischen oder wissenschaftlichen Inhalten, sofern diese Zusammenstellung aufgrund von Auswahl und Anordnung der darin enthaltenen selbständigen Elemente eine geistige Schöpfung darstellt, unabhängig davon, ob die Elemente systematisch oder metho-disch angelegt und dadurch einzeln zugänglich sind oder nicht.

c. "Verbreiten" im Sinne dieser Lizenz bedeutet, den Schutzgegenstand im Original oder in Form von Vervielfältigungsstücken, mithin in körperlich fixierter Form der Öffentlichkeit anzubieten oder in Verkehr zu bringen.

d. Der "Lizenzgeber" im Sinne dieser Lizenz ist diejenige natürliche oder juristische Person oder Gruppe, die den Schutzgegenstand unter den Bedingungen dieser Lizenz anbietet und insoweit als Rechteinhaberin auftritt.

e. "Rechteinhaber" im Sinne dieser Lizenz ist der Urheber des Schutzgegenstandes oder jede andere natürliche oder juristische Person oder Gruppe von Personen, die am Schutzgegen-stand ein Immaterialgüterrecht erlangt hat, welches die in Abschnitt 3 genannten Handlun-gen erfasst und bei dem eine Einräumung von Nutzungsrechten oder eine Weiterübertra-gung an Dritte möglich ist.

f. Der Begriff "Schutzgegenstand" bezeichnet in dieser Lizenz den literarischen, künstleri-schen oder wissenschaftlichen Inhalt, der unter den Bedingungen dieser Lizenz angeboten wird. Das kann insbesondere eine persönliche geistige Schöpfung jeglicher Art, ein Werk der kleinen Münze, ein nachgelassenes Werk oder auch ein Lichtbild oder anderes Objekt eines verwandten Schutzrechts sein, unabhängig von der Art seiner Fixierung und unabhän-gig davon, auf welche Weise jeweils eine Wahrnehmung erfolgen kann, gleichviel ob in analoger oder digitaler Form. Soweit Datenbanken oder Zusammenstellungen von Daten einen immaterialgüterrechtlichen Schutz eigener Art genießen, unterfallen auch sie dem Be-griff "Schutzgegenstand" im Sinne dieser Lizenz.

g. Mit "Sie" bzw. "Ihnen" ist die natürliche oder juristische Person gemeint, die in dieser Li-zenz im Abschnitt 3 genannte Nutzungen des Schutzgegenstandes vornimmt und zuvor in Hinblick auf den Schutzgegenstand nicht gegen Bedingungen dieser Lizenz verstoßen oder aber die ausdrückliche Erlaubnis des Lizenzgebers erhalten hat, die durch diese Lizenz ge-währten Nutzungsrechte trotz eines vorherigen Verstoßes auszuüben.

h. Unter "Öffentlich Zeigen" im Sinne dieser Lizenz sind Veröffentlichungen und Präsentatio-nen des Schutzgegenstandes zu verstehen, die für eine Mehrzahl von Mitgliedern der Öf-fentlichkeit bestimmt sind und in unkörperlicher Form mittels öffentlicher Wiedergabe in Form von Vortrag, Aufführung, Vorführung, Darbietung, Sendung, Weitersendung, zeit- und ortsunabhängiger Zugänglichmachung oder in körperlicher Form mittels Ausstellung erfol-gen, unabhängig von bestimmten Veranstaltungen und unabhängig von den zum Einsatz kommenden Techniken und Verfahren, einschließlich drahtgebundener oder drahtloser Mit-tel und Einstellen in das Internet.

i. "Vervielfältigen" im Sinne dieser Lizenz bedeutet, mittels beliebiger Verfahren Vervielfälti-gungsstücke des Schutzgegenstandes herzustellen, insbesondere durch Ton- oder Bildauf-zeichnungen, und umfasst auch den Vorgang, erstmals körperliche Fixierungen des Schutz-gegenstandes sowie Vervielfältigungsstücke dieser Fixierungen anzufertigen, sowie die Übertragung des Schutzgegenstandes auf einen Bild- oder Tonträger oder auf ein anderes elektronisches Medium, gleichviel ob in digitaler oder analoger Form.

97

Anhang

2. Schranken des Immaterialgüterrechts

Diese Lizenz ist in keiner Weise darauf gerichtet, Befugnisse zur Nutzung des Schutzgegenstandes zu vermindern, zu beschränken oder zu vereiteln, die Ihnen aufgrund der Schranken des Urheber-rechts oder anderer Rechtsnormen bereits ohne Weiteres zustehen oder sich aus dem Fehlen eines immaterialgüterrechtlichen Schutzes ergeben.

3. Einräumung von Nutzungsrechten

Unter den Bedingungen dieser Lizenz räumt Ihnen der Lizenzgeber - unbeschadet unverzichtbarer Rechte und vorbehaltlich des Abschnitts 3.c) - das vergütungsfreie, räumlich und zeitlich (für die Dauer des Schutzrechts am Schutzgegenstand) unbeschränkte einfache Recht ein, den Schutzgegen-stand auf die folgenden Arten und Weisen zu nutzen ("unentgeltlich eingeräumtes einfaches Nut-zungsrecht für jedermann"):

a. Den Schutzgegenstand in beliebiger Form und Menge zu vervielfältigen, ihn in Sammel-werke zu integrieren und ihn als Teil solcher Sammelwerke zu vervielfältigen;

b. Den Schutzgegenstand, allein oder in Sammelwerke aufgenommen, öffentlich zu zeigen und zu verbreiten.

c. Bezüglich Vergütung für die Nutzung des Schutzgegenstandes gilt Folgendes:

i. Unverzichtbare gesetzliche Vergütungsansprüche: Soweit unverzichtbare Vergü-tungsansprüche im Gegenzug für gesetzliche Lizenzen vorgesehen oder Pauschal-abgabensysteme (zum Beispiel für Leermedien) vorhanden sind, behält sich der Li-zenzgeber das ausschließliche Recht vor, die entsprechende Vergütung einzuziehen für jede Ausübung eines Rechts aus dieser Lizenz durch Sie.

ii. Vergütung bei Zwangslizenzen: Sofern Zwangslizenzen außerhalb dieser Lizenz vorgesehen sind und zustande kommen, verzichtet der Lizenzgeber für alle Fälle ei-ner lizenzgerechten Nutzung des Schutzgegenstandes durch Sie auf jegliche Vergü-tung.

iii. Vergütung in sonstigen Fällen: Bezüglich lizenzgerechter Nutzung des Schutzge-genstandes durch Sie, die nicht unter die beiden vorherigen Abschnitte (i) und (ii) fällt, verzichtet der Lizenzgeber auf jegliche Vergütung, unabhängig davon, ob eine Einziehung der Vergütung durch ihn selbst oder nur durch eine Verwertungsgesell-schaft möglich wäre.

Das vorgenannte Nutzungsrecht wird für alle bekannten sowie für alle noch nicht bekannten Nut-zungsarten eingeräumt. Es beinhaltet auch das Recht, solche Änderungen am Schutzgegenstand vorzunehmen, die für bestimmte nach dieser Lizenz zulässige Nutzungen technisch erforderlich sind. Weitergehende Änderungen oder Abwandlungen sind jedoch untersagt. Alle sonstigen Rechte, die über diesen Abschnitt hinaus nicht ausdrücklich durch den Lizenzgeber eingeräumt werden, bleiben diesem allein vorbehalten. Soweit Datenbanken oder Zusammenstellungen von Daten Schutzgegenstand dieser Lizenz oder Teil dessen sind und einen immaterialgüterrechtlichen Schutz eigener Art genießen, verzichtet der Lizenzgeber auf sämtliche aus diesem Schutz resultierenden Rechte.

98

Anhang

4. Bedingungen

Die Einräumung des Nutzungsrechts gemäß Abschnitt 3 dieser Lizenz erfolgt ausdrücklich nur un-ter den folgenden Bedingungen:

a. Sie dürfen den Schutzgegenstand ausschließlich unter den Bedingungen dieser Lizenz ver-breiten oder öffentlich zeigen. Sie müssen dabei stets eine Kopie dieser Lizenz oder deren vollständige Internetadresse in Form des Uniform-Resource-Identifier (URI) beifügen. Sie dürfen keine Vertrags- oder Nutzungsbedingungen anbieten oder fordern, die die Bedingun-gen dieser Lizenz oder die durch diese Lizenz gewährten Rechte beschränken. Sie dürfen den Schutzgegenstand nicht unterlizenzieren. Bei jeder Kopie des Schutzgegenstandes, die Sie verbreiten oder öffentlich zeigen, müssen Sie alle Hinweise unverändert lassen, die auf diese Lizenz und den Haftungsausschluss hinweisen. Wenn Sie den Schutzgegenstand ver-breiten oder öffentlich zeigen, dürfen Sie (in Bezug auf den Schutzgegenstand) keine tech-nischen Maßnahmen ergreifen, die den Nutzer des Schutzgegenstandes in der Ausübung der ihm durch diese Lizenz gewährten Rechte behindern können. Dieser Abschnitt 4.a) gilt auch für den Fall, dass der Schutzgegenstand einen Bestandteil eines Sammelwerkes bildet, was jedoch nicht bedeutet, dass das Sammelwerk insgesamt dieser Lizenz unterstellt wer-den muss. Sofern Sie ein Sammelwerk erstellen, müssen Sie auf die Mitteilung eines Li-zenzgebers hin aus dem Sammelwerk die in Abschnitt 4.b) aufgezählten Hinweise entfer-nen.

b. Die Verbreitung und das öffentliche Zeigen des Schutzgegenstandes oder ihn enthaltender Sammelwerke ist Ihnen nur unter der Bedingung gestattet, dass Sie, vorbehaltlich etwaiger Mitteilungen im Sinne von Abschnitt 4.a), alle dazu gehörenden Rechtevermerke unberührt lassen. Sie sind verpflichtet, die Rechteinhaberschaft in einer der Nutzung entsprechenden, angemessenen Form anzuerkennen, indem Sie - soweit bekannt - Folgendes angeben:

i. Den Namen (oder das Pseudonym, falls ein solches verwendet wird) des Rechtein-habers und / oder, falls der Lizenzgeber im Rechtevermerk, in den Nutzungsbedin-gungen oder auf andere angemessene Weise eine Zuschreibung an Dritte vorgenom-men hat (z.B. an eine Stiftung, ein Verlagshaus oder eine Zeitung) ("Zuschreibungs-empfänger"), Namen bzw. Bezeichnung dieses oder dieser Dritten;

ii. Den Titel des Inhaltes;

iii. In einer praktikablen Form den Uniform-Resource-Identifier (URI, z.B. Internet-adresse), den der Lizenzgeber zum Schutzgegenstand angegeben hat, es sei denn, dieser URI verweist nicht auf den Rechtevermerk oder die Lizenzinformationen zum Schutzgegenstand.

Die nach diesem Abschnitt 4.b) erforderlichen Angaben können in jeder angemessenen Form gemacht werden; im Falle eines Sammelwerkes müssen diese Angaben das Minimum darstellen und bei gemeinsamer Nennung mehrerer Rechteinhaber dergestalt erfolgen, dass sie zumindest ebenso hervorgehoben sind wie die Hinweise auf die übrigen Rechteinhaber. Die Angaben nach diesem Abschnitt dürfen Sie ausschließlich zur Angabe der Rechteinha-berschaft in der oben bezeichneten Weise verwenden. Durch die Ausübung Ihrer Rechte aus dieser Lizenz dürfen Sie ohne eine vorherige, separat und schriftlich vorliegende Zustim-mung des Lizenzgebers und / oder des Zuschreibungsempfängers weder explizit noch im-plizit irgendeine Verbindung zum Lizenzgeber oder Zuschreibungsempfänger und ebenso wenig eine Unterstützung oder Billigung durch ihn andeuten.

99

Anhang

c. Die oben unter 4.a) und b) genannten Einschränkungen gelten nicht für solche Teile des Schutzgegenstandes, die allein deshalb unter den Schutzgegenstandsbegriff fallen, weil sie als Datenbanken oder Zusammenstellungen von Daten einen immaterialgüterrechtlichen Schutz eigener Art genießen.

d. Persönlichkeitsrechte bleiben - soweit sie bestehen - von dieser Lizenz unberührt.

5. Gewährleistung

SOFERN KEINE ANDERSLAUTENDE, SCHRIFTLICHE VEREINBARUNG ZWISCHEN DEM LIZENZGEBER UND IHNEN GESCHLOSSEN WURDE UND SOWEIT MÄNGEL NICHT ARGLISTIG VERSCHWIEGEN WURDEN, BIETET DER LIZENZGEBER DEN SCHUTZGEGENSTAND UND DIE EINRÄUMUNG VON RECHTEN UNTER AUSSCHLUSS JEGLICHER GEWÄHRLEISTUNG AN UND ÜBERNIMMT WEDER AUSDRÜCKLICH NOCH KONKLUDENT GARANTIEN IRGENDEINER ART. DIES UMFASST INSBESONDE-RE DAS FREISEIN VON SACH- UND RECHTSMÄNGELN, UNABHÄNGIG VON DEREN ERKENNBARKEIT FÜR DEN LIZENZGEBER, DIE VERKEHRSFÄHIGKEIT DES SCHUTZ-GEGENSTANDES, SEINE VERWENDBARKEIT FÜR EINEN BESTIMMTEN ZWECK SOWIE DIE KORREKTHEIT VON BESCHREIBUNGEN. DIESE GEWÄHRLEISTUNGSBESCHRÄN-KUNG GILT NICHT, SOWEIT MÄNGEL ZU SCHÄDEN DER IN ABSCHNITT 6 BEZEICHNE-TEN ART FÜHREN UND AUF SEITEN DES LIZENZGEBERS DAS JEWEILS GENANNTE VERSCHULDEN BZW. VERTRETEN MÜSSEN EBENFALLS VORLIEGT.

6. Haftungsbeschränkung

DER LIZENZGEBER HAFTET IHNEN GEGENÜBER IN BEZUG AUF SCHÄDEN AUS DER VERLETZUNG DES LEBENS, DES KÖRPERS ODER DER GESUNDHEIT NUR, SOFERN IHM WENIGSTENS FAHRLÄSSIGKEIT VORZUWERFEN IST, FÜR SONSTIGE SCHÄDEN NUR BEI GROBER FAHRLÄSSIGKEIT ODER VORSATZ, UND ÜBERNIMMT DARÜBER HINAUS KEINERLEI FREIWILLIGE HAFTUNG.

7. Erlöschen

a. Diese Lizenz und die durch sie eingeräumten Nutzungsrechte erlöschen mit Wirkung für die Zukunft im Falle eines Verstoßes gegen die Lizenzbedingungen durch Sie, ohne dass es dazu der Kenntnis des Lizenzgebers vom Verstoß oder einer weiteren Handlung einer der Vertragsparteien bedarf. Mit natürlichen oder juristischen Personen, die den Schutzgegen-stand enthaltende Sammelwerke unter den Bedingungen dieser Lizenz von Ihnen erhalten haben, bestehen nachträglich entstandene Lizenzbeziehungen jedoch solange weiter, wie die genannten Personen sich ihrerseits an sämtliche Lizenzbedingungen halten. Darüber hinaus gelten die Ziffern 1, 2, 5, 6, 7, und 8 auch nach einem Erlöschen dieser Lizenz fort.

b. Vorbehaltlich der oben genannten Bedingungen gilt diese Lizenz unbefristet, bis der recht-liche Schutz für den Schutzgegenstand ausläuft. Davon abgesehen behält der Lizenzgeber das Recht, den Schutzgegenstand unter anderen Lizenzbedingungen anzubieten oder die ei-gene Weitergabe des Schutzgegenstandes jederzeit einzustellen, solange die Ausübung die-ses Rechts nicht einer Kündigung oder einem Widerruf dieser Lizenz (oder irgendeiner Weiterlizenzierung, die auf Grundlage dieser Lizenz bereits erfolgt ist bzw. zukünftig noch erfolgen muss) dient und diese Lizenz unter Berücksichtigung der oben zum Erlöschen ge-

100

Anhang

nannten Bedingungen vollumfänglich wirksam bleibt.

8. Sonstige Bestimmungen

a. Jedes Mal, wenn Sie den Schutzgegenstand für sich genommen, oder als Teil eines Sam-melwerkes verbreiten oder öffentlich zeigen, bietet der Lizenzgeber dem Empfänger eine Lizenz zu den gleichen Bedingungen und im gleichen Umfang an, wie Ihnen in Form dieser Lizenz.

b. Sollte eine Bestimmung dieser Lizenz unwirksam sein, so bleibt davon die Wirksamkeit der Lizenz im Übrigen unberührt.

c. Keine Bestimmung dieser Lizenz soll als abbedungen und kein Verstoß gegen sie als zuläs-sig gelten, solange die von dem Verzicht oder von dem Verstoß betroffene Seite nicht schriftlich zugestimmt hat.

d. Diese Lizenz (zusammen mit in ihr ausdrücklich vorgesehenen Erlaubnissen, Mitteilungen und Zustimmungen, soweit diese tatsächlich vorliegen) stellt die vollständige Vereinbarung zwischen dem Lizenzgeber und Ihnen in Bezug auf den Schutzgegenstand dar. Es bestehen keine Abreden, Vereinbarungen oder Erklärungen in Bezug auf den Schutzgegenstand, die in dieser Lizenz nicht genannt sind. Rechtsgeschäftliche Änderungen des Verhältnisses zwi-schen dem Lizenzgeber und Ihnen sind nur über Modifikationen dieser Lizenz möglich. Der Lizenzgeber ist an etwaige zusätzliche, einseitig durch Sie übermittelte Bestimmungen nicht gebunden. Diese Lizenz kann nur durch schriftliche Vereinbarung zwischen Ihnen und dem Lizenzgeber modifiziert werden. Derlei Modifikationen wirken ausschließlich zwi-schen dem Lizenzgeber und Ihnen und wirken sich nicht auf die Dritten gemäß Ziffern 8.a) angeboteten Lizenzen aus.

e. Sofern zwischen Ihnen und dem Lizenzgeber keine anderweitige Vereinbarung getroffen wurde und soweit Wahlfreiheit besteht, findet auf diesen Lizenzvertrag das Recht der Bun-desrepublik Deutschland Anwendung.

„Creative Commons Notice“

„Creative Commons“ ist nicht Partei dieser Lizenz und übernimmt keinerlei Gewähr oder dergleichen in Bezug auf den Schutzgegenstand. „Creative Commons“ haftet Ih-nen oder einer anderen Partei unter keinem rechtlichen Gesichtspunkt für irgendwelche Schäden, die - abstrakt oder konkret, zufällig oder vorhersehbar - im Zusammenhang mit dieser Lizenz entstehen. Unbeschadet der vorangegangen beiden Sätze hat „Creati-ve Commons“ alle Rechte und Pflichten eines Lizenzgebers, wenn es sich ausdrücklich als Lizenzgeber im Sinne dieser Lizenz bezeichnet.

„Creative Commons“ gewährt den Parteien nur insoweit das Recht, das Logo und die Marke „Creative Commons“ zu nutzen, als dies notwendig ist, um der Öffentlichkeit gegenüber kenntlich zu machen, dass der Schutzgegenstand unter einer CCPL steht. Ein darüber hinaus gehender Gebrauch der Marke „Creative Commons“ oder einer verwandten Marke oder eines verwandten Logos bedarf der vorherigen schriftlichen Zustimmung von „Creative Commons“. Jeder erlaubte Gebrauch richtet sich nach der „Creative Commons“ Marken-Nutzungs-Richtlinie in der jeweils aktuellen Fassung, die von Zeit zu Zeit auf der Website veröffentlicht oder auf andere Weise auf Anfrage

101

Anhang

zugänglich gemacht wird. Zur Klarstellung: Die genannten Einschränkungen der Mar-kennutzung sind nicht Bestandteil dieser Lizenz.

„Creative Commons“ kann kontaktiert werden über http://creativecommons.org/.

102