Autor: Markus Wamser, Mixed Mode GmbH<\/p>\n
Trusted Platform Modules (TPMs) sind seit vielen Jahren fest am Markt etabliert. Mittlerweile haben Module nach der aktuellen Version 2.0 des Standards \u00e4ltere Module weitgehend abgel\u00f6st. Dennoch bleiben viele der Neuerungen und Funktionen dieser Module ungenutzt. Ein prominentes Beispiel ist das Konzept der Extended Authorization Policies. Damit sind nicht nur sichere und vertrauensw\u00fcrdige Boot- und Update-Konzepte m\u00f6glich. Mit wenig Aufwand l\u00e4sst sich auch ein Konzept zum Rechte- bzw. Lizenzmanagement umsetzen, zum Beispiel in einem Fahrzeug.<\/strong><\/p>\n Im Alltag verbinden viele den Begriff Digitales Rechtemanagement (DRM) mit dem Kauf und Konsum von Mediendateien. Tats\u00e4chlich macht Videostreaming mehr als die H\u00e4lfte des gesamten Internetverkehrs aus [1], davon ist ein Gro\u00dfteil per DRM gesch\u00fctzt. Im Embedded-Umfeld sind die Einsatzm\u00f6glichkeiten f\u00fcr ein Rechte- und Lizenzmanagement aber weit vielf\u00e4ltiger. So lassen sich Nutzungsrechte f\u00fcr einzelne Softwarefunktionen kryptographisch sicher an eine Autorisierung binden. Diese Autorisierungen wiederum k\u00f6nnen mit einem TPM 2.0 Modul flexibel und nahezu beliebig komplex gestaltet werden. Gleichzeitig ist aber die Implementierung im eingebetteten System kosteng\u00fcnstig realisierbar, da lediglich ein TPM 2.0 Modul als hardwarebasierter Vertrauensanker vorhanden sein muss.<\/p>\n Dieser Zugewinn an Flexibilit\u00e4t und Sicherheit entstammt wesentlich dem Konzept der Extended Authorization und darauf aufbauender Policies, das beim \u00dcbergang zu Version 2.0 Einzug in den TPM-Standard gefunden hat.<\/p>\n Trusted Platform Modules (TPMs) wurden aus der Not geboren, einen m\u00f6glichst g\u00fcnstigen, aber dennoch sicheren Vertrauensanker in Ger\u00e4ten zu haben. Einfache, auf eine Hauptplatine aufl\u00f6tbare Chips, die grundlegende Funktionen zur Generierung und zur sicheren Aufbewahrung von kryptographischem Schl\u00fcsselmaterial boten, fanden kurz nach der Jahrtausendwende zum ersten Mal weite Verbreitung. Inkompatibilit\u00e4ten im Detail verhinderten aber eine tats\u00e4chliche intensivere Verwendung, mit Ausnahme einzelner gro\u00dfer Unternehmen mit homogenen Umgebungen. Ein Wendepunkt war die Verabschiedung der Version\u00a01.2 des TPM-Standards durch die Trusted Computing Group (TCG) im Jahr 2009. Sie brachte neben Verbesserungen am Sicherheitskonzept vor allem eine weitgehende Harmonisierung von Schnittstellen und Funktionen. Trotz des kleinen Versionssprunges war dies ein Meilenstein f\u00fcr die Akzeptanz und Verwendung von TPMs. Eines des prominentesten Anwendungsszenarien \u2013 TPM-gest\u00fctzte Festplattenverschl\u00fcsselung \u2013 wurde fester Bestandteil von Betriebssystemen und kann seither ohne weitere Software oder aufw\u00e4ndige Konfiguration genutzt werden.<\/p>\n Die intensivere Nutzung von TPMs offenbarte aber auch Schw\u00e4chen dieser Version: Der Standard war \u00fcber mehrere Versionen entsprechend der W\u00fcnsche von Anwendern gewachsen, behielt aber stets eine Abw\u00e4rtskompatibilit\u00e4t. Dadurch war er komplex und schwer lesbar geworden, was die Entwicklung weitere Einsatzszenarien hemmte. Ebenso wirkte sich das Fehlen weiterer Funktionen hemmend aus. Als gr\u00f6\u00dfter Mangel offenbarte sich schlie\u00dflich die enge Festlegung auf bestimmte (wenige) kryptographische Verfahren. Sollte sich auch nur eines dieser Verfahren als schwach oder unsicher erweisen, so gab es keine M\u00f6glichkeit auf Alternativen auszuweichen. Dass diese Furcht nicht nur theoretischer Natur war, zeigte sich noch w\u00e4hrend der Entwicklung der Version 2.0. Erste praktikable Angriffe auf SHA-1, das in Version 1.2 festgeschriebene Hashverfahren, zeichneten sich am Horizont ab.<\/p>\n Die Entwicklung von Version 2.0 des Standards war deswegen von drei grundlegenden Gedanken gepr\u00e4gt:<\/p>\n Die pr\u00e4gendste \u00c4nderung war die Einf\u00fchrung symmetrische Kryptographie. Auf diese war in den 1.x-Versionen bewusst verzichtet worden, um einen Konflikt mit eventuellen Exportrestriktionen zu vermeiden. Flexibilit\u00e4t in der Auswahl von Kryptoverfahren und die Verwendung moderner Primitiven (etwa asymmetrischer Verfahren auf Basis von Elliptischen Kurven) machten die Einf\u00fchrung hybrider Verfahren und damit symmetrischer Primitiven notwendig. Zwischenzeitlich gelockerte Exportrestriktionen vereinfachten diese Entscheidung.<\/p>\n Die zweite zentrale und nicht zu untersch\u00e4tzende \u00c4nderung war die Vereinheitlichung der verschiedenen Autorisierungsverfahren zur sogenannten\u00a0Enhanced Authorization<\/em>. Diese Vereinheitlichung erweiterte das Spektrum an Einsatzm\u00f6glichkeiten, etwa im Sinne von Extended Authorization Policies, welche in diesem Artikel n\u00e4her beleuchtet werden. Gleichzeitig wurde der Implementierungsaufwand f\u00fcr Hersteller und Anwender von TPMs reduziert.<\/p>\n Das Ziel der einfachen Lesbarkeit wurde schlie\u00dflich der Eindeutig untergeordnet. Im Gegenzug ist es m\u00f6glich aus der Spezifikation einen TPM\u00a02.0-Simulator zu erzeugen, dessen Verhalten letztendlich als autoritative Referenz herangezogen werden kann.<\/p>\n In Erg\u00e4nzung zur Spezifikation\u00a0[2] entstand schlie\u00dflich\u00a0A\u00a0Practical Guide to TPM\u00a02.0\u00a0<\/em>[3] als frei verf\u00fcgbares Buch um den Zugang zu Technologie und Spezifikation zu vereinfachen. Kapitel\u00a03 dieses Buchsnennt weitere, f\u00fcr diesen Artikel nicht relevante Neuerungen in TPM\u00a02.0, die im Wesentlichen der Benutzerfreundlichkeit dienen.<\/p>\n Kern der \u00a0Extended Authorization Policies ist das Hash-extend-Verfahren um eine Art revisionssicheres Protokoll zu erzeugen. Allerdings werden nicht die zu protokollierenden Daten selbst gespeichert, sondern nur ein aktueller Statuswert. Durch das verwendete Hashverfahren ist sichergestellt, dass es praktisch unm\u00f6glich ist, einen zweites Protokoll zu erzeugen, das zu demselben Statuswert f\u00fchrt. Ebenso ist es nicht m\u00f6glich, bei vorgegebenem aktuellem Statuswert das Protokoll\u00a0(beliebig)<\/em>\u00a0so fortzuschreiben, dass ein bestimmter Statuswert erreicht wird. Dies entspricht, salopp gesprochen, einer in das TPM integrierten Blockchain, wobei nur der jeweils aktuelle Block gespeichert wird. Genauer handelt es sich sogar nur um dessen Hashwert.<\/p>\n Das Fortschreiben dieser Hash-Kette geschieht nun folgenderma\u00dfen: Ist im TPM ein Statuswert\u00a0S<\/em>\u00a0hinterlegt und sollen die Daten\u00a0D<\/em>\u00a0dort mit hinterlegt werden (die Spezifikation spricht hier davon, dass\u00a0D<\/em>\u00a0extended<\/em>\u00a0wird), so wird zuerst\u00a0D<\/em>\u00a0an\u00a0S<\/em>\u00a0angeh\u00e4ngt. Mit einer Hashfunktion\u00a0hash<\/em>\u00a0wird dann ein neuer Statuswert\u00a0S\u2018<\/em>\u00a0berechnet:<\/p>\n S\u2018<\/em>\u00a0\u2190\u00a0hash<\/em>(S<\/em>\u00a0||\u00a0D<\/em>)<\/p>\n Diese Statuswerte werden meist in sogenannten Platform Configuration Registers (PCRs) hinterlegt. Namensgebend war dabei der urspr\u00fcngliche und auch heute noch h\u00e4ufigste Einsatzzweck, n\u00e4mlich die Absicherung und Protokollierung des Bootvorganges (Secure Boot<\/em>\u00a0resp.\u00a0Trusted Boot<\/em>). Die PCRs eines TPMs lassen sich nicht direkt beschreiben. Ausgehend von einem wohldefinierten Anfangswert sind sie nur durch die\u00a0extend<\/em>-Operation ver\u00e4nderbar. Damit ist ein Zur\u00fcckstellen auf einen vorherigen Wert oder das gezielte Schreiben eines Statuswertes praktisch unm\u00f6glich.<\/p>\n Die\u00a0extend<\/em>-Operation selbst ist auch ein zentraler Baustein der Extended Authorization Policies.<\/p>\n Um einen st\u00f6rungsfreien und sicheren Betrieb zu gew\u00e4hrleisten, pr\u00fcft das TPM bei jedem erhaltenen Befehl, ob der Sender des Befehls auch zu dessen Ausf\u00fchrung, genauer zur Nutzung der im Befehl referenzierten Ressourcen (entities), berechtigt ist. Im einfachsten Fall geschieht dieser Nachweis \u00fcber die Eingabe eines Kennwortes oder das Verwenden eines mit dem TPM vereinbarten Sitzungsschl\u00fcssels.<\/p>\n Extended Authorization Policies<\/em>, manchmal auch als\u00a0Enhanced Authorization Policies<\/em>\u00a0und oft einfach kurz als\u00a0Policies<\/em>\u00a0bezeichnet, stellen eine weitere und deutlich m\u00e4chtigere M\u00f6glichkeit dar, Rechte zu vergeben und zu pr\u00fcfen. Die einschl\u00e4gige Literatur wagt sogar die Behauptung: „Clever policy designs can allow virtually any restriction on key use that you can envision,[\u2026]“ [3, p. 33] Dies nat\u00fcrlich mit der Einschr\u00e4nkung, dass der ben\u00f6tigte Implementierungsaufwand eine nat\u00fcrliche Schranke darstellt.<\/p>\n Als einfaches Beispiel kann folgendes Szenario dienen: In einem Unternehmen werden die Schl\u00fcssel f\u00fcr die Kommunikation per eMail von TPMs verwaltet. Erh\u00e4lt ein Anwender eine verschl\u00fcsselte eMail, so kann er diese vom TPM nach Eingabe seiner Passphrase entschl\u00fcsseln lassen. Im Interesse des Unternehmens soll aber auch ein Zugriff auf die eMails ohne Kenntnis dieser Passphrase m\u00f6glich sein, etwa nach dem Ausscheiden des Mitarbeiters oder bei pl\u00f6tzlicher Erkrankung. F\u00fcr diesen Fall werden Passw\u00f6rter f\u00fcr Betriebsrat, Gesch\u00e4ftsf\u00fchrer und Administrator hinterlegt. Mittels einer Policy kann nun geregelt werden, dass der Zugriff auf das Schl\u00fcsselmaterial und damit auf die eMails ebenfalls m\u00f6glich ist, wenn mindestens zwei dieser drei Passw\u00f6rter korrekt eingegeben wurden. Damit sind sowohl die Interessen des Unternehmens als auch die Privatsph\u00e4re des Mitarbeiters gewahrt.<\/p>\n Policies attestieren einen bestimmten Systemzustand, eine bestimmte Eigenschaft oder ein bestimmtes Ereignis. Dies kann z.B. das Vorhandensein eines bestimmten Wertes oder Wertebereichs in einem PCR oder im nichtfl\u00fcchtigen Speicher des TPMs sein. Aber auch komplexere Bedingungen, wie ein bestimmter Wert in einem zweiten TPM, das in einem Fingerabduckleser verbaut ist.<\/p>\n Der Zweck einer Policy ist dabei immer die Freigabe des Zugriffs aufs eine\u00a0entity<\/em>\u00a0des TPMs, meist ein geheimer Schl\u00fcssel oder ein Bereich des nichtfl\u00fcchtigen Speichers. Eine Policy ist also ein Satz von Restriktionen, die den Zugriff beschr\u00e4nken.<\/p>\n Zur \u00dcberpr\u00fcfung der Restriktionen wird ein spezielles\u00a0policyDigest<\/em>-Register verwendet. Ist die Policy erf\u00fcllt, wird das\u00a0policyDigest<\/em>-Register mittels\u00a0extend<\/em>-Funktion und einem speziellen Fingerabdruck der Policy (und der Bedingung) aktualisiert. Die Freigabe der\u00a0entity<\/em>\u00a0ist dann an einen bestimmten Wert des\u00a0policyDigest<\/em>-Registers gebunden. Dieser Wert muss bei der Erzeugung der\u00a0entity<\/em>\u00a0bekannt sein.<\/p>\n Es sind dabei zwei Arten von Policies zu unterscheiden: Policies mit unmittelbarer (immediate assertion<\/em>) \u00dcberpr\u00fcfung der Bedingungen und Policies mit zur\u00fcckgestellter (deferred assertion<\/em>) \u00dcberpr\u00fcfung der Bedingungen. W\u00e4hrend erstere wie bereits beschrieben funktioniert, findet bei letzterer die \u00dcberpr\u00fcfung der Bedingungen bei Zugriff auf die durch die Policy gesch\u00fctzte\u00a0entity<\/em>\u00a0statt. Das\u00a0policyDigest<\/em>\u00a0wird aber bereits zum Zeitpunkt der Vormerkung mit einem speziellen Wert aktualisiert. Die \u00dcberpr\u00fcfung der Bedingungen unmittelbar beim Zugriff auf die\u00a0entity<\/em>\u00a0wird dann durch das TPM sichergestellt.<\/p>\n Policies mit zur\u00fcckgestellter \u00dcberpr\u00fcfung erm\u00f6glichen das Vorverarbeiten komplexer Policy-Kombinationen, die statische Bedingungen (z.B. bestimmte Hardwarekonfigurationen) und externe\/dynamische Ereignisse (z.B. bestimmte Zeitr\u00e4ume) koppeln. Das typischste Beispiel ist aber die einfache Autorisierung per Passwort. Hierbei flie\u00dft in den\u00a0policyDigest<\/em>\u00a0lediglich ein, dass eine solche Autorisierung beim Zugriff auf die entsprechende entity zu pr\u00fcfen ist, nicht das Passwort selbst. (Das TPM stellt die \u00dcberpr\u00fcfung beim tats\u00e4chlichen Zugriff sicher.)<\/p>\n Generell ist es m\u00f6glich, den Referenz-policyDigest<\/em>\u00a0offline, d.h. ohne TPM und rein in Software zu berechnen, da nie Geheimnisse in diesen Wert einflie\u00dfen. In der Praxis verwendet man aber meist eine sogenannten\u00a0trial policy session<\/em>. Dabei werden die Policies auf dem TPM in gleicher Weise wie bei der \u00dcberpr\u00fcfung angewandt, allerdings wird stets die Erf\u00fcllung der Policy angenommen. Am Ende kann der ben\u00f6tigte\u00a0policyDigest-Wert<\/em>\u00a0ausgelesen oder direkt zur Erzeugung einer entity verwendet werden.<\/p>\n Die logische und-Verkn\u00fcpfung mehrerer Policies ergibt sich trivial: Die Policies m\u00fcssen lediglich nacheinander abgepr\u00fcft werden. Wichtig ist hierbei die Einhaltung der Reihenfolge. Der TPM\u00a02.0-Standard erm\u00f6glicht aber auch die Verbindung von Policies mit einer (nicht-)exklusiven oder- Verkn\u00fcpfung.<\/p>\n Dadurch lassen sich komplexe Hierarchien in Form von Policy-B\u00e4umen erzeugen. Noch mehr Flexibilit\u00e4t ergibt sich durch die Verwendung von digitalen Signaturen. Innerhalb einer Policy-Hierarchie l\u00e4sst sich die Bedingung „Policy A ist erf\u00fcllt“ ersetzen durch „Policy X ist erf\u00fcllt und es liegt eine g\u00fcltige Signatur f\u00fcr Policy X vor.“ Damit lassen sich Policies dynamisch austauschen oder erg\u00e4nzen, insbesondere wenn die konkreten Werte zur Erf\u00fcllung von Policy X bei der Erstellung der Hierarchie noch nicht bekannt sind.<\/p>\n Was in der theoretischen Beschreibung noch kompliziert klingt, wird schnell klar wenn ein tats\u00e4chlich implementiertes Beispiel betrachtet wird.<\/p>\n Zur Veranschaulichung der Konzepte sei nun folgendes Szenario gegeben: F\u00fcr ein Fahrzeug (etwa einen Mietwagen), sollen verschiedene Benutzerrollen (Gruppen von Fahrern) definiert werden. Neben dem normalen Fahrer, der das Analogon eines Schl\u00fcssels besitzt, soll es eine alternative M\u00f6glichkeit zur Autorisierung f\u00fcr einen Hotelportier geben. Dieser darf das Fahrzeug zum Parken nur mit reduzierter Geschwindigkeit bewegen. Die dritte Rolle bildet einen Servicetechniker ab, der Zugriff auf erweiterte Funktonalit\u00e4t hat, sich daf\u00fcr aber mittels Zweifaktor-Authentifizierung legitimieren muss. Unabh\u00e4ngig von der Rolle soll die gesamte Policy an ein Fahrzeugmerkmal gebunden sein. Dazu wird im nichtfl\u00fcchtigen Speicher des TPMs das Kennzeichen oder die Fahrgestellnummern hinterlegt.<\/p>\n Aus diesen Anforderungen ergibt sich initial die in Abbildung 1 (siehe\u00a0PDF<\/a>) dargestellte Policy-Hierarchie. Die KFZ-ID wird bei der Provisionierung des Systems im nichtfl\u00fcchtigen Speicher des TPMs hinterlegt. Sei f\u00fcr den Moment angenommen, alle darunterliegenden Policies seien erf\u00fcllt, wird \u00fcber das SAPI-Kommando\u00a0TPM_PolicyNV<\/em>\u00a0gepr\u00fcft ob der angegebene Bereich im NV-RAM des TPMs den gew\u00fcnschten Wert enth\u00e4lt.<\/p>\n Die darunterliegende ODER-Verkn\u00fcpfung kann mit dem Kommando\u00a0TPM2_PolicyOR<\/em>\u00a0realisiert werden. Hierbei pr\u00fcft das TPM ob der aktuelle\u00a0policyDigest<\/em>\u00a0einem der in der Policy hinterlegten Werte entspricht. (Im Standard ist die Zahl der m\u00f6glichen Werte auf acht begrenzt. Es lassen sich aber beliebig viele\u00a0TPM2_PolicyOR<\/em>-Bedingungen verketten.) Ist die Policy erf\u00fcllt, d.h. der aktuelle\u00a0policyDigest<\/em>\u00a0entspricht einem g\u00fcltigen Wert, wird die Policy\u00a0konvertiert<\/em>: Es wird ein Hashwert \u00fcber die Policy berechnet und dieser in (einen frischen)\u00a0policyDigest<\/em>\u00a0erweitert. Damit ergibt sich stets der gleiche Folgewert f\u00fcr den\u00a0policyDigest<\/em>, unabh\u00e4ngig davon welche Teilbedingung erf\u00fcllt ist.<\/p>\n Die unterste Ebene der Hierarchie kann beispielsweise durch sequentielles Ausf\u00fchren von\u00a0TPM_PolicyNV<\/em>\u00a0und\u00a0TPM2_PolicyAuthValue<\/em>\u00a0realisiert werden.<\/p>\n F\u00fcr den praktischen Einsatz erweist sich diese Hierarchie aber als noch nicht ausreichend flexibel, denn jede Rolle ist starr mit einer einzigen ID verkn\u00fcpft. Dar\u00fcber hinaus sind alternative Methoden zur Authentifizierung noch nicht explizit abgebildet.<\/p>\n Die L\u00f6sung findet sich in Konzept der Wildcard-Policies. Konkret wird in der initialen Hierarchie jede Benutzer-ID durch eine solche Wildcard-Policy ersetzt. Mittels\u00a0TPM2_PolicyAuthorize<\/em>\u00a0wird ein (Fingerabruck) des \u00f6ffentlichen Teils eines asymmetrischen Schl\u00fcsselpaares in den\u00a0policyDigest\u00a0<\/em>erweitert. An dieser Stelle kann nun jede Policy eingesetzt werden, zu derem abschlie\u00dfenden Wert eine g\u00fcltige Signatur mit diesem Schl\u00fcsselpaar vorliegt. Die \u00dcberpr\u00fcfung der Policy-Hierarchie erfolgt dann in zwei Schritten, zuerst wird die Signatur durch das TPM \u00fcberpr\u00fcft. Das TPM erzeugt daraufhin ein Ticket mit dem es sich selbst gegen\u00fcber die erfolgreiche Signaturpr\u00fcfung attestiert. Damit wird, bildlich gesprochen, die konkrete Policy anstelle der Wildcard-Policy in die Policy-Hierarchie eingeh\u00e4ngt. Schlussendlich ergibt sich die Hierarchie aus Abbildung 2 (siehe\u00a0PDF<\/a>). Jede der dort gestrichelt markierten Sub-Hierarchien kann mehrfach existieren. Damit k\u00f6nnen dynamisch Benutzer-IDs f\u00fcr die verschiedenen Rollen aktiviert und deaktiviert werden.<\/p>\n Die Erzeugung und \u00dcberpr\u00fcfung der vorgestellten Policy-Hierarchie wurde bei MixedMode sowohl mit Skripten auf einem RaspberryPi, als auch f\u00fcr die hauseigene M2Control Demonstratorplattform als QT-App umgesetzt. Als TPM-Modul kam dabei in beiden F\u00e4llen ein Infineon SLB 9670-Baustein zum Einsatz, der per SPI angebunden wurde.<\/p>\n Die Policies werden durch die Demo direkt per\u00a0trial-session<\/em>\u00a0auf dem TPM generiert (Abbildung 3, siehe\u00a0PDF<\/a>), das Schl\u00fcsselpaar f\u00fcr die Wildcard-Policies wird mit OpenSSL erzeugt. \u00dcber die QT-Oberfl\u00e4che lassen sich schlie\u00dflich User-IDs registrieren und Authentifizierungen durchf\u00fchren.<\/p>\n Das vorgestellte Beispiel l\u00e4sst sich leicht auf ein allgemeineres Rechtemanagement \u00fcbertragen. Dies kann f\u00fcr ein reines Software-Lizenzmanagement (Freigabe von Funktionalit\u00e4ten on-demand und im pay-per-use-Modell) bis zu einem integrierten Produktionsmanagement (Lizensierung von Produktionsdaten, Limitierung produzierter Einheiten, Echtheitszertifizierung etc.) ausgebaut werden, da Policies auch einfache numerische Vergleichsoperationen und \u00fcber das TPM realisierte irreversible Z\u00e4hler umfassen k\u00f6nnen.<\/p>\n Extended Authorizations erm\u00f6glichen auch, Policies zu zertifizieren. Damit l\u00e4sst sich etwa das Vertrauen in Signaturschl\u00fcssel erh\u00f6hen, da das TPM zus\u00e4tzlich zur Signatur auch einen kryptographischen Nachweis dar\u00fcber liefern kann, welche Form der Zugriffskontrolle auf den Signaturschl\u00fcssel realisiert ist.<\/p>\n Schlussendlich erm\u00f6glichen Wildcard-Policies ein sicheres Systemupdate. Sie liefern die ben\u00f6tigte Indirektion um eine\u00a0TPM_PolicyPCR<\/em>\u00a0ohne tempor\u00e4ren Bruch der Vertrauenskette zu aktualisieren. Ein auf diese Weise realisiertes SecureBoot\/TrustedBoot-Konzept kann dann sogar mit der vorgestellten L\u00f6sung kombiniert werden.<\/p>\n Mit der Einf\u00fchrung von Policies wurde ein m\u00e4chtiges Werkzeug geschaffen, um komplexe und gleichzeitig flexible Rechtemanagement-Architekturen auf Basis von TPM 2.0 Modulen zu realisieren.<\/p>\n Die weite Verbreitung der Module und standardisierte Programmierschnittstellen erlauben eine schnelle, sichere und nachhaltige Umsetzung eines Rechtemanagements in verschiedensten Einsatzszenarien.<\/p>\n Die Verkn\u00fcpfung verschiedener Arten von Teil-Policies zu einer komplexen Policy wurde am Beispiel des Mixed Mode M2Control Embedded Demonstrators aufgezeigt. Hier wurden an einem (fiktiven) Fahrzeug Funktionalit\u00e4t auf Basis von Benutzerrollen freigegeben. Die Authentifizierung der einzelnen Benutzer war dabei f\u00fcr jede f\u00fcr jede Rolle individuell gestaltet.<\/p>\nTPM 2.0: Motivation und \u00c4nderungen zu TPM 1.2<\/h2>\n
\n
Extended Authorization Policies<\/h2>\n
Grundlagen<\/h3>\n
Konzept<\/h3>\n
Funktionsweise<\/h3>\n
Hierarchien<\/h2>\n
Beispiel: Rechte-Management<\/h2>\n
Policy-Hierarchie<\/h2>\n
Umsetzung<\/h2>\n
Ausblick: Weitere Einsatzszenarien<\/h2>\n
Zusammenfassung<\/h2>\n
Literatur- und Quellenverzeichnis<\/h2>\n