DE60002893T2

DE60002893T2 - Computerplattformen und deren betriebsverfahren

Info

Publication number: DE60002893T2
Application number: DE60002893T
Authority: DE
Inventors: Lynne Siani Westbury-on-Trym Pearson; David Chan
Original assignee: Hewlett Packard Co
Current assignee: HP Inc
Priority date: 1999-08-13
Filing date: 2000-08-11
Publication date: 2004-05-13
Anticipated expiration: 2020-08-12
Also published as: WO2001013199A1; JP4278327B2; US7996669B2; US20090031141A1; EP1204910B1; US7461249B1; DE60002893D1; JP2003507785A; EP1204910A1; EP1076279A1

Description

Diese Erfindung bezieht sich auf Computerplattformen und ihre Funktionsweisen, und betrifft insbesondere ein Steuern und/oder Messen der Installation und/oder Verwendung von Daten auf Computerplattformen.
In dieser Spezifikation bedeutet der Begriff „Daten" alles das, was digital formatiert werden kann, beispielsweise Bilder, Anwendungssoftware und Streaming-Medien. Die in dem vorliegenden Dokument beschriebenen Techniken können potentiell verwendet werden, um viele Arten von Informationen, von einfachen Textdokumenten bis hin zu Audio- und Videoclips, Software, Graphiken sowie Photo- und Multimediamaterialien, zu schützen oder aufzuzeichnen.
In Zukunft werden Computersysteme in der Lage sein, ein sichereres Booten zusammen mit Integritätsprüfungen eines anderen Codes zu erreichen, um zu gewährleisten, daß an den Betriebssystemen und der installierten Software keine Viren vorliegen oder keine andere nicht-autorisierte Modifikationen vorgenommen wurden. Ferner erscheint bereits jetzt oder in Bälde eine neue Generation von manipulationssicheren Vorrichtungen bzw. Bauelementen auf dem Markt, die sowohl externe oder tragbare Komponenten (wie beispielsweise Smartcards) als auch interne Komponenten (eingebettete Prozessoren, halbeingebettete Prozessoren oder Coprozessoren mit einer Sicherheitsfunktionalität, d.h. einschließlich Hauptplatinen-, USB- und ISA-Implementierungen) umfassen. Diese manipulationssicheren Komponenten werden verwendet, um zu prüfen, daß die Hardware des Systems nicht manipuliert wurde, und um eine zuverlässigere Form einer Maschinenidentität zu liefern, als sie derzeit verfügbar ist (beispielsweise den Ethernet-Namen der Maschine). Es bleibt jedoch weiterhin ein sehr bedeutendes Problem, wie Pirate rie entgegengewirkt werden soll und wie Software auf eine Art und Weise lizenziert und gemessen werden soll, die für Softwareentwickler und Endbenutzer akzeptabel ist.
Die Software-Lizenzierung ist Hackern und Piraterie ausgesetzt, und alle derzeit verwendeten Software-Lizenzierungsverfahren weisen Probleme auf. Software-Implementierungen eines Lizenzierens (beispielsweise „Lizenzverwaltungssysteme") sind flexibel, aber nicht besonders sicher oder schnell. Insbesondere weisen sie einen Mangel an Sicherheit (beispielsweise sind sie einem allgemeinen „Hacken" ausgesetzt) und Schwierigkeiten bei einem echten bzw. legitimen Austauschen von Software auf. Im Gegensatz dazu sind Hardware-Implementierungen („Dongles") schneller und allgemein sicherer als Software-Implementierungen, jedoch unflexibel. Sie sind lediglich für eine bestimmte Software ausgelegt und sind für Endbenutzer unzweckmäßig.
In ihrem bevorzugten Ausführungsbeispiel liefert die vorliegende Erfindung das Beste aus beiden Welten: Eine Hardware-Implementierung, die sicher und schnell ist, jedoch die Zweckmäßigkeit und Flexibilität einer Software-Implementierung aufweist. Bei dem Ausführungsbeispiel dieses neuen, generischen Konzeptes in Bezug auf Software-Lizenzierung und -Messung werden eine erhöhte Sicherheit beim Integritätsprüfen von Computerplattformen zusammen mit einer sichereren Schlüsselspeicherung, kryptographischen Fähigkeiten und einer sichereren Identifizierung (und somit Authentifizierung) in einer manipulationsresistenten Hardware geliefert.
Eine Patentanmeldung des Standes der Technik (internationale Patentanmeldung Nr. PCT/GB00/00528, am 15. Februar 2000 eingereicht) beschrieb die Verwendung einer Vertrauenswürdigen Komponente, um eine Verifizierung der Integrität einer Computerplattform durch die zuverlässige Messung und das zuverlässige Melden von Integritätsmetriken zu ermögli chen. Dies ermöglicht die Verifizierung der Integrität einer Plattform entweder durch einen Benutzer vor Ort oder eine entfernte Entität. Jene Patentanmeldung des Standes der Technik beschrieb ein allgemeines Verfahren zum Melden von Integritätsmetriken und zum Verifizieren der Korrektheit der Integrität einer Plattform durch Vergleichen gemeldeter Werte von Metriken mit ordnungsgemäßen Metrikwerten. Die vorliegende Erfindung verwendet einen Lizenzprüfungscode, dessen Integrität unter Verwendung des Verfahrens jener Patentanmeldung des Standes der Technik gemeldet wird.
Zusammengefaßt gesagt verwendet das Ausführungsbeispiel der vorliegenden Erfindung eine manipulationssichere Komponente oder ein „vertrauenswürdiges Modul" einer Computerplattform in Verbindung mit Software, die vorzugsweise in der manipulationssicheren Komponente betrieben wird, die das Hochladen und die Verwendung von Daten auf der Plattform als einen generischen Dongle für diese Plattform steuert. Lizenzierungsprüfungen können in einer vertrauenswürdigen Umgebung stattfinden (mit anderen Worten einer Umgebung, bei der man darauf vertrauen kann, daß sie sich so verhält, wie der Benutzer dies erwartet); dies kann durch ein Integritätsprüfen der Hochlade- und Lizenzprüfungssoftware durchgesetzt werden. Meßaufzeichnungen können in der manipulationssicheren Vorrichtung gespeichert und nach Bedarf den Administratoren gemeldet werden. Es kann ein zugeordneter Verrechnungsinstanzmechanismus vorliegen, um eine Registrierung und Bezahlung von Daten zu ermöglichen.
Formeller gesagt ist gemäß einem ersten Aspekt der vorliegenden Erfindung eine Computerplattform vorgesehen, die folgende Merkmale aufweist: ein vertrauenswürdiges Modul, das gegenüber einem internen Manipulieren resistent ist und das ein Öffentlicher-Schlüssel-Zertifikat einer dritten Partei speichert; eine Einrichtung, die einen lizenzbezogenen Code speichert, der zumindest eines der folgenden Merkmale umfaßt: eine sichere Ausführeinrichtung (die vorzugs weise generisch ist) zum Prüfen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, bestimmte Daten zu verwenden, und zum Bereitstellen einer Schnittstelle zum Verwenden der Daten und/oder zum Überwachen ihrer Verwendung; und eine sichere Ladeeinrichtung (die vorzugsweise generisch ist) zum Prüfen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, bestimmte Daten zu installieren, und/oder zum Prüfen bezüglich einer Datenintegrität vor einer Installation; und eine Einrichtung, die eine hash-codierte Version des lizenzbezogenen Codes, die mit dem privaten Schlüssel der dritten Partei signiert ist, speichert; wobei die Computerplattform so programmiert ist, daß auf ein Booten der Plattform hin: der lizenzbezogene Code bezüglich der signierten Version und des Öffentlicher-Schlüssel-Zertifikats auf seine Integrität hin überprüft wird; und falls die Integritätsprüfung negativ ausfällt, verhindert wird, daß der lizenzbezogene Code geladen wird. Falls die Integritätsprüfung negativ ausfällt, kann es eingerichtet sein, daß die gesamte Plattformintegrität negativ ausfällt.
Im Kontext dieser Spezifikation kann der Begriff „Benutzer" einen Endbenutzer der Plattform oder einen Systemadministrator oder beides bedeuten.
Das vertrauenswürdige Modul oder die vertrauenswürdige Komponente, wie es bzw, sie in der oben erwähnten Patentanmeldung des Standes der Technik beschrieben ist, ist vorzugsweise immun gegenüber einer nicht-autorisierten Modifikation oder Inspektion von internen Daten. Es bzw. sie ist physisch, um Fälschungen zu verhindern, manipulationsresistent, um Nachahmungen zu verhindern, und weist vorzugsweise Kryptofunktionen auf, um über eine Entfernung sicher zu kommunizieren. Verfahren zum Aufbauen vertrauenswürdiger Module sind an sich Fachleuten hinreichend bekannt. Das vertrauenswürdige Modul kann kryptographische Verfahren verwenden, um sich selbst eine kryptographische Identität zu verleihen und um eine Authentizität, Integrität, Ver traulichkeit, einen Schutz vor Wiedergabeangriffen zu liefern, digitale Signaturen durchzuführen und digitale Zertifikate zu verwenden, je nach Bedarf. Diese und andere Kryptoverfahren und ihre Initialisierung sind Fachleuten auf dem Gebiet der Sicherheit hinreichend bekannt.
Vorzugsweise wird das Integritätsprüfen auf folgende Weise durchgeführt: durch Lesen und Hash-Codieren des lizenzbezogenen Codes, um einen ersten Hash-Wert zu erzeugen; Lesen und Entschlüsseln der signierten Version unter Verwendung des Öffentlicher-Schlüssel-Zertifikats, um einen zweiten Hash-Wert zu erzeugen; und Vergleichen des ersten und des zweiten Hash-Werts.
Vorzugsweise umfaßt der lizenzbezogene Code ferner einen Code für einen sicheren Schlüsseltransfer zum Ermöglichen, daß ein Lizenzschlüssel zwischen dem vertrauenswürdigen Modul und einem weiteren vertrauenswürdigen Modul einer weiteren Computerplattform transferiert wird. Dieser Schlüsseltransfercode ist besonders nützlich beim Verbessern einer Schlüsselverwaltung, wenn Lizenzierungsmodelle verwendet werden, die einen Entriegelungsschlüssel beinhalten, das heißt, wenn die Daten in einer verschlüsselten Form übertragen werden und der Entriegelungsschlüssel verwendet wird, um zu ermöglichen, daß die geschützten Daten entschlüsselt und betrieben werden. Der Transfer kann durch Verwendung einer Öffentlicher-Schlüssel-Infrastruktur, um eine Nachricht, die einen Entriegelungsschlüssel enthält, zu verschlüsseln, und durch Prüfen in bezug auf die Integrität über ein Hash-Codieren und digitale Signaturen durchgeführt werden. Es kann auch eine Option vorliegen, die Daten selbst unter Verwendung der sicheren Ladeeinrichtung auf diese Weise zu transferieren.
Vorzugsweise umfaßt der lizenzbezogene Code ferner eine Bibliothek von Schnittstellen-Teilroutinen, die aufgerufen werden können, um mit dem vertrauenswürdigen Modul zu kommunizieren. Die Client-Bibliothek ist eine Sammlung von Schnittstellen-Teilroutinen auf hoher Ebene, die Anwendungen aufrufen, um mit dem vertrauenswürdigen Modul zu kommunizieren. Die Client-Bibliothek kann ferner durch Software-Ausführeinrichtungen (siehe unten) zum Zweck einer Kommunikation mit dem vertrauenswürdigen Modul und Betriebssystem („OS – operating system") verwendet werden.
Der lizenzbezogene Code kann für zumindest eine Gruppe von Daten eine (oder eine jeweilige) Software-Ausführeinrichtung umfassen, die die jeweilige Gruppe von Daten spezifiziert und die wirksam ist, um als Schnittstelle zu dieser Datengruppe zu fungieren. Dies macht Verfahren zum Lizenzieren eines Schutzes möglich, die für die geschützten Daten spezifisch sind, und macht somit potentiell einen höheren Schutz möglich. Falls einer Anwendung eine Software-Ausführeinrichtung zugeordnet ist, verarbeitet diese optional Anfragen (API-Anrufe bzw. -Rufe), die durch die Anwendung unterbreitet werden.
Falls es der Raum erlaubt, wird bzw. werden die Einrichtung, die den lizenzbezogenen Code speichert, und/oder die Einrichtung, die die hash-codierte Version des lizenzbezogenen Codes speichert, zumindest teilweise durch das vertrauenswürdige Modul bereitgestellt.
Vorzugsweise weisen das vertrauenswürdige Modul und ein Betriebssystem der Plattform einen zweckgebundenen Kommunikationsweg zwischen denselben auf, der für andere Teile der Computerplattform unzugänglich ist.
Als nächstes wird betrachtet, wie diese Komponenten interagieren, um ein System zum Lizenzieren von Mehrzweckdaten zu bilden. Es gibt mehrere Stufen, in denen ein derartiges System aufgebaut werden kann, die man als aufeinander aufbauend betrachten kann. Die erste Stufe besteht darin, derzeitige Lizenzierungsverfahren wie beispielsweise Dongles zu verbessern, um das vertrauenswürdige Modul dazu zu bringen, als generischer Dongle zu agieren, der durch eine ge nerische lizenzbezogene Software (wie sie oben erläutert wurde) geregelt wird, die eine Lizenzprüfung durchführt und durch eine Integritätsprüfung vor einer Umgehung (einem Bypassing) geschützt ist. Eine derartige Lizenzprüfungssoftware muß nicht in dem vertrauenswürdigen Modul selbst ablaufen bzw. betrieben werden. Eine bevorzugte Stufe ist das logische Erweitern eines derartigen Systems, bei dem die Lizenzierungssoftware in dem vertrauenswürdigen Modul abläuft. Eine Anforderung, manche Daten zu laden oder auszuführen, wird, vorzugsweise von der Software-Ausführeinrichtung, an das vertrauenswürdige Modul gesandt. Die Lizenzierungssoftware in dem vertrauenswürdigen Modul wertet eine derartige Anforderung aus und entscheidet, auf der Basis von Einzelheiten von Lizenzierungsrechten, ob sie dies erlaubt. Falls der Anforderung stattgegeben wird, werden diese Informationen über einen Hardware-Kommunikationsweg von dem vertrauenswürdigen Modul zu der Zentralverarbeitungseinheit (CPU – central processing unit) an das OS übermittelt. Der Kommunikationsweg ist vorzugsweise für gewöhnliche Anwendungen und eine nicht-OS-Software unzugänglich. Das OS startet anschließend je nach Fall den Vorgang, die Daten zu laden oder auszuführen.
Es werden nun verschiedene Verfahren betrachtet, wie die Systemkomponenten interagieren können, um eine nützliche Lizenzierungsfunktionalität durchzuführen. Zuerst wird betrachtet, wie die sichere Ladeeinrichtung arbeitet, um Daten zu installieren.
Bei einem Installationsmodus ist das Betriebssystem wirksam, um die sichere Ladeeinrichtung aufzufordern, eine Lizenzprüfung bezüglich dessen durchzuführen, ob die Plattform oder ein Benutzer derselben (z.B. ein Endbenutzer oder ein Systemadministrator) dazu lizenziert ist, diese bestimmten Daten zu installieren, und/oder die Integrität dieser Daten zu prüfen; ist die sichere Ladeeinrichtung ansprechend auf eine solche Aufforderung wirksam, um eine derartige Prüfung durchzuführen und auf das Betriebssystem mit dem Ergebnis der Prüfung zu antworten; und ist das Betriebssystem in Abhängigkeit von der Antwort wirksam, um die bestimmten Daten zu installieren oder nicht zu installieren. Diese Prüfung der Plattform oder des Benutzers kann durch verschiedene Verfahren durchgeführt werden, beispielsweise ein Prüfen bezüglich des Vorhandenseins eines Private-Anwendung-Schlüssels oder eines anderen Geheimnisses in dem vertrauenswürdigen Modul oder in einer Smartcard, oder ein Prüfen in Bezug auf die Identität und das Vorhandensein des vertrauenswürdigen Moduls oder der Smartcard. Eine derartige Identität könnte dem Entwickler bekanntgegeben werden, oder ein derartiges Geheimnis könnte während eines Registrierungsvorganges in das vertrauenswürdige Modul oder die Smartcard eingebracht werden. Dies ist analog zu dem Vorgang, der später bei Beispiel A beschrieben wird.
Vorzugsweise ist das Betriebssystem bei diesem Modus programmiert, um die bestimmten Daten lediglich ansprechend auf die sichere Ladeeinrichtung zu installieren. Bei diesem Modus gilt außerdem vorzugsweise folgendes: das vertrauenswürdige Modul speichert ein Öffentlicher-Schlüssel-Zertifikat für eine Partei, die den bestimmten zu installierenden Daten zugeordnet ist; das Betriebssystem ist wirksam, um in der Prüfaufforderung die bestimmten Daten zusammen mit einer hash-codierten Version derselben, die mit einem privaten Schlüssel der zugeordneten Partei signiert ist, aufzunehmen; und die sichere Ladeeinrichtung ist beim Durchführen der Prüfung wirksam, um: die in der Aufforderung enthaltenen bestimmten Daten einer Hash-Codierung zu unterziehen, um einen dritten Hash-Wert zu erzeugen; die signierte hash-codierte Version in der Aufforderung unter Verwendung des Öffentlicher-Schlüssel-Zertifikats für die zugeordnete Partei zu entschlüsseln, um einen vierten Hash-Wert zu erzeugen; und die Antwort in Abhängigkeit davon, ob der dritte und der vierte Hash-Wert übereinstimmen, zu erzeugen.
Dies prüft die Integrität der Nachricht. Der Integritätsprüfungsmechanismus verhindert ferner Wiedergabeangriffe durch Verwenden eines standardmäßigen Mechanismus, beispielsweise Herausforderung/Antwort, oder durch Einbringen einer Historie der Kommunikationen in den Hash-Wert. Das Problem einer Nicht-Ablehnung kann dadurch vermieden werden, daß private Schlüssel in einer manipulationssicheren Hardware aufbewahrt werden. Vorzugsweise umfaßt die Aufforderung zum Prüfen die Software-Ausführeinrichtung für die bestimmten Daten.
Bei einem anderen Installationsmodus: ist die Software-Ausführeinrichtung (oder zumindest eine der Software-Ausführeinrichtungen) wirksam, um das vertrauenswürdige Modul aufzufordern, bestimmte Daten zu installieren; ist die sichere Ladeeinrichtung in dem vertrauenswürdigen Modul als Antwort auf eine solche Aufforderung wirksam, um eine Lizenzprüfung bezüglich dessen durchzuführen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, diese bestimmten Daten zu installieren, und/oder um die Integrität dieser Daten zu prüfen und auf das Betriebssystem mit dem Ergebnis der Prüfung zu antworten; und ist das Betriebssystem in Abhängigkeit von der Antwort wirksam, um die bestimmten Daten zu installieren oder nicht zu installieren.
Die Prüfung kann auf ähnliche Weise durchgeführt werden wie die oben in Bezug auf einen Installationsmodus beschriebene Weise.
Bei diesem anderen Modus ist das Betriebssystem vorzugsweise programmiert, um die bestimmten Daten lediglich ansprechend auf das vertrauenswürdige Modul zu installieren. Ferner wird bei diesem Modus die Antwort von dem vertrauenswürdigen Modul vorzugsweise über den zweckgebundenen Kommunikationsweg an das Betriebssystem geliefert, wie oben beschrieben wurde.
Bei beiden dieser Installationsmodi ist das vertrauenswürdige Modul, falls die Prüfung erfolgreich ist, vorzugsweise wirksam, um ein Protokoll zum Überprüfen der bestimmten Daten zu erzeugen. Falls die Prüfung erfolgreich ist, ist die sichere Ladeeinrichtung ferner vorzugsweise wirksam, um eine Virusprüfung der bestimmten Daten durchzuführen.
Auf eine Installation hin können die bestimmten Daten in der vertrauenswürdigen Plattform installiert werden. Alternativ kann die Plattform ein weiteres entfernbares vertrauenswürdiges Modul (beispielsweise eine Smartcard) umfassen und wirksam sein, um eine Authentifizierungsprüfung zwischen dem zuerst erwähnten vertrauenswürdigen Modul und dem entfernbaren vertrauenswürdigen Modul durchzuführen, wobei die bestimmten Daten in diesem Fall auf eine Installation hin in dem weiteren vertrauenswürdigen Modul installiert werden können.
Die Software-Ausführeinrichtung kann selbst über Integritätsprüfungen, die durch die sichere Ladeeinrichtung durchgeführt werden, geschützt sein. Beispielsweise kann diese Prozedur wie folgt funktionieren:

(a) Die Software-Ausführeinrichtung ist individuell ausgelegt, derart, daß der öffentliche Schlüssel, der dem vertrauenswürdigen Modul des Client entspricht, in derselben enthalten ist.
(b) Die Daten, die einer individuell ausgelegten Software-Ausführeinrichtung zugeordnet sind, werden an den Client gesandt.
(c) Sowohl die Daten als auch die Software-Ausführeinrichtung werden hash-codiert und mit dem privaten Schlüssel der Verrechnungsinstanz/des Entwicklers signiert, und dieser wird zusammen mit den Daten und der Software-Ausführeinrichtung gesandt.
(d) Die sichere Ladeeinrichtung unterzieht die Software-Ausführeinrichtung einer Integritätsprüfung, wenn sie empfangen wird – auf eine Installation der Software-Ausführeinrichtung hin wird das Paket durch ein Hash-Codieren und einen Vergleich mit der entschlüsselten Signatur (unter Verwendung des öffentlichen Schlüssels in dem vertrauenswürdigen Modul) verifiziert. Die Software-Ausführeinrichtung wird nicht geladen, falls die digitale Signatur nicht mit dem Erwarteten übereinstimmt, und in diesem Fall signalisiert die sichere Ladeeinrichtung einen Fehler. Unter Verwendung derselben Prozedur unterzieht die sichere Ladeeinrichtung auch die Daten selbst einer Integritätsprüfung.

Nun wird die Art und Weise betrachtet, wie die sichere Ausführeinrichtung arbeitet, um Daten zu verwenden.
Bei einem ersten Ausführungsmodus: enthält die Software-Ausführeinrichtung (oder zumindest eine der Software-Ausführeinrichtungen) einen öffentlichen Schlüssel des vertrauenswürdigen Moduls und ein Lizenzierungsmodell für die jeweiligen Daten; ist das Betriebssystem wirksam, um diese Software-Ausführeinrichtung aufzufordern, daß ihre jeweiligen Daten verwendet werden; ist diese Software-Ausführeinrichtung ansprechend auf eine solche Aufforderung wirksam, um die sichere Ausführeinrichtung aufzufordern, unter Verwendung ihres Lizenzierungsmodells eine Lizenzprüfung bezüglich dessen durchzuführen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, diese Daten zu verwenden; ist die sichere Ausführeinrichtung ansprechend auf eine derartige zuletzt genannte Aufforderung wirksam, um die angeforderte Lizenzprüfung durchzuführen, das Ergebnis der Lizenzprüfung unter Verwendung eines privaten Schlüssels des vertrauenswürdigen Moduls zu signieren und auf diese Software-Ausführeinrichtung mit dem signierten Ergebnis anzusprechen; ist diese Software-Ausführeinrichtung ansprechend auf eine derartige Antwort wirksam, um: die Integrität des signierten Ergebnisses unter Verwendung des öf fentlichen Schlüssels des vertrauenswürdigen Moduls zu prüfen; und auf eine erfolgreiche Integritätsprüfung eines erfolgreichen Lizenzprüfungsergebnisses hin das Betriebssystem aufzufordern, diese Daten zu verwenden.
Bei einem zweiten Ausführungsmodus: enthält die Software-Ausführeinrichtung (oder zumindest eine der Software-Ausführeinrichtungen) einen öffentlichen Schlüssel des vertrauenswürdigen Moduls und ein Lizenzierungsmodell für die jeweiligen Daten; ist das Betriebssystem wirksam, um die sichere Ausführeinrichtung aufzufordern, daß bestimmte Daten verwendet werden; ist die sichere Ausführeinrichtung ansprechend auf eine solche Aufforderung wirksam, um an die jeweilige Software-Ausführeinrichtung eine unter Verwendung eines privaten Schlüssels des vertrauenswürdigen Moduls signierte Anforderung eines Lizenzierungsmodells für die bestimmten Daten zu senden; ist die Software-Ausführeinrichtung ansprechend auf eine derartige zuletzt genannte Anforderung wirksam, um: die Integrität der Anforderung unter Verwendung des öffentlichen Schlüssels des vertrauenswürdigen Moduls zu prüfen; und auf eine erfolgreiche Integritätsprüfung hin das Lizenzierungsmodell an die sichere Ausführeinrichtung zu senden; und ist die sichere Ausführeinrichtung auf einen Empfang des Lizenzierungsmodells hin wirksam, um: eine Lizenzprüfung unter Verwendung dieses Lizenzierungsmodells durchzuführen; und auf eine erfolgreiche Lizenzprüfung hin das Betriebssystem aufzufordern, diese Daten zu verwenden.
Bei einem dritten Ausführungsmodus: enthält die sichere Ausführeinrichtung zumindest ein Lizenzierungsmodell; ist das Betriebssystem wirksam, um die sichere Ausführeinrichtung aufzufordern, daß bestimmte Daten verwendet werden; und ist die sichere Ausführeinrichtung ansprechend auf eine derartige Aufforderung wirksam, um: eine Lizenzprüfung unter Verwendung des oder eines der Lizenzierungsmodelle durchzuführen; und auf eine erfolgreiche Lizenzprüfung hin das Betriebssystem aufzufordern, diese Daten zu verwenden.
Bei jeglichen dieser drei Ausführungsmodi ist das Betriebssystem vorzugsweise programmiert, um die bestimmten Daten lediglich ansprechend auf die sichere Ausführeinrichtung oder die Software-Ausführeinrichtung zu verwenden.
Bei einem vierten Ausführungsmodus: enthält die sichere Ausführeinrichtung zumindest ein Lizenzierungsmodell; ist die Software-Ausführeinrichtung (oder zumindest eine der Software-Ausführeinrichtungen) wirksam, um das vertrauenswürdige Modul aufzufordern, daß seine jeweiligen Daten verwendet werden; ist die sichere Ausführeinrichtung in dem vertrauenswürdigen Modul ansprechend auf eine solche Aufforderung wirksam, um: eine Lizenzprüfung unter Verwendung des oder eines der Lizenzierungsmodelle durchzuführen; und auf eine erfolgreiche Lizenzprüfung hin das Betriebssystem aufzufordern, diese Daten zu verwenden. In diesem Fall ist das Betriebssystem vorzugsweise programmiert, um die bestimmten Daten lediglich ansprechend auf das vertrauenswürdige Modul zu verwenden.
Bei jeglichen des zweiten, dritten und vierten Ausführungsmodus wird die Anforderung von der sicheren Ausführeinrichtung an das Betriebssystem, die Daten zu verwenden, vorzugsweise über den zweckgebundenen Kommunikationsweg geliefert.
Bei jeglichen der Ausführungsmodi 1 bis 4 ist das vertrauenswürdige Modul vorzugsweise wirksam, um die Anforderung an das Betriebssystem, die Daten zu verwenden, zu protokollieren. Die Sicherheit und Zuverlässigkeit eines Lizenzierens oder Messens wird durch ein sicheres Protokollieren einer Datenverwendung in dem vertrauenswürdigen Modul verstärkt. Ein Protokollieren einer lizenzierungsbezogenen Aktivität wird in der manipulationssicheren Komponente durchgeführt und auf sichere Weise in derselben festgehalten. Es gibt die Option, dies in einer Anzahl unterschiedlicher Stufen während des Lizenzierens durchzuführen. Das üblich ste wäre in der Stufe, in der die Daten durch die sichere Ausführeinrichtung oder die Software-Ausführeinrichtung betrieben werden dürften. Ein weiterer üblicher Punkt wäre in der Stufe, in der die sichere Ladeeinrichtung ihre Integritätsprüfungen der zu installierenden Daten erfolgreich abgeschlossen und diese Daten erfolgreich in der Client-Maschine installiert hat. Da die sichere Ausführeinrichtung, die Software-Ausführeinrichtung und die sichere Ladeeinrichtung durch Integritätsprüfungen geschützt sind, ist ein gewisser Schutz vor Hackern gegeben, die versuchen, den Protokollierungsvorgang zu umgehen oder zu editieren. Derartige Protokolle würden sowohl sichere Überprüfungsinformationen als auch die Möglichkeit flexibler Lizenzierungs- und Zahlungsmodelle wie beispielsweise Bezahlen-Pro-Nutzung, Ausleihen, zeitabhängige Gebühren usw. liefern. Derartige Überprüfungsprotokolle würden die Basis für Nutzungsberichte und Informationen bilden, die für dritte Parteien wie beispielsweise die IT-Abteilung des Maschinenbenutzers oder Wirtschaftsprüfer der Unternehmen, zugänglich sind. Sie hätten auch einen kommerziellen Wert, beispielsweise für Werbezwecke oder in Bezug auf Rating-Rückmeldungen.
In dem Fall, in dem die Plattform ein weiteres, entfernbares vertrauenswürdiges Modul (beispielsweise eine Smartcard) umfaßt, wie oben erwähnt wurde, umfaßt sie vorzugsweise eine Benutzeridentität und ist auf ein Lizenzprüfen der sicheren Ausführeinrichtung oder der Software-Ausführeinrichtung hin wirksam, um die Lizenzprüfung bezüglich der Benutzeridentität durchzuführen.
Wenn der Benutzer bittet, eine Software zu betreiben oder auf geschützte Daten zuzugreifen, kann die sichere Ausführeinrichtung die Lizenzprüfung beispielsweise durch folgendes durchführen:

(a) Prüfen hinsichtlich eines Geheimnisses, das einer Software- oder Datenreferenz in einer Vorrichtung entspricht, oder
(b) Verwenden eines Entriegelungsschlüssels, um Daten zu entschlüsseln, und Ermöglichen, daß sie ausgeführt werden (es gibt diverse Optionen für eine unterschiedliche Funktionalität des Entriegelungsschlüssels, einschließlich eines teilweisen Entriegelns des Codes), oder
(c) Prüfen bezüglich Lizenzierungsrechten in einer Datenbank, entsprechend einer Datenreferenz und einer Vorrichtungsidentität, oder
(d) Wiedergewinnen eines Schlüssels von einer Datenbank, entsprechend einer Datenreferenz und einer Vorrichtungsidentität, und Verwenden desselben, um die Daten zu entriegeln.

Wenn der Benutzer versucht, eine Anwendung zu betreiben, kann es eingerichtet werden, daß die sichere Ausführeinrichtung die Gesamtsteuerung übernimmt und daß sie Informationen von der Software-Ausführeinrichtung, falls eine solche vorhanden ist, die den Daten zugeordnet sind, wiedergewinnt, um herauszufinden, welche spezifische Prüfung durch den Entwickler bevorzugt ist. Falls eine Prüfungsart festgelegt ist, führt die sichere Ausführeinrichtung dieselbe aus; andernfalls verwendet sie eine standardmäßige Prüfung, wie nachstehend beschrieben wird. Falls die Prüfung erfolgreich ist, führt die sichere Ausführeinrichtung die Daten aus. Falls die Prüfung negativ ausfällt, verhindert die sichere Ausführeinrichtung, daß die Daten ausgeführt werden.
Falls die Software-Ausführeinrichtung kein Lizenzierungsverfahren festlegt, oder falls keine Software-Ausführeinrichtung zu der Anwendung gehört, kann die sichere Ausführeinrichtung ein Standardprotokoll verwenden, das für die bestimmte Maschine definiert wurde. Dies wird durch den Administrator der Maschine mit Blick auf die Umgebung der Maschine eingestellt worden sein; falls die Maschine beispielsweise lediglich von einer Person genutzt wird, wäre ein Lizenzierungsmodell, das dem internen vertrauenswürdigen Modul entspricht, wahrscheinlich das geeignetste. Es ist nicht möglich, die sichere Ausführeinrichtung und somit die Lizenzierungsprüfungen zu umgehen, da der Code der sicheren Ausführeinrichtung als Bestandteil der Boot-Integritätsprozedur in die Plattformintegritätsprüfung aufgenommen sein wird.
Unterschiedliche Lizenzierungsmodelle verwenden die sichere Ausführeinrichtung und die Software-Ausführeinrichtung auf unterschiedliche Art und Weise. Wie aus dem Obigen hervorgeht, ist es möglich, sie in Kombination zu verwenden, oder es ist möglich, daß eine der beiden die Lizenzierungsprüfungen durchführt. Es gibt zwei bevorzugte Hauptoptionen:

(1) Die erste Option besteht darin, verschiedene Software-Ausführeinrichtungen aufzuweisen, die an jede Dateneinheit angegliedert sind und die eine Lizenzierungsprüfung in der sicheren Ausführeinrichtung für diese bestimmten Dateneinheiten regeln. Bei manchen der Beispiele in dem nächsten Absatz kommunizieren die Software-Ausführeinrichtungen auf diese Weise direkt mit dem Betriebssystem.
(2) Ein alternativer Lösungsansatz besteht darin, mehr Gewicht auf die sichere Ausführeinrichtung zu legen, indem der generische Code in der Plattform, die die Prüfungen durchführt, aufgebaut wird und indem man die sichere Ausführeinrichtung als Brücke zwischen dem OS und jeglichen Software-Ausführeinrichtungen agieren läßt. Diese Alternative vermeidet, daß die Last des Protokollschreibens dem Entwickler auferlegt wird, ermöglicht dem Entwickler, Lizenzierungsauswahlen auf sehr leichte Weise zu spezifizieren, und verwendet ein Integritätsprüfen eines Lizenzprüfcodes, wenn die Plattformintegritätsprüfung durchgeführt wird.

Die einer Dateneinheit zugeordnete Software-Ausführeinrichtung kann jegliche bestimmte Informationen umfassen, in bezug auf die eine Prüfung durchgeführt werden soll (und die während des Registrierungsvorganges erhalten wurden), zusammen mit Informationen, die die sichere Ausführeinrichtung in der Computerplattform von dem zu verwendenden Lizenzierungsverfahren, der bestimmten vertrauenswürdigen Vorrichtung, auf der die Prüfung durchgeführt werden soll, und einer Bezugnahme auf die Daten, die geschützt werden sollen, in Kenntnis setzen. Beispielsweise geben licensing_method (secret, sc, k, w) (Lizenzierungs_Verfahren (Geheimnis, sc, k, w) und licensing_method (secret, tc, k, w) (Lizenzierungs_Verfahren (Geheimnis, tc, k, w) an, daß es der mit w bezeichneten Software nur dann ermöglicht werden sollte, auf einer Maschine zu laufen, falls man feststellt, daß das Geheimnis k in der vorliegenden Smartcard bzw. internen vertrauenswürdigen Komponente der Maschine aufbewahrt wird.
An Daten sind unterschiedliche Software-Ausführeinrichtungen angegliedert, wobei Software-Ausführeinrichtungen angeben, welche Art von Lizenzierungsmodell verwendet werden soll. Die sichere Ausführeinrichtung führt gemäß diesem Lizenzierungsmodell zur Laufzeit eine Prüfung durch und erlaubt es der Software w nicht, abzulaufen, es sei denn, die Prüfung ist erfolgreich. Mittels dieser Einrichtung spezifiziert eine Kommunikation von der Verrechnungsinstanz zu dem vertrauenswürdigen Modul, welches Lizenzierungsprotokoll die Verrechnungsinstanz verwenden möchte.
Seitens der sicheren Ausführeinrichtung können verschiedene spezifische Protokolle verwendet werden. Bei einem ersten Protokoll, beispielsweise:

– prüft die sichere Ausführeinrichtung den ID-Eintrag des vertrauenswürdigen Moduls oder den ID-Eintrag der Smartcard;
– lädt die sichere Ausführeinrichtung optional Datenbankeinträge in ein in dem vertrauenswürdigen Modul gespeichertes Profil herunter;
– führt die sichere Ausführeinrichtung in einer externen Datenbank oder einem in dem vertrauenswürdigen Modul gespeicherten Profil eine Prüfung im Vergleich zu einer Datenreferenz und dem ID-Eintrag des vertrauenswürdigen Moduls (oder dem ID-Eintrag der Smartcard) bezüglich eines Entriegelungsschlüssels für die Daten durch;
– gewinnt die sichere Ausführeinrichtung diesen Schlüssel wieder und entschlüsselt die zugeordneten Daten, so daß sie durch das Betriebssystem ausgeführt werden können;
– speichert die sichere Ausführeinrichtung den Entriegelungsschlüssel optional in dem vertrauenswürdigen Modul, zusammen mit der Datenreferenz;
– werden die Daten unter Verwendung des entsprechenden Schlüssels über eine Verschlüsselung oder eine teilweise Verschlüsselung geschützt;
– gibt es verschiedene Optionen für eine unterschiedliche Funktionalität des Entriegelungsschlüssels; und
– wird der Datenbankeintrag, der der Vertrauenswürdiges-Modul-ID entspricht, als Gegenleistung für die Zahlung mit diesem Schlüssel aktualisiert.

Bei einem zweiten Protokoll:

– lädt die sichere Ausführeinrichtung Datenbankeinträge optional in ein in dem vertrauenswürdigen Modul gespeichertes Profil herunter;
– führt die sichere Ausführeinrichtung in einer externen Datenbank oder einem in dem vertrauenswürdigen Modul gespeicherten Profil eine Prüfung in bezug auf Lizenzierungsrechte durch, entsprechend einer Datenreferenz und dem ID-Eintrag des vertrauenswürdigen Moduls (oder dem ID-Eintrag der Smartcard);
– autorisiert die sichere Ausführeinrichtung das Betriebssystem nur dann dazu, Daten auszuführen, wenn entsprechende Lizenzierungsrechte vorliegen; und
– wird der Datenbankeintrag, der der Vertrauenswürdiges-Modul-ID oder der ID der Smartcard entspricht, als Gegenleistung für eine Zahlung mit einer entsprechenden Erlaubnis aktualisiert.

Bei einem dritten Protokoll:

– führt die sichere Ausführeinrichtung eine Prüfung bezüglich eines Geheimnisses durch, das einer Software- oder Datenreferenz in einem vertrauenswürdigen Modul (einschließlich einer Smartcard) entspricht;
– wird das Geheimnis, bezüglich dessen eine Prüfung durchgeführt werden soll, durch die Software-Ausführeinrichtung spezifiziert, die den Daten, deren Lizenz geprüft wird, zugeordnet ist; und
– autorisiert die sichere Ausführeinrichtung das Betriebssystem nur dann dazu, die zugeordnete(n) Software oder Daten auszuführen, wenn das Geheimnis in dem vertrauenswürdigen Modul vorliegt.

Bei einem vierten Protokoll:

– verwendet die sichere Ausführeinrichtung einen Entriegelungsschlüssel, der manchen Daten, die in dem ver trauenswürdigen Modul oder der Smartcard gespeichert sind, zugeordnet ist, um die Daten zu entschlüsseln, so daß sie durch das Betriebssystem ausgeführt werden können; und
– gibt es verschiedene Optionen einer unterschiedlichen Funktionalität des Entriegelungsschlüssels, einschließlich eines teilweisen Entriegelns des Codes.

Bei einem fünften Protokoll:

– verwendet die sichere Ausführeinrichtung einen Schlüssel, der manchen Daten, die in dem vertrauenswürdigen Modul oder der Smartcard gespeichert sind oder ansonsten von dem Endbenutzer über die Tastatur eingegeben wurden, der Vertrauenswürdiges-Modul-ID oder der Smartcard-ID zugeordnet ist, und einen vordefinierten Algorithmus, um einen Entschlüsselungsschlüssel zu berechnen;
– verwendet die sichere Ausführeinrichtung den Entschlüsselungsschlüssel, um die Daten zu entschlüsseln, so daß sie durch das Betriebssystem ausgeführt werden können;
– gibt es verschiedene Optionen einer unterschiedlichen Funktionalität des Entriegelungsschlüssels, einschließlich eines teilweisen Entriegelns des Codes.

Bei einem sechsten Protokoll:

– erlaubt die sichere Ausführeinrichtung eine Verwendung von variablen Lizenzen für eine Benutzergruppe;
– führt die sichere Ausführeinrichtung in einer Datenbank eine Prüfung im Vergleich zu der Vertrauenswürdiges-Modul-ID oder dem ID-Eintrag der Smartcard bezüglich eines Lizenzschlüssels für die Daten durch;
– gewinnt die sichere Ausführeinrichtung einen Lizenzschlüssel (falls einer verfügbar ist) wieder, um diese bestimmte Ausführung zu erlauben; und
– gibt die sichere Ausführeinrichtung den Lizenzschlüssel an den Pool zurück, wenn die Datenausführung geschlossen ist.

Bei einem siebten Protokoll:

– führt die sichere Ausführeinrichtung eine Kombination jeglicher der ersten sechs Protokolle durch, derart, daß für verschiedene Datenentitäten unterschiedliche Verfahren eines Lizenzprüfens durchgeführt werden können;
– kann die Wahl des Protokolls durch die sichere Ausführeinrichtung selbst bestimmt werden;
– kann ein Standard- oder ein dominierendes Protokoll durch einen Administrator definiert werden; und
– wird das beim Durchführen einer Lizenzprüfung in Bezug auf bestimmte Daten zu verwendende Protokoll durch eine beliebige Software-Ausführeinrichtung, die diesen Daten zugeordnet ist, bestimmt.

Manche Lizenzierungsmodelle, die später in diesem Dokument beschrieben werden, verhindern nicht ein Kopieren von Daten, sondern hemmen lediglich eine nicht-autorisierte Verwendung von Daten und sichern das Protokollieren einer Verwendung an Maschinen, die die manipulationssichere Vorrichtung als Teil der Plattform aufweisen. Der gewünschte Datenschutzumfang hängt von dem Geschäftsmodell ab. Daten können über traditionelle und andere nicht-sichere Kanäle gesandt werden. Es ist jedoch am wichtigsten, daß der Lizenzschlüsseltransfer sicher ist.
Gemäß einem zweiten Aspekt der vorliegenden Erfindung ist ein Verfahren zum Transferieren einer Lizenz (oder eines Schlüssels hierfür) von einer ersten an eine zweite Computerplattform vorgesehen, die jeweils gemäß dem ersten Aspekt der Erfindung sind, wobei das Verfahren folgende Schritte aufweist: Einrichten einer sicheren Kommunikation zwischen den vertrauenswürdigen Modulen; Senden der Lizenz oder des Schlüssels für dieselbe von dem ersten vertrauenswürdigen Modul an das zweite vertrauenswürdige Modul unter Verwendung der sicheren Kommunikation; und Löschen der Lizenz oder des Schlüssels für dieselbe aus dem ersten vertrauenswürdigen Modul.
Es gibt viele Situationen, in denen ein Kunde vielleicht eine Lizenz an eine andere Person oder eine andere Maschine transferieren möchte. Wenn beispielsweise ein neuer PC gekauft wurde, wenn Software erweitert oder ersetzt wird, oder wenn der Kunde eine Anwendung auf einem tragbaren Computer statt auf einem Desktop-Computer durchführen möchte. Ein Bewegen eines Hardware-Dongles, der für jede Anwendung spezifisch ist, ist die einfache Lösung, und es gibt die analoge Lösung einer Verwendung spezifischer Smartcards. Jedoch weisen alle Systeme, die einen generischen Dongle bereitstellen und somit in den meisten Situationen für Endbenutzer praktischer sind, ein großes Problem der Schlüsselverwaltung in dieser Situation auf. WaveNet von Wave System und Lizenzverwaltungssysteme („LMFs – licence management Systems") sind keine Ausnahme. Nur-Software-Verfahren erfordern einen Installations-/Deinstallationsvorgang oder müssen ansonsten darauf vertrauen, daß der Endbenutzer lediglich die Anzahl von Lizenzen verwendet, die auf legitime Weise gekauft wurden, wenn ein zweites Paßwort für dieselbe Lizenz ausgegeben ist.
Die Optionen für einen Lizenztransfer unter Verwendung vertrauenswürdiger Module hängen von dem betreffenden Lizenzierungsaspekt ab. Allgemein lauten diese wie folgt:
Für ein Lizenzieren unter Verwendung einer Datenbankprüfung sollten die Datenbankeinträge, die beiden IDs von vertrauenswürdigen Maschinen-Modul-Ids entsprechen (falls die Lizenz auf eine andere Maschine geändert ist) oder beiden IDs der Smartcard (falls die Lizenz auf eine andere Person geändert ist) entsprechen, geändert werden.
Für ein Lizenzieren, das eine Prüfung eines auf ein vertrauenswürdiges Modul bezogenen Fingerabdrucks oder die Verwendung eines auf das vertrauenswürdige Modul zugeschnittenen Codes beinhaltet, sollte die neue Vorrichtung (d.h. eine Smartcard, falls eine Lizenz auf eine andere Person geändert wird; das interne vertrauenswürdige Modul, falls eine Lizenz auf eine andere Maschine geändert wird) bei dem Verkäufer neu registriert werden, und ein anderer Schlüssel oder eine andere zugeschnittene Software, der bzw. die auf der Basis der neuen ID der Vorrichtung ausgegeben ist, sollte erhalten werden.
Bei Verfahren, die eine Verschlüsselung und einen Entriegelungsschlüssel beinhalten, sollte die entsprechende Smartcard (und jegliche Pinnummern) dem neuen Lizenznehmer gegeben werden, falls eine Smartcard pro Anwendung vorliegt. Andernfalls können der Entriegelungsschlüssel und die Daten automatisch zwischen vertrauenswürdigen Modulen transferiert werden, ohne daß der Verkäufer über einen Empfang eines Berichts des Transfers (wie bei dem achten Verfahren beschrieben ist) hinaus involviert werden muß. Dies beinhaltet ein Integritätsprüfen von zugeordneten Daten, ein Kopieren eines Lizenzschlüssels von einem vertrauenswürdigen Modul zu einem anderen und ein Deinstallieren der Lizenz von dem ursprünglichen vertrauenswürdigen Modul.
Die Stufen beim Transferieren einer Lizenz (d.h. eines Entriegelungsschlüssels L) für Daten S von TC1 in einer Client-Maschine M1 an TC2 in einer Maschine M2 lauten beispielsweise wie folgt:
A. Ein Code für einen sicheren Schlüsseltransfer („SKT-Code") wird als Erweiterung der BIS-Prozedur integritätsgeprüft. Der Lizenztransfercode wird hash-codiert und mit dem privaten Schlüssel des Herstellers signiert. Auf ein Booten/eine Installation der Plattform hin wird das Paket durch ein Hash-Codieren und einen Vergleich mit der entschlüsselten Signatur, um die Integrität zu prüfen, verifiziert, wobei ein Öffentlicher-Schlüssel-Zertifikat, das durch den Hersteller in dem vertrauenswürdigen Modul installiert ist, verwendet wird. Der Lizenztransfercode wird nicht geladen, falls die digitale Signatur nicht mit der Erwarteten übereinstimmt, und die Plattformintegritätsprüfung fällt negativ aus.
B. Initialisierung. Der Inhaltsanbieter weist bereits den öffentlichen Schlüssel von TC1 über den ursprünglichen Registrierungs- und Dateninstallationsprozeß auf; falls nicht, wird dieser an ihn gesandt.

1. Falls der Eigentümer von TC1 die Lizenz an TC2 transferieren möchte, erfolgt ein Anruf von dem OS der Maschine M1 an SKT in M1, um die Lizenz für Daten S an TC2 zu transferieren.
2. SKT in M1 erzeugt eine Zufallszahl R und sendet an M2 eine Nachricht, in der darum gebeten wird, daß die Lizenz, die eine Bezugnahme auf die Daten S enthält, zusammen mit dem Öffentlicher-Schlüssel-Zertifikat von TC1 transferiert wird.
3. Falls M2 eine Autorisierung von einer entsprechenden Quelle erhält, bejaht SKT in M2, einschließlich R, des Öffentlicher-Schlüssel-Zertifikats von T2, einer Bezugnahme auf S und einer neuen Einmalverfügung T, die er erzeugt hat.
4. SKT in M1 sendet dann das Öffentlicher-Schlüssel-Zertifikat des Inhaltsanbieters von S zusammen mit T an M2.

Diese Kommunikationen werden an eine hash-codierte Version der Kommunikation angehängt, die durch den privaten Schlüssel des vertrauenswürdigen Moduls in der Maschine des Senders signiert ist, so daß der Empfänger SKT die Integrität der Nachricht prüfen kann. Falls die Integritätsprüfung negativ ausfällt, werden von jedem SKT an das OS in ihren Maschinen Nachrichten gesandt, und das Protokoll endet.
C. Programmhochladung. Falls die obige Authentifizierung erfolgreich ist, hash-codiert TC1 die Daten S (optional eine Version, die bereits durch den Inhaltsanbieter signiert ist) und signiert sie mit dem privaten Schlüssel von TC1 (beispielsweise unter Verwendung von Authenticode von Microsoft). Dann lädt TC1 diese Signatur zusammen mit den Daten in TC2 hoch. Optional sind die Daten verschlüsselt.
D. Codeverifizierung. Die sichere Ladeeinrichtung in TC2 verifiziert die Signaturen der Daten S: sie prüft die Signatur unter Verwendung des öffentlichen Schlüssels von TC1, wodurch sie den Hash-Wert der Nachricht wiedergewinnt; als nächstes berechnet sie den Hash-Wert von S, um zu prüfen, daß er derselbe ist wie der Hash-Wert der entschlüsselten Nachricht. Falls diese Validierung erfolgreich ist, installiert die sichere Ladeeinrichtung das Programm in die Maschine, die TC2 entspricht. Falls dies nicht der Fall ist, erzeugt sie eine Fehlermeldung an den SKT, der ein weiteres Durchleiten des Lizenztransferprotokolls blockiert.
E. Transferschlüssel. Der SKT in M1 erzeugt unter Verwendung eines Zufallszahlengenerators einen symmetrischen Schlüssel und verwendet ihn, um eine Nachricht, die den Entriegelungsschlüssel transportiert, zu verschlüsseln. Der SKT in M1 sendet diese Nachricht zusammen mit dem symmetri schen Schlüssel, der mit dem öffentlichen Schlüssel von TC2 verschlüsselt ist, und ferner einen Hash-Wert all dieser Informationen, der mit dem privaten Schlüssel von TC1 signiert ist, an den SKT in M2. Lediglich TC2 weist den privaten RSA-Schlüssel auf, um den symmetrischen Schlüssel zu entschlüsseln, was eine Entschlüsselung des Entriegelungsschlüssels ermöglicht.
F. Nachrichtenverifizierung. Der SKT in M2 prüft die Signatur unter Verwendung des öffentlichen Schlüssels von TC1 und entschlüsselt die Nachricht unter Verwendung des symmetrischen Schlüssels, der durch eine Entschlüsselung unter Verwendung des privaten Schlüssels von TC2 erhalten wurde, wodurch er den Entriegelungsschlüssel erhält. Falls die Signatur korrekt ist, wird der Schlüssel in der vertrauenswürdigen Komponente gespeichert und den Daten S zugeordnet. Falls die Signatur nicht korrekt ist, wird eine Fehlernachricht an den SKT in M1 gesandt, und das Protokoll endet.
G. Schlüssel von TC1 gelöscht, und Inhaltsanbieter benachrichtigt. Der SKT in M1 löscht den Entriegelungsschlüssel aus TC1 und erstellt ein Protokoll dessen in TC1. Der SKT in M1 sendet eine Nachricht an den Inhaltsanbieter, die unter Verwendung des privaten Schlüssels von TC1 signiert ist und den Inhaltsanbieter informiert, daß die Lizenz für den Code S an M2 transferiert wurde. Optional sendet SKT in M1 oder in M2 eine Nachricht an den Datenverkäufer, die Einzelheiten darüber angibt, wie der Eigentümer von M2 zum Zweck einer Registrierung kontaktiert werden kann.
Es besteht eine Option, daß die vertrauenswürdige Komponente und die Software-Ausführeinrichtung als neuer Bestandteil des Betriebssystems arbeitet bzw. arbeiten und eine Brücke zwischen dem Betriebssystem und Anwendungen bildet bzw. bilden, indem eine Umgebung für bestimmte Funktionen bereitgestellt wird. Beispielsweise können API-Anrufe zu dem vertrauenswürdigen Modul durchgeführt werden, beispielsweise „sichern" und „wiederherstellen". „Sichern" läßt Daten durch das vertrauenswürdige Modul passieren, was die Daten in dem vertrauenswürdigen Modul verschlüsselt und sie entweder in dem vertrauenswürdigen Modul oder auf der Festplatte speichert. Es ist nicht möglich, ohne die Erlaubnis des vertrauenswürdigen Moduls auf diese Daten zuzugreifen. Es gibt eine zusätzliche Option, manche Transformationen in dem vertrauenswürdigen Modul unter Verwendung derartiger Daten durchzuführen, und es gibt die Option, daß die Software API-Anrufe verwendet, um Informationen von dem vertrauenswürdigen Modul anzufordern und eine exportierte Antwort zu bekommen. Zusammenfassend gesagt können API-Anrufe von der Software-Ausführeinrichtung oder dem Anwendungscode zu dem vertrauenswürdigen Modul verwendet werden, um das Vorhandensein des vertrauenswürdigen Moduls oder eines privaten Anwendungsschlüssels, der in dem vertrauenswürdigen Modul gespeichert ist (analog zu existierenden Dongle-Verfahren) zu prüfen, und außerdem um das vertrauenswürdige Modul zum Bereitstellen einer Umgebung für bestimmte Funktionen oder eine Datenspeicherung zu verwenden.
Genauer gesagt können API-Anrufe zu dem Anwendungscode oder der Software-Ausführeinrichtung hinzugefügt werden und verwendet werden, um das OS, das vertrauenswürdige Modul oder die sichere Ausführeinrichtung über die Client-Bibliothek abzufragen. Beispielsweise können API-Anrufe zu dem Anwendungscode oder der Software-Ausführeinrichtung hinzugefügt und verwendet werden, um das vertrauenswürdige Modul oder die sichere Ausführeinrichtung über die Client-Bibliothek abzufragen, um eine Prüfung bezüglich des Vorhandenseins eines privaten Anwendungsschlüssels oder eines anderen Geheimnisses in dem vertrauenswürdigen Modul oder der Smartcard durchzuführen, oder um eine Prüfung bezüglich der Identität und des Vorhandenseins des vertrauenswürdigen Moduls oder der Smartcard durchzuführen.
Bei einem bestimmten Modell, das nachstehend ausführlicher beschrieben wird, wird ein Lizenzierungsmodell verwendet, bei dem ein Eintrag in eine lizenzierungsbezogene Datenbank, der der Vertrauenswürdiges-Modul-ID entspricht, aktualisiert wird, und bei dem die sichere Ausführeinrichtung erst dann erlaubt, daß Daten ablaufen, wenn Erlaubnisse auf dieser Datenbank geprüft wurden. In diesem Fall ruft die einer Anwendung zugeordnete Software-Ausführeinrichtung die sichere Ausführeinrichtung an (üblicherweise in dem vertrauenswürdigen Modul), prüft die sichere Ausführeinrichtung die Lizenzierungsrechte und, falls diese Prüfung erfolgreich ist, leitet die sichere Ausführeinrichtung den Anruf an das Betriebssystem („OS") weiter, damit die Anwendung auf die normale Weise durchgeführt werden kann. Mit anderen Worten akzeptiert das OS Anrufe, Daten auszuführen, lediglich dann, wenn der Anruf von einem sicheren lizenzbezogenen Code, beispielsweise der sicheren Ausführeinrichtung oder der Software-Ausführeinrichtung, kommt.
Bei einem anderen bestimmten Modell, das später ausführlicher beschreiben wird, speichert das vertrauenswürdige Modul vorzugsweise eine Hardware und/oder Software, die verwendet wird, um die Erfindung zu implementieren, und das OS akzeptiert Anrufe, Daten auszuführen, falls der Anruf von dem vertrauenswürdigen Modul kommt. Insbesondere agiert das vertrauenswürdige Modul vorzugsweise als Brücke zwischen einer Anwendung und dem OS, und das OS ignoriert vorzugsweise alle Anforderungen, Anwendungen zu laden, mit Ausnahme derjenigen, die von dem vertrauenswürdigen Modul kommen.
Ein mögliches Lizenzierungsmodell wäre, daß die sichere Ausführeinrichtung in einer Datenbank eine Prüfung bezüglich des ID-Eintrags des vertrauenswürdigen Moduls für einen Entriegelungsschlüssel für die Daten durchführt. In diesem Fall werden die Daten unter Verwendung des entsprechenden Schlüssels über eine Verschlüsselung oder teilweise Verschlüsselung geschützt und können somit ohne Angst vor Piraterie frei verteilt werden. Nachdem die Zahlung erfolgte, wird der Datenbankeintrag, der der Vertrauenswürdiges-Modul-ID entspricht, mit diesem Schlüssel aktualisiert.
Wenn der Benutzer die Anwendung ablaufen lassen möchte, kann der Schlüssel wiedergewonnen werden, um zu erlauben, daß die Daten entriegelt werden. Der Schlüssel kann dann in einer manipulationssicheren Vorrichtung gespeichert werden, so daß das Nachschlagen in der Datenbank nur einmal stattfinden muß. Jedoch wäre es bei Lizenzierungsmodellen, bei denen variable Lizenzen gewünscht sind, angemessener, derartige Schlüssel zentral zu speichern und einen Zugriff lediglich bei jeder Ausführung zu erlauben, so daß die Lizenz dann gegenüber der entsprechenden Gruppe zum Zweck einer Benutzung durch einen anderen Benutzer wiederhergestellt werden kann. Somit wird ein Modell für einen Lizenz-„Austausch" geschaffen.
Dementsprechend erweitert sich die vorliegende Erfindung auf den Fall, bei dem zwischen der sicheren Ausführeinrichtung, der Software-Ausführeinrichtung und dem vertrauenswürdigen Modul eine optionale Interaktion stattfindet, um variable Lizenzen für eine Gruppe von Benutzern darüber zu verwenden, daß die sichere Ausführeinrichtung oder die Software-Ausführeinrichtung eine Prüfung in einer Datenbank bezüglich des ID-Eintrags des vertrauenswürdigen Moduls bezüglich eines Lizenzschlüssels für die Software einleiten, einen Lizenzschlüssel (falls einer zur Verfügung steht) wiedergewinnen, um diese bestimmte Ausführung zu erlauben, und den Lizenzschlüssel an den Pool zurückgeben, wenn die Anwendung geschlossen wird.
Um flexiblere Situationen wie beispielsweise Hot-Desking, wenn mehrere Benutzer generische Anschlüsse verwenden, zu berücksichtigen, kann eine Kombination mehrerer vertrauenswürdiger Vorrichtungen verwendet werden. Insbesondere schafft eine Kombination aus stationären manipulationssicheren Komponenten und tragbaren manipulationssicheren Komponenten eine große Flexibilität beim Lizenzieren. Natürlich würde die Smartcard eines privaten Benutzers in Kombination mit einer internen manipulationssicheren Vorrichtung in dem Computer verwendet. Bei dieser Art von Lizenzie rungsmodell würde die Software-Ausführeinrichtung oder sichere Ausführeinrichtung die Daten nur dann ablaufen lassen, wenn eine bestimmte Smartcard vorliegt (oder eine einer ausgewählten Gruppe von Smartcards vorliegt).
Das interne vertrauenswürdige Modul enthält eine Vertrauenswürdige-Maschine-Identität, und das tragbare vertrauenswürdige Modul (in diesem Fall eine Smartcard) enthält eine für den Benutzer spezifische Identität (die unter Verwendung einer integrierten biometrischen Vorrichtung authentifiziert werden könnte). In einer derartigen Situation könnten viele verschiedene Lizenzierungsarten eingesetzt werden (ein Beispiel wird in dem folgenden Absatz genannt), und diese sind analog zu den Optionen, die in dem Absatz „Bevorzugtes Ausführungsbeispiel" präsentiert werden. Die Unterschiede bestehen darin, daß, gemäß dem bestimmten implementierten Modell:

– die Smartcard-Identität an der Lizenzierungsprüfung, die durch die sichere Ausführeinrichtung oder die Software-Ausführeinrichtung durchgeführt wird, beteiligt ist, und nicht die interne Maschinenidentität. Deshalb wird beispielsweise eine Prüfung der Benutzeridentität im Vergleich zu dem Profil oder Verzeichnis und nicht der Maschinenidentität durchgeführt. Falls Entriegelungsschlüssel auf der Smartcard gespeichert sind, bewirkt das Vorliegen der Smartcard-ID in dem vertrauenswürdigen Modul, daß die sichere Ausführeinrichtung, wenn sie den Entriegelungsschlüssel benötigt, (a) den Entriegelungsschlüssel in einer verschlüsselten Form zu dem vertrauenswürdigen Modul kopiert, indem die Smartcard, die ihn verschlüsselt, den öffentlichen Schlüssel des vertrauenswürdigen Moduls verwendet, oder (b) den Entriegelungsschlüssel direkt von der Smartcard verwendet.
– Es liegt eine Authentifizierung zwischen dem internen vertrauenswürdigen Modul und der Smartcard vor. Eine Authentifizierung zwischen der Smartcard und dem vertrauenswürdigen Modul wird in der Stufe, in der die Smartcard eingeführt wird, durchgeführt, und die Aktuelle-Smartcard-ID wird vorübergehend in dem vertrauenswürdigen Modul gespeichert, um auf dieselbe Weise für die Lizenzierungsprüfung verwendet zu werden, wie die Vertrauenswürdiges-Modul-ID bei den nachstehend in diesem Dokument beschriebenen Lizenzierungsmodellen verwendet worden wäre (siehe Beispiele A, B und F, die später beschrieben werden). Wenn die Smartcard entnommen wird oder (bei einer einzigen Anmeldung) wenn sich der Benutzer abmeldet, wird dieser vorübergehende Smartcard-ID-Wert in dem vertrauenswürdigen Modul auf einen Nullabgleichswert zurückgesetzt.

Für verschiedene Daten in derselben Maschine könnte sowohl ein benutzerbasiertes Lizenzieren als auch ein maschinenbasiertes Lizenzieren verwendet werden. Dies könnte erfolgen, indem (a) Verzeichniseinträge im Vergleich mit der Smartcard-ID und nicht der Maschinen-ID geprüft werden, falls der Smartcard-ID-Wert in dem vertrauenswürdigen Modul kein Nullabgleich ist (und im Vergleich zu der Maschinen-ID, falls diese Prüfung negativ ausfällt) oder (b) auf einen Entriegelungsschlüssel in der Smartcard hin geprüft wird, falls eine Smartcard derzeit in die Lesevorrichtung eingeführt ist – das heißt, entweder anfordern, daß derselbe zu dem vertrauenswürdigen Modul kopiert wird, oder denselben direkt verwenden.
Dementsprechend erweitert sich die Erfindung auf den Fall, bei dem eine optionale Verwendung einer Kombination eines vertrauenswürdigen Interne-Maschine-Moduls und eines vertrauenswürdigen tragbaren Moduls (und der sicheren Ausführeinrichtung und der Software-Ausführeinrichtung) vorliegt, um eine Lizenzprüfung auf der Basis der Benutzeridentität, die dem vertrauenswürdigen Modul der tragbaren Maschine zugeordnet ist, durchzuführen.
Ein Lizenzierungssystem der vorliegenden Erfindung, das nachstehend ausführlicher beschrieben wird, weist die folgenden Merkmale auf:

– Die Computerplattform ist bei einer dritten Partei C registriert. Optional wird C die Vertrauenswürdiges-Modul-ID oder die Smartcard-ID gegeben;
– eine Authentifizierung zwischen dem vertrauenswürdigen Modul und C und ein Austausch von Öffentlicher-Schlüssel-Zertifikaten findet vor einem oder zur selben Zeit wie ein Austausch von DES-Sitzungsschlüsseln zum Zweck der Vertraulichkeit der Nachrichten statt;
– die sichere Ladeeinrichtung führt eine Integritätsprüfung der Daten durch und installiert die Daten nur dann, falls diese Prüfung erfolgreich ist;
– die Daten werden unter Verwendung eines der oben beschriebenen Protokolle ausgeführt; und
– jeder Entwickler kann entweder einen generischen oder einen spezifischen Inhaltsschutz verwenden.

Bei einer Form:

– werden Daten, die unter Verwendung eines Schlüssels K verschlüsselt werden, unter dem Privatcodesignierungsschlüssel von C signiert und durch C an das vertrauenswürdige Modul gesandt;
– wird der Entriegelungsschlüssel, der K entspricht, unter Verwendung des öffentlichen Schlüssels des vertrauenswürdigen Moduls durch C verschlüsselt, unter Verwendung des Privatcodesignierungsschlüssels von C signiert und an die Computerplattform gesandt; und
– entschlüsselt der Schlüsseltransfercode den Entriegelungsschlüssel, prüft die Integrität und die Signatur, und wird dieser Schlüssel anschließend in dem vertrauenswürdigen Modul, das den relevanten Daten zugeordnet ist, gespeichert.

Bei einer anderen Form:

– werden Daten, die unter Verwendung eines Schlüssels K verschlüsselt werden, unter dem Privatcodesignierungsschlüssel von C signiert und durch C an das vertrauenswürdige Modul gesandt;
– wird ein Entriegelungsschlüssel von C an den Endbenutzer der Computerplattform oder an die Computerplattform transferiert;
– berechnet der Schlüsseltransfercode den Entschlüsselungsschlüssel, der K entspricht, aus dem Entriegelungsschlüssel, der Vertrauenswürdiges-Modul-ID oder der Smartcard-ID und einem vorab gespeicherten Algorithmus;
– wird die vorhergehende Stufe optional durch die den Daten zugeordnete sichere Ausführeinrichtung oder Software-Ausführeinrichtung durchgeführt; und
– wird dieser Entschlüsselungsschlüssel anschließend in dem bzw. einer den relevanten Daten zugeordneten vertrauenswürdigen Modul oder Smartcard gespeichert.

Bei einer weiteren Form:

– werden Daten, die unter Verwendung eines Schlüssels K und einer jeglichen zugeordneten Software-Ausführeinrichtung verschlüsselt werden, unter dem Privatcodesignierungsschlüssel von C signiert und durch C an das vertrauenswürdige Modul gesandt; und
– wird der Entriegelungsschlüssel, der K entspricht, in den Datenbankeintrag, der der Vertrauenswürdiges-Modul-ID oder der Smartcard-ID entspricht, eingeführt.

Bei einer weiteren Form:

– werden Daten und eine beliebige zugeordnete Software-Ausführeinrichtung unter dem Privatcodesignierungsschlüssel von C signiert und durch C an das vertrauenswürdige Modul gesandt; und
– wird ein Eintrag, der einer Erlaubnis, die Daten auszuführen, entspricht, in den Datenbankeintrag eingeführt, der der Vertrauenswürdiges-Modul-ID oder der Smartcard-ID entspricht, oder umgekehrt.

Lediglich beispielhaft wird nun unter Bezugnahme auf die beiliegenden Zeichnungen ein spezifisches Ausführungsbeispiel der vorliegenden Erfindung beschrieben. Es zeigen:
1 ein Diagramm, das ein System veranschaulicht, das in der Lage ist, Ausführungsbeispiele der vorliegenden Erfindung zu implementieren;
2 ein Diagramm, das eine Hauptplatine veranschaulicht, die eine vertrauenswürdige Vorrichtung umfaßt, die angeordnet ist, um über eine Smartcard-Lesevorrichtung mit einer Smartcard und mit einer Gruppe von Modulen zu kommunizieren;
3 ein Diagramm, das die vertrauenswürdige Vorrichtung ausführlicher veranschaulicht;
4 ein Flußdiagramm, das die Schritte veranschaulicht, die an einem Gewinnen einer Integritätsmetrik der Rechenvorrichtung beteiligt sind;
5 ein Flußdiagramm, das die Schritte veranschaulicht, die an einem Einrichten von Kommunikationen zwischen einer vertrauenswürdigen Rechenplattform und einer entfernten Plattform beteiligt sind, einschließlich einer Verifizierung der Integrität derselben durch die vertrauenswürdige Plattform;
6 ein Diagramm, das die funktionstüchtigen Teile einer Benutzer-Smartcard zur Verwendung gemäß Ausführungsbeispielen der vorliegenden Erfindung veranschaulicht;
7 ein Flußdiagramm, das den Prozeß eines gegenseitigen Authentifizierens einer Smartcard und einer Host-Plattform veranschaulicht;
8 ein schematisches Blockdiagramm eines vertrauenswürdigen Moduls in dem System der 21;
9 bis 12 Teile des Systems der 21, um verschiedene in demselben verwendete Kommunikationsverfahren zu veranschaulichen;
13 das Format einer bei dem System der 21 verwendeten Protokolldateneinheit;
14 eine Modifikation des Systems der 21, die verwendet wird, um ein spezifisches Ausführungsbeispiel der vorliegenden Erfindung zu beschreiben;
15 ein Diagramm der logischen Komponenten eines vertrauenswürdigen Moduls in dem System der 14;
16 die Struktur einer geschützten Software von Daten in dem System der 14;
17 ein Flußdiagramm, das ein Installieren oder Hochrüsten von Software oder anderen Daten in dem System der 14 veranschaulicht;
18 ein Flußdiagramm, das die Verwendung geschützter Software oder Daten in dem System der 14 unter Verwendung eines Modells einer Lizenzprüfung veranschaulicht;
19 ein Flußdiagramm, das die Verwendung geschützter Software oder Daten in dem System der 14 unter Verwendung eines anderen Modells einer Lizenzprüfung veranschaulicht;
20 ein Flußdiagramm, das die Verwendung geschützter Software oder Daten in dem System der 14 unter Verwendung eines weiteren Modells einer Lizenzprüfung veranschaulicht; und
21 ein schematisches Blockdiagramm eines Host-Computersystems, das der Gegenstand einer weiteren Patentanmeldung ist (internationale Patentanmeldung Nr. PCT/GB00/00504, am 15. Februar 2000 eingereicht).
Bevor das Ausführungsbeispiel der vorliegenden Erfindung beschrieben wird, wird zunächst unter Bezugnahme auf 1 bis 7 die Rechenplattform beschrieben, die eine vertrauenswürdige Vorrichtung beinhaltet, die der Gegenstand der am 15. Februar 2000 eingereichten internationalen Patentanmeldung Nr. PCT/GB00/00528 ist. Eine Rechenplattform dieses allgemeinen Typs eignet sich besonders gut zur Verwendung bei Ausführungsbeispielen der vorliegenden Erfindung. Die Verwendung einer vertrauenswürdigen Token-Vorrichtung, die einen Benutzer der Computerplattform persönlich betrifft, ist ebenfalls beschrieben (da sie für bestimmte der unten beschriebenen Ausführungsbeispiele relevant ist) – bei be vorzugten Beispielen ist diese Token-Vorrichtung eine Smartcard.
Jene Anmeldung beschreibt die Integration in eine Rechenplattform einer physischen vertrauenswürdigen Vorrichtung oder eines physischen vertrauenswürdigen Moduls, deren bzw. dessen Funktion darin besteht, die Identität der Plattform an zuverlässig gemessene Daten zu knüpfen, die eine Integritätsmetrik der Plattform liefern, wodurch eine „vertrauenswürdige Plattform" geliefert wird. Die Identität und die Integritätsmetrik werden mit erwarteten Werten verglichen, die durch eine vertrauenswürdige Partei (TP) geliefert werden, die bereit ist, für die Vertrauenswürdigkeit der Plattform zu bürgen. Falls eine Übereinstimmung vorliegt, folgt hieraus, daß zumindest ein Teil der Plattform ordnungsgemäß funktioniert, je nach Umfang der Integritätsmetrik.
In dieser Spezifikation bedeutet der Begriff „vertrauenswürdig", wenn er in bezug auf eine physische oder logische Komponente verwendet wird, daß sich die physische oder logische Komponente immer auf eine erwartete Weise verhält. Das Verhalten jener Komponente ist vorhersehbar und bekannt. Vertrauenswürdige Komponenten weisen einen hohen Widerstand gegenüber nicht-autorisierten Modifikationen auf.
In dieser Spezifikation bezieht sich der Begriff „Rechenplattform" (oder „Computerplattform") auf zumindest einen Datenprozessor und zumindest eine Datenspeichereinrichtung, üblicherweise, aber nicht notwendigerweise, mit zugeordneten Kommunikationseinrichtungen, z.B. einer Mehrzahl von Treibern, zugeordneten Anwendungen und Datendateien, und die in der Lage sein können, mit externen Entitäten, beispielsweise einem Benutzer oder einer anderen Computerplattform, zu interagieren, beispielsweise mittels eines Internetanschlusses, einer Verbindung mit einem externen Netzwerk oder dadurch, daß sie ein Eingangstor aufweisen, das in der Lage ist, Daten zu empfangen, die auf einem Da tenspeichermedium, z.B. einem CD-ROM, einer Floppy-Disk, einem Bandstreifen oder dergleichen gespeichert sind.
Ein Benutzer verifiziert den korrekten Betrieb der Plattform vor einem Austauschen anderer Daten mit der Plattform. Ein Benutzer tut dies, indem er die vertrauenswürdige Vorrichtung anfordert, ihre Identität und eine Integritätsmetrik zu liefern. (Optional lehnt es die vertrauenswürdige Vorrichtung ab, einen Identitätsbeweis zu liefern, wenn sie selbst nicht in der Lage war, einen korrekten Betrieb der Plattform zu verifizieren.) Der Benutzer empfängt den Identitätsbeweis und die Integritätsmetrik und vergleicht sie mit Werten, die er für wahr hält. Diese ordnungsgemäßen Werte werden durch die TP oder eine andere Entität, der der Benutzer vertraut, geliefert. Falls Daten, die durch die vertrauenswürdige Vorrichtung berichtet werden, dieselben sind wie die durch die TP gelieferten, vertraut der Benutzer der Plattform. Das liegt daran, daß der Benutzer der Entität vertraut. Die Entität vertraut der Plattform, weil sie zuvor die Identität der Plattform validiert und deren richtige Integritätsmetrik bestimmt hat.
Ein Benutzer einer Rechenentität kann beispielsweise durch Verwendung einer derartigen vertrauenswürdigen Token-Vorrichtung eine Vertrauensebene mit der Computerentität herstellen. Die vertrauenswürdige Token-Vorrichtung ist eine persönliche und tragbare Vorrichtung, die eine Datenverarbeitungsfähigkeit aufweist und in die der Benutzer ein hohes Maß an Vertrauen setzt. Sie kann ferner durch die vertrauenswürdige Plattform verwendet werden, um den Benutzer zu identifizieren. Die vertrauenswürdige Token-Vorrichtung kann folgende Funktionen erfüllen:

– Verifizieren eines korrekten Betriebs einer Computerplattform auf eine Weise, die für den Benutzer ohne weiteres offensichtlich ist, beispielsweise durch eine Audio- oder visuelle Anzeige;
– Herausfordern einer Überwachungskomponente, um einen Beweis eines korrekten Betriebs einer Computerplattform zu liefern, der die Überwachungskomponente zugeordnet ist; und
– Herstellen einer Interaktionsebene der Token-Vorrichtung mit einer Rechenplattform in Abhängigkeit davon, ob eine Überwachungskomponente einen zufriedenstellenden Beweis eines korrekten Betriebs der Rechenentität geliefert hat, und Zurückhalten spezifischer Interaktionen mit der Computerentität, falls ein derartiger Beweis eines korrekten Betriebs nicht durch die Token-Vorrichtung empfangen wird.

Nachdem ein Benutzer einen vertrauenswürdigen Betrieb der Plattform hergestellt hat, tauscht er andere Daten mit der Plattform aus. Für einen lokalen Benutzer kann der Austausch durch ein Interagieren mit einer Software-Anwendung, die auf der Plattform läuft, stattfinden. Für einen entfernten Benutzer kann der Austausch eine sichere Transaktion beinhalten. In beiden Fällen werden die ausgetauschten Daten durch die vertrauenswürdige Vorrichtung „signiert". Der Benutzer kann dann stärker darauf vertrauen, daß Daten mit einer Plattform ausgetauscht werden, deren Verhalten vertrauenswürdig ist.
Die vertrauenswürdige Vorrichtung verwendet kryptographische Prozesse, liefert diesen kryptographischen Prozessen jedoch nicht unbedingt eine externe Schnittstelle. Ferner bestünde eine höchst wünschenswerte Implementierung darin, die vertrauenswürdige Vorrichtung manipulationssicher zu machen, um Geheimnisse zu schützen, indem sie für andere Plattformfunktionen unzugänglich sind, und eine Umgebung zu schaffen, die im wesentlichen immun gegen eine nichtautorisierte Modifikation ist. Da die Herstellung einer völligen Manipulationssicherheit unmöglich ist, ist die nächstbeste Lösung eine vertrauenswürdige Vorrichtung, das manipulationsresistent ist oder Manipulationen erfaßt. Des halb besteht die vertrauenswürdige Vorrichtung vorzugsweise aus einer physischen Komponente, die manipulationsresistent ist.
Fachleuten auf dem Gebiet der Sicherheit sind Techniken, die in bezug auf eine Manipulationsresistenz relevant sind, hinreichend bekannt. Diese Techniken umfassen Verfahren zum Widerstehen gegenüber einer Manipulation (je nach Fall, Einkapseln der vertrauenswürdigen Vorrichtung), Verfahren zum Erfassen von Manipulationen (beispielsweise Erfassung von Spannungen oder Röntgenstrahlen, die außerhalb der Spezifikation liegen, oder Erfassung eines Verlustes der physischen Integrität in dem Gehäuse der vertrauenswürdigen Vorrichtung) sowie Verfahren zum Eliminieren von Daten, wenn eine Manipulation erfaßt wird. Eine weitere Erörterung geeigneter Techniken ist unter http://www.cl.cam.ac.uk/~mgk25/tamper.html zu finden. Man wird erkennen, daß, obwohl eine Herstellung einer völligen Manipulationssicherheit ein höchst wünschenswertes Merkmal des beschriebenen Systems ist, es nicht in den normalen Betrieb der vorliegenden Erfindung eingeht und somit außerhalb des Schutzbereichs der vorliegenden Erfindung liegt und im folgenden nicht ausführlich beschrieben wird.
Die vertrauenswürdige Vorrichtung ist vorzugsweise eine physische, da sie schwierig zu fälschen sein muß. Am stärksten bevorzugt ist sie manipulationsresistent, da sie schwer nachzuahmen sein muß. In der Regel weist sie eine Maschine auf, die in der Lage ist, kryptographische Prozesse zu verwenden, weil sie eine Identitätsprüfung liefern muß, sowohl auf lokaler Basis als auch über eine Entfernung hinweg, und sie enthält zumindest ein Verfahren zum Messen einer Integritätsmetrik der Plattform, der sie zugeordnet ist.
In dem Diagramm in 1 ist eine vertrauenswürdige Plattform 10 veranschaulicht. Die Plattform 10 umfaßt die standardmäßigen Merkmale einer Tastatur 14 (die einen Bestäti gungsschlüssel eines Benutzers bereitstellt), einer Maus 16 und eines Monitors 18, die die physische „Benutzerschnittstelle" der Plattform bereitstellen. Dieses Ausführungsbeispiel einer vertrauenswürdigen Plattform enthält ferner eine Smartcard-Lesevorrichtung 12. Neben der Smartcard-Lesevorrichtung 12 ist eine Smartcard 19 veranschaulicht, um eine vertrauenswürdige Benutzerinteraktion mit der vertrauenswürdigen Plattform zu ermöglichen, wie weiter unten beschrieben wird. In der Plattform 10 liegt eine Mehrzahl von Modulen 15 vor: diese sind andere funktionelle Elemente der vertrauenswürdigen Plattform von im wesentlichen jeglicher Art, die für diese Plattform geeignet ist. Die funktionelle Bedeutung derartiger Elemente ist für die vorliegende Erfindung nicht relevant und wird hierin nicht näher erläutert. Zusätzliche Komponenten der vertrauenswürdigen Computerentität umfassen in der Regel ein oder mehrere Tore eines lokalen Netzwerks (LAN), ein oder mehrere Modemtore, eine oder mehrere Leistungsversorgungen, Kühlgebläse und dergleichen.
Wie in 2 veranschaulicht ist, umfaßt die Hauptplatine 20 der vertrauenswürdigen Rechenplattform 10 (neben anderen standardmäßigen Komponenten) einen Hauptprozessor 21, einen Hauptspeicher 22, eine vertrauenswürdige Vorrichtung 24, einen Datenbus 26, jeweilige Steuerleitungen 27 und Leitungen 28, einen BIOS-Speicher 29, der das BIOS-Programm für die Plattform 10 enthält, sowie eine Eingabe-/Ausgabevorrichtung (IO-Vorrichtung) 23, die eine Interaktion zwischen den Komponenten der Hauptplatine und der Smartcard-Lesevorrichtung 12, der Tastatur 14, der Maus 1b und des Monitors 18 (und jeglicher etwaiger zusätzlicher Peripheriegeräte wie beispielsweise eines Modems, Druckers, Scanners oder dergleichen) steuert. Der Hauptspeicher 22 ist in der Regel ein Direktzugriffsspeicher (RAM). Im Betrieb lädt die Plattform 10 das Betriebssystem, beispielsweise Windows NT^TM, von einer Festplatte (nicht gezeigt) in einen RAM. Ferner lädt die Plattform 10 im Betrieb die Prozesse oder Anwendungen, die durch die Plattform 10 ausge führt werden können, von der Festplatte (nicht gezeigt) in den RAM.
Die Computerentität kann als eine logische sowie auch eine physische Architektur aufweisend angesehen werden. Die logische Architektur weist eine selbe grundlegende Unterteilung zwischen der Computerplattform und der vertrauenswürdigen Komponente, auf wie sie bei der in den 1 bis 4 des vorliegenden Dokuments beschriebenen physischen Architektur vorliegt. Das heißt, daß die vertrauenswürdige Komponente von der Computerplattform, mit der sie physisch verbunden ist, logisch getrennt ist. Die Computerentität weist einen Benutzerraum auf, der ein logischer Raum ist, der physisch auf der Computerplattform (der ersten Verarbeitungseinrichtung und der ersten Datenspeichereinrichtung) vorhanden ist, und einen Vertrauenswürdige-Komponente-Raum, der ein logischer Raum ist, der physisch auf der vertrauenswürdigen Komponente vorhanden ist. In dem Benutzerraum befinden sich ein oder eine Mehrzahl von Treibern, ein oder eine Mehrzahl von Anwendungsprogrammen, ein Dateispeicherbereich; eine Smartcard-Lesevorrichtung; eine Smartcard-Schnittstelle; und ein Software-Agent, der in dem Benutzerraum Operationen durchführen und an die vertrauenswürdige Komponente zurückmelden kann. Der Vertrauenswürdige-Komponente-Raum ist ein logischer Bereich, der auf der vertrauenswürdigen Komponente basiert und physisch in derselben vorhanden ist und durch den zweiten Datenprozessor und den zweiten Speicherbereich der vertrauenswürdigen Komponente gestützt wird. Der Monitor 18 empfängt Bilder direkt von dem Vertrauenswürdige-Komponente-Raum. Außerhalb der Computerentität befinden sich externe Kommunikationsnetzwerke, z.B. das Internet und verschiedene lokale Netzwerke, Weitverkehrsnetze, die über die Treiber (die ein oder mehrere moderne Tore aufweisen können) mit dem Benutzerraum verbunden sind. Eine Externer-Benutzer-Smartcard gibt in eine Smartcard-Lesevorrichtung in dem Benutzerraum ein.
Bei einem Personal-Computer befindet sich das BIOS-Programm in der Regel in einem speziell reservierten Speicherbereich, widmen sich die oberen 64K des ersten Megabytes dem Systemspeicher (Adressen F⌀⌀⌀h bis FFFFh), und ist der Hauptprozessor angeordnet, um gemäß einem branchenweiten Standard zuerst diese Speicherstelle zu betrachten.
Der bedeutende Unterschied zwischen der Plattform und einer herkömmlichen Plattform besteht darin, daß der Hauptprozessor nach einer Rücksetzung anfänglich durch die vertrauenswürdige Vorrichtung gesteuert wird, die anschließend die Steuerung an das plattformspezifische BIOS-Programm übergibt, das wiederum alle Eingabe-/Ausgabevorrichtungen wie üblich initialisiert. Nachdem das BIOS-Programm ausgeführt wurde, wird die Steuerung wie üblich durch das BIOS-Programm an ein Betriebssystemprogramm, beispielsweise Windows NT (TM), übergeben, das in der Regel von einem (nicht gezeigten) Festplattenlaufwerk in den Hauptspeicher 22 geladen wird.
Diese Änderung im Vergleich zu der normalen Prozedur erfordert selbstverständlich eine Modifikation der Implementierung des Industriestandards, wodurch den der Hauptprozessor 21 angeleitet wird, die vertrauenswürdige Vorrichtung 24 zu adressieren, um ihre ersten Anweisungen zu empfangen. Diese Änderung kann einfach durch Festcodieren einer unterschiedlichen Adresse in den Hauptprozessor 21 bewerkstelligt werden. Alternativ kann der vertrauenswürdigen Vorrichtung 24 die Standard-BIOS-Programmadresse zugewiesen sein, wobei in diesem Fall kein Bedarf besteht, die Hauptprozessorkonfiguration zu modifizieren.
Es ist äußerst wünschenswert, daß der BIOS-Bootblock in der vertrauenswürdigen Vorrichtung 24 enthalten ist. Dies verhindert eine Untergrabung des Erhaltens der Integritätsmetrik (was andernfalls stattfinden könnte, wenn schurkische Software-Prozesse vorliegen) und verhindert, daß schurkische Software-Prozesse eine Situation erzeugen, in der das BIOS (auch wenn es korrekt ist) es nicht schafft, die richtige Umgebung für das Betriebssystem aufzubauen.
Obwohl die vertrauenswürdige Vorrichtung 24 bei dem hierin beschriebenen System eine einzelne, diskrete Komponente ist, ist ins Auge gefaßt, daß die Funktionen der vertrauenswürdigen Vorrichtung 24 alternativ in mehrere Vorrichtungen auf der Hauptplatine unterteilt oder sogar in eine oder mehrere der vorhandenen standardmäßigen Vorrichtungen der Plattform integriert werden können. Beispielsweise ist es vorstellbar, eine oder mehrere der Funktionen der vertrauenswürdigen Vorrichtung in den Hauptprozessor selbst zu integrieren, vorausgesetzt, daß die Funktionen und ihre Kommunikationen nicht untergraben werden können. Wahrscheinlich würde dies jedoch getrennte Anschlußleitungen an dem Prozessor zur alleinigen Nutzung durch die vertrauenswürdigen Funktionen erfordern. Zusätzlich oder alternativ dazu wird erwartet, daß eine vertrauenswürdige Vorrichtung als „entfernbare" Vorrichtung, beispielsweise ein Dongle, implementiert sein kann, die bzw. der bei Bedarf an einer Plattform befestigt sein kann, obwohl die vertrauenswürdige Vorrichtung bei dem vorliegenden System eine Hardware- Vorrichtung ist, die für eine Integration in die Hauptplatine 20 ausgelegt ist. Ob die vertrauenswürdige Vorrichtung integriert oder entfernbar ist, ist eine Angelegenheit der Entwurfswahl. Wenn die vertrauenswürdige Vorrichtung jedoch trennbar ist, sollte ein Mechanismus zum Vorsehen einer logischen Verbindung zwischen der vertrauenswürdigen Vorrichtung und der Plattform vorhanden sein.
Die vertrauenswürdige Vorrichtung 24 weist eine Anzahl von Blöcken auf, wie in 3 veranschaulicht ist. Nach einer Systemrücksetzung führt die vertrauenswürdige Vorrichtung 24 einen sicheren Bootvorgang durch, um zu gewährleisten, daß das Betriebssystem der Plattform 10 (einschließlich des Systemtakts und der Anzeige auf dem Monitor) ordnungsgemäß und auf sichere Weise läuft. Während des sicheren Bootvorgangs gewinnt die vertrauenswürdige Vorrichtung 24 eine In tegritätsmetrik der Rechenplattform 10. Die vertrauenswürdige Vorrichtung 24 kann ferner über eine Verschlüsselung/Entschlüsselung und Signatur/Verifikation einen sicheren Datentransfer und, beispielsweise, eine Authentifizierung zwischen derselben und einer Smartcard durchführen. Die vertrauenswürdige Vorrichtung 24 kann ferner auf sichere Weise verschiedene Sicherheitskontrollrichtlinien, beispielsweise ein Verriegeln der Benutzerschnittstelle, durchsetzen.
Im einzelnen weist die vertrauenswürdige Vorrichtung folgende Merkmale auf: eine Steuerung 30, die programmiert ist, um den Gesamtbetrieb der vertrauenswürdigen Vorrichtung 24 zu steuern und mit den anderen Funktionen auf der vertrauenswürdigen Vorrichtung 24 und mit den anderen Vorrichtungen auf der Hauptplatine 20 zu interagieren; eine Meßfunktion 31 zum Gewinnen der Integritätsmetrik von der Plattform 10; eine kryptographische Funktion 32 zum Signieren, Verschlüsseln oder Entschlüsseln spezifizierter Daten; eine Authentifizierungsfunktion 33 zum Authentifizieren einer Smartcard; und eine Schnittstellenschaltungsanordnung 34, die entsprechende Tore (36, 37 & 38) zum Verbinden der vertrauenswürdigen Vorrichtung 24 mit dem Datenbus 26, den Steuerleitungen 27 bzw. den Adreßleitungen 28 der Hauptplatine 20 aufweist. Jeder der Blöcke in der vertrauenswürdigen Vorrichtung 24 hat Zugriff (in der Regel über die Steuerung 30) auf entsprechende Flüchtiger-Speicher-Bereiche 4 und/oder Nichtflüchtiger-Speicher-Bereiche 3 der vertrauenswürdigen Vorrichtung 24. Ferner ist die vertrauenswürdige Vorrichtung 24 auf eine bekannte Weise entworfen, um manipulationsresistent zu sein.
Aus Gründen der Leistungsfähigkeit kann die vertrauenswürdige Vorrichtung 24 als anwendungsspezifische integrierte Schaltung (ASIC – application specific integrated circuit) implementiert sein. Der Flexibilität halber ist die vertrauenswürdige Vorrichtung 24 jedoch vorzugsweise eine entsprechend programmierte Mikrosteuerung. Sowohl ASICs als auch Mikrosteuerungen sind auf dem Gebiet der Mikroelektronik hinreichend bekannt und werden hierin nicht ausführlicher betrachtet.
Eine in dem nicht-flüchtigen Speicher 3 der vertrauenswürdigen Vorrichtung 24 gespeicherte Dateneinheit ist ein Zertifikat 350. Das Zertifikat 350 enthält zumindest einen öffentlichen Schlüssel 351 der vertrauenswürdigen Vorrichtung 24 und einen authentifizierten Wert 352 der durch eine vertrauenswürdige Partei (TP) gemessenen Plattformintegritätsmetrik. Das Zertifikat 350 wird durch die TP unter Verwendung des privaten Schlüssels der TP signiert, bevor es in der vertrauenswürdigen Vorrichtung 24 gespeichert wird. In späteren Kommunikationssitzungen kann ein Benutzer der Plattform 10 die Integrität der Plattform 10 verifizieren, indem er die gewonnene Integritätsmetrik mit der authentischen Integritätsmetrik 352 vergleicht. Falls eine Übereinstimmung vorliegt, kann der Benutzer darauf vertrauen, daß die Plattform 10 nicht untergraben wurde. Eine Kenntnis des allgemein verfügbaren öffentlichen Schlüssels der TP ermöglicht eine einfache Verifizierung des Zertifikats 350. Der nicht-flüchtige Speicher 35 enthält ferner eine Identitätsmarkierung (ID-Markierung) 353. Die ID-Markierung 353 ist eine herkömmliche ID-Markierung, beispielsweise eine Seriennummer, die in einem gewissen Kontext eindeutig ist. Die ID-Markierung 353 wird allgemein zum Indexieren und Markieren von für die vertrauenswürdige Vorrichtung 24 relevanten Daten verwendet, ist jedoch an sich unzureichend, um die Identität der Plattform 10 unter vertrauenswürdigen Bedingungen zu beweisen.
Die vertrauenswürdige Vorrichtung 24 ist mit zumindest einem Verfahren zum zuverlässigen Messen oder Gewinnen der Integritätsmetrik der Rechenplattform 10, der sie zugeordnet ist, ausgestattet. Bei dem vorliegenden Ausführungsbeispiel wird die Integritätsmetrik durch die Meßfunktion 31 gewonnen, indem ein Auszug der BIOS-Anweisungen in dem BIOS-Speicher erzeugt wird. Eine derartige gewonnene Inte gritätsmetrik, falls sie wie oben beschrieben verifiziert wurde, vermittelt einem potentiellen Benutzer der Plattform 10 ein hohes Maß an Vertrauen, daß die Plattform 10 nicht auf einer Hardware-Ebene oder einer BIOS-Programm-Ebene untergraben wurde. Andere bekannte Prozesse, beispielsweise Virusprüfungseinrichtungen, sind in der Regel vorhanden, um zu prüfen, daß das Betriebssystem und der Anwendungsprogrammcode nicht untergraben wurden.
Die Meßfunktion 31 hat Zugriff auf den nicht-flüchtigen Speicher 3 zum Speichern eines Hash-Programms 354 und eines privaten Schlüssels 355 der vertrauenswürdigen Vorrichtung 24, und auf den flüchtigen Speicher 4 zum Speichern einer gewonnenen Integritätsmetrik in Form eines Auszugs 361. Bei geeigneten Ausführungsbeispielen kann der flüchtige Speicher 4 auch verwendet werden, um die öffentlichen Schlüssel und zugeordneten ID-Markierungen 360a bis 360n einer oder mehrerer authentischer Smartcards 19s, die verwendet werden können, um Zugriff zu der Plattform 10 zu erhalten, zu speichern.
Bei einer bevorzugten Implementierung umfaßt die Integritätsmetrik, ebenso wie der Auszug, einen Booleschen Wert, der aus Gründen, die noch ersichtlich werden, durch die Meßfunktion 31 in dem flüchtigen Speicher 4 gespeichert wird.
Unter Bezugnahme auf 4 wird nun ein bevorzugter Prozeß zum Gewinnen einer Integritätsmetrik beschrieben.
Bei einem Schritt 400, bei einem Einschalten, überwacht die Meßfunktion 31 die Aktivität des Hauptprozessors 21 auf den Daten-, Steuer- und Adreßleitungen (26, 27 & 28), um zu bestimmen, ob die vertrauenswürdige Vorrichtung 24 der erste Speicher ist, auf den zugegriffen wird. Bei einem herkömmlichen Betrieb würde ein Hauptprozessor zuerst auf den BIOS-Speicher gerichtet, um das BIOS-Programm auszuführen. Gemäß der vorliegenden Erfindung wird der Hauptprozessor 21 jedoch auf die vertrauenswürdige Vorrichtung 24, die als Speicher agiert, gerichtet. Bei Schritt 405, falls die vertrauenswürdige Vorrichtung 24 der erste Speicher ist, auf den zugegriffen wird, schreibt die Meßfunktion 31 bei Schritt 410 einen Booleschen Wert in den nicht-flüchtigen Speicher 3, der angibt, daß die vertrauenswürdige Vorrichtung 24 der erste Speicher war, auf den zugegriffen wurde. Andernfalls schreibt die Meßfunktion bei Schritt 415 einen Booleschen Wert, der angibt, daß die vertrauenswürdige Vorrichtung 24 nicht der erste Speicher war, auf den zugegriffen wurde.
Falls die vertrauenswürdige Vorrichtung 24 nicht die erste ist, auf die zugegriffen wurde, besteht selbstverständlich eine Möglichkeit, daß überhaupt nicht auf die vertrauenswürdige Vorrichtung 24 zugegriffen wird. Dies wäre beispielsweise der Fall, wenn der Hauptprozessor 21 manipuliert würde, um das BIOS-Programm als erstes auszuführen. Unter diesen Umständen würde die Plattform arbeiten, wäre jedoch nicht in der Lage, ihre Integrität auf Anfrage zu verifizieren, da die Integritätsmetrik nicht zur Verfügung stünde. Falls auf die vertrauenswürdige Vorrichtung 24 zugegriffen würde, nachdem auf das BIOS-Programm zugegriffen wurde, würde der Boolesche Wert deutlich einen Integritätsmangel der Plattform angeben.
Bei Schritt 420, wenn (oder falls) durch den Hauptprozessor 21 ein Zugriff als Speicher vorgenommen wird, liest der Hauptprozessor 21 bei Schritt 425 die gespeicherten nativen Hash-Anweisungen 354 aus der Meßfunktion 31. Die Hash-Anweisungen 354 werden zum Verarbeiten durch den Hauptprozessor 21 über den Datenbus 26 geleitet. Bei Schritt 430 führt der Hauptprozessor 21 die Hash-Anweisungen 354 aus und verwendet sie bei Schritt 435, um einen Auszug des BIOS-Speichers 29 zu berechnen, indem er den Inhalt des BIOS-Speichers 29 liest und diesen Inhalt gemäß dem Hash-Programm verarbeitet. Bei Schritt 440 schreibt der Hauptprozessor 21 den berechneten Auszug 361 in die entsprechen de Nicht-Flüchtiger-Speicher-Stelle 4 in der vertrauenswürdigen Vorrichtung 24. Bei Schritt 445 ruft dann die Meßfunktion 31 das BIOS-Programm in dem BIOS-Speicher 29, und eine Ausführung wird auf herkömmliche Weise fortgesetzt.
Selbstverständlich gibt es eine Anzahl unterschiedlicher Arten und Weisen, auf die die Integritätsmetrik berechnet werden kann, je nach dem Umfang des erforderlichen Vertrauens. Die Messung der Integrität des BIOS-Programms liefert eine fundamentale Prüfung der Integrität einer Verarbeitungsumgebung, die einer Plattform zugrunde liegt. Die Integritätsmetrik sollte eine derartige Form aufweisen, daß sie eine Schlußfolgerung über die Gültigkeit des Bootvorgangs ermöglicht – der Wert der Integritätsmetrik kann verwendet werden, um zu verifizieren, ob die Plattform unter Verwendung des korrekten BIOS gebootet wurde. Optional könnten einzelne funktionelle Blöcke in dem BIOS ihre eigenen Auszugswerte aufweisen, wobei ein Kollektiv-BIOS-Auszug ein Auszug dieser einzelnen Auszüge ist. Dies ermöglicht, daß eine Richtlinie darlegt, welche Teile einer BIOS-Operation für einen beabsichtigten Zweck kritisch sind und welche irrelevant sind (wobei die einzelnen Auszüge in diesem Fall auf eine derartige Weise gespeichert werden müssen, daß eine Validität der Operation gemäß der Richtlinie etabliert werden kann).
Andere Integritätsprüfungen könnten eine Feststellung beinhalten, daß verschiedene andere Bauelemente, Komponenten oder Vorrichtungen, die an der Plattform angebracht sind, vorhanden sind und absolut funktionstüchtig sind. Bei einem Beispiel könnten die einer SCSI-Steuerung zugeordneten BIOS-Programme verifiziert werden, um zu gewährleisten, daß Kommunikationen mit Peripheriegeräten vertraut werden könnte. Bei einem anderen Beispiel könnte die Integrität anderer Vorrichtungen, beispielsweise von Speichervorrichtungen oder Coprozessoren, auf der Plattform dadurch verifiziert werden, daß feststehende Herausforderung/Antwort-Interaktionen durchgeführt werden, um einheitliche Ergeb nisse zu gewährleisten. Dort, wo die vertrauenswürdige Vorrichtung 24 eine trennbare Komponente ist, ist eine derartige Interaktionsform wünschenswert, um eine geeignete logische Bindung zwischen der vertrauenswürdigen Vorrichtung 24 und der Plattform zu schaffen. Obwohl die vertrauenswürdige Vorrichtung 24 bei dem vorliegenden Ausführungsbeispiel den Datenbus als ihr Hauptkommunikationsmittel mit anderen Teilen der Plattform verwendet, wäre es ferner denkbar, allerdings nicht sehr zweckmäßig, alternative Kommunikationswege, beispielsweise festverdrahtete Wege oder optische Wege, bereitzustellen. Obwohl die vertrauenswürdige Vorrichtung 24 bei dem vorliegenden Ausführungsbeispiel den Hauptprozessor 21 anweist, die Integritätsmetrik zu berechnen, wird vorweggenommen, daß die vertrauenswürdige Vorrichtung selbst bei anderen Ausführungsbeispielen angeordnet ist, um eine oder mehrere Integritätsmetriken zu messen.
Vorzugsweise umfaßt der BIOS-Bootvorgang Mechanismen, um die Integrität des Bootvorgangs selbst zu verifizieren. Solche Mechanismen sind beispielsweise bereits aus dem Entwurf „Wired for Management baseline specification v 2.0 – BOOT Integrity Service" von Intel bekannt und beinhalten ein Berechnen von Auszügen von Software oder Firmware, bevor diese Software oder Firmware geladen wird. Ein derartiger berechneter Auszug wird mit einem Wert verglichen, der in einem Zertifikat gespeichert ist, das durch eine vertrauenswürdige Entität bereitgestellt wird, deren öffentlicher Schlüssel dem BIOS bekannt ist. Die Software/Firmware wird anschließend nur dann geladen, falls der berechnete Wert mit dem erwarteten Wert aus dem Zertifikat übereinstimmt und sich das Zertifikat durch eine Verwendung des öffentlichen Schlüssels der vertrauenswürdigen Entität als gültig erwiesen hat. Andernfalls wird eine entsprechende Ausnahmenhandhabungsroutine aufgerufen.
Nach dem Empfangen des berechneten BIOS-Auszugs kann die vertrauenswürdige Vorrichtung 24 den richtigen Wert des BIOS-Auszugs in dem Zertifikat inspizieren und die Steuerung nicht an das BIOS weiterleiten, falls der berechnete Auszug nicht mit dem richtigen Wert übereinstimmt. Zusätzlich oder alternativ dazu kann die vertrauenswürdige Vorrichtung 24 den Booleschen Wert inspizieren und die Steuerung nicht an das BIOS zurückgeben, falls die vertrauenswürdige Vorrichtung 24 nicht der erste Speicher war, auf den zugegriffen wurde. In beiden Fällen kann eine entsprechende Ausnahmenhandhabungsroutine aufgerufen werden.
5 veranschaulicht den Fluß von Handlungen durch eine TP, der in eine Plattform integrierten vertrauenswürdigen Vorrichtung 24 und eines Benutzers (einer entfernten Plattform), der die Integrität der vertrauenswürdigen Plattform verifizieren möchte. Man wird erkennen, daß, wenn der Benutzer ein lokaler Benutzer ist, im wesentlichen dieselben Schritte wie die in 5 gezeigten beteiligt sind. In beiden Fällen stützt sich der Benutzer in der Regel auf eine Form von Software-Anwendung, um die Verifizierung durchzuführen. Es wäre möglich, die Software-Anwendung auf der entfernten Plattform oder der vertrauenswürdigen Plattform zu betreiben. Es besteht jedoch eine Möglichkeit, daß – auch auf der entfernten Plattform – die Software-Anwendung auf eine gewisse Art und Weise untergraben werden könnte. Deshalb ist bevorzugt, daß sich die Software-Anwendung zum Zwecke eines hohen Maßes an Integrität auf einer Smartcard des Benutzers befindet, der die Smartcard zu Verifizierungszwecken in eine entsprechende Lesevorrichtung einführt. Bestimmte Ausführungsbeispiele beziehen sich auf eine derartige Anordnung.
In dem ersten Fall inspiziert eine TP, die für vertrauenswürdige Plattformen bürgt, den Typ der Plattform, um zu entscheiden, ob sie für dieselbe bürgt oder nicht. Dies ist eine Angelegenheit von Richtlinien. Falls alles in Ordnung ist, mißt die TP bei Schritt 500 den Wert der Integritätsmetrik der Plattform. Dann erzeugt die TP bei Schritt 505 ein Zertifikat für die Plattform. Das Zertifikat wird durch die TP erzeugt, indem der öffentliche Schlüssel der vertrauenswürdigen Vorrichtung und optional ihre ID-Markierung an die gemessene Integritätsmetrik angefügt werden und indem die Zeichenfolge mit dem privaten Schlüssel der TP signiert wird.
Anschließend kann die vertrauenswürdige Vorrichtung 24 ihre Identität beweisen, indem sie ihren privaten Schlüssel verwendet, um manche von dem Benutzer empfangenen Eingangsdaten zu verarbeiten und Ausgangsdaten zu erzeugen, derart, daß es statistisch unmöglich ist, das Eingang/Ausgang-Paar ohne die Kenntnis des privaten Schlüssels zu erzeugen. Somit bildet eine Kenntnis des privaten Schlüssels in diesem Fall die Identitätsbasis. Selbstverständlich wäre es denkbar, eine symmetrische Verschlüsselung zu verwenden, um die Identitätsbasis zu bilden. Jedoch besteht der Nachteil der Verwendung einer symmetrischen Verschlüsselung darin, daß der Benutzer sein Geheimnis der vertrauenswürdigen Vorrichtung anvertrauen müßte. Infolge des Erfordernisses, das Geheimnis mit dem Benutzer zu teilen, wäre es unzureichend – während eine symmetrische Verschlüsselung im Prinzip ausreichend wäre, um dem Benutzer die Identität zu beweisen – die Identität gegenüber einer dritten Partei zu beweisen, die sich nicht gänzlich sicher sein könnte, daß die Verifizierung von der vertrauenswürdigen Vorrichtung oder dem Benutzer stammte.
Bei Schritt 510 wird die vertrauenswürdige Vorrichtung 24 initialisiert, indem das Zertifikat 350 in die entsprechenden Nicht-Flüchtiger-Speicher-Stellen 3 der vertrauenswürdigen Vorrichtung 24 geschrieben werden. Dies erfolgt vorzugsweise durch eine sichere Kommunikation mit der vertrauenswürdigen Vorrichtung 24, nachdem sie in der Hauptplatine 20 installiert ist. Das Verfahren, mit dem das Zertifikat in die vertrauenswürdige Vorrichtung 24 geschrieben wird, ist analog zu dem Verfahren, das verwendet wird, um Smartcards durch ein Schreiben von privaten Schlüsseln in dieselben zu initialisieren. Die sicheren Kommunikationen wer den durch einen „Hauptschlüssel" gestützt, der lediglich der TP bekannt ist und der während der Herstellung in die vertrauenswürdige Vorrichtung (oder die Smartcard) geschrieben wird und verwendet wird, um das Schreiben von Daten in die vertrauenswürdige Vorrichtung 24 zu ermöglichen; ein Schreiben von Daten in die vertrauenswürdige Vorrichtung 24 ohne Kenntnis des Hauptschlüssels ist nicht möglich.
An einem späteren Punkt während des Betriebs der Plattform, beispielsweise wenn sie eingeschaltet oder neu eingestellt wird, gewinnt und speichert die vertrauenswürdige Vorrichtung 24 bei Schritt 515 die Integritätsmetrik 361 der Plattform.
Wenn ein Benutzer mit der Plattform kommunizieren möchte, erzeugt er bei Schritt 520 eine Einmalverfügung (Nonce), beispielsweise eine Zufallszahl, und fordert bei Schritt 525 die vertrauenswürdige Vorrichtung 24 heraus (das Betriebssystem der Plattform oder eine entsprechende Software-Anwendung ist angeordnet, um die Herausforderung zu erkennen und sie in der Regel über einen Anruf vom BIOS-Typ auf geeignete Weise an die vertrauenswürdige Vorrichtung 24 weiterzuleiten). Die Einmalverfügung wird verwendet, um den Benutzer vor einer Täuschung zu schützen, die durch eine Wiedergabe alter, jedoch echter Signaturen (als „Wiedergabeattacke" bezeichnet) durch nicht-vertrauenswürdige Plattformen bewirkt wird. Der Prozeß des Bereitstellens einer Einmalverfügung und des Verifizierens der Antwort ist ein Beispiel des hinreichend bekannten „Herausforderung/Antwort"-Prozesses.
Bei Schritt 530 empfängt die vertrauenswürdige Vorrichtung 24 die Herausforderung und erzeugt eine entsprechende Antwort. Dies kann ein Auszug der gemessenen Integritätsmetrik und der Einmalverfügung und optional ihrer ID-Markierung sein. Bei Schritt 535 signiert die vertrauenswürdige Vorrichtung 24 dann unter Verwendung ihres privaten Schlüssels den Auszug und gibt den signierten Auszug in Begleitung des Zertifikats 350 an den Benutzer zurück.
Bei Schritt 540 empfängt der Benutzer die Herausforderungsantwort und verifiziert das Zertifikat unter Verwendung des hinreichend bekannten öffentlichen Schlüssels der TP. Bei Schritt 550 extrahiert der Benutzer dann den öffentlichen Schlüssel der vertrauenswürdigen Vorrichtung 24 aus dem Zertifikat und verwendet ihn, um den signierten Auszug aus der Herausforderungsantwort zu entschlüsseln. Bei Schritt 560 verifiziert der Benutzer dann die Einmalverfügung in der Herausforderungsantwort. Als nächstes vergleicht der Benutzer bei Schritt 570 die berechnete Integritätsmetrik, die er aus der Herausforderungsantwort extrahiert, mit der richtigen Plattformintegritätsmetrik, die er aus dem Zertifikat extrahiert. Falls einer der vorstehenden Verifizierungsschritte negativ ausfällt, Schritte 545, 555, 565 oder 575, endet der ganze Vorgang bei Schritt 580, ohne daß weitere Kommunikationen stattfinden.
Wenn man davon ausgeht, daß alles in Ordnung ist, verwenden der Benutzer und die vertrauenswürdige Plattform bei Schritten 585 und 590 andere Protokolle, um sichere Kommunikationen für andere Daten einzurichten, wobei die Daten von der Plattform vorzugsweise durch die vertrauenswürdige Vorrichtung 24 signiert sind.
Weitere Verfeinerungen dieses Verifizierungsvorgangs sind möglich. Es ist wünschenswert, daß sich der Herausforderer durch die Herausforderung sowohl des Wertes der Plattformintegritätsmetrik als auch des Verfahrens, anhand dessen sie erhalten wurde, bewußt wird. Beide diese Informationen sind wünschenswert, um es dem Herausforderer zu ermöglichen, eine richtige Entscheidung über die Integrität der Plattform zu treffen. Dem Herausforderer stehen ferner viele verschiedene Optionen zur Verfügung – er kann akzeptieren, daß die Integritätsmetrik in der vertrauenswürdigen Vorrichtung 24 als gültig anerkannt wird, oder alternativ dazu akzeptiert er vielleicht lediglich, daß die Plattform das relevante Maß an Integrität aufweist, falls der Wert der Integritätsmetrik gleich einem Wert ist, der durch den Herausforderer aufrechterhalten wird (oder er kann annehmen, daß es in diesen beiden Fällen ein unterschiedliches Maß an Vertrauen gibt).
Die Techniken eines Signierens, Verwendens von Zertifikaten und einer Herausforderung/Antwort und eines Verwendens derselben, um eine Identität zu beweisen, sind Fachleuten auf dem Gebiet der Sicherheit hinreichend bekannt und müssen deshalb in dem vorliegenden Dokument nicht ausführlicher beschrieben werden.
Die Smartcard 19 eines Benutzers ist eine Token-Vorrichtung, die von der Rechenentität getrennt ist und die über das Smartcard-Lesevorrichtungstor 19 mit der Rechenentität interagiert. Ein Benutzer kann mehrere unterschiedliche Smartcards aufweisen, die von mehreren unterschiedlichen Verkäufern oder Dienstanbietern ausgestellt sind, und kann von einer beliebigen einer Mehrzahl von Rechenentitäten, wie sie hierin beschrieben sind, die mit einer vertrauenswürdigen Komponente und einer Smartcard-Lesevorrichtung versehen sind, Zugriff auf das Internet oder eine Mehrzahl von Netzwerk-Computern erlangen. Das Vertrauen eines Benutzers zu der individuellen Rechenentität, die er benutzt, leitet sich aus der Interaktion zwischen den Vertrauenswürdige-Smartcard-Token und der vertrauenswürdigen Komponente der Rechenentität ab. Der Benutzer stütze sich auf sein Vertrauenswürdige-Smartcard-Token, um die Vertrauenswürdigkeit der vertrauenswürdigen Komponente zu verifizieren.
In 6 ist ein verarbeitender Teil 60 einer Benutzer-Smartcard 19 veranschaulicht. Wie gezeigt ist, weist der verarbeitende Teil 60 der Benutzer-Smartcard 19 die standardmäßigen Merkmale eines Prozessors 61, eines Speichers 62 und vor Schnittstellenkontakten 63 auf. Der Prozessor 61 ist für einfache Herausforderung/Antwort-Operationen programmiert, die eine Authentifizierung der Benutzer-Smartcard 19 und eine Verifizierung der Plattform 10 beinhalten, wie nachfolgend beschrieben wird. Der Speicher 62 enthält seinen privaten Schlüssel 620, seinen öffentlichen Schlüssel 628, (optional) ein Benutzerprofil 621, den öffentlichen Schlüssel 622 der TP und eine Identität 627. Das Benutzerprofil 621 führt die zulässigen Hilfs-Smartcards 20 AC1-ACn, die durch den Benutzer verwendbar sind, und die individuelle Sicherheitsrichtlinie 624 für den Benutzer auf. Für jede Hilfs-Smartcard 20 umfaßt das Benutzerprofil jeweilige Identifizierungsinformationen 623, die Vertrauensstruktur 625 zwischen den Smartcards (falls eine vorhanden ist) und optional den Typ oder die Marke 626 der Smartcard.
Bei dem Benutzerprofil 621 umfaßt jeder Eintrag AC1-ACn der Hilfs-Smartcard 20 zugeordnete Identifizierungsinformationen 623, die je nach Kartentyp variieren. Beispielsweise umfassen Identifizierungsinformationen für eine Cash-Karte üblicherweise eine einfache Seriennummer, wohingegen die Identifizierungsinformationen für eine Kryptokarte in der Regel den öffentlichen Schlüssel (oder das Zertifikat) der Kryptokarte umfassen (wobei der private Schlüssel geheim auf der Kryptokarte selbst gespeichert ist).
Die „Sicherheitsrichtlinie" 624 gibt die Erlaubnisse vor, die der Benutzer auf der Plattform 10 hat, während er eine Hilfs-Smartcard 20 verwendet. Beispielsweise kann die Benutzerschnittstelle verriegelt oder entriegelt sein, während eine Hilfs-Smartcard 20 im Gebrauch ist, je nach der Funktion der Hilfs-Smartcard 20. Zusätzlich oder alternativ dazu können bestimmte Dateien oder ausführbare Programme auf der Plattform 10 zugänglich gemacht werden oder nicht, je nachdem, wie sehr einer bestimmten Hilfs-Smartcard 20 vertraut wird. Ferner kann die Sicherheitsrichtlinie 624 einen bestimmten Betriebsmodus für die Hilfs-Smartcard 20 spezifizieren, beispielsweise „Guthabenbescheinigung" oder „vorübergehende Übertragung", wie nachstehend beschrieben wird.
Eine „Vertrauensstruktur" 625 definiert, ob eine Hilfs-Smartcard 20 selbst weitere Hilfs-Smartcards 20 in das System „einführen" kann, ohne zuerst die Benutzer-Smartcard 19 erneut zu benutzen. Bei den hierin ausführlich beschriebenen Ausführungsbeispielen ist die einzige definierte Vertrauensstruktur diejenige zwischen der Benutzer-Smartcard 19 und den Hilfs-Smartcards 20, die durch die Benutzer-Smartcard 19 in die Plattform 10 eingeführt werden können. Wie unten beschrieben wird, kann eine Einführung eine Einführung einer „Einzelsitzung" oder einer „Mehrfachsitzung" sein. Es besteht jedoch kein Grund, warum bestimmte Hilfs-Smartcards 20 in der Praxis nicht weitere Hilfs-Smartcards 20 einführen könnten. Dies würde erfordern, daß eine Hilfs-Smartcard 20 ein Äquivalent eines Benutzerprofils aufweist, das die oder jede Hilfs-Smartcard, die sie einzuführen in der Lage ist, auflistet. Die Verwendung von Hilfs-Smartcards 20 ist kein notwendiges Merkmal der vorliegenden Erfindung und wird in der vorliegenden Anmeldung nicht näher beschrieben. Die Verwendung von Hilfs-Smartcards ist Gegenstand der gleichzeitig anhängigen internationalen Patentanmeldung Nr. PCT/GB00/00751 vom 5. März 2000 des vorliegenden Anmelders mit dem Titel „Computing Apparatus and Methods of Operating Computing Apparatus", die durch Bezugnahme in das vorliegende Dokument aufgenommen ist.
Ein bevorzugter Prozeß für eine Authentifizierung zwischen einer Benutzer-Smartcard 19 und einer Plattform 10 wird nun unter Bezugnahme auf das Flußdiagramm in 7 beschrieben. Wie beschrieben wird, implementiert das Verfahren zweckmäßigerweise eine Herausforderung/Antwort-Routine. Es stehen viele Herausforderung/Antwort-Mechanismen zur Verfügung. Die Implementierung eines bei dem vorliegenden Ausführungsbeispiel verwendeten Authentifizierungsprotokolls ist eine gegenseitige (oder 3-Schritt-)Authentifizierung, wie bei ISO/IEC 9798-3 beschrieben ist. Selbstverständlich gibt es keinen Grund, warum nicht auch andere Authentifizierungsprozeduren verwendet werden können, beispielsweise 2-Schritt- oder 4-Schritt-Prozeduren, wie sie ebenfalls bei ISO/IEC 9798-3 beschrieben sind.
Anfänglich führt der Benutzer bei Schritt 700 seine Benutzer-Smartcard 19 in die Smartcard-Lesevorrichtung 12 der Plattform 10 ein. Zuvor arbeitet die Plattform 10 in der Regel unter der Steuerung ihres standardmäßigen Betriebssystems und führt den Authentifizierungsvorgang durch, der darauf wartet, daß ein Benutzer seine Benutzer-Smartcard 19 einführt. Abgesehen davon, daß die Smartcard-Lesevorrichtung 12 auf diese Weise aktiv ist, wird die Plattform 10 in der Regel für Benutzer unzugänglich gemacht, indem die Benutzerschnittstelle (d.h. der Bildschirm, die Tastatur und die Maus) „verriegelt" wird.
Wenn die Benutzer-Smartcard 19 in die Smartcard-Lesevorrichtung 12 eingeführt wird, wird ausgelöst, daß die vertrauenswürdige Vorrichtung 24 bei einem Schritt eine gegenseitige Authentifizierung versucht, indem sie eine Einmalverfügung A erzeugt und bei Schritt 705 an die Benutzer-Smartcard 19 übermittelt. Eine Einmalverfügung, beispielsweise eine Zufallszahl, wird verwendet, um den Urheber vor einer Täuschung zu schützen, die durch eine Wiedergabe alter, jedoch echter Antworten (als „Wiedergabeattacke" bezeichnet) seitens nicht-vertrauenswürdiger dritter Parteien bewirkt wird.
Ansprechend darauf erzeugt die Benutzer-Smartcard 19 bei Schritt 710 eine Antwort, die eine Verkettung der folgenden aufweist, und gibt diese zurück: des einfachen Texts der Einmalverfügung A, einer neuen Einmalverfügung B, die durch die Benutzer-Smartcard 19 erzeugt wird, der ID 353 der vertrauenswürdigen Vorrichtung 24 und einer gewissen Redundanz; der Signatur des einfachen Textes, die durch ein Signieren des einfachen Textes mit dem privaten Schlüssel der Benutzer-Smartcard 19 erstellt wurde, und eines Zertifi kats, das die ID und den öffentlichen Schlüssel der Benutzer-Smartcard 19 enthält.
Die vertrauenswürdige Vorrichtung 24 authentifiziert die Antwort, indem sie den öffentlichen Schlüssel in dem Zertifikat verwendet, um die Signatur des einfachen Textes bei Schritt 715 zu verifizieren. Falls die Antwort nicht authentisch ist, endet der Prozeß bei Schritt 720. Falls die Antwort authentisch ist, erzeugt und sendet die vertrauenswürdige Vorrichtung 24 bei Schritt 725 eine weitere Antwort, die die Verkettung der folgenden umfaßt: des einfachen Textes der Einmalverfügung A, der Einmalverfügung B, der ID 627 der Benutzer-Smartcard 19 und der gewonnenen Integritätsmetrik; der Signatur des einfachen Textes, die durch ein Signieren des einfachen Textes unter Verwendung des privaten Schlüssels der vertrauenswürdigen Vorrichtung 24 erstellt wurde; und des Zertifikats, das den öffentlichen Schlüssel der vertrauenswürdigen Vorrichtung 24 und die authentische Integritätsmetrik, die beide durch den privaten Schlüssel der TP signiert sind, aufweist.
Die Benutzer-Smartcard 19 authentifiziert diese Antwort, indem sie den öffentlichen Schlüssel der TP verwendet und die gewonnene Integritätsmetrik mit der authentischen Integritätsmetrik vergleicht, wobei eine Übereinstimmung bei Schritt 730 eine erfolgreiche Verifizierung angibt. Falls die weitere Antwort nicht authentisch ist, endet der Prozeß bei Schritt 735.
Falls die Prozedur erfolgreich ist, hat die vertrauenswürdige Vorrichtung 24 die Benutzer-Smartcard 19 authentifiziert, und die Benutzer-Smartcard 19 hat die Integrität der vertrauenswürdigen Plattform 10 verifiziert, und bei Schritt 740 führt der Authentifizierungsprozeß den sicheren Prozeß für den Benutzer aus. Dann stellt der Authentifizierungsprozeß bei Schritt 745 eine Intervallzeitgebungseinrichtung ein. Danach wartet der Authentifizierungsprozeß die Intervallzeitgebungseinrichtung periodisch unter Ver wendung entsprechender Betriebssystemsunterbrechungsroutinen, um zu erfassen, wann die Zeitgebungseinrichtung bei Schritt 750 eine vorbestimmte Zeitablaufperiode erfüllt oder überschreitet.
Der Authentifizierungsprozeß und die Intervallzeitgebungseinrichtung laufen deutlich parallel zu dem sicheren Prozeß. Wenn die Zeitablaufperiode erfüllt oder überschritten wird, löst der Authentifizierungsprozeß aus, daß die vertrauenswürdige Vorrichtung 24 die Benutzer-Smartcard 19 erneut authentifiziert, indem eine Herausforderung für die Benutzer-Smartcard 19, sich selbst bei Schritt 760 zu identifizieren, übermittelt wird. Die Benutzer-Smartcard 19 gibt bei Schritt 765 ein Zertifikat zurück, das ihre ID 627 und ihren öffentlichen Schlüssel 628 umfaßt. Bei Schritt 770, falls keine Antwort vorliegt (beispielsweise weil die Benutzer-Smartcard 19 entfernt wurde) oder falls das Zertifikat aus irgendeinem Grund nicht mehr gültig ist (beispielsweise wurde die Benutzer-Smartcard durch eine andere Smartcard ersetzt), wird die Sitzung bei Schritt 775 durch die vertrauenswürdige Vorrichtung 24 beendet. Andernfalls wiederholt sich der Prozeß aus Schritt 745 bei Schritt 770, indem die Intervallzeitgebungseinrichtung neu eingestellt wird.
Die Techniken des Signierens, Verwendens von Zertifikaten und Herausforderung/Antwort sowie des Verwendens derselben, um eine Identität zu beweisen, sind Fachleuten auf dem Gebiet der Sicherheit hinreichend bekannt und werden deshalb in dem vorliegenden Dokument nicht ausführlicher beschrieben.
Unter Bezugnahme auf 21 und 8 bis 13 wird nun eine modifizierte Form des oben unter Bezugnahme auf 1 bis 7 beschriebenen Systems beschrieben. Diese modifizierte Form ist Gegenstand der am 15. Februar 2000 eingereichten internationalen Patentanmeldung Nr. PCT/GB00/00504. In 21 weist ein Host-Computer 100 eine Haupt-CPU 102 (CPU = Zen tralverarbeitungseinheit), ein Festplattenlaufwerk 104, eine PCI-Netzwerkschnittstellenkarte 106 und einen DRAM-Speicher 108 mit herkömmlichen („normalen") Kommunikationswegen 110 (beispielsweise ISA, EISA, PCI, USB) zwischen denselben auf. Die Netzwerkschnittstellenkarte 106 weist ferner einen externen Kommunikationsweg 112 mit der Welt außerhalb des Host-Computers 100 auf.
Die Netzwerkschnittstellenkarte 106 ist logisch in „rote" und „schwarze" Datenzonen 114, 116 unterteilt, wobei zwischen denselben eine Schnittstelle 118 vorliegt. In der roten Zone 114 sind Daten üblicherweise einfacher Text, und sie sind empfindlich und anfällig in Bezug auf eine nicht erfaßbare Änderung und unerwünschtes Lauschen. In der schwarzen Datenzone 116 werden Daten vor einer nicht erfaßten Änderung und einem unerwünschten Lauschen geschützt (vorzugsweise durch standardmäßige Kryptomechanismen verschlüsselt). Die Schnittstelle 118 gewährleistet, daß rote Informationen nicht in die schwarze Zone 116 eindringen. Die Schnittstelle 118 verwendet vorzugsweise standardmäßige Kryptoverfahren und elektronische Isolationstechniken, um die rote und die schwarze Zone 114, 116 zu trennen. Der Entwurf und Aufbau einer derartigen roten und schwarzen Zonen 114, 116 und der Schnittstelle 118 ist Fachleuten auf dem Gebiet der Sicherheit und Elektronik, insbesondere auf militärischem Gebiet, hinreichend bekannt. Der normale Kommunikationsweg 110 und der externe Kommunikationsweg 112 sind mit der schwarzen Zone 116 der Netzwerkschnittstellenkarte 106 verbunden.
Der Host-Computer 100 umfaßt ferner ein vertrauenswürdiges Modul 120, das nicht nur mit den normalen Kommunikationswegen 110, sondern auch durch zueinander separate zusätzliche Kommunikationswege 122 (mit den Teilreferenzen 122a, 122, 122c versehen) mit der CPU 102, dem Festplattenlaufwerk 104 und der roten Zone 114 der Netzwerkschnittstellenkarte 106 verbunden ist. Beispielsweise weist das vertrauenswürdige Modul 120 keinen derartigen separaten zusätzlichen Kommunikationsweg 122 mit dem Speicher 108 auf.
Das vertrauenswürdige Modul 120 kann über die zusätzlichen Kommunikationswege 122a, b bzw. c mit der CPU 102, dem Festplattenlaufwerk 104 und der roten Zone 114 der Netzwerkschnittstellenkarte 106 kommunizieren. Es kann ferner über die normalen Kommunikationswege 110 mit der CPU 102, dem Festplattenlaufwerk 104, der schwarzen Zone 116 der Netzwerkschnittstellenkarte 106 und dem Speicher 108 kommunizieren. Das vertrauenswürdige Modul 120 kann ferner als 100VG-Schaltzentrum agieren, um bestimmte Informationen zwischen der CPU 102, dem Festplattenlaufwerk 104 und der roten Zone 114 der Netzwerkschnittstellenkarte 106 über das vertrauenswürdige Modul 120 und die zusätzlichen Kommunikationswege 122 unter Steuerung einer in dem vertrauenswürdigen Modul gespeicherten Richtlinie zu leiten. Das vertrauenswürdige Modul 120 kann ferner kryptographische Schlüssel erstellen und diese Schlüssel an die CPU 102, das Festplattenlaufwerk 104 und die rote Zone 114 der Netzwerkschnittstellenkarte 106 über die zusätzlichen Kommunikationswege 122a, b bzw. c verteilen.
8 veranschaulicht die physische Architektur des vertrauenswürdigen Moduls 120. Eine erste Schaltmaschine 124 ist separat mit den zusätzlichen Kommunikationswegen 122a, b, c verbunden und ist ferner mit einem internen Kommunikationsweg 126 des vertrauenswürdigen Moduls 120 verbunden. Diese Schaltmaschine 124 unterliegt der Steuerung einer in das vertrauenswürdige Modul 120 geladenen Richtlinie. Andere Komponenten des vertrauenswürdigen Moduls 120 sind:

– eine Rechenmaschine 128, die das vertrauenswürdige Modul 120 verwaltet und ein Mehrzweckberechnen für das vertrauenswürdige Modul 120 durchführt;
– ein flüchtiger Speicher 130, der vorübergehende Daten speichert;
– ein nicht-flüchtiger Speicher 132, der langfristige Daten speichert;
– kryptographische Maschinen 134, die spezielle Kryptofunktionen, beispielsweise Verschlüsselung und Schlüsselerstellung, durchführen;
– eine Zufallszahlenquelle 136, die vorwiegend bei Kryptooperationen verwendet wird;
– eine zweite Umschaltmaschine 138, die das vertrauenswürdige Modul 120 mit den normalen Kommunikationswegen 110 verbindet; und
– Manipulationserfassungsmechanismen 140,

126

120

Das vertrauenswürdige Modul 120 beruht auf einer vertrauenswürdigen Vorrichtung oder einem vertrauenswürdigen Modul 24, wie sie bzw. es oben unter Bezugnahme auf 1 bis 7 ausführlicher beschrieben wurde.
In bezug auf eine Kryptoschlüsselerzeugung und -verteilung erzeugt das vertrauenswürdige Modul 120 unter Verwendung des Zufallszahlengenerators 136, eines Hash-Algorithmus und anderer Algorithmen, die an sich alle Fachleuten auf dem Gebiet der Sicherheit bekannt sind, kryptographische Schlüssel. Das vertrauenswürdige Modul 120 verteilt ausgewählte Schlüssel an die CPU 102, das Festplattenlaufwerk 104 und die rote Zone 114 der Netzwerkschnittstellenkarte 106 unter Verwendung der zusätzlichen Kommunikationswege 122a, b, c statt der normalen Kommunikationswege 110. Schlüssel können für Kommunikationen zwischen den internen Modulen 102, 104, 106, 120 der Plattform über die normalen Kommunikationswege 110 verwendet werden. Andere vorüberge hende Schlüssel können (durch die Netzwerkschnittstellenkarte 106 oder die CPU 102) für eine Massenverschlüsselung oder -entschlüsselung von externen Daten unter Verwendung des SSL-Protokolls verwendet werden, nachdem das vertrauenswürdige Modul 120 die SSL-Quittungsaustauschstufe, die langfristige Identitätsgeheimnisse verwendet, die nicht außerhalb des vertrauenswürdigen Moduls 120 offenbart werden dürfen, abgeschlossen hat. Andere vorübergehende Schlüssel können (durch das Festplattenlaufwerk 104 oder die CPU 102) zum Zweck einer Massenverschlüsselung oder -entschlüsselung von Daten, die auf dem Festplattenlaufwerk 104 gespeichert sind, verwendet werden, nachdem diese vorübergehenden Schlüssel unter Verwendung langfristiger Geheimnisse, die nicht außerhalb des vertrauenswürdigen Moduls 120 offenbart werden dürfen, in dem vertrauenswürdigen Modul 120 erzeugt oder offenbart wurden.
Das vertrauenswürdige Modul 120 setzt eine Richtliniensteuerung in bezug auf Kommunikationen zwischen Modulen durch die selektive Verteilung von Verschlüsselungsschlüsseln durch. Das vertrauenswürdige Modul 120 setzt eine Richtliniensperre in bezug auf Kommunikationen zwischen gegebenen Paaren von Modulen durch, indem es es ablehnt, Schlüssel auszugeben, die sichere Kommunikationen über die gemeinsam verwendete Infrastruktur 110 zwischen diesen Paaren von Modulen ermöglichen.
9 veranschaulicht einen Prozeß, anhand dessen das vertrauenswürdige Modul 120 eine Überwachungsfunktion durchführen und die Module 102, 104, 106, die mit den zusätzlichen Kommunikationswegen 122 verbunden sind, „anklingeln" („ping") kann. Das vertrauenswürdige Modul erzeugt eine Herausforderung 142 und sendet sie unter Verwendung der zusätzlichen Kommunikationswege 122a, b bzw. c an die CPU 102, das Festplattenlaufwerk 104 bzw. die rote Zone 114 der Netzwerkschnittstellenkarte 106. Sowohl die CPU 102, das Festplattenlaufwerk 104 als auch die Netzwerkschnittstellenkarte 106 antworten mit einer Antwort 144a, b bzw. c auf dem jeweiligen zusätzlichen Kommunikationsweg 122a, b, c, um zu sagen, ob das jeweilige Modul aktiv ist, und vorzugsweise, daß das Modul ordnungsgemäß arbeitet. Das vertrauenswürdige Modul 120 notiert die Antworten 144a, b, c und verwendet sie als Metriken in seinen Antworten auf Integritätsherausforderungen, die oben unter Bezugnahme auf 1 bis 7 beschrieben sind.
10 veranschaulicht den Prozeß, anhand dessen ankommende externe sichere Nachrichten verarbeitet werden, wenn das vertrauenswürdige Modul 120 das einzige Modul in der Plattform mit kryptographischen Fähigkeiten ist. Unter Verwendung des externen Kommunikationsweges 112 wird durch die schwarze Zone 116 der Netzwerkschnittstellenkarte 106 eine externe Nachricht 146 empfangen. Die Netzwerkschnittstellenkarte 106 sendet unter Verwendung der normalen Kommunikationswege 110 eine Protokolldateneinheit 148 (die später ausführlich beschrieben werden soll), die einige Daten und eine Anforderung bezüglich einer Authentifizierung und Integritätsprüfung enthält, an das vertrauenswürdige Modul 120. Das vertrauenswürdige Modul 120 führt die Authentifizierung und Integritätsprüfungen unter Verwendung der langfristigen Schlüssel in dem vertrauenswürdigen Modul 120, die nicht außerhalb des vertrauenswürdigen Moduls 120 offenbart werden dürfen, durch und sendet unter Verwendung des zusätzlichen Kommunikationswegs 122c eine Protokolldateneinheit 150, die eine „OK"-Anzeige enthält, an die rote Zone 114 der Netzwerkschnittstellenkarte 106. Die Netzwerkschnittstellenkarte 106 sendet dann unter Verwendung der normalen Kommunikationswege 110 eine Protokolldateneinheit 152, die einige Daten und eine Anforderung bezüglich einer Entschlüsselung enthält, an das vertrauenswürdige Modul 120. Das vertrauenswürdige Modul 120 entschlüsselt die Daten entweder unter Verwendung vorübergehender oder langfristiger Schlüssel in dem vertrauenswürdigen Modul 120 und sendet unter Verwendung des zusätzlichen Kommunikationswegs 122a eine Protokolldateneinheit 154, die die entschlüssel ten Daten enthält, an die CPU 102. Die CPU leitet dann entsprechende Schritte ein.
11 veranschaulicht den Prozeß, anhand dessen die CPU 102 eine Richtlinienentscheidung von dem vertrauenswürdigen Modul 120 anfordert. Dies könnte beispielsweise verwendet werden, wenn die CPU 102 bestimmen muß, ob eine Richtlinie erlaubt, daß bestimmte Daten manipuliert werden oder eine Anwendung ausgeführt wird. Dies wird später unter Bezugnahme auf 14 bis 20 ausführlicher beschrieben. Die CPU 102 sendet eine Protokolldateneinheit 156, die eine Anforderung enthält, unter Verwendung der normalen Kommunikationswege 110 an das vertrauenswürdige Modul 120. Das vertrauenswürdige Modul 120 verarbeitet die Anforderung 156 gemäß der in dem vertrauenswürdigen Modul 120 gespeicherten Richtlinie. Das vertrauenswürdige Modul 120 sendet eine Protokolldateneinheit 158, die eine Antwort enthält, unter Verwendung des zusätzlichen Kommunikationswegs 122a an die CPU 102, damit die CPU 102 sicher sein kann, daß die Autorisierung von dem vertrauenswürdigen Modul 120 kam. Falls die Handlung autorisiert wird, leitet die CPU 102 die notwendigen Schritte ein. Andernfalls bricht sie den Prozeß ab.
12 veranschaulicht ein Beispiel der Richtliniensteuerung in bezug auf geschützte Kommunikationen zwischen den Modulen 102, 104, 106. Alle Kommunikationen in diesem Beispiel verwenden die zusätzlichen Kommunikationswege 122. Die rote Zone 114 der Netzwerkschnittstellenkarte 106 sendet eine Protokolldateneinheit 160, die für das Festplattenlaufwerk 104 bestimmt ist, auf dem zusätzlichen Datenweg 122c an das vertrauenswürdige Modul 120. In dem Fall, in dem die Richtlinie dies nicht erlaubt, lehnt das vertrauenswürdige Modul 120 die Anforderung ab, indem es eine Protokolldateneinheit 162, die eine Ablehnung enthält, auf dem zusätzlichen Datenweg 122c an den Netzwerkschnittstellenkarte 106 sendet. Später fordert die CPU 102 sensible Daten von dem Festplattenlaufwerk 104 an, indem sie eine an das Festplattenlaufwerk adressierte Protokolldateneinheit 164 sendet, wobei diese jedoch auf dem zusätzlichen Datenweg 122a an das vertrauenswürdige Modul 120 gesendet wird. Das vertrauenswürdige Modul 120 prüft, daß die Richtlinie dies erlaubt. In dem Fall, in dem sie das tut, leitet das vertrauenswürdige Modul 120 die Protokolldateneinheit 164 auf dem zusätzlichen Datenweg 122b an das Festplattenlaufwerk 104 weiter. Das Festplattenlaufwerk 104 stellt die Daten bereit und sendet sie in einer Protokolldateneinheit 166 auf dem zusätzlichen Datenweg 122b an das vertrauenswürdige Modul 120 zurück, und zwar an die CPU 102 adressiert. Das vertrauenswürdige Modul 120 prüft, daß die Richtlinie dies erlaubt, und in dem Fall, in dem sie das tut, leitet es die Protokolldateneinheit 166 auf dem zusätzlichen Datenweg 122a an die CPU 102 weiter.
13 veranschaulicht das Format der Datenprotokolleinheiten 178, anhand derer Daten über die zusätzlichen Kommunikationswege 122 geleitet werden. Die Datenprotokolleinheit 178 weist folgendes auf:

– ein Identifiziererfeld 168, das den Typ der Protokolldateneinheit angibt;
– ein Längenfeld 170, das die Länge der Protokolldateneinheit angibt;
– ein Quellenfeld 172, das die Quelle der Protokolldateneinheit angibt;
– ein Zielortfeld 174, das den Zielort der Protokolldateneinheit angibt;
– und so weiter, einschließlich, in vielen Fällen, eines Datenfeldes 176.

Es sind nicht immer alle Felder notwendig. Wenn man beispielsweise annimmt, daß die Richtlinie des vertrauenswür digen Moduls 120 es demselben verbietet, Schlüsselprotokolldateneinheiten weiterzuleiten, die nicht in dem vertrauenswürdigen Modul 120 entstanden, können die CPU 102, das Festplattenlaufwerk 104 und die Netzwerkschnittstellenkarte 106 somit annehmen, daß Schlüssel immer von dem vertrauenswürdigen Modul 120 stammen. Somit sind Quellen- und Zielortfelder bei Schlüsselprotokolldateneinheit unnötig – derartige Protokolldateneinheiten werden auf implizite Weise authentifiziert. Der Entwurf, der Aufbau sowie die Verwendung an sich von Protokolldateneinheiten sind Fachleuten auf dem Gebiet der Kommunikation hinreichend bekannt.
Das spezifische Ausführungsbeispiel der vorliegenden Erfindung wird nun unter Bezugnahme auf 14 bis 20 beschrieben. 14 veranschaulicht das physische System und ist eine Weiterführung des oben unter Bezugnahme auf 21 und 7 bis 13 beschriebenen Systems. Bei 14 ist eine Anzeige 121 mittels eines 122d der zusätzlichen Kommunikationswege, wie sie oben beschrieben wurden, mit dem vertrauenswürdigen Modul 120 verbunden. Dies befähigt das vertrauenswürdige Modul 120, ohne Angst vor einer Untergrabung bzw. Subversion von einer normalen Software, einschließlich des Betriebssystems, auf zuverlässige Weise an die Anzeige zu schreiben. Ferner ist der Host-Computer 100 mit einer Tastatur 101 verbunden, die eine eingebaute Smartcard-Lesevorrichtung 103 aufweist, die beide mit den normalen Kommunikationswegen 110 verbunden sind. Eine Smartcard, die in die Smartcard-Lesevorrichtung 103 eingeführt ist, kann als ein zusätzliches vertrauenswürdiges Modul angesehen werden und ist somit in der Lage, auf sichere Weise mit dem vertrauenswürdigen Modul 120 zu kommunizieren.
15 veranschaulicht ein logisches Diagramm der Komponenten des vertrauenswürdigen Moduls 120, die Lizenzierungscodekomponenten 200 und andere Lizenzierungsdatenkomponenten 202 in dem vertrauenswürdigen Modul 120 umfassen. Die Lizenzierungscodekomponenten 200 laufen in einer geschützten Umgebung, wie zuvor beschrieben wurde, und vor zugsweise in dem vertrauenswürdigen Modul 120 selbst; sie umfassen: eine sichere Ausführeinrichtung 204, eine sichere Ladeeinrichtung 206, einen Code für einen sicheren Schlüsseltransfer 208 und eine Client-Bibliothek 210. Die lizenzbezogenen Datenkomponenten 202, die in dem vertrauenswürdigen Modul 120 gespeichert sind, umfassen den privaten Schlüssel 212 des vertrauenswürdigen Moduls 120, das Öffentlicher-Schlüssel-Zertifikat 214 einer vertrauenswürdigen Entität, das Öffentlicher-Schlüssel-Zertifikat 216 der Verrechnungsinstanz oder des Entwicklers, ein Lizenzierungsprotokoll 218 und eine hash-codierte Version 220 des lizenzbezogenen Codes 200, die mit dem privaten Schlüssel der vertrauenswürdigen Entität, die das Öffentlicher-Schlüssel-Zertifikat 214 aufweist, signiert ist.
16 veranschaulicht die Struktur einer geschützten Software oder von geschützten Daten 222 in dem Client-Computer 100. Digitale Daten 224 auf dem Client-Computer 100 sind einer entsprechenden Software-Ausführeinrichtung 226 zugeordnet, in der der öffentliche Schlüssel 228 des vertrauenswürdigen Moduls 120 gespeichert ist. Diese Struktur 230 ist zusammen mit einer hash-codierten Version 232 hiervon, die mit dem privaten Schlüssel der Verrechnungsinstanz oder des Entwicklers signiert ist, gespeichert. Für jede Einheit einer geschützten Software oder von geschützten Daten gibt es eine Struktur, die zu der sich ergebenden Einheit 222 analog ist.
17 veranschaulicht das Flußdiagramm zum Laden oder Hochrüsten von Software oder anderen Daten auf die Client-Plattform, für den allgemeinen Fall, in dem die sichere Ladeeinrichtung 206 eventuell nicht in dem vertrauenswürdigen Modul 120 läuft.
Die zu installierenden Daten werden hash-codiert und mit dem privaten Schlüssel des Senders signiert, und dieser wird durch den Sender an die Daten selbst angehängt.
Bei Schritt 234 sendet das Betriebssystem zusammen mit den Daten und der signierten hash-codierten Version eine Anforderung an die sichere Ladeeinrichtung 206, daß die Daten installiert werden sollen. Bei Schritt 236 empfängt die sichere Ladeeinrichtung 206 die Anforderung, und bei Schritt 238 prüft sie die Signatur dieser Nachricht unter Verwendung des Öffentlicher-Schlüssel-Zertifikats, das dem Sender entspricht, wodurch sie die Authentifizierung des Senders prüft.
Falls die Authentifizierung negativ ausfällt, sendet die sichere Ladeeinrichtung 206 bei Schritt 240 eine Fehlernachricht an das Betriebssystem. Bei Schritt 242 empfängt das Betriebssystem diese Fehlernachricht und zeigt bei Schritt 244 eine entsprechende Nachricht an.
Falls die Authentifizierung bei Schritt 238 erfolgreich ist, berechnet die sichere Ladeeinrichtung 206 bei Schritt 246 den Hash-Wert der Nachricht über die in dem vertrauenswürdigen Modul 120 zur Verfügung stehenden kryptographischen Fähigkeiten und vergleicht ihn bei Schritt 248 mit dem Nachricht-Hash-Wert, der den Daten zugeordnet ist und bei Schritt 236 empfangen wurde. Dies prüft die Integrität der Nachricht.
Falls die Hash-Werte nicht dieselben sind, deutet dies darauf hin, daß die Daten geändert wurden und daß sie nicht installiert werden sollten. In diesem Fall sendet die sichere Ladeeinrichtung 206 bei Schritt 250 eine Fehlernachricht an das OS, das dann die oben beschriebenen Schritte 242, 244 durchführt.
Falls sich die Hash-Werte bei Schritt 248 als dieselben erweisen, erzeugt das vertrauenswürdige Modul 120 bei Schritt 252 ein Protokoll der Installation, und bei Schritt 254 weist die sichere Ladeeinrichtung 206 das OS darauf hin, daß die Daten wie üblich installiert werden können, was dann bei Schritt 256 geschieht.
Falls andere Prüfungsformen (insbesondere Lizenzprüfungen) zusätzlich oder alternativ verwendet werden sollen, können diese zwischen den Schritten 250 und 252 in dem oben unter Bezugnahme auf 17 beschriebenen Verfahren enthalten sein.
18 veranschaulicht das Flußdiagramm zum Lizenzieren unter Verwendung eines Modells eines Lizenzprüfens, bei dem das OS mit der sicheren Ausführeinrichtung 204 kommuniziert und die Software-Ausführeinrichtung 226, die einer Dateneinheit zugeordnet ist, die Option hat, das Lizenzierungsmodell, das zum Schutz jener Daten verwendet werden soll, zu wählen. Dies gilt wiederum für den allgemeinen Fall, bei dem in dem vertrauenswürdigen Modul 120 nicht unbedingt eine Lizenzierungssoftware angebracht ist. Die Prozedur lautet wie folgt:
Wenn der Benutzer einige digitale Daten ablaufen lassen möchte, wird bei Schritt 258 eine Anforderung durch das Betriebssystem gesandt, die bei Schritt 260 durch die sichere Ausführeinrichtung 204 empfangen wird. Bei Schritt 262 erzeugt die sichere Ausführeinrichtung 206 eine Zufallszahl (Einmalverfügung) und gibt bei Schritt 264 eine Herausforderung/Antwort an die Software-Ausführeinrichtung 226 aus, die jener Dateneinheit entspricht, indem sie die Einmalverfügung zusammen mit einer Bezugnahme auf die Anwendung (z.B. ihren Titel), wobei sie unter Verwendung des privaten Schlüssels 212 des vertrauenswürdigen Moduls 120 signiert ist, sendet.
Im Anschluß an den Empfang bei Schritt 266 durch die Software-Ausführeinrichtung 226 verifiziert und authentifiziert sie bei Schritt 268 die Herausforderung der sicheren Ausführeinrichtung unter Verwendung des öffentlichen Schlüssels 228 des vertrauenswürdigen Moduls 120. Falls ein Fehler vorliegt oder falls die Software-Ausführeinrichtung 226 nicht wünscht, daß die Daten an dieser bestimmten Maschine ausgeführt werden, wird bei Schritt 270 eine Fehlernachricht gesandt, die durch die sichere Ausführeinrichtung 204 bei Schritt 272 an das Betriebssystem weitergeleitet wird. Im Anschluß an einen Empfang einer derartigen Fehlermeldung bei Schritt 274 zeigt das Betriebssystem bei Schritt 276 eine entsprechende Fehlermeldung an, und die Daten werden nicht ausgeführt.
Falls bei Schritt 268 kein Fehler vorliegt, gibt die Software-Ausführeinrichtung 226 bei Schritt 278 eine Nachricht an die sichere Ausführeinrichtung 204 zurück, die die Einmalverfügung, die Bezugnahme auf die Daten und optional ein Lizenzierungsmodell beinhaltet. Die Einmalverfügung ist enthalten, um einen Schutz vor Wiedergabeattacken zu liefern.
Nachdem sie die Nachricht bei Schritt 280 empfangen hat, führt die sichere Ausführeinrichtung 204 bei Schritt 282 die entsprechende Lizenzierungsprüfung in Abhängigkeit von dem durch die Software-Ausführeinrichtung spezifizierten Lizenzierungsmodell durch. Dies kann ein Entriegeln der Daten unter Verwendung eines Schlüssels beinhalten. Weitere Details dieser Lizenzierungsmodelle werden später betrachtet. Falls den Daten keine Software-Ausführeinrichtung zugeordnet ist, führt die sichere Ausführeinrichtung eine Lizenzierungsprüfung entsprechend einem Standardlizenzierungsmodell durch, das zuvor durch einen Administrator in derselben eingestellt wurde. Falls eine gültige Lizenz vorliegt, bittet die sichere Ausführeinrichtung 204 bei Schritt 284 das vertrauenswürdige Modul 120, eine Meßaufzeichnung der Transaktion durchzuführen, Schritte 286, 288, und sendet bei Schritt 290 eine Erlaubnis an das Betriebssystem, die Daten auszuführen. Auf einen Empfang bei Schritt 292 hin führt das Betriebssystem die Daten bei Schritt 294 aus. Im Anschluß an die Lizenzierungsprüfung bei Schritt 282, falls keine gültige Lizenz vorliegt, bittet die sichere Ausführeinrichtung 204 bei Schritt 296 das Betriebssystem, den Endbenutzer entsprechend zu benachrich tigen, Schritte 274, 276, und die Daten werden nicht ausgeführt.
19 ist ein Flußdiagramm zum Lizenzieren unter Verwendung eines Modells eines Lizenzierungsprüfens, bei dem das OS mit den Software-Ausführeinrichtungen 226 statt der sicheren Ausführeinrichtung 204 kommuniziert. Dies gilt wiederum für den allgemeinen Fall, bei dem in dem vertrauenswürdigen Modul 120 nicht unbedingt eine Lizenzierungssoftware angebracht ist.
Wenn der Benutzer manche Daten ausführen möchte, sendet das OS bei Schritt 298 eine Nachricht an die den Daten zugeordnete Software-Ausführeinrichtung 226, wobei die Nachricht bei Schritt 300 empfangen wird. Bei Schritt 302 erzeugt die Software-Ausführeinrichtung 226 eine Zufallszahl (Einmalverfügung) und gibt bei Schritt 304 eine Herausforderung/Antwort an die sichere Ausführeinrichtung 204 in dem vertrauenswürdigen Modul 120 aus, indem sie die Einmalverfügung zusammen mit einer Bezugnahme auf die Daten sendet. Zusätzlich wird eine Smartcard-ID gesandt, falls dieselbe verwendet wurde, um sich in die Client-Maschine einzuloggen und falls Hot-Desking das zu verwendende Lizenzierungsmodell ist.
Im Anschluß an einen Empfang der Nachricht bei Schritt 306 führt die sichere Ausführeinrichtung 204 bei Schritt 308 eine entsprechende Lizenzierungsprüfung der Daten durch. Falls keine gültige Lizenz vorliegt, gibt die sichere Ausführeinrichtung 204 bei Schritt 310 eine Fehlermeldung zurück, von der die Software-Ausführeinrichtung die genaue Art des Problems in Bezug auf die Lizenzierung bestimmen könnte, und benachrichtigt das OS entsprechend, Schritte 312, 314, 316.
Falls eine gültige Lizenz vorliegt, gibt die sichere Ausführeinrichtung 204 bei Schritt 318 eine Nachricht zurück, die die Einmalverfügung und Bezugnahme auf die Daten ent hält und unter Verwendung des privaten Schlüssels 212 des vertrauenswürdigen Moduls 120 signiert und verschlüsselt ist. Die Einmalverfügung ist enthalten, um einen Schutz vor Wiedergabeattacken zu liefern.
Im Anschluß an den Empfang der Nachricht bei Schritt 320 verifiziert die Software-Ausführeinrichtung 226 bei Schritt 322 unter Verwendung des Öffentlicher-Schlüssel-Zertifikats 228 des vertrauenswürdigen Moduls 120, ob die Antwort der sicheren Ausführeinrichtung korrekt ist. Falls sie korrekt ist, bittet die Software-Ausführeinrichtung 226 bei Schritt 324 das vertrauenswürdige Modul 120, ein Protokoll zu erzeugen, Schritte 326, 328, und leitet bei Schritt 330 den Anruf an das OS, um die Daten auszuführen, Schritte 332, 334. Falls sie jedoch nicht korrekt ist, sendet die Software-Ausführeinrichtung 226 bei Schritt 336 eine Fehlermeldung an das OS, das dann entsprechend eine Fehlermeldung anzeigt, Schritte 314, 316.
Bei einem bevorzugten Mechanismus zum Durchsetzen von Prüfungen bezüglich einer Erlaubnis, digitale Daten auszuführen, umfaßt das vertrauenswürdige Modul 120 die Hardware und/oder speichert die Software, die verwendet wird, um die Erfindung zu implementieren. Insbesondere agiert das vertrauenswürdige Modul 120 als Brücke zwischen einer Anwendung und dem OS. Das OS ignoriert vorzugsweise alle Anforderungen, Anwendungen zu laden oder zu betreiben, mit Ausnahme derjenigen von dem vertrauenswürdigen Modul 120, die über einen Kommunikationsweg 122 zwischen dem vertrauenswürdigen Modul 120 und der CPU 102, die für gewöhnliche Anwendungen und Nicht-OS-Software vorzugsweise unzugänglich ist, gegeben werden. Die Prozesse laufen wie folgt an dem Host-Computer ab. Zuerst liegt eine anfängliche Anforderung an das vertrauenswürdige Modul 120 vor, eine Anwendung oder andere Daten auszuführen, vorzugsweise über die Software-Ausführeinrichtung 226, die diesen Daten zugeordnet ist, und üblicherweise ansprechend auf eine Handlung durch den Endbenutzer. Die Software-Ausführeinrichtung 226 enthält das Öffentlicher-Schlüssel-Zertifikat 228 des vertrauenswürdigen Moduls 120, auf dem die Daten installiert sind oder werden sollen. Die sichere Ausführeinrichtung 204 in dem vertrauenswürdigen Modul 120 führt ein entsprechendes Lizenzprüfen durch, wie oben erläutert wurde. Falls das Ergebnis dieses Prüfens dahingehend ausfällt, daß es angemessen ist, die Daten auszuführen, vermittelt die sichere Ausführeinrichtung 204 diese Informationen an das OS über einen Kommunikationsweg 122 an die CPU 102, die vorzugsweise für gewöhnliche Anwendungen und Nicht-OS-Software unzugänglich ist. Das OS beginnt dann einen Prozeß an dem Host, um die Anwendung oder Daten auszuführen. Ein analoger Prozeß wird ausgeführt, wenn die sichere Ladeeinrichtung mit dem OS kommuniziert, um anzugeben, daß eine Dateninstallation angemessen ist, oder wenn der Schlüsseltransfercode mit dem OS kommuniziert, um Entriegelungsschlüssel zu transferieren.
20 veranschaulicht das Flußdiagramm zum Lizenzieren unter Verwendung eines Modells eines Lizenzprüfens, wie es oben verwendet wurde, bei dem die Lizenzierungssoftware in dem vertrauenswürdigen Modul 120 gespeichert ist und das vertrauenswürdige Modul 120 als eine Brücke zwischen einer Anwendung und dem OS agiert. Der Prozeß ist ähnlich dem in 19 gezeigten, mit der Ausnahme, daß sich die sichere Ausführeinrichtung 204 in dem vertrauenswürdigen Modul 120 selbst befindet und daß die sichere Ausführeinrichtung 120 einen Kommunikationsweg 122 (vorzugsweise zweckgebunden) von dem vertrauenswürdigen Modul 120 zu der CPU 102 verwendet, wenn sie mit dem OS kommuniziert.
Diese Erfindung kann auf viele verschiedene Arten und Weisen verwendet werden. Es werden nun Einzelheiten von sechs dieser Arten und Weisen präsentiert.
Beispiel A
Ein erstes Beispiel besteht darin, eine manipulationsresistente Hardware als einen generischen Dongle zu verwenden, indem Anwendungen an die Hardware gebunden werden. Die Hauptunterschiede zwischen diesem Beispiel und den anderen Beispielen in diesem Abschnitt sind zunächst, daß ein Lizenzierungsschutz durchgeführt wird, wenn der Code in der Tat ausgeführt wird, und zweitens, daß dieses Verfahren für einen Schutz von Anwendungen geeignet ist, für die der Partei, die den Schutzmechanismus ausführt, ein Quellcode zur Verfügung steht.
Es wird eine Software in die Plattform (und optional in die manipulationsresistente Hardware, wo eine solche betrieben wird) geladen. Die Software wird unter Verwendung der sicheren Ladeeinrichtung auf ihre Integrität hin überprüft. API-Anrufe an das vertrauenswürdige Modul werden verwendet, um das Vorliegen eines Geheimnisses in dem vertrauenswürdigen Modul zu überprüfen oder um die Identität und das Vorhandensein des vertrauenswürdigen Moduls zu prüfen. Zusätzlich kann das vertrauenswürdige Modul dazu gebracht werden, einen Teil des Codes auszuführen. Eine starke Authentifizierung des vertrauenswürdigen Moduls ist möglich, indem der private kryptographische Schlüssel des vertrauenswürdigen Moduls und standardmäßige Authentifizierungsprotokolle verwendet werden.
Ferner gibt es folgende Optionen:

– API-Anrufe können statt an das OS auch an das vertrauenswürdige Modul durchgeführt werden (wie zuvor erörtert wurde).
– Das vertrauenswürdige Modul kann dazu gebracht werden, einen Teil des Codes auszuführen. Dies kann auf verschiedene Arten und Weisen, von denen einige bereits erörtert wurden, geschehen.
– Ein Teil des Codes könnte für einen Transfer in eine manipulationsresistente Hardware (beispielsweise das interne vertrauenswürdige Modul oder eine SmartCard) vermarktet werden, wo er in einer verschlüsselten Form gespeichert werden könnte, und Anrufe bezüglich dieser Funktionalität könnten andernorts in dem Code durchgeführt werden.
– Analog können tragbare vertrauenswürdige Module wie beispielsweise Smartcards dazu gebracht werden, einen Teil des Codes auszuführen.

Die Verwendung dieses Verfahrens statt der analogen Verwendung von API-Anrufen zu einem Hardware-Dongle wirkt vielen der Nachteile, die normalerweise mit diesem Lösungsansatz in Verbindung gebracht werden, entgegen.
Erstens ist ein traditioneller Software-Schutz, der API-Anrufe zu einem Hardware-Dongle verwendet, für eine Modifizierung von Software-Verriegelungen über einen Debugger (beispielsweise durch Durchschreiten von Kommunikationen zwischen Prozessoren und der Hauptplatine) oder Disassembler anfällig, wodurch der Code geändert wird, um Anrufe zu dem Schlüssel zu entfernen. Modifizierte Kopien des Codes werden produziert und sowohl auf der Hostmaschine als auch auf anderen Maschinen frei betrieben. Dem kann bei diesem Verfahren durch folgendes entgegengewirkt werden:

– Ein Teil des Codes wird in dem vertrauenswürdigen Modul selbst betrieben.
– Integritätsprüfungen der Plattform und zugeordneten Software, die sicherstellen, daß ein zugeordneter Lizenzprüfungscode zusammen mit der Software geladen werden muß, und die verhindern, daß Lizenzprüfungen umgangen werden.

Zweitens besteht derzeit eine Gefahr, daß Aufnahme und Wiedergabe (oder andere Techniken) verwendet werden könnten, um einen Teil der fehlenden Verarbeitungsfunktionalität, die auf Hardware ausgeführt wird, zu kompensieren. Dem wird bei diesem Verfahren durch Integritätsprüfungen der Software und des Lizenzprüfungscodes entgegengewirkt.
Drittens besteht bei dem Lizenzierungsmodell eine viel größere Flexibilität, sowohl insofern, als die Lizenz nicht an die Maschine gebunden sein muß, als auch insofern, als eine größere Auswahl von Zahlungsmodellen vorliegt. Das vertrauenswürdige Modul stellt einen generischen Dongle bereit, der nicht nur auf eine spezifische Anwendung zugeschnitten ist, und liefert ferner eine größere Kapazität für ein Lizenzieren einer Informationsspeicherung sowie ein besseres Messen.
Schließlich gibt es Vorteile für den Entwickler, die auf seine Anstrengungen bezogen sind. Die Vorteile einer Hinzufügung von API-Anrufen zu der Software bestehen darin, daß die Software auf eine bestimmte Maschine zugeschnitten ist und somit an einer anderen Maschine nicht unmittelbar von Vorteil ist, auch wenn der ausführbare oder Quellcode im Klartext erhalten würde. Sie kann jedoch eine beträchtliche Anstrengung seitens des Entwicklers erfordern. Dadurch, daß der einzige Unterschied in einer anderen Vertrauenswürdiges-Modul-ID besteht, kann mit einem Schutz über ein Integritätsprüfen eines Codes mit nur sehr geringen Anstrengungen seitens des Entwicklers ein beträchtlicher Schutz erzielt werden. Wiederum erfordert ein Betreiben eines Teils des Codes in dem vertrauenswürdigen Modul selbst keine individuelle Kundenwunschanpassung des Codes.
Bei diesem Beispiel:

– kann der Entwickler eine beliebige Kombination der folgenden durchführen:
– API-Anrufe in die Software und/oder in eine Software-Ausführeinrichtung, die der Software zugeordnet ist, einführen. Diese prüfen:
– bezüglich des Vorliegens eines Geheimnisses in der manipulationsresistenten Vorrichtung (z.B. falls der Entwickler Smartcard-Dongles hergestellt und diese an die Endbenutzer versandt hat) oder
– bezüglich der Identität und des Vorliegens einer manipulationssicheren Vorrichtung in der Maschine des Endbenutzers (wobei diese als generischer Dongle verwendet wird).

Eine Software-Ausführeinrichtung führt allgemein nur bei Laufzeit eine Prüfung durch; weitere API-Anrufe in dem Code können, falls gewünscht, in verschiedenen Stufen während der Ausführung des Codes durchgeführt werden. Dies erfolgt auf eine allgemeine Weise für die Software (d.h. jeder Kunde erhält dieselbe Version), und kundengerechte Details wie beispielsweise die exakte Vertrauenswürdiges-Modul-ID können später, bei der unten beschriebenen Registrierungsstufe, hinzugefügt werden.

– Ein Geheimnis in die den Daten zugeordnete Software-Ausführeinrichtung einführen, zusammen mit Informationen, die die sichere Ausführeinrichtung in der Computerplattform davon benachrichtigen, daß das Lizenzierungsverfahren des Verwendens einer Prüfung bezüglich des Vorliegens eines Geheimnisses in dem vertrauenswürdigen Modul oder einer anderen vertrauenswürdigen Vorrichtung verwendet werden soll. Beispielsweise gibt Lizenzierungs_Verfahren (Geheimnis, sc, k, w) oder Lizenzierungs_Verfahren (Geheimnis, tc, k, w) an, daß die Software, auf die durch w verwiesen wird, lediglich dann auf einer Maschine laufen dürfen sollte, wenn das Geheimnis k in der aktuellen Smartcard oder der internen vertrauenswürdigen Komponente der Maschine gespeichert gefunden wird. Die sichere Ausführeinrichtung wird ein Protokoll vorab speichern lassen, das es ihr ermöglicht, diese Prüfung durchzuführen, und wird nicht erlauben, daß die Software w betrieben wird, wenn die Prüfung nicht erfolgreich ist.
– Der Benutzer läßt sich bei dem Entwickler registrieren. Als Teil des Initialisierungsvorgangs findet vorher (oder zur gleichen Zeit, gemäß den betreffenden Protokollen) eine Authentifizierung zwischen kommunizierenden Parteien in dem Lizenzierungssystem als Austausch von Sitzungsschlüsseln zum Zweck der Vertraulichkeit von Nachrichten, die zwischen denselben hin- und hergeleitet werden, statt (weitere Einzelheiten dieses Prozesses finden sich in Beispiel B). Entsprechend dem Entwickler werden der manipulationssicheren Komponente Öffentlicher-Schlüssel-Zertifikate gesandt. Im Gegenzug für eine Zahlung (1) wird ihm die allgemein kundengerecht gestaltete Software zusammen mit einer tragbaren hardwareresistenten Vorrichtung (beispielsweise einer Smartcard) gegeben, die (mittels Speicherung oder Festcodieren) das Geheimnis des Entwicklers enthält, bezüglich dessen in dem Code geprüft wird, oder ein Schlüssel wird an seine manipulationssichere Vorrichtung transferiert (beispielsweise durch ein Verfahren, das analog zu dem in Beispiel B nachstehend ausführlicher Erläuterten ist, mit der Ausnahme, daß dieser Schlüssel kein Entriegelungsschlüssel für eine Entschlüsselung der Software ist); (2) wird seine Maschinen-ID in die Software eingefügt (damit API-Anrufe bezüglich dieser bestimmten Maschinen-ID eine Prüfung durchführen), und wird die Software an ihn gesandt.
– Um Interaktionen zwischen der Anwendung und dem vertrauenswürdigen Modul zu steuern, muß der Entwickler zwei zusätzliche Komponenten an Kunden versenden, nämlich die Software-Ausführeinrichtung und die Client-Bibliothek. Die Client-Bibliothek ist eine Sammlung von auf hoher Ebene stattfindenden Schnittstellen-Teilroutinen, die die Anwendung aufruft, um mit der Software-Ausführeinrichtung zu kommunizieren.
– Die bzw. der oben in den vorherigen zwei Stufen beschriebene Software bzw. Code werden durch Verwendung einer hash-codierten Version der Nachricht signiert, die durch den an die Nachricht angehängten privaten Schlüssel des Senders signiert ist, so daß der Empfänger die Integrität der Nachricht prüfen kann. Deutlicher gesagt unterzieht der Entwickler den Code M einer Hash-Codierung und signiert ihn mit seinem privaten Schlüssel (Sprk) , um die Signatur Σ_Sprk(h(M)) zu erzeugen. Dann sendet er diese Signatur zusammen mit der Nachricht M.
– Die sichere Ladeeinrichtung prüft dann die Signatur unter Verwendung des öffentlichen Schlüssels des Entwicklers und gewinnt somit den Nachricht-Hash-Wert wieder. Dies garantiert, daß der Sender derjenige ist, dessen öffentlicher Schlüssel verwendet wurde, um die Signatur zu prüfen. Wenn sie die Nachricht und den Nachricht-Hash-Wert hat, kann die sichere Ladeeinrichtung dann den Hash-Wert der Nachricht berechnen und ihn mit dem Nachricht-Hash-Wert, den sie entschlüsselt hat, vergleichen. Dies prüft die Integrität der Nachricht. Ferner sollte der Integritätsprüfmechanismus Wiedergabeattacken durch einen gewissen Standardmechanismus – beispielsweise Herausforderung/Antwort, oder Einführen einer Historie der Kommunikationen in den Hash-Wert – verhindern.
– Falls die Integritätsprüfung funktioniert, installiert die sichere Ladeeinrichtung die Software. Dies gewährleistet, daß keine modifizierte Software (z.B. ohne API-Anrufe) betrieben werden kann, keine Viren eingeführt werden usw. Die Software kann ferner modifiziert werden, um das Vorliegen in der Plattform des vertrauenswürdigen Moduls beim Installieren zu prüfen.
– Wenn der Benutzer versucht, die Software zu betreiben, übernimmt die Software-Ausführeinrichtung die gesamte Steuerung und führt zu Beginn der Ausführung anfängliche Prüfungen durch. Falls diese Prüfungen erfolgreich sind, erlaubt die Software-Ausführeinrichtung, daß die Software betrieben wird. Falls zusätzliche API-Anrufe in die Software integriert wurden, werden diese an verschiedenen Punkten während der Laufzeit zu dem vertrauenswürdigen Modul durchgeführt.
– Zur gleichen Zeit, wie derartige Prüfungen durchgeführt werden, wird in dem vertrauenswürdigen Modul eine Aufstellung erstellt, falls die Software erfolgreich ausgeführt wurde. Bei manchen Zahlungsmodellen könnten die Nutzungsberichte an die Verrechnungsinstanz oder die Registrierungsinstanz gesandt werden. Es könnte ohne weiteres eine Zahlung einer gewissen Anzahl von Ausführungen von Software modelliert werden, z.B. unter Verwendung von Smartcards.

Beispiel B
Das zweite Beispiel verwendet das vertrauenswürdige Modul als einen generischen Dongle, indem Abschnitte von Daten oder alle Daten verschlüsselt werden. Wiederum liegt ein Integritätsprüfen der Daten, die durch die sichere Ladeeinrichtung ausgeführt werden sollen, vor, sowie eine Integri tätsprüfung der sicheren Ladeeinrichtung, der sicheren Ausführeinrichtung, der Software-Ausführeinrichtung und des sicheren Transfercodes. Die vertrauenswürdige Identität (privater Kryptoschlüssel) des vertrauenswürdigen Moduls wird verwendet, um eine starke Authentifizierung durchzuführen. Optional können Anwendungen in einem vertrauenswürdigen Modul oder einer Smartcard betrieben werden.
Der allgemeine Vorteil eines derartigen Lizenzierungssystems besteht darin, daß die Flexibilität von Lizenzverwaltungssystemen ohne den Nachteil von Donglen mit dem höheren Maß an Hardware-Sicherheit kombiniert werden kann.
Insbesondere wird Problemen mit aktuellen Lizenzierungsproblemen wie folgt entgegengewirkt:

– einem Umgehen von Lizenzierungsprüfungen wird durch eine Integritätsprüfung der Plattform entgegengewirkt, die negativ ausfällt, falls die vertrauenswürdige Vorrichtung entfernt oder manipuliert ist oder wenn die Lizenzierungssoftware geändert ist.
– Ein Nachteil aktueller generischer Datenschutzmethoden besteht darin, daß das Ausführbare, auch wenn die Daten bis zur Ausführung hin geschützt sind, potentiell kopiert und frei verwendet werden können, nachdem es entriegelt oder zum Gebrauch zur Verfügung gestellt ist. Obwohl es immer noch möglich sein wird, die Daten zu kopieren, können die Daten nicht ohne eine erforderliche Lizenz auf jedweder anderen sicheren Client-Plattform, die diese Erfindung beinhaltet, ausgeführt werden.
– Der Dongle ist generisch, statt für spezifische Anwendungen ausgelegt zu sein.
– Es herrscht Flexibilität bei Zahlungs- und Lizenzierungsmodellen (einschließlich eines Ermöglichens einer Kombination von unterschiedlichen Lizenzierungsarten).
– Es besteht insofern eine Verbesserung gegenüber generischen Donglen wie beispielsweise Wave Systems Wave-Meter, als sie eine Vermeidung universeller Systemschlüssel in der Hardware-Vorrichtung ermöglicht und ermöglicht, daß die geheimen Schlüssel des Entwicklers und der Hardware geheim bleiben. Dies ist besonders dann wichtig, wenn die dritten Parteien nicht vertrauenswürdig sind, da weder die Verrechnungsinstanz noch sonst jemand in der Lage sein wird, die geschützten Daten zu nutzen, da sie bzw. er den Entriegelungsschlüssel nicht kennt. Dies stellt eine Verbesserung gegenüber aktuellen Systemen dar, bei denen dieser Schlüssel der Verrechnungsinstanz bekannt ist.
– Der automatisierte Transfer von Lizenzen zwischen vertrauenswürdigen Modulen vermeidet das Schlüsselverwaltungsproblem.
– Jeder Entwickler hat eine Wahl zwischen entweder einem generischen oder einem spezifischen Inhaltsschutz – K (oder K') kann für jeden Kunden potentiell verschieden sein, falls gewünscht. Dies gibt dem Entwickler eine größere Flexibilität und erlaubt ihm, Mühe und zusätzliche Sicherheit gegeneinander abzuwägen. Allgemeiner gesagt kann jede Art von Lizenzierungsmodell (beispielsweise entsprechend den Beispielen A, B oder C) auf der Basis dessen verwendet werden, daß die Daten, die an jeden Kunden gesandt werden, dieselben sind oder individuell kundengerecht angepaßt sind (und somit nicht auf anderen Maschinen verwendbar sind). Eine Kombination dieser Verfahren könnte auf derselben Plattform verwendet werden. Somit wird dem Entwickler die Wahl bezüglich dessen gegeben, welche Art von Datenschutz er verwenden möchte. Der Entwickler gestal tet lediglich den Entriegelungsschlüssel oder den Typ des generischen Schutzes für jeden Kunden unterschiedlich oder gleich. Die Client-Plattform muß nicht von dieser Wahl informiert werden.

Bei diesem Beispiel:

– ist in jeder vertrauenswürdigen Computerplattform ein(e) generische sichere Ausführeinrichtung, sichere Ladeeinrichtung und Code für einen sicheren Schlüsseltransfer enthalten. Der Code wird nicht geladen, wenn die Integritätsprüfung negativ ausfällt, und in diesem Fall sollte die gesamte Client-Plattform-Integritätsprüfung negativ ausfallen, wie zuvor in diesem Dokument beschrieben wurde.
– Ein Endbenutzer A registriert seine Client-Maschine (Vertrauenswürdige-Vorrichtung-ID) bei einem Entwickler, einem Server oder einer Verrechnungsinstanz C (je nach Zahlungsmodell) und vereinbart, eine entsprechende Zahlung zu leisten, um einige Daten zu empfangen. Als Alternative könnte die Hardware-Vorrichtung im voraus aufgeladen werden, und der Datenkauf könnte auf dieser Vorrichtung aufgezeichnet und zu einem späteren Zeitpunkt an C rückgemeldet werden.
– Als Teil des Initialisierungsprozesses findet eine Authentifizierung zwischen kommunizierenden Parteien in dem Lizenzierungssystem vorher (oder zur gleichen Zeit, gemäß den betreffenden Protokollen) als Austausch von Sitzungsschlüsseln zum Zweck der Vertraulichkeit der Nachrichten statt.
– Authentifizierung: Es findet eine Authentifizierung von C zu der manipulationssicheren Vorrichtung des Client statt. Dies erfolgt unter Verwendung eines Standardprotokolls, das eine Herausforderung von dem vertrauenswürdigen Modul von A zu C, das eine Einmal verfügung enthält (um einen Schutz vor Wiedergabeattacken zu bieten), und wobei C mit einer Nachricht, die diese Einmalverfügung enthält und die unter Verwendung seines Privatcodesignierungsschlüssels digital signiert ist, antwortet. Optional erfolgt eine Authentifizierung von der manipulationssicheren Vorrichtung von A zu C. Ein Öffentlicher-Schlüssel-Zertifikat, das den öffentlichen Schlüssel W, der dem Privatcodesignierungsschlüssel von C entspricht, gibt, wird an die vertrauenswürdige Komponente des Endbenutzers transferiert (in manchen Fällen (z.B. Hochrüstungen) liegt es bereits bei dem vertrauenswürdigen Modul vor). Dies hat den Zweck, daß die Maschine in der Lage ist, die Identität des Verkäufers und die Integrität der Hochrüstungsdaten, die sie später empfangen wird, zu prüfen. Falls ein benutzerbasiertes Lizenzierungsmodell verwendet werden soll, erfolgt der Transfer zu der tragbaren vertrauenswürdigen Vorrichtung (z.B. Smartcard). C wird auch der öffentliche Schlüssel gegeben, der einem privaten Schlüssel P in der manipulationssicheren Vorrichtung von A entspricht. Dies wird für manche Arten der Authentifizierung von A zu C benötigt, und wird ferner benötigt, wenn symmetrische Verschlüsselungsschlüssel verwendet werden, die unter Verwendung eines asymmetrischen Schlüsselpaares (siehe unten) eingerichtet werden. Auf analoge Weise müssen Öffentlicher-Schlüssel-Zertifikate zwischen dem Entwickler und der Verrechnungsinstanz, falls diese separate Parteien sind, anfänglich ausgetauscht werden, und eine entsprechende Authentifizierung muß durchgeführt werden. Es können dieselben Protokolle verwendet werden wie die, die oben beschrieben wurden.
– Daten, die unter Verwendung eines symmetrischen Schlüssels K verschlüsselt werden, werden unter dem Privatcodesignierungsschlüssel von C (z.B. unter Verwendung von Authenticode von Microsoft) signiert und durch C an die Maschine von A an den Endbenutzer ge sandt. K kann, falls gewünscht, potentiell für jeden Kunden unterschiedlich sein. Diese Daten werden anhand beliebiger zweckmäßiger Mittel (beispielsweise Internet oder Satellitenempfang) an den Endbenutzer transferiert, da gerade der Entriegelungsschlüssel geschützt werden muß. Eine Option besteht darin, statt dessen einen privaten Schlüssel K' zu verwenden, da die Zeit, die zum Verschlüsseln benötigt wird, auf dieser Stufe wahrscheinlich kein Thema ist.
– Vertraulichkeit: Falls der Entwickler und die Verrechnungsinstanz separate Entitäten sind, wird zwischen dem Entwickler und der Verrechnungsinstanz ein Protokoll verwendet, um ein symmetrisches Schlüsselpaar einzurichten, das verwendet werden kann, um eine Kommunikation zwischen denselben zu verschlüsseln, beispielsweise über Zahlung und Nutzung von Daten. Dadurch kennt keine Partei den Geheimschlüssel der anderen Partei. Der Inhalt jeder Nachricht, die zu schützen ist, wird unter Verwendung eines zufällig erzeugten DES-Schlüssels verschlüsselt, und mit demselben wird der symmetrische Schlüssel unter Verwendung des öffentlichen Schlüssels des beabsichtigten Empfängers auf RSA-verschlüsselte Weise transferiert. Auch in diesem Fall muß anfänglich bei jeder Partei ein Öffentlicher-Schlüssel-Zertifikat, das der anderen Partei entspricht, installiert werden. Falls Prüfungen bezüglich Authentizität und Integrität hinzugefügt werden, ergibt sich das folgende Protokoll für jede Nachricht: der Sender erzeugt einen DES-Schlüssel (unter Verwendung eines Zufallszahlengenerators, wobei sichergestellt wird, daß diese Schlüssel lediglich einmal verwendet werden). Der Sender verwendet denselben dann, um die Daten D zu verschlüsseln, und verschlüsselt anschließend diesen DES-Schlüssel unter Verwendung des RSA-Öffentlicher-Schlüssels des Empfängers. Dann signiert der Sender einen Hash-Wert all dieser Informationen, um eine Authentifizierung und Integrität zu bieten, und sendet die verschlüsselten Daten und den verschlüsselten DES-Schlüssel zusammen mit dieser Signatur. Man beachte, daß die sensiblen Daten D mit dem DES-Schlüssel verschlüsselt gespeichert sind. Lediglich der Empfänger sollte dann den RSA-Privatschlüssel haben, um den DES-Verschlüsselungsschlüssel zu entschlüsseln, und ihn verwenden, um die Daten D zu entschlüsseln.
– Alle Kommunikationen zwischen A und C werden unter Verwendung von DES-Sitzungsschlüsseln verschlüsselt, wie in der vorherigen Stufe erörtert wurde.
– Ferner wird der symmetrische Entriegelungsschlüssel, der K entspricht (oder alternativ dazu der öffentliche Schlüssel, der K' entspricht) unter Verwendung des öffentlichen Schlüssels von A verschlüsselt und unter Verwendung des Privatcodesignierungsschlüssels von C signiert und an die manipulationssichere Komponente des Endbenutzers gesandt, um zu ermöglichen, daß die Daten betrieben werden.
– Nach Empfang durch die Endbenutzerplattform wird durch die sichere Ladeeinrichtung an den Daten eine Integritätsprüfung durchgeführt, indem die Signatur unter Verwendung von W geprüft wird und indem verifiziert wird, ob sie von der erwarteten Quelle stammt.
– Falls die Integritätsprüfung erfolgreich ist, werden die Daten auf der Plattform installiert, und die vertrauenswürdige Komponente zeichnet dieses Ereignis auf. Andernfalls wird eine Fehlermeldung erzeugt, und die Daten werden nicht geladen.
– Die dem PC des Endbenutzers zugeordnete manipulationssichere Vorrichtung ist die einzige, die in der Lage ist, diese Informationen zu nutzen und den Entriegelungsschlüssel zu erhalten. Der Schlüsseltransfercode prüft die Nachricht bezüglich Integrität und Authentifizierung, entschlüsselt den Entriegelungsschlüssel und speichert dies auf dem vertrauenswürdigen Modul, das den Daten zugeordnet ist.
– Wenn der Benutzer die Daten betreiben möchte, entschlüsselt die sichere Ausführeinrichtung die Daten unter Verwendung des Entriegelungsschlüssels und ermöglicht den Daten, betrieben zu werden. Die tatsächliche Funktionalität des Entriegelungsschlüssels könnte variieren: beispielsweise könnte ein Teil des Programms auf ein Hochfahren oder eine Installation hin entschlüsselt werden, oder der Schlüssel selbst könnte unter Verwendung der Identität der manipulationssicheren Komponente als Eingabe gebildet werden.
– Die manipulationssichere Komponente führt Protokoll, um die Nutzung der Daten lokal und auf vertrauenswürdige Weise zu überwachen.

Beispiel C
Das dritte Beispiel betrifft ein Lizenzieren über ein Konsultieren von Datenbank- oder Profilinformationen, die der Identität des vertrauenswürdigen Moduls zugeordnet sind.
Dies beinhaltet ein Aktualisieren eines Lizenzdatenbankeintrags im Gegenzug für eine Registrierung und Zahlung. Bei der Verwendung dieses Lösungsansatzes gibt es zwei Hauptoptionen.
Beispiel C1
Die erste Option besteht darin, daß die sichere Ausführeinrichtung in einer Datenbank gegen den Vertrauenswürdiges-Modul-ID-Eintrag bezüglich eines Entriegelungsschlüssels für die Daten prüft. Die Daten werden über eine Verschlüsselung oder teilweise Verschlüsselung unter Verwendung eines Schlüssels geschützt und können deshalb ohne Angst vor Piraterie frei verteilt werden.
Beispiel C2
Die zweite Option besteht darin, daß die sichere Ausführeinrichtung oder Software-Ausführeinrichtung in einer Datenbank gegen den Vertrauenswürdiges-Modul-ID-Eintrag in Bezug auf Erlaubnisse zum Betreiben einer Dateneinheit prüft. Ein Eintrag, der der Vertrauenswürdiges-Modul-ID entspricht, wird aktualisiert, um eine Erlaubnis, eine bestimmte Anwendung zu betreiben, zu zeigen, und die sichere Ausführeinrichtung oder Software-Ausführeinrichtung erlaubt ein Betreiben von Daten erst, nachdem Erlaubnisse auf dieser Datenbank geprüft wurden. In diesem Fall sind die Daten generisch und ungeschützt und können frei kopiert werden, können jedoch selbstverständlich nicht auf dieser Art von Plattform betrieben werden, wenn die erforderlichen Erlaubnisse nicht vorliegen. Das vertrauenswürdige Modul aktualisiert sein Protokoll, falls die sichere Ausführeinrichtung erlaubt hat, daß die Daten betrieben werden. Im Fahl einer Verwendung einer Software-Ausführeinrichtung zum Durchführen der Prüfungen ruft die Software-Ausführeinrichtung, die der zu betreibenden Anwendung zugeordnet ist, das vertrauenswürdige Modul auf, führt das vertrauenswürdige Modul die Lizenzprüfung durch und anschließend, falls diese Prüfung erfolgreich ist, leitet die Software-Ausführeinrichtung den Anruf an das OS, um die Anwendung zu betreiben.
Die Vorteile dieses Lösungsansatzes lauten wie folgt:

1) Die Flexibilität von Lizenzverwaltungssystemen kann ohne die Nachteile von Dongles mit dem höheren Grad an Hardware-Sicherheit kombiniert werden.
2) Eine Hauptmotivation zum Verwenden eines derartigen Verfahrens liegt in der Schlüsselverwaltung. Insbesondere ist ein Ausgeben von Ersatzpaßwörtern mühsam. Dieses Verfahren umgeht dieses Problem, indem lediglich eine Datenbank aktualisiert werden muß.
3) Falls bereits Verzeichnissysteme vorhanden sind, wäre dieses Lizenzierungsverfahren eine folgerichtige Wahl, da es keine große zusätzliche Investition erfordern würde, um eine sichere Lizenzierungsprüfung zu liefern.
4) Das obige Beispiel C1 entspricht einem anderen Verfahren einer Übergabe eines Entriegelungsschlüssels an die Client-Maschine im Vergleich zum Beispiel B. Dieses könnte aus zwei Gründen bevorzugt werden. Erstens sind vielleicht bereits Verzeichnissysteme vorhanden und ferner eine favorisierte Lösung für ein bestimmtes Unternehmen. Zweitens kann dieses Verfahren eine nicht-dauerhafte Speicherung von Entriegelungsschlüsseln ermöglichen, was variable Lizenzen ermöglicht, was bei Beispiel B nicht der Fall ist.

Eine Lizenzierungsprozedur, die derzeit verwendet werden könnte, bestünde darin, Fingerabdruckinformationen im Vergleich mit einer Lizenzierungsdatenbank zu prüfen, um zu sehen, ob diesem Fingerabdruck eine gültige Lizenz entspricht. Diese Anwendung dürfte dann je nach diesen Informationen laufen oder nicht. Jedoch wird dieses Verfahren eigentlich nicht verwendet, weil:

– der Lizenzprüfungscode derzeit ohne weiteres umgangen werden könnte.
– ein Erstellen und stetiges Aktualisieren der Datenbanken Mehrkosten verursacht.
– es möglich ist, eine ID zu beschwindeln, um Zugriff auf Informationen zu erlangen, die für eine andere Maschine oder einen anderen Benutzer lizenziert sind.

Auf dem Weg einer Verwendung einer manipulationssicheren Vorrichtung in Verbindung mit einem Integritätsprüfen des zugeordneten Lizenzprüfungscodes könnte jedoch ein analoges Verfahren verwendet werden.
Das Verfahren überwindet die Probleme, die mit der existierenden Vorgehensweise verbunden sind.

– Verzeichnisstrukturen können erweitert werden, um ein Lizenzieren zu ermöglichen (vgl. Lizenzverwaltung) – diese Strukturen sind bereits vorhanden und ermöglichen eine Integration mit einer zusätzlichen Funktionalität. Die Lizenzdatenbank könnte in Form von lokalen Aufstellungen, die in der vertrauenswürdigen Komponente gespeichert sind, einer Aufstellung, die auf einem Server gespeichert ist (und bei Bedarf lokal konsultiert wird oder gespeichert ist) oder eines zentral unterhaltenen Verzeichnisdienstes, wo entsprechende Informationen über Zugriff gespeichert sind, vorliegen. Es könnte sogar eine Kombination dieser Möglichkeiten verwendet werden. Verzeichnisstandards, die allgemein als X.500 bekannt sind, liefern die Grundlagen für einen verteilten Mehrzweck-Verzeichnisdienst, der Computersysteme, die Dienstleistern, Regierungen und Privatorganisationen gehören, miteinander verbindet. Es wäre unkompliziert, derartige Verzeichnisse so zu modifizieren, daß für Computernetzwerkbenutzer ein Nachschlagen einer Benutzer-ID oder Maschinen-ID einer Person Informationen bringen könnte, die Einzelheiten der Anwendungen, die für diese Person bzw. Maschine lizenziert sind, enthalten.
– Es gibt eine Integritätsprüfung eines Lizenzprüfcodes und ferner der Daten. Eine zugeordnete Software auf der Computerplattform würde prüfen, ob der Benutzer oder die Maschine die Erlaubnis besitzt, die Anwendung zu betreiben, und würde dies je nach Fall erlauben oder verbieten. Alternativ dazu könnten, falls die Daten beispielsweise durch Verschlüsselung geschützt wären, in dem Verzeichnis verschiedene Datenzugriffsschlüssel gespeichert werden, und ein Zugriff auf dieselben könnte auf diese Weise über die zugeordnete Software erhalten werden.
– Eine bessere Authentifizierung ermöglicht ein Verzeichnis/Profil-Lösungsansatz. Eine vertrauenswürdige ID in dem vertrauenswürdigen Modul (möglicherweise mit Biometrik kombiniert, falls es eine Benutzer-ID ist) ermöglicht eine stärkere Authentifizierung und trägt dazu bei, Betrug zu verhindern. (Eine vertrauenswürdigere Maschinen- oder Benutzeridentität führt dazu, daß dieses Verfahren weniger leicht mißbraucht wird, beispielsweise dadurch, daß eine Identität eines anderen Benutzers gegeben wird.) Ferner können Schlüssel auf sicherere Weise gespeichert werden. Optional könnte eine Software hinzugefügt werden, um zu gewährleisten, daß das System eine Datennutzung mißt und diese in der manipulationssicheren Vorrichtung speichert. Falls eine Smartcard verwendet würde, erfolgte die Prüfung in dem Profil gegenüber der Benutzer-ID, ein einmaliges Anmelden würde bedeuten, daß die Karte nicht in der Lesevorrichtung belassen werden müßte, und ferner würde eine örtliche Unabhängigkeit erreicht.

Unter Bezugnahme auf die beiden Hauptoptionen eines Lizenzierens unter Verwendung des oben angegebenen Verfahrens C werde nun zuerst der erste Fall, C1, betrachtet:

– Die sichere Ausführeinrichtung ist generisch und ist mit der Plattform integriert, um einen Diebstahl des Entriegelungsschlüssels zu verhindern. Dies ist möglich, weil dieselbe Vorgehensweise mit unterschiedlichen Daten verwendet wird und weil sich in jedem Fall lediglich der Datenname und der zugeordnete Schlüssel unterscheiden. Die sichere Ausführeinrichtung und die sichere Ladeeinrichtung werden zusammen mit einer hash-codierten Version, die mit dem privaten Schlüssels des Herstellers signiert ist, gespeichert. Das Öffentlicher-Schlüssel-Zertifikat des Herstellers ist in jeder Plattform enthalten. Auf ein Hochfahren/Installieren der Plattform hin wird das Paket durch Hash-Codieren und einen Vergleich mit der entschlüsselten Signatur zum Prüfen der Integrität unter Verwendung des Öffentlicher-Schlüssel-Zertifikats verifiziert. Der Code wird nicht geladen, wenn die Integritätsprüfung negativ ausfällt, und in diesem Fall fällt die gesamte Plattformintegrität negativ aus.
– Auf eine Registrierung der Vertrauenswürdiges-Modul-ID und eine Zahlung hin veranlaßt die Verrechnungsinstanz oder der Entwickler, daß der Entriegelungsschlüssel der Daten K in dem Datenbankeintrag, der der Vertrauenswürdiges-Modul-ID entspricht, eingeführt wird (dies kann in der Tat durch eine dritte Partei mit Autorisierung von der Verrechnungsinstanz oder dem Entwickler durchgeführt werden).
– Das Öffentlicher-Schlüssel-Zertifikat für C wird durch C in das vertrauenswürdige Modul des Client installiert. Ein geeignetes Protokoll, das eine Authentifizierung von C zu dem vertrauenswürdigen Modul beinhalten würde, wäre, daß C als Antwort auf eine Anforderung einer Authentifizierung von dem vertrauenswürdigen Modul, die eine durch das vertrauenswürdige Modul erzeugte Einmalverfügung beinhaltet, eine Nachricht zurückgibt, die sein Öffentlicher-Schlüssel-Zertifikat und die Einmalverfügung, mit seinem privaten Schlüssel signiert, enthält. Das vertrauenswürdige Modul kann dann prüfen, daß die Nachricht von C kam.
– Die zu schützende Software oder andere Daten werden unter Verwendung eines symmetrischen Schlüssels, der K entspricht, verschlüsselt und unter dem Privatcodesignierungsschlüssel von C (z.B. unter Verwendung von Authenticode) signiert und durch C an die Maschine von A an den Endbenutzer gesandt. K kann, falls gewünscht, potentiell für jeden Kunden unterschiedlich sein. Diese Daten können durch ein beliebiges geeignetes Mittel (beispielsweise Internet oder Satellitenempfang) an den Endbenutzer transferiert werden, da der Entriegelungsschlüssel geschützt werden muß.
– Nach Empfang durch die Endbenutzerplattform wird durch die sichere Ladeeinrichtung an den Daten eine Integritätsprüfung durchgeführt, indem unter Verwendung des öffentlichen Schlüssels, der dem Privatcodesignierungsschlüssel von C entspricht, die Signatur geprüft wird.
– Falls die Integritätsprüfung erfolgreich ist, wird bzw. werden die Software oder andere Daten auf der Plattform installiert, und die vertrauenswürdige Komponente zeichnet dieses Ereignis auf. Andernfalls wird eine Fehlermeldung erzeugt, und die Daten werden nicht geladen.
– Wenn der Benutzer die Daten betreiben möchte, führt die sichere Ausführeinrichtung folgendes durch:
– Sie prüft die Vertrauenswürdiges-Modul-ID, beispielsweise durch eine Authentifizierung, die eine Einmalverfügung beinhaltet, um Wiedergabeattacken und einer signierten Kommunikation entgegenzuwirken.
– Sie prüft den Datenbankeintrag der Vertrauenswürdiges-Modul-ID und gewinnt den Entriegelungsschlüssel K wieder.
– Sie ermöglicht, daß die Daten betrieben werden oder nicht, je nach Fall.
– Die manipulationssichere Vorrichtung aktualisiert anschließend ihre Protokolle, um aufzuzeichnen, ob die Daten betrieben wurden. Falls sich ein Benutzer mit einer Smartcard eingeloggt hat, kann die Benutzer-ID dieser Vorrichtung zusammen mit den Daten und dem Zeitpunkt notiert werden.

Eine Variation besteht darin, den Entriegelungsschlüssel, nachdem er wiedergewonnen wurde, zusammen mit dem Datennamen in dem vertrauenswürdigen Modul zu speichern, so daß die Datenbanknachschlageprozedur für diese bestimmten Daten noch einmal durchgeführt werden muß. Zukünftige Anforderungen bezüglich eines Betreibens der Daten wurden zu einer Herausforderung von der Software-Ausführeinrichtung führen, um die Vertrauenswürdiges-Modul-ID zu authentifizieren, den Entriegelungsschlüssel zu prüfen, dies zum Entschlüsseln der Daten zu verwenden und zu erlauben, daß die Daten betrieben werden (auf dieselbe Weise wie bei dem obigen Beispiel B).
Nun werde zu einer Betrachtung des zweiten Falles, C2, übergegangen, wenn bezüglich der sicheren Lizenzerlaubnisse zum Betreiben einer Dateneinheit geprüft wird. Es gibt zwei mögliche Teilmodelle, je nachdem, ob die sichere Ausführeinrichtung (eine generische Codeeinheit, die in die Plattform integriert ist) mit dem Betriebssystem kommuniziert und den Datenausführungsprozeß einleitet oder ob eine (kundengerechte) Software-Ausführeinrichtung, die zusammen mit jeder Dateneinheit von der Verrechnungsinstanz oder dem Entwickler versandt wird, mit dem Betriebssystem kommuni ziert und den Prozeß einleitet. Bei jedem Teilmodell besteht eine Wahl, ob Lizenzierungsinformationen in das vertrauenswürdige Modul selbst geladen werden oder ob auf eine externe Datenbank verwiesen wird.
Die Daten selbst sind bei diesem Modell nicht geschützt. Falls eine höhere Vertraulichkeit der Daten erforderlich ist, sollten statt dessen Varianten der Beispiele A oder B verwendet werden.
Wenn man das erste generische Teilmodell betrachtet, so ist dies demjenigen, das bei dem Schlüsselprüfungsfall des Beispiels C1 beschrieben ist, sehr ähnlich.

– Ein Öffentlicher-Schlüssel-Zertifikat, das der Partei, die die Datenbank betreibt, entspricht, ist bei der Verrechnungsinstanz oder dem Entwickler installiert, und umgekehrt.
– Auf eine Registrierung und/oder Zahlung für die Daten durch den Endbenutzer hin wird der Verrechnungsinstanz oder dem Entwickler C (je nach dem Zahlungsmodell) die Vertrauenswürdiges-Modul-ID mitgeteilt.
– Ein Öffentlicher-Schlüssel-Zertifikat, das dem vertrauenswürdigen Modul des Client entspricht, ist an der Verrechnungsinstanz oder dem Entwickler installiert (falls nicht bereits vorhanden), und umgekehrt. Ein geeignetes Protokoll, das eine Authentifizierung von C zu dem vertrauenswürdigen Modul beinhalten würde, wäre, daß C ansprechend auf eine Anforderung bezüglich einer Authentifizierung von dem vertrauenswürdigen Modul, das eine durch das vertrauenswürdige Modul erstellte Einmalverfügung beinhaltet, eine Nachricht zurückgibt, die sein Öffentlicher-Schlüssel-Zertifikat und die Einmalverfügung, mit seinem privaten Schlüssel signiert, enthält. Das vertrauenswürdige Modul kann dann prüfen, daß die Nachricht von C kam. Ein analoges Protokoll würde für einen Transfer eines Öffentlicher-Schlüssel-Zertifikats und eine Authentifizierung von dem vertrauenswürdigen Modul zu C verwendet.
– C sendet die Anwendungs- oder andere Daten, die geschützt werden sollen, auf folgende Weise an den Client: Die Daten werden durch Verwendung einer hashcodierten Version der Nachricht, die durch den an die Nachricht angehängten privaten Schlüssel des Senders signiert ist, signiert, so daß der Empfänger die Integrität der Nachricht prüfen kann. Genauer gesagt unterzieht der Entwickler M einer Hash-Codierung, was die Daten zusammen mit jeglicher zugeordneter Software-Ausführeinrichtung ist, und signiert es mit seinem privaten Schlüssel (Sprk), um eine Signatur Σ_Sprk(h(M)) zu erzeugen. Dann sendet er diese Signatur zusammen mit M.
– Die sichere Ladeeinrichtung wird dann die Signatur unter Verwendung des öffentlichen Schlüssels des Entwicklers prüfen und somit den Nachricht-Hash-Wert wiedergewinnen. Dies garantiert, daß der Entwickler derjenige ist, dessen öffentlicher Schlüssel zum Prüfen der Signatur verwendet wurde. Nachdem sie die Nachricht und den Nachricht-Hash-Wert hat, kann die sichere Ladeeinrichtung sodann über das vertrauenswürdige Modul den Hash-Wert der Nachricht berechnen und ihn mit dem Nachricht-Hash-Wert, den sie entschlüsselt hat, vergleichen. Dies prüft die Integrität des Codes. Ferner sollte der Integritätsprüfmechanismus Wiedergabeattacken durch einen Standardmechanismus – beispielsweise Verwenden einer Einmalverfügung – verhindern. Falls die Integritätsprüfung funktioniert, installiert die sichere Ladeeinrichtung die Daten. Dies gewährleistet, daß keine modifizierten Daten (z.B. oh ne API-Anrufe) betrieben werden können, daß keine Viren eingebracht werden usw.
– C autorisiert den Datenbankeintrag, der der zu aktualisierenden Vertrauenswürdiges-Modul-ID entspricht, gemäß den gekauften Daten. Die Partei, die die Datenbank betreibt, kommuniziert unter Verwendung einer öffentlicher-Schlüssel-Kryptographie, die gemeinsam verwendete symmetrische Schlüssel einrichtet, und dadurch, daß jeder seine Nachrichten signiert, mit der Verrechnungsinstanz oder dem Entwickler. Der Inhalt jeder Nachricht, die zu schützen ist, wird unter Verwendung eines zufällig erzeugten DES-Schlüssels verschlüsselt und zusammen mit dem symmetrischen Schlüssel, der unter Verwendung des öffentlichen Schlüssels des beabsichtigten Empfängers RSA-verschlüsselt ist, transferiert. Falls Prüfungen bezüglich Authentizität und Integrität hinzugefügt werden, ergibt sich das folgende Protokoll für jede Nachricht:
– Der Sender erzeugt einen DES-Schlüssel (unter Verwendung eines Zufallszahlengenerators, und wobei er sicherstellt, daß diese Schlüssel nur einmal verwendet werden). Der Sender verwendet ihn anschließend zum Verschlüsseln der Daten D und anschließend zum Verschlüsseln dieses DES-Schlüssels unter Verwendung des RSA-Öffentlicher-Schlüssels des Empfängers. Dann signiert der Sender einen Hash-Wert all dieser Informationen, um eine Authentifizierung und Integrität anzubieten, und sendet alles zusammen mit dieser Signatur. Lediglich der Empfänger sollte dann den RSA-Privatschlüssel haben, um den DES-Verschlüsselungsschlüssel zu entschlüsseln, und ihn zum Entschlüsseln der Daten D verwenden.
– Auf eine Anforderung, eine Dateneinheit von dem Benutzer zu betreiben, hin konsultiert die sichere Ausführeinrichtung die Datenbank, die Lizenzierungsinforma tionen enthält, um zu sehen, ob eine Erlaubnis, die Daten zu betreiben, der Vertrauenswürdiges-Modul-ID der aktuellen Plattform zugeordnet ist. Falls dies nicht der Fall ist, wird dem Benutzer eine Fehlermeldung zugestellt, und die Daten dürfen nicht betrieben werden. Falls dies jedoch der Fall ist, bittet die sichere Ausführeinrichtung das Betriebssystem, die Daten zu betreiben.

Bei Betrachtung des zweiten Teilmodells würde eine Instantiierung des Modells, bei der das Modell eine spezifische Software-Ausführeinrichtung pro Anwendung aufweist, wie folgt lauten.

– Auf eine Registrierung und/oder Zahlung für die Daten hin autorisiert die Verrechnungsinstanz oder der Entwickler C (gemäß dem genauen Zahlungsmodell) den Datenbankeintrag, der der zu aktualisierenden Vertrauenswürdiges-Modul-ID entspricht, gemäß den gekauften Daten. (Vorher wurden Öffentlicher-Schlüssel-Zertifikate zwischen diesen Entitäten ausgetauscht: ein geeignetes Protokoll, das eine Authentifizierung von C zu dem vertrauenswürdigen Modul beinhalten würde, wäre, daß C ansprechend auf eine Anforderung bezüglich einer Authentifizierung von dem vertrauenswürdigen Modul, das eine durch das vertrauenswürdige Modul erstellte Einmalverfügung beinhaltet, eine Nachricht zurückgibt, die sein Öffentlicher-Schlüssel-Zertifikat und die Einmalverfügung, mit einem privaten Schlüssel signiert, umfaßt. Ein analoges Protokoll würde für einen Transfer eines Öffentlicher-Schlüssel-Zertifikats und einer Autorisierung von dem vertrauenswürdigen Modul an C verwendet.) Die Partei, die die Datenbank betreibt, kommuniziert unter Verwendung einer öffentlicher-Schlüssel-Kryptographie, die gemeinsam verwendete symmetrische Schlüssel einrichtet, und dadurch, daß jeder seine Nachrichten signiert, mit der Verrechnungsinstanz oder dem Entwickler.
– Die Verrechnungsinstanz oder der Entwickler sendet die Daten, die einer (kundengerechten) Software-Ausführeinrichtung zugeordnet sind, an den Client. Die Software-Ausführeinrichtung ist derart kundenspezifisch ausgelegt, daß der öffentliche Schlüssel des vertrauenswürdigen Moduls in die Software-Ausführeinrichtung eingeführt wird (alternativ wird ein gemeinsam verwendeter Schlüssel zwischen der sicheren Ausführeinrichtung und dem vertrauenswürdigen Modul eingerichtet). Sowohl die Daten als auch die Software-Ausführeinrichtung werden hash-codiert und mit dem privaten Schlüssel der Verrechnungsinstanz/des Entwicklers signiert, und der öffentliche Schlüssel, der diesem entspricht, wird in dem vertrauenswürdigen Modul gespeichert.
– Die sichere Ladeeinrichtung unterzieht die Daten und die Software-Ausführeinrichtung einer Integritätsprüfung: Auf eine Installation hin wird das Paket durch ein Hash-Codieren und einen Vergleich mit der entschlüsselten Signatur (unter Verwendung des öffentlichen Schlüssels in dem vertrauenswürdigen Modul) verifiziert.
– Die Daten und die Software-Ausführeinrichtung werden nicht geladen, falls die digitale Signatur nicht mit der Erwarteten übereinstimmt.
– Wenn der Benutzer die Daten ausführen möchte, sendet das OS eine Nachricht an die Software-Ausführeinrichtung, die diesen Daten entspricht. Die Software-Ausführeinrichtung gibt dann eine Herausforderung/Antwort an die sichere Ausführeinrichtung aus, indem sie eine Zufallszahl (Einmalverfügung) zusammen mit dem Titel der Anwendung sendet. Ferner wird eine Smartcard-ID gesandt, falls diese verwendet wurde, um sich in die Client-Maschine einzuloggen, und falls ein Hot-Desking das zu verwendende Lizenzierungsmodell ist.
– Die sichere Ausführeinrichtung:
– prüft, ob die Daten dafür lizenziert sind, um auf der Vertrauenswürdiges-Modul-Maschinen-ID in dem in dem vertrauenswürdigen Modul gespeicherten Profil betrieben zu werden, oder
– prüft, ob die Daten dafür lizenziert sind, um gemäß der Benutzer-ID einer Smartcard betrieben zu werden, die in das in dem vertrauenswürdigen Modul gespeicherte Profil eingeführt wurde, oder
– konsultiert einen Teil einer externen Datenbank oder lädt denselben herunter, um ein Profil in dem vertrauenswürdigen Modul zu bilden, um zu sehen, ob die Anwendung auf die oben beschriebene Weise lizenziert ist.
– Falls keine gültige Lizenz vorliegt, gibt die sichere Ausführeinrichtung eine Fehlermeldung zurück, aus der die Software-Ausführeinrichtung die genaue Art des Problems bezüglich der Lizenzierung bestimmen und das OS entsprechend benachrichtigen kann. Falls eine gültige Lizenz vorliegt, gibt die sichere Ausführeinrichtung eine Nachricht zurück, die die Einmalverfügung und Datenreferenz beinhaltet und die signiert und unter Verwendung des privaten Schlüssels des vertrauenswürdigen Moduls verschlüsselt ist.
– Die Software-Ausführeinrichtung verifiziert unter Verwendung des öffentlichen Schlüssels des vertrauenswürdigen Moduls, ob die Antwort der sicheren Ausführeinrichtung korrekt ist, und leitet je nach Fall entweder den Anruf an das OS weiter, um die Daten auszuführen, oder sendet eine Fehlermeldung an das OS.

Beispiel D
Das vierte Beispiel betrifft die Verwendung des vertrauenswürdigen Moduls als Dongle durch ein Unterziehen des vertrauenswürdigen Moduls einer Fingerabdruckprozedur.
Dies unterscheidet sich insofern von aktuellen Fingerabdruckmethoden, als es eine vertrauenswürdige Identität in der Hardware (d.h. die nicht-geheime Vertrauenswürdiges-Modul-Identität), ein Integritätsprüfen der zu betreibenden Anwendung, ein Integritätsprüfen einer zugeordneten, eine Anwendung freigebenden Software, und ein sicheres Audit in der Hardware verwendet. Optional kann ein Entriegelungsschlüssel statt auf entfernte Weise in der Software-Ausführeinrichtung auf der Clientmaschine erzeugt werden. Das vertrauenswürdige Modul muß dann den Verkäufer kontaktieren, um einen Schlüssel, die geschützten Daten und die zugeordnete Software-Ausführeinrichtung zu erhalten, was den Entschlüsselungsschlüssel befähigen wird, unter Verwendung der Vertrauenswürdiges-Modul-ID lokal erstellt zu werden. Die Daten könnten generisch verschlüsselt und versandt werden, da ein einziger Schlüssel verwendet werden könnte, um sie zu entschlüsseln, oder es könnten verschiedene Schlüssel für jeden Endbenutzer verwendet werden (was sicherer ist).
Dieses Verfahren ist eine Variante von B und liefert eine Alternative zu dem bei B verwendeten Lösungsansatz. Es unterscheidet sich in folgenden Punkten:

– Der Entriegelungsschlüssel kann statt auf entfernte Weise in der Software-Ausführeinrichtung oder der sicheren Ausführeinrichtung auf der Client-Maschine erstellt werden.
– Der von der Verrechnungsinstanz an die Client-Maschine transferierte Schlüssel ist nicht der Entriegelungs schlüssel, sondern ein Schlüssel, von dem dieser unter Verwendung eines in der Software-Ausführeinrichtung zu findenden Algorithmus und von Fingerabdruckeinzelheiten des vertrauenswürdigen Moduls abgeleitet werden kann. Es wäre besser, die Software-Ausführeinrichtung und nicht die sichere Ausführeinrichtung zu verwenden, da die zum Ableiten des Entriegelungsschlüssels verwendeten Techniken von Entwickler zu Entwickler variieren können.

Die Flexibilität von Lizenzverwaltungssystemen kann ohne die Nachteile von Dongles mit dem höheren Grad an Hardwaresicherheit kombiniert werden. Dieses Verfahren wirkt Problemen entgegen, die mit aktuellen Verfahren des Lizenzschutzes verbunden sind, einschließlich der folgenden:

– Attacken, die Maschinen verwenden, die vorgeben, andere Maschinen zu sein. Die Maschinen-ID, die die Vorrichtungs-ID für interne Komponenten ist, ist vertrauenswürdig. Dies ist nützlich für ein Lizenzieren in bezug auf ein sichereres Protokollieren und erlaubt mehr Lizenzierungsinformationen und Modelle sowie eine Authentifizierung. PC-Fingerabdrücke können weniger leicht nachgeahmt werden, als dies zur Zeit möglich ist, da die Vorrichtungs-ID zuverlässiger ist als das, was derzeit für PC-Fingerabdrucktechniken verwendet wird, d.h. Festplatten-ID, BIOS-Seriennummer, Netzwerk-ID-Karte usw. Eine derart zuverlässige Identifizierung hilft gegen Attacken unter Verwendung von Maschinen, die vorgeben, andere Maschinen zu sein.
– Daten können umgangen oder geändert werden, und deshalb unterliegt ein Nur-Software-Schutz einem universalen Bruch. Die Schritte, die unternommen werden, um die Sicherheit, Fingerabdrucknahme und Authentifizierung durchzuführen, müssen vor einem Hacker versteckt werden. Da jedoch alle Informationen auf dem PC gespeichert sind und alle Funktionen unter Verwendung des Prozessors des PCs erledigt werden, können diese Schritte bzw. Aktionen durch einen Debugger nachverfolgt werden. Der einzige Weg, diese Aktionen vor einem Debugger zu schützen, besteht darin, betriebssystem- oder maschinenspezifische Ausnahmen, wie beispielsweise Ring Zero bei Windows, zu verwenden. Währen dies die Sicherheit verbessert, indem die meisten Debugger abgeblockt werden, hält es nicht Chip-Simulatoren ab, die für PC-Prozessoren wie Pentium von Intel umfassend erhältlich sind. Ferner macht dies die Nur-Software-Lösung maschinenspezifisch und erfordert eine Version für jede der verschiedenen Plattformen. Viele Lieferanten von Nur-Software-Schutz sind klein und können nicht für alle verschiedenen Kombinationen von Anwendungen und Betriebsumgebungen aktuelle Schutzmodule bereitstellen. Dies führt zu Inkompatibilitäten, die den Benutzer ärgern und den Entwickler Kundendienstzeit kosten. Da dieselbe Authentifizierungsaktion lediglich an einigen identifizierbaren PC-Komponenten durchgeführt werden muß, bevor ein Programm geladen wird, hat der Hacker relativ wenig Code zum Nachverfolgen; deshalb kann der Schutz für alle Anwendungen, die das Nur-Software-Schema verwenden, leicht gebrochen werden, wenn erst einmal die Ladefrequenz verstanden wird. Integritätsprüfungen der Plattform und Software ermöglichen Integritätsprüfungen von zugeordneten Lizenzierungsprüf- und Hochladesoftware und vermeiden, daß Daten umgangen oder geändert werden. Die beschriebenen Lizenzierungsaspekte stützen sich nicht auf den PC-Prozessor – die Algorithmusfunktion wird in der vertrauenswürdigen Hardware erfüllt, wo kein Debugger oder Chip-Simulator den Prozeß offenlegen kann.
– Ein einzelner LMF kann alle Merkmale aller Anwendungen, die durch einen Entwickler verkauft werden, verwalten. Es muß jedoch mit jedem Entwickler eine getrennte Vereinbarung vorliegen, und es kommt mögli cherweise zu Konflikten zwischen den unterschiedlichen Lizenzverwaltern. Es wäre besser, lediglich einen Lizenzverwalter pro Benutzerstandort zu haben, und es wäre besser, wenn jeder Entwickler mit demselben verbunden ist. Dieses Modell ist sogar noch allgemeiner und könnte alle Entwickler abdecken.
– Software-Lösungen ergeben eine langsame Verschlüsselung, sind weniger sicher und können gespeicherten Daten lediglich ein begrenztes Maß an Sicherheit bieten. Eine langsame Verschlüsselung ist von begrenztem Nutzen und macht eine Verwendung von Massenverschlüsselung für alle Kommunikationen unpraktisch. Endbenutzer können entweder länger auf ihre Kommunikation und Anwendungen warten oder auswählen, lediglich kleine Teile der Kommunikation zu verschlüsseln. Hardware-Verschlüsselung ist schneller. Durch Verwendung einer schnellen Verschlüsselung für die gesamte Kommunikation kann sie transparent sein – eine bessere Lösung als eine teilweise Verschlüsselung. Hardware wird allgemein als sicherer anerkannt, da sie in einem manipulationsresistenten Gehäuse eingeschlossen werden kann und ihre Schnittstelle auf sicherere Weise gesteuert werden kann. Hardware-Lösungen ermöglichen einen viel größeren Schutz von sensiblen Daten, beispielsweise Schlüsseln und Benutzerinformationen.

Es gibt zwei Hauptverwendungstypen des Beispiels D.

– Erstens in Situationen, bei denen sich ein maschinenbasiertes Lizenzierungsmodell am besten geeignet:
– Daten S werden unter Verwendung eines Schlüssels K verschlüsselt.
– Ein Benutzer läßt sich bei der Verrechnungsinstanz/dem Entwickler C registrieren, es herrscht eine gegenseitige Authentifizierung, und C wird die Vertrauenswürdiges-Modul-ID gegeben.
– C sendet die verschlüsselten Daten plus zugeordnete Software-Ausführeinrichtung auf beliebige zweckmäßige Weise signiert und hash-codiert an den Benutzer.
– Die sichere Ladeeinrichtung auf dem Client-Computer prüft die Integrität und installiert die Daten S, falls die Integritätsprüfung erfolgreich ist.
– Symmetrische Kryptographie wird verwendet, um den Entriegelungsschlüssel von C an das vertrauenswürdige Modul zu transferieren. Dieser Schlüssel ist für keine andere Maschine nützlich und muß deshalb nicht so sehr wie bei dem Beispiel B, wenn der transferierte Schlüssel ein Entriegelungsschlüssel auf Systemebene sein könnte, vor dritten Parteien geschützt werden.
– Die Software-Ausführeinrichtung berechnet den Entschlüsselungsschlüssel, der K entspricht, aus dem Entriegelungsschlüssel und der Vertrauenswürdiges-Modul-ID unter Verwendung eines Algorithmus, der durch C oder eine dritte Partei, der von C vertraut wird, in derselben vorab gespeichert ist.
– Der Entschlüsselungsschlüssel wird verwendet, um die Daten zu entschlüsseln und ein Betreiben derselben zu ermöglichen.
– Zweitens in Situationen, in denen ein benutzerbasiertes Lizenzierungsmodell erforderlich ist – Daten S werden unter Verwendung eines Schlüssels K verschlüsselt.
– Ein Benutzer läßt sich bei der Verrechnungsinstanz/dem Entwickler C registrieren, es herrscht eine gegenseitige Authentifizierung, und C wird die Smartcard-ID gegeben.
– C sendet die verschlüsselten Daten plus zugeordnete Software-Ausführeinrichtung auf beliebige zweckmäßige Weise signiert und hash-codiert an den Benutzer.
– Die sichere Ladeeinrichtung auf dem bzw. den Client-Computer(n), die/der durch den Benutzer ausgewählt ist bzw. sind, prüft die Integrität und installiert die Daten S, falls die Integritätsprüfung erfolgreich ist.
– Der Entriegelungsschlüssel wird durch jegliches zweckmäßige Mittel von C an den Benutzer transferiert. Dieser Schlüssel ist nicht besonders vertraulich und kann per Telefon oder elektronisch transferiert werden.
– Der Benutzer loggt sich in einen Vertrauenswürdige-Plattform-Computer ein und führt die Smartcard in die Lesevorrichtung ein.
– Wenn der Benutzer die Daten zu betreiben versucht, wird er aufgefordert, den Entriegelungsschlüssel einzutippen.
– Die Software-Ausführeinrichtung berechnet den Entschlüsselungsschlüssel, der K entspricht, aus dem Entriegelungsschlüssel und der Smartcard-ID unter Verwendung eines Algorithmus, der durch C oder eine dritte Partei, der von C vertraut wird, in derselben vorab gespeichert ist.
– Der Entschlüsselungsschlüssel wird verwendet, um die Daten zu entschlüsseln und ein Betreiben derselben zu ermöglichen.

Beispiel E
Es besteht eine Option, jegliche der obigen Beispiele A–D zu verwenden, jedoch Anwendungen zu betreiben, die auf geeignete Weise in einem vertrauenswürdigen Modul segmentiert sind: ebenso wie Anwendungen auf der Plattform auf ähnliche Weise wie in der aktuellen Praxis zu betreiben, bestehen zusätzliche Optionen, die Anwendungen in dem Interne-Maschine-Vertrauenswürdiges-Modul, in einem tragbaren vertrauenswürdigen Modul wie beispielsweise einer Smartcard zu verwenden, oder eine Kombination aus beliebigen der Vorstehenden. Es würden hochmoderne Techniken verwendet, die Fachleuten bekannt sind und die zum Betreiben von mehreren Anwendungen auf einer Smartcard patentiert wurden.
Beispiel F
Das letzte Beispiel besteht darin, wie eine Kombination von mehreren vertrauenswürdigen Vorrichtungen verwendet werden kann, um Daten auf flexible Weise zu lizenzieren. Die Kombination eines Interne-Maschine-Vertrauenswürdiges-Moduls und eines tragbaren vertrauenswürdigen Moduls wie beispielsweise einer Smartcard wird betrachtet, für den besonderen Fall, bei dem das Hot-Desking-Lizenzierungsmodell verwendet wird und das OS mit den Software-Ausführeinrichtungen kommuniziert. Eine analoge Prozedur würde für das in 19 beschriebene Modell verwendet.

– Auf eine Registrierung und/oder Zahlung für die Daten hin autorisiert die Verrechnungsinstanz oder der Entwickler C (gemäß dem genauen Zahlungsmodell) den Datenbankeintrag, der der zu aktualisierenden Vertrau enswürdiges-Modul-ID entspricht, gemäß den gekauften Daten. (Vorher erfolgt eine gegenseitige Authentifizierung, wie bei vorherigen Beispielen beschrieben wurde, und Öffentlicher-Schlüssel-Zertifikate zwischen diesen Entitäten wurden ausgetauscht). Die Partei, die die Datenbank betreibt, kommuniziert unter Verwendung einer öffentlicher-Schlüssel-Kryptographie, die gemeinsam verwendete symmetrische Schlüssel einrichtet, und dadurch, daß jeder seine Nachrichten signiert, mit der Verrechnungsinstanz oder dem Entwickler. Der Inhalt der Nachricht, die zu schützen ist, wird unter Verwendung eines zufällig erzeugten DES-Schlüssels verschlüsselt und zusammen mit dem symmetrischen Schlüssel, der unter Verwendung des öffentlichen Schlüssels des beabsichtigten Empfängers gemäß einem Standardprotokoll RSA-verschlüsselt ist, transferiert.
– Die Verrechnungsinstanz oder der Entwickler sendet die Daten, die einer (kundengerechten) Software-Ausführeinrichtung zugeordnet sind, an den Client. Die Software-Ausführeinrichtung ist derart kundenspezifisch ausgelegt, daß der öffentliche Schlüssel des vertrauenswürdigen Moduls in die Software-Ausführeinrichtung eingeführt wird (alternativ wird ein gemeinsam verwendeter Schlüssel zwischen der sicheren Ausführeinrichtung und dem vertrauenswürdigen Modul eingerichtet). Sowohl die Daten als auch die Software-Ausführeinrichtung werden hash-codiert und mit dem privaten Schlüssel der Verrechnungsinstanz/des Entwicklers signiert, und der öffentliche Schlüssel, der diesem entspricht, wird in dem vertrauenswürdigen Modul gespeichert.
– Die sichere Ladeeinrichtung unterzieht die Daten und die Software-Ausführeinrichtung einer Integritätsprüfung: Auf eine Installation hin wird das Paket durch ein Hash-Codieren und einen Vergleich mit der entschlüsselten Signatur (unter Verwendung des öffentli chen Schlüssels in dem vertrauenswürdigen Modul) verifiziert.
– Die Software-Ausführeinrichtung wird nicht geladen, falls die digitale Signatur nicht mit der Erwarteten übereinstimmt.
– Auf einen Anmeldevorgang unter Verwendung der Smartcard hin werden Öffentlicher-Schlüssel-Zertifikate der Smartcard und des vertrauenswürdigen Moduls zum Zweck einer zukünftigen Kommunikation ausgetauscht (falls dies nicht bereits geschehen ist), und es findet eine gegenseitige Authentifizierung zwischen dem vertrauenswürdigen Modul und der Smartcard statt.
– Das vertrauenswürdige Modul speichert die (aktuelle) Smartcard-ID.
– Wenn der Benutzer einige Daten ausführen möchte, gibt die Software-Ausführeinrichtung, die diesen Daten entspricht, eine Herausforderung/Antwort an die sichere Ausführeinrichtung aus, indem sie eine Zufallszahl (Einmalverfügung) zusammen mit einer Bezugnahme auf die Daten sendet.
– Die sichere Ausführeinrichtung führt eine entsprechende Lizenzierungsprüfung der Daten durch, indem sie die Smartcard-ID verwendet oder indem sie ansonsten manche Informationen, die auf der Smartcard gespeichert sind, erhält. Unter Verwendung des oben beschriebenen Lizenzierungsmodells führt die sichere Ausführeinrichtung beispielsweise folgendes durch:
– Sie prüft, ob die Daten lizenziert sind, um gemäß der Benutzer-ID der Smartcard, die eingeführt wurde, in dem in dem vertrauenswürdigen Modul gespeicherten Profil betrieben zu werden, oder
– sie prüft, ob die Daten lizenziert sind, um auf der Vertrauenswürdiges-Modul-ID in dem in dem vertrauenswürdigen Modul gespeicherten Profil betrieben zu werden, oder
– konsultiert einen Teil einer externen Datenbank oder lädt denselben herunter, um ein Profil in dem vertrauenswürdigen Modul zu bilden, um zu sehen, ob die Daten auf die oben beschriebene Weise lizenziert sind.
– Falls keine gültige Lizenz vorliegt, gibt die sichere Ausführeinrichtung eine Fehlermeldung zurück, aus der die Software-Ausführeinrichtung die genaue Art des Problems bezüglich der Lizenzierung bestimmen und das OS entsprechend benachrichtigen kann. Falls eine gültige Lizenz vorliegt, gibt die sichere Ausführeinrichtung eine Nachricht zurück, die die Einmalverfügung und Datenreferenz beinhaltet und die signiert und unter Verwendung des privaten Schlüssels des vertrauenswürdigen Moduls verschlüsselt ist.
– Die Software-Ausführeinrichtung verifiziert unter Verwendung des öffentlichen Schlüssels des vertrauenswürdigen Moduls, ob die Antwort der sicheren Ausführeinrichtung korrekt ist, und leitet je nach Fall entweder den Anruf an das OS weiter, um die Daten auszuführen, oder sendet eine Fehlermeldung an das OS.
– Das Protokoll wird statt in der Smartcard in dem Maschine-Vertrauenswürdiges-Modul gehalten und wird entsprechend aktualisiert.

Man sollte beachten, daß das Ausführungsbeispiel der Erfindung oben lediglich beispielhaft beschrieben wurde und daß innerhalb des Schutzbereichs der vorliegenden Erfindung viele Modifikationen und Entwicklungen an demselben vorgenommen werden können.

Claims

Eine Computerplattform, die folgende Merkmale aufweist: ein vertrauenswürdiges Modul (120), das gegenüber einem internen Manipulieren resistent ist und das ein Öffentlicher-Schlüssel-Zertifikat (214) einer dritten Partei speichert; eine Einrichtung, die einen lizenzbezogenen Code (200) speichert, der zumindest eines der folgenden Merkmale umfaßt: eine sichere Ausführeinrichtung (204) zum Prüfen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, bestimmte Daten zu verwenden, und zum Bereitstellen einer Schnittstelle zum Verwenden der Daten und/oder zum Überwachen ihrer Verwendung; und eine sichere Ladeeinrichtung (206) zum Prüfen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, bestimmte Daten zu installieren, und/oder zum Prüfen bezüglich einer Datenintegrität vor einer Installation; eine Einrichtung, die eine hash-codierte Version des lizenzbezogenen Codes (200), die mit dem privaten Schlüssel der dritten Partei signiert ist, speichert; wobei die Computerplattform so programmiert ist, daß auf ein Booten der Plattform hin: der lizenzbezogene Code (200) bezüglich der signierten Version und des Öffentlicher-Schlüssel-Zertifikats (214) auf seine Integrität hin überprüft wird; und falls die Integritätsprüfung negativ ausfällt, verhindert wird, daß der lizenzbezogene Code (200) geladen wird.
Eine Computerplattform gemäß Anspruch 1, bei der das Integritätsprüfen durch folgende Schritte durchgeführt wird: Lesen und Hash-Codieren des lizenzbezogenen Codes (200), um einen ersten Hash-Wert zu erzeugen; Lesen und Entschlüsseln der signierten Version unter Verwendung des Öffentlicher-Schlüssel-Zertifikats (214), um einen zweiten Hash-Wert zu erzeugen; und Vergleichen des ersten und des zweiten Hash-Wertes.
Eine Computerplattform gemäß Anspruch 1 oder 2, bei der der lizenzbezogene Code (200) ferner einen Code für einen sicheren Schlüsseltransfer (208) zum Ermöglichen, daß ein Lizenzschlüssel zwischen dem vertrauenswürdigen Modul (120) und einem weiteren vertrauenswürdigen Modul (120) einer weiteren Computerplattform transferiert wird, umfaßt.
Eine Computerplattform gemäß einem der vorhergehenden Ansprüche, bei der der lizenzbezogene Code (200) ferner eine, Bibliothek (210) von Schnittstellen-Teilroutinen umfaßt, die aufgerufen werden können, um mit dem vertrauenswürdigen Modul (120) zu kommunizieren.
Eine Computerplattform gemäß einem der vorhergehenden Ansprüche, bei der der lizenzbezogene Code (200) für zumindest eine Gruppe von Daten eine (oder eine jeweilige) Software-Ausführeinrichtung umfaßt, die die jeweilige Gruppe von Daten spezifiziert und die wirksam ist, um als Schnittstelle zu dieser Datengruppe zu fungieren.
Eine Computerplattform gemäß einem der vorhergehenden Ansprüche, bei der die Einrichtung, die den lizenzbezogenen Code (200) speichert, und/oder die Einrichtung, die die hash-codierte Version des lizenzbezogenen Codes (200) speichert, zumindest teilweise durch das vertrauenswürdige Modul (120) bereitgestellt werden.
Eine Computerplattform gemäß einem der vorhergehenden Ansprüche, bei der das vertrauenswürdige Modul (120) und ein Betriebssystem der Plattform einen zweckgebundenen Kommunikationsweg (122a) zwischen denselben aufweisen, der für andere Teile der Computerplattform unzugänglich ist.
Eine Computerplattform gemäß einem der vorhergehenden Ansprüche, bei der: das Betriebssystem wirksam ist, um die sichere Ladeeinrichtung (206) aufzufordern, eine Lizenzprüfung bezüglich dessen durchzuführen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, diese bestimmten Daten zu installieren, und/oder die Integrität dieser Daten zu prüfen; die sichere Ladeeinrichtung (206) ansprechend auf eine solche Aufforderung wirksam ist, um eine derartige Prüfung durchzuführen und auf das Betriebssystem mit dem Ergebnis der Prüfung zu antworten; und das Betriebssystem in Abhängigkeit von der Antwort wirksam ist, um die bestimmten Daten zu installieren oder nicht zu installieren.
Eine Computerplattform gemäß Anspruch 8, bei der das Betriebssystem programmiert ist, um die bestimmten Daten lediglich ansprechend auf die sichere Ladeeinrichtung (206) zu installieren.
Eine Computerplattform gemäß Anspruch 8 oder 9, bei der: das vertrauenswürdige Modul (120) ein Öffentlicher-Schlüssel-Zertifikat (216) für eine Partei speichert, die den bestimmten zu installierenden Daten zugeordnet ist; das Betriebssystem wirksam ist, um in der Prüfaufforderung die bestimmten Daten zusammen mit einer hashcodierten Version derselben, die mit einem privaten Schlüssel der zugeordneten Partei signiert ist, aufzunehmen; und die sichere Ladeeinrichtung (206) beim Durchführen der Prüfung wirksam ist, um: die in der Aufforderung enthaltenen bestimmten Daten einer Hash-Codierung zu unterziehen, um einen dritten Hash-Wert zu erzeugen; die signierte hash-codierte Version in der Aufforderung unter Verwendung des Öffentlicher-Schlüssel-Zertifikats (216) für die zugeordnete Partei zu entschlüsseln, um einen vierten Hash-Wert zu erzeugen; und die Antwort in Abhängigkeit davon, ob der dritte und der vierte Hash-Wert übereinstimmen, zu erzeugen.
Eine Computerplattform gemäß Anspruch 10, wenn dieser direkt oder indirekt von Anspruch 5 abhängig ist, bei der die Prüfaufforderung die Software-Ausführeinrichtung für die bestimmten Daten umfaßt.
Eine Computerplattform gemäß Anspruch 6, wenn dieser von Anspruch 5 abhängig ist, oder gemäß einem der Ansprüche 7 bis 11, wenn sie von demselben abhängig sind, bei der: die Software-Ausführeinrichtung (oder zumindest eine der Software-Ausführeinrichtungen) wirksam ist, um das vertrauenswürdige Modul (120) aufzufordern, bestimmte Daten zu installieren; die sichere Ladeeinrichtung (206) in dem vertrauenswürdigen Modul (120) als Antwort auf eine solche Aufforderung wirksam ist, um eine Lizenzprüfung bezüglich dessen durchzuführen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, diese bestimmten Daten zu installieren, und/oder um die Integrität dieser Daten zu prüfen und auf das Betriebssystem mit dem Ergebnis der Prüfung zu antworten; und das Betriebssystem in Abhängigkeit von der Antwort wirksam ist, um die bestimmten Daten zu installieren oder nicht zu installieren.
Eine Computerplattform gemäß Anspruch 12, bei der das Betriebssystem programmiert ist, um die bestimmten Daten lediglich als Antwort auf das vertrauenswürdige Modul (120) zu installieren.
Eine Computerplattform gemäß Anspruch 12 oder 13, wenn diese von Anspruch 7 abhängig sind, wobei die Antwort von dem vertrauenswürdigen Modul (120) an das Betriebssystem über den zweckgebundenen Kommunikationsweg (122a) geliefert wird.
Eine Computerplattform gemäß einem der Ansprüche 8 bis 14, bei der, falls die Prüfung erfolgreich ist, das vertrauenswürdige Modul (120) wirksam ist, um ein Protokoll zum Überprüfen der bestimmten Daten zu erzeugen.
Eine Computerplattform gemäß einem der Ansprüche 8 bis 15, bei der, falls die Prüfung erfolgreich ist, die sichere Ladeeinrichtung (206) wirksam ist, um eine Virusprüfung an den bestimmten Daten durchzuführen.
Eine Computerplattform gemäß einem der Ansprüche 8 bis 16, bei der die bestimmten Daten auf eine Installation hin in dem vertrauenswürdigen Modul (120) installiert werden.
Eine Computerplattform gemäß einem der Ansprüche 8 bis 16: die ferner ein weiteres, entfernbares vertrauenswürdiges Modul (120) umfaßt; wobei die Plattform wirksam ist, um eine Authentifizierungsprüfung zwischen dem zuerst erwähnten vertrauenswürdigen Modul (120) und dem entfernbaren vertrauenswürdigen Modul (19) durchzuführen; und wobei die bestimmten Daten auf eine Installation hin in dem weiteren vertrauenswürdigen Modul (120) installiert werden.
Eine Computerplattform gemäß Anspruch 5 oder einem der Ansprüche 6 bis 18, wenn diese direkt oder indirekt von demselben abhängig sind, bei der: die Software-Ausführeinrichtung (oder zumindest eine der Software-Ausführeinrichtungen) einen öffentlichen Schlüssel (228) des vertrauenswürdigen Moduls (120) und ein Lizenzierungsmodell für die jeweiligen Daten enthält; das Betriebssystem wirksam ist, um diese Software-Ausführeinrichtung aufzufordern, daß ihre jeweiligen Daten verwendet werden; diese Software-Ausführeinrichtung ansprechend auf eine solche Aufforderung wirksam ist, um die sichere Ausführeinrichtung (204) aufzufordern, unter Verwendung ihres Lizenzierungsmodells eine Lizenzprüfung bezüglich dessen durchzuführen, ob die Plattform oder ein Benutzer derselben dazu lizenziert ist, diese Daten zu verwenden; die sichere Ausführeinrichtung (204) ansprechend auf eine derartige zuletzt genannte Aufforderung wirksam ist, um die angeforderte Lizenzprüfung durchzuführen, das Ergebnis der Lizenzprüfung unter Verwendung eines privaten Schlüssels (212) des vertrauenswürdigen Moduls (120) zu signieren und auf diese Software-Ausführeinrichtung mit dem signierten Ergebnis anzusprechen; diese Software-Ausführeinrichtung ansprechend auf eine derartige Antwort wirksam ist, um: die Integrität des signierten Ergebnisses unter Verwendung des öffentlichen Schlüssels (228) des vertrauenswürdigen Moduls (120) zu prüfen; und auf eine erfolgreiche Integritätsprüfung eines erfolgreichen Lizenzprüfungsergebnisses hin das Betriebssystem aufzufordern, diese Daten zu verwenden.
Eine Computerplattform gemäß Anspruch 5 oder gemäß einem der Ansprüche 6 bis 19, wenn diese direkt oder indirekt von demselben abhängig sind, bei der: die Software-Ausführeinrichtung (oder zumindest eine der Software-Ausführeinrichtungen) einen öffentlichen Schlüssel (228) des vertrauenswürdigen Moduls (120) und ein Lizenzierungsmodell für die jeweiligen Daten enthält; das Betriebssystem wirksam ist, um die sichere Ausführeinrichtung (204) aufzufordern, daß bestimmte Daten verwendet werden; die sichere Ausführeinrichtung (204) ansprechend auf eine solche Aufforderung wirksam ist, um an die jeweilige Software-Ausführeinrichtung eine unter Verwendung eines privaten Schlüssels (212) des vertrauenswürdigen Moduls (120) signierte Anforderung eines Lizenzierungsmodells für die bestimmten Daten zu senden; die Software-Ausführeinrichtung ansprechend auf eine derartige zuletzt genannte Anforderung wirksam ist, um: die Integrität der Anforderung unter Verwendung des öffentlichen Schlüssels (228) des vertrauenswürdigen Moduls (120) zu prüfen; und auf eine erfolgreiche Integritätsprüfung hin das Lizenzierungsmodell an die sichere Ausführeinrichtung zu senden; und die sichere Ausführeinrichtung (204) auf einen Empfang des Lizenzierungsmodells hin wirksam ist, um: eine Lizenzprüfung unter Verwendung dieses Lizenzierungsmodells durchzuführen; und auf eine erfolgreiche Lizenzprüfung hin das Betriebssystem aufzufordern, diese Daten zu verwenden.
Eine Computerplattform gemäß einem der vorhergehenden Ansprüche, bei der: die sichere Ausführeinrichtung (204) zumindest ein Lizenzierungsmodell enthält; das Betriebssystem wirksam ist, um die sichere Ausführeinrichtung (204) aufzufordern, daß bestimmte Daten verwendet werden; und die sichere Ausführeinrichtung (204) ansprechend auf eine derartige Aufforderung wirksam ist, um: eine Lizenzprüfung unter Verwendung des oder eines der Lizenzierungsmodelle durchzuführen; und auf eine erfolgreiche Lizenzprüfung hin das Betriebssystem aufzufordern, diese Daten zu verwenden.
Eine Computerplattform gemäß einem der Ansprüche 19 bis 21, bei der das Betriebssystem programmiert ist, um die bestimmten Daten lediglich ansprechend auf die sichere Ausführeinrichtung (204) oder die Software-Ausführeinrichtung zu verwenden.
Eine Computerplattform gemäß Anspruch 6, wenn dieser von Anspruch 5 abhängig ist, oder gemäß einem der An sprüche 7 bis 22, wenn diese von demselben abhängig sind, bei der: die sichere Ausführeinrichtung (204) zumindest ein Lizenzierungsmodell enthält; die Software-Ausführeinrichtung (oder zumindest eine der Software-Ausführeinrichtungen) wirksam ist, um das vertrauenswürdige Modul (120) aufzufordern, daß seine jeweiligen Daten verwendet werden; die sichere Ausführeinrichtung (204) in dem vertrauenswürdigen Modul (120) ansprechend auf eine solche Aufforderung wirksam ist, um: eine Lizenzprüfung unter Verwendung des oder eines der Lizenzierungsmodelle durchzuführen; und auf eine erfolgreiche Lizenzprüfung hin das Betriebssystem aufzufordern, diese Daten zu verwenden.
Eine Computerplattform gemäß Anspruch 23, bei der das Betriebssystem programmiert ist, um die bestimmten Daten lediglich ansprechend auf das vertrauenswürdige Modul (120) zu verwenden.
Eine Computerplattform gemäß einem der Ansprüche 20 bis 24, wenn diese direkt oder indirekt von Anspruch 7 abhängig sind, bei der die Anforderung von der sicheren Ausführeinrichtung (204) an das Betriebssystem, die Daten zu verwenden, über den zweckgebundenen Kommunikationsweg (122a) geliefert wird.
Eine Computerplattform gemäß einem der Ansprüche 19 bis 25, bei der das vertrauenswürdige Modul (120) wirksam ist, um die Anforderung an das Betriebssystem, die Daten zu verwenden, zu protokollieren.
Eine Computerplattform gemäß einem der Ansprüche 19 bis 26; die ferner ein weiteres, entfernbares vertrauenswürdiges Modul (120) umfaßt, das eine Benutzeridentität enthält; wobei die Plattform wirksam ist, um eine Authentifizierungsprüfung zwischen dem zuerst erwähnten vertrauenswürdigen Modul (120) und dem entfernbaren vertrauenswürdigen Modul (19) durchzuführen; und wobei die sichere Ausführeinrichtung (204) oder Software-Ausführeinrichtung auf eine Lizenzprüfung hin wirksam ist, um die Lizenzprüfung unter Bezugnahme auf die Benutzeridentität durchzuführen.