DE102004024793A1

DE102004024793A1 - Verfahren und Gerät zur sicheren Verwaltung digitaler Rechte

Info

Publication number: DE102004024793A1
Application number: DE102004024793A
Authority: DE
Inventors: Marc Blommaert; Jorge Dr. Cuellar; Christian GÜNTHER; Michael Dr. Marhöfer
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2004-05-17
Filing date: 2004-05-17
Publication date: 2005-12-08

Abstract

Zur Lösung des Problems der Verlässlichkeit bei der Verwaltung digitaler Rechte (DRM) setzt die Erfindung Vertrauenswürdige Recheneinheiten (VRE) ein, die den Schutz wichtiger Daten und Programme sicherstellen, und verwendet so genannte infrastrukturgestützte Maßnahmen, um die Verlässlichkeit von Geräteidentifikatoren zu erhöhen. Je nach Anforderung an das Verlässlichkeits-Niveau eines DRM-Systems können jene Daten und Programme auch nur teilweise unter den Schutz einer VRE gestellt werden. Bei einer VRE handelt es sich um eine Hardwarekomponente des mobilen Kommunikationsgerätes, welches fest mit dem Gerät verbunden ist, über einen Speichermodul verfügt und Zugriffe auf diesen Speichermodul kontrolliert.

Description

Die sogenannte Verwaltung Digitaler Rechte (Digital Rights Management, kurz: DRM), also die Verwaltung von Rechten (z.B. von Urheberrechten oder gewerblichen Schutzrechten) an in digitaler Form vorliegenden, urheberrechtlich, vertraglich oder auf andere Weise rechtlich geschützten Werken oder Software-Produkten, etc. und insbesondere die Unterstützung dieser Verwaltung durch technische Maßnahmen und Einrichtungen, gewinnt zunehmend an Bedeutung in vielen Bereichen der Informations- und Kommunikationstechnik.
Ein Problem besteht dabei darin, die Nutzungsrechte, die ein Inhaber von Rechten einem oder mehreren mobilen Kommunikationsgeräten im Bezug auf bestimmte Dateninhalte gewährt, durch technische Maßnahmen an diese Geräte zu binden.
Ein weiteres Problem wird charakterisiert durch die Frage, wie Systeme, die das erste Problem lösen, durch technische Maßnahmen zu sicheren Systemen gemacht werden können, die verlässlich die Einhaltung von Nutzungsrechten garantieren.
Lädt beispielsweise der Benutzer eines mobilen Kommunikationsgerätes von einem geeigneten Diensteanbieter ein Musikstück auf sein Gerät und erwirbt die Erlaubnis, dieses Musikstück auf diesem einen Gerät anzuhören, so muss in dieser Situation verlässlich verhindert werden, dass das Musikstück auf einem anderen, nicht autorisierten Gerät angehört werden kann.

DRM-Verfahren, die für digitale, mobile Kommunikation spezifisch sind, befinden sich zur Zeit in der Standardisierung bei der Open Mobile Alliance (OMA), einem internationalen Standardisierungsgremium für mobile Datendienste. Die Standardisierungsentwürfe der OMA für DRM in der aktuellen Version 2 beschreiben DRM Protokolle, die eine ganze Reihe von wichtigen technischen Problemen – unter anderem die oben genannten Probleme – offen lassen. Dies liegt in der Natur der OMA Standards, die für viele Industrien und Netze gelten. Auch fast alle anderen, nicht von der OMA spezifizierten DRM Technologien benötigen Lösungen für die beiden oben genannten Probleme.

Diese Situation sucht die vorliegende Erfindung zu verbessern. Diese Aufgabe wird durch ein Verfahren bzw. durch ein Erzeugnis nach einem der Patentansprüche gelöst.

Im folgenden wird die Erfindung anhand bevorzugter Ausführungsbeispiele und mit Hilfe von Figuren näher beschrieben. Dabei zeigen die 3 – 15 in schematischer Weise verschiedene Ausführungsbeispiele der Erfindung. Um diese Beispiele und Figuren möglichst konkret zu machen, sind sie exemplarisch im Kontext der OMA Protokolle beschrieben.
Die Grundzüge einer bekannten, durch die Open Mobile Alliance (OMA) standardisierten Lösung für DRM können folgendermaßen beschrieben werden: Bevor ein Benutzer eines einzelnen mobilen Kommunikationsgerätes einen Dateninhalt, der durch OMA DRM geschützt ist, auf diesem Gerät verwenden kann, muss der Benutzer von einem sogenannten Rechteanbieter RI (englisch: Rights Issuer; wir verwenden daher die Abkürzung "RI" für den Rechteanbieter) ein sogenanntes Rechteobjekt RO (englisch: Rights Object) im Bezug auf den betreffenden Dateninhalt anfordern. Dieses RO legt fest, in welcher Art und Weise der Dateninhalt auf dem im RO genannten Gerät verwendet werden darf. Außerdem stellt es in verschlüsselter Form den Dekodierungsschlüssel zur Verfügung, der notwendig ist, um den Da teninhalt, der dem Gerät in verschlüsselter Form übermittelt wird, zu entschlüsseln.
Die Grundzüge des OMA DRM Verfahrens beruhen auf insgesamt vier verschiedenen Schlüsseln, von den zwei symmetrische Schlüssel sind, und die übrigen zwei ein asymmetrisches Schlüsselpaar bilden. Es gibt:

1) den "Dateninhaltsverschlüsselungsschlüssel" CEK (Content Encryption Key): Damit wird der Dateninhalt Cont verschlüsselt, um ihn vor unbefugter Benutzung zu schützen. CEK ist ein symmetrischer Schlüssel, so dass also CEK sowohl zum Ver- als auch zum Entschlüsseln verwendet wird.
2) den "Rechteverschlüsselungsschlüssel" REK (Rights Encryption Key): REK ist ebenfalls ein symmetrischer Schlüssel. Er dient zur Verschlüsselung des CEK.
3) den öffentlichen Geräteschlüssel Publ_Key: Wird verwendet, um REK asymmetrisch zu verschlüsseln.
4) den privaten Geräteschlüssel Priv_Key: Diesen kennt nur das Gerät. Das Gerät benötigt diesen, um aus Publ_Key(REK) den REK asymmetrisch dekodieren zu können.

Im Detail gibt es noch weitere kryptographische Daten, aber diese vier Schlüssel sind für das OMA DRM System entscheidend. OMA DRM funktioniert nun folgendermaßen:

1) Ein Benutzer möchte auf seinem mobilen Gerät einen bestimmten Dateninhalt Cont nutzen.
2) Auf das Gerät wird übertragen: CEK(Cont) [symm. Verschl. des Dateninhaltes] REK(CEK) [symm. Verschl. von CEK mit Hilfe von REK] Publ_Key(REK) [asym. Verschl. von REK mit Hilfe von Publ_Key] Rechteobjekt RO, das die Nutzungsrechte festlegt, die der Rechteanbieter dem Gerät im Bezug auf Cont gewährt ("Dieser Song darf fünfmal angehört werden").
3) Ein dafür vorgesehenes Programm auf dem Gerät tut folgendes: Berechne REK=Priv_Key(Publ_Key(REK)) [asym. Entschl. von REK mittels Priv_Key] Überprüfe anhand von RO, ob die Nutzung von Cont zulässig ist. Falls nein: Verweigere Nutzung. Ende. Andernfalls: Berechne CEK=REK(REK(CEK)) [symm. Entschl. von CEK mittels REK] Bestimme Cont=CEK (CEK (Cont)) [symm. Entschl. von Cont mittels CEK] Stelle Cont dem Benutzer auf diesem Gerät sinnvoll dar (Anhören, Ansehen, ...)

Die vorliegende Erfindung entwickelt die OMA Lösung weiter und kann zusammen mit der OMA Lösung verwendet werden. Die bekannten Entwürfe zu OMA DRM sind dadurch gekennzeichnet, dass die meisten Funktionen, die für das verlässliche Arbeiten des Systems wichtig sind, von einem sogenannten "DRM Agent" zu erledigen sind. Dies ist ein Softwareprogramm, das auf einem Endgerät läuft und das insbesondere die Interessen von Besitzern von Datennutzungsrechten durchsetzen soll. Wie genau die geforderten Sicherheitseigenschaften eines DRM Agenten implementiert werden sollen und auf welche Hardware genau er bei seiner Arbeit zurückgreifen kann, wird bei OMA DRM offen gelassen. Insbesondere wird offen gelassen, wie genau verhindert werden soll, dass Dateninhalte auf unbefugten Geräten genutzt werden. Die Erfindung bietet eine Lösung dieses Problems an.
Sie bezieht sich auf Datennutzungsrechtesysteme, die verschlüsselte Dateninhalte und Nutzungsrechte im Bezug auf diese Dateninhalte auf ein mobiles Kommunikationsgerät übertragen. Die Verschlüsselung des Dateninhaltes ist dabei abhängig von einem dafür vorgesehenen, öffentlichen Geräteschlüssel. Lassen die gewährten Nutzungsrechte dies zu, dann entschlüsselt das Gerät den Dateninhalte mit Hilfe des privaten Geräteschlüssels, um den Dateninhalt dem Benutzer sinnvoll zugänglich machen zu können.
Wie in 1 dargestellt, enthält das vom RI dem Gerät zur Verfügung gestellte RO insbesondere Empfängerinformationen. Zu den Empfängerinformationen gehören ein Geräteidentifizierer (englisch: Device ID) und ein Rechteverschlüsselungsschlüssel REK (englisch: Rights Encryption Key), der mit Hilfe des öffentlichen Schlüssels Publ_Key (Public Key) des Gerätes verschlüsselt ist (E_{Publ_Key}(REK)). Das Gerät kann den REK dekodieren unter Benutzung seines privaten, geheimen Schlüssels Priv_Key (Private Key), der zu seinem öffentlichen Schlüssel Publ_Key korrespondiert. Das eigentliche Rechteobjekt enthält neben einer digitalen Unterschrift auch den Dateninhaltsverschlüsselungsschlüssel CEK (englisch: Content Encryption Key), der mit Hilfe des REK verschlüsselt ist (E_REK(CEK)). Nach der Dekodierung des REK kann das Gerät auch den CEK entschlüsseln und mit dessen Hilfe den Dateninhalt dekodieren. Nach dieser Dekodierung ist der Dateninhalt einer sinnvollen Nutzung durch den Benutzer zugänglich.
Während in 1 der Fall eines einzelnen Gerätes betrachtet wird, sehen die Standardisierungsentwürfe der OMA auch eine DRM Lösungen für eine Gruppe (englisch: Domain) von Geräten vor. In 2 wird das Aussehen des ROs in diesem Fall illustriert.
An die Stelle eines einzelnen Geräteidentifizierers (Geräte ID) und eines öffentlichen Schlüssels Publ_Key, der einem einzelnen Gerät zugeordnet ist, tritt im Falle einer Gruppe von Geräten ein Gruppenidentifizierer (Domain ID) und ein öffentlicher Gruppenschlüssel (DK; englisch: Domain Key).
Der aktuelle Entwurf für OMA DRM, Version 2, datiert vom 27. Januar 2004 und kann bei der Open Mobile Alliance bestellt werden.
Die Erfindung beruht auf folgenden grundlegenden Ideen:

• Das Problem der Bindung von Nutzungsrechten an mobile Kommunikationsgeräte wird gelöst, indem Internationale Mobilgeräteidentitäten (International Mobile Equipment Identity – IMEI) als Geräteidentifizierer in DRM Systemen eingesetzt werden. Dabei geht die Geräte-IMEI als Identifizierer in ein Zertifikat ein und bindet so die Nutzungsrechte an das zugehörende Geräte (erste Grundidee).
• Das andere Problem, nämlich solche DRM Systeme verlässlich zu machen, wird gelöst, indem sogenannte Vertrauenswürdige Recheneinheiten (VRE) Daten und Programme schützen, die für die Verlässlichkeit des Systems relevant sind. Geräte-IMEIs können daneben auch durch infrastrukturgestützte Maßnahmen geschützt werden: Hierbei setzen Gerätehersteller und/oder Betreiber mobiler Kommunikationsnetze Equipment Identity Registers (EIRs) und/oder Central EIRs (CEIRs) dazu ein, Eigenschaften von IMEIs zu überprüfen, die für die Vertrauenswür digkeit des IMEI-basierten DRM Systems entscheidend sind (zweite Grundidee).

Die Verfahren zum Schutz von IMEIs, die dieser Erfindung entsprechen, können nicht nur in IMEI-basierten DRM Systemen verwendet werden, sondern auch in anderen Systemen. Hierzu zählen z.B. Spiele-Anwendungen, bei denen Datenströme verlässlich an Kommunikationsgeräte gebunden werden müssen.
IMEIs sind mehrstellige Ziffernfolgen, die u.a. einen Typenüberprüfungscode mit Länderkennung, einen Herstellercode und eine Seriennummer enthalten (siehe z.B. geltenden Standard 3GPP TS 23.003 V6.1.0 (2003-12)). Jedes mobile Kommunikationsgerät, das den Standards des Third Generation Partnership Project (3GPP) entspricht, wird bei der Herstellung mit einer eindeutigen IMEI ausgestattet, die bei jedem Einbuchen des Gerätes in ein geeignetes, mobiles Kommunikationsnetz angefordert wird. Die IMEI ist laut geltendem Standard (3GPP TS 22.016 V5.0.0 (2002-06)/dort section 3) so beschaffen, dass jedes individuelle Mobilfunkendgerät separat identifiziert werden kann.
Zur Lösung des ersten Problems, setzt diese Erfindung die IMEI eines Gerätes als Identifizierer in DRM Systemen ein. Die Nutzung eines Dateninhaltes durch den Benutzer kann entsprechend dieser Erfindung auf folgende Arten von der IMEI eines Gerätes abhängig gemacht werden: Die IMEI eines Gerätes kann in Zertifikaten verwendet werden, die die Bindung zwischen der IMEI und dem öffentlichen Schlüssel des Gerätes nachprüfbar verbürgen. Die IMEI kann auch als Eingabeparameter für ein sogenanntes Darstellungsprogramm verwendet werden: Das Darstellungsprogramm berechnet bei seinem ersten Aufruf auf dem Gerät einen Prüfwert, der u.a. von seinem eigenen Programmcode und der Geräte-IMEI abhängt, bestimmt bei jedem weiteren Aufruf diesen Prüfwert erneut, und macht den Dateninhalt für den Benutzer nur dann sinnvoll zugänglich, wenn der neu berechnete mit dem zuvor bestimmten Prüfwert übereinstimmt.
Diese Erfindung schließt auch die Verwendung von Internationalen Mobilgeräteidentitäten mit Softwareversionsnummer (International Mobile Equipment Identity and Software Version Number – IMEISV) als Geräteidentifizierer anstelle von IMEIs mit ein. Siehe hierzu z.B. die Technische Spezifikation 3GPP TS 23.003 V6.1.0 (2003-12) und dort den Abschnitt 6.2.2. Ist in dieser Erfindung von IMEI die Rede, so soll damit stets auch die Verwendung von IMEIs mit SV abgedeckt sein.
Das Problem der Verlässlichkeit verlangt nach Verfahren, mit deren Hilfe die Verlässlichkeit von IMEI-basierten DRM Systemen gewährleistet oder zumindest erhöht werden kann. Ein verlässliches DRM System ist insbesondere dadurch gekennzeichnet, dass es die Einhaltung von gewährten Nutzungsrechten sicherstellt. Ein verlässliches DRM System muss beispielsweise verhindern, dass entschlüsselte Dateninhalte auf nichtautorisierte Geräte übertragen werden, oder dass sich Programme zum Anhören oder Ansehen von Dateninhalten im Widerspruch zu den gewährten Nutzungsrechten verhalten. Insgesamt betrachtet muss ein vertrauenswürdiges, IMEI-basiertes DRM System Verfahren bereitstellen, die Daten und Programmen, die für die Vertrauenswürdigkeit des Systems entscheidend sind, vor nicht-autorisiertem Verändern, Lesen und Kopieren, aber auch vor Fälschen, Duplizieren und Übertragen auf andere Geräte schützen.
Einige der Daten, die im System eine Rolle spielen, sind ihrem Wesen nach nicht auf einen besonderen Schutz angewiesen oder verfügen über einen eingebauten Schutz (wie z.B. eine digitale Signatur oder eine Verschlüsselung). Hierzu zählen:

• Publ_Key: Public Key (der öffentliche, zu Priv_Key korrespondierende Schlüssel des Gerätes)
• Cert: Certificate (Digital unterschriebenes Zertifikat, das die Bindung zwischen der IMEI des Gerätes und Publ_Key überprüfbar verbürgt)
• RO: Rechteobjekt (enthält u.a. Nutzungsrechte und einen kodierten Dateninhaltsverschlüsselungsschlüssel)
• CEK(Cont): Der Dateninhalt Cont, der mit Hilfe des Dateninhaltsverschlüsselungsschlüssel CEK verschlüsselt ist. Zu den Daten und Programmen, deren Schutz die Verlässlichkeit eines IMEI-basierten DRM Systems im Sinne dieser Erfindung erhöhen oder sogar sicherstellen kann, zählen:
• IMEI: International Mobile Equipment Identity (Internationale Mobilgeräteidentität)
• Priv_Key: Private Key (der geheime, private Schlüssel des Gerätes)
• REK: Rights Encryption Key (Rechteverschlüsselungsschlüssel)
• CEK: Content Encryption Key (Dateninhaltsverschlüsselungsschlüssel)
• DP: Dekodierungsprogramm (entschlüsselt Dateninhalte mit Hilfe von Dateninhaltsverschlüssselungsschlüssel)
• AP: Anwendungsprogramm (macht Dateninhalte für den Benutzer sinnvoll zugänglich)
• VM: Verifikationsmodul (überprüft u.a. die Integrität der Anwendungsprogramme; siehe auch die Erläuterungen zum Ausführungsbeispiel 9)
• D: Darstellungsprogramm (siehe Erläuterung zu Ausführungsbeispiel 13)
• W: IMEI-abhängiger Prüfwert, von dem ein Darstellungsprogramm die Entschlüsselung und Darstellung eines Dateninhaltes für den Benutzer abhängig macht (siehe Erläuterungen zu Ausführungsbeispiel 13)

Zur Lösung des Problems der Verläßlichkeit setzt diese Erfindung Vertrauenswürdige Recheneinheiten (VREen – VRE im Singular) ein, die den Schutz der soeben aufgelisteten Daten und Programme sicherstellen. Je nach Anforderung an das Verlässlichkeits-Niveau des IMEI-basierten DRM Systems können auch nur ein Teil dieser Daten und Programme unter den Schutz einer VRE gestellt werden. Bei einer VRE handelt es sich um eine Hardwarekomponente des mobilen Kommunikationsgerätes, welches fest mit dem Gerät verbunden ist, über einen Speichermodul verfügt und Zugriffe auf diesen Speichermodul kontrolliert. Eine VRE kann zusätzlich auch über die Möglichkeit verfügen, bei der Geräteherstellung Daten und Programme einzuspeichern, ohne dass diese zu einem späteren Zeitpunkt unbefugt verändert werden könnten. Sie ist gegenüber Manipulation an der Gerätehardware geschützt. Außerdem gestattet sie das Lesen und Verändern der von ihr geschützten Daten und Programme nur solchen Programmen, die vom IMEI-basierten DRM System dafür autorisiert sind.
Die VRE kann z.B. analog zur entsprechenden Teilfunktion des Subscriber Identity Modul's (SIM, siehe GSM 02.17 V8.0.0: "SIM functional characteristics") realisiert werden. Verfügt die verwendete VRE über einen ausreichend großen Speichermo dul, so können dort nicht nur wenig speicherplatzintensive Daten wie IMEIs, sondern auch weitere Daten und Programme gespeichert und geschützt werden, die in der letzten Liste aufgeführt sind.
Eine VRE soll vor allem zwei Dinge leisten: Sie soll

a) die in ihr gespeicherten Daten und Programme, die entscheidend für die Vertrauenswürdigkeit des auf einem Geräteidentifikator basierenden DRM Systems sind, vor Veränderung schützen, und
b) Zugriffe auf diese nur autorisierten Programmen gewähren.

Insofern besteht eine VRE im allgemeinen aus einem Speichermodul, in dem sensible Daten und/oder Programme abgelegt werden können, und einem VRE-Kontrollprogramm bzw. VRE-Kontrollmodul, das Zugriffe auf diese Daten und Programme kontrolliert und selbst in einem Speicherbereich der VRE abgelegt ist, der gegen Veränderung geschützt ist. Ein VRE-Speichermodul kann sogar einen Bereich enthalten, indem Daten und Programme nur einmal geschrieben werden können. Dort kann dann z.B. die IMEI eines Gerätes und der private Geräteschlüssel abgelegt werden.
Die grundsätzliche Arbeitsweise einer VRE in einem auf Geräteidentifikatoren basierenden DRM System ist dann die folgende:

– Ein Programm A (etwa zur Dekodierung eines Rechteverschlüsselungsschlüssel (REK)) schickt einen Lese- oder Veränderungs-Request im Bezug auf ein bestimmtes Datum oder Programm (etwa einen Request, den privaten Geräteschlüssel lesen zu dürfen) an das VRE-Kontrollprogramm.
– Das VRE-Kontrollprogramm prüft, ob A befugt ist, dieses Datum oder Programm zu lesen bzw. zu verändern. Falls nein, wird der Zugriff verweigert. Falls ja, darf A das gewünschte Datum oder Programm lesen bzw. das gewünschte Datum oder Programm im VRE-Speichermodul verändern.

Im Sinne dieser Erfindung werden zum besonderen Schutz der IMEI auch sogenannte infrastrukturgestützte Maßnahmen eingesetzt, bei denen Gerätehersteller und/oder Betreiber mobiler Kommunikationsnetze mit Hilfe von EIRs und/oder CEIRs Eigenschaften (wie etwa Korrektheit und Eindeutigkeit) von IMEIs überprüfen, die für die Vertrauenswürdigkeit des IMEI-basierten DRM Systems relevant sind. Beispielsweise können die Betreiber mobiler Kommunikationsnetze entsprechend dem geltenden Standard (3GPP TS 22.016/dort section 4) die IMEI administrativ nutzen in einem sogenannten Geräteidentitätsregister (Equipment Identity Register – EIR). Ein solches EIR umfasst u.a. eine sogenannte "weiße Liste" (white list): „The white list is composed of all number series of equipment, that is permitted for use". Der Hauptzweck von IMEI/EIR ist das Erkennen von gestohlenen mobilen Kommunikationsgeräten. Flankierend zu den IMEI Standards hat die GSM Association (GSMA) gemeinsam mit der EICTA im Dokument „Security Principles Related to Handset Theft" Empfehlungen für Hersteller von mobilen Kommunikationsgeräten und für Betreiber von mobilen Kommunikationsnetzen zusammengestellt, um die Integrität der IMEI weiter zu verbessern. Im Unterschied zu ihrer ursprünglichen Funktionalität setzt diese Erfindung EIRs auch zum Schutz der IMEI in IMEI-basierten DRM Systemen ein.
In den nachfolgenden Ausführungsbeispielen 1 bis 12 wird der Fall von IMEI-basierten DRM Systemen behandelt, die IMEIs mit Hilfe von Zertifikaten an öffentliche Geräteschlüssel binden, aber keine Darstellungsprogramme einsetzen. Diese Ausführungsbeispiele unterscheiden sich in der Art und Anzahl der Daten und Programme, die sich in einem IMEI-basierten DRM System unter dem Schutz von dafür geeigneten Hardware-, Software- und Infrastrukturkomponenten befinden. Das Ausführungsbeispiel 13 illustriert IMEI-basierte DRM Systeme, bei denen die IMEI als Eingabeparameter für ein Darstellungsprogramm dient. Die Ausführungsbeispiele unterscheiden sich im Grad der Vertrauenswürdigkeit, die ein IMEI-basierten DRM System zur Verfügung stellt, das dem jeweiligen Ausführungsbeispiel entspricht.
Ein Zertifikat besteht im wesentlichen aus drei Daten:

1) Einem Identifizierer (z.B. eine Personalnummer oder einem Geräteidentifikator), der angibt, auf wen oder was sich das Zertifikat bezieht.
2) Einem Schlüssel, welcher der in 1) bezeichneten Identität (Person, Gerät) gehört, d.h. dieser Person bzw. diesem Gerät rechtmäßig zugeordnet ist.
3) Eine digitale Unterschrift über die Daten 1) und 2).

Diese Unterschrift ist folgendermaßen zu interpretieren: Derjenige, der diese Unterschrift erstellt hat, verbürgt mit seiner Unterschrift, dass der in 2) genannte Schlüssel auch tatsächlich der in 1) genannten Identität gehört. Insofern bindet ein Zertifikat einen Schlüssel an eine Identität. Mit Hilfe des öffentlichen Schlüssels des Unterzeichners kann jeder diese Unterschrift nachprüfen. Dass der öffentliche Schlüssel des Unterzeichners tatsächlich dem Unterzeichner gehört, verbürgt ein weiteres Zertifikat, das wiederum mit einem anderem öffentlichen Schlüssel unterschrieben ist. So gelangt man zu Ketten von Zertifikaten, an deren Schluss ein sog. Wurzelzertifikat steht. Dieses enthält dann den öffentlichen Schlüssel einer als vertrauenswürdig angesehenen Institution, ist selbst nicht unterschrieben, sondern ist häufig bereits Teil desjenigen Programms, das solche Zertifikate überprüft. Bei der Installation des MS Internet Explorer's z.B. werden bereits Dutzende solcher Wurzelzertifikate verfügbar gemacht.
Die wesentliches Bestandteile eines erfindungsgemäßen Zertifikats könnte z.B. so aussehen:
{Datum 1: IMEI des Gerätes,
Datum 2: Rechteverschlüsselungsschlüssel Publ_Key des Gerätes,
Datum 3: digitale Unterschrift über die Daten 1 und 2}
Die digitale Unterschrift könnte zum Beispiel von einem Gerätehersteller geleistet werden.
Um die Erfindung auszuführen, würde man beispielsweise mobile Kommunikationsgeräte mit einem existierenden oder noch zu bauenden Hardware-Module versehen, der die Eigenschaften einer verlässlichen Recheneinheit (VRE) erfüllt. Weiter würde man einen z.B. zu der OMA Lösung kompatiblen DRM Agent programmieren, der die Nutzung von Dateninhalten von dem Geräteidentifikator, z.B. der IMEI des Gerätes, auf dem er läuft, abhängig macht, und zur Absicherung des Systems Daten und/oder Programme unter den Schutz einer VRE stellt; hier ergeben sich einige Variationsmöglichkeiten, wie an den Ausführungsbeispielen zu erkennen ist; falls gewünscht, würde man auch noch ein Programm implementieren, das geeignet ist, die Geräte-IMEI an Server zu übertragen, die Anfragen an EIRs und/oder CEIRs stellen können, die die Vertrauenswürdigkeit der IMEI überprüfen. Der eigentliche Transport zu einem solchen Server muss sich an die entsprechenden 3GPP Spezifikationen halten. Auf den Servern würde man Programme implementieren, die folgende Datenbankabfragen durchführen können: "Ist diese IMEI eindeutig?", "Läßt sich diese IMEI einem Gerätehersteller zuordnen?", "Hat dieser Hersteller diese IMEI in der Vergangenheit einem Gerät zugeordnet?".
IMEIs können als Geräteidentifizierer in DRM Systemen dienen, und dabei helfen, Datennutzungsrechte an Geräte zu binden. Bei einer Implementierung interessiert dann aber auch die Frage, welches Niveau an Vertrauenswürdigkeit von dem IMEI-basierten System gefordert wird, und wie das Niveau erreicht werden kann. Hier kommen jetzt die VREen und die "infrastrukturgestützten Maßnahmen" ins Spiel. Die Ausführungsbeispiele zeigen IMEI-basierte DRM Systeme, die unterschiedliche Niveaus an Vertrauenswürdigkeit bereitstellen.
Ausführungsbeispiel 1 (3)
Entsprechend dieser Erfindung werden Nutzungsrechte an Dateninhalten mit Hilfe der IMEI an ein mobiles Kommunikationsgerät gebunden. In diesem ersten Ausführungsbeispiel werden keine besonderen Maßnahmen zum Schutz der IMEI oder anderer Daten und Programme ergriffen, die für das System relevant sind – weder auf Seiten der Gerätehersteller oder Betreiber mobiler Netze, noch geräteseitig. Insbesondere stehen in diesem Beispiel die folgenden Daten und Programme nicht unter dem Schutz einer VRE:

• IMEI des Gerätes.
• Privater Schlüssel des Gerätes.
• Öffentlicher Schlüssel des Gerätes, der zu dem privaten Schlüssel des Gerätes korrespondiert.
• Ein Zertifikat, das die Bindung der IMEI des Gerätes an seinen öffentlichen Schlüssel überprüfbar verbürgt. Dieses Zertifikat verwendet die IMEI als Identifizierer für das zugehörende Gerät.
• Rechteobjekte für jeden verschlüsselten Dateninhalt. Es ist auch möglich, dass sich ein Rechteobjekt auf mehrere Da teninhalte bezieht. Zu jedem Rechteobjekt gehört auch ein Dateninhaltsverschlüsselungsschlüssel (CEK), der mit Hilfe eines Rechteverschlüsselungsschlüssel (REK) verschlüsselt ist, der selbst wiederum über den öffentlichen Geräteschlüssel verschlüsselt ist.
• Gegebenenfalls einzelne Rechteverschlüsselungsschlüssel, die bereits unter Zuhilfenahme des privaten Geräteschlüssels dekodiert wurden.
• Dateninhalte, die mit ihrem jeweiligen Dateninhaltsverschlüsselungsschlüssel (CEK) verschlüsselt sind.
• Eines oder mehrere Programme, die verschlüsselte Dateninhalte unter Zuhilfenahme von Dateninhaltsverschlüsselungsschlüssel dekodieren können. Solche Programme sollen im folgenden kurz "Dekodierungsprogramme" genannt werden.
• Eines oder mehrere Programme, die die DRM geschützten Dateninhalte für den Benutzer sinnvoll zugänglich machen. Solche Programme sollen im folgenden kurz "Anwendungsprogramme" genannt werden. Beispiele für Anwendungsprogramme sind also Programme zum Abspielen von Musikstücken und zum Betrachten von Bildern oder Videos.

Die Vertrauenswürdigkeit eines IMEI-basierten DRM Systems, das diesem Ausführungsbeispiel entspricht, kann allerdings deutlich gesteigert werden. Dies wird in den nachfolgenden Beispielen beschrieben.
Ausführungsbeispiel 2 (4)
In diesem zweiten Ausführungsbeispiel wird die IMEI des mobilen Kommunikationsgerätes durch infrastrukturgestützte Maßnahmen geschützt, die die Eindeutigkeit der IMEI gewährleisten und sicherstellen, dass sich die IMEI eindeutig einem Hersteller zuordnen lässt und von diesem Hersteller in der Vergangenheit tatsächlich einem Gerät zugeordnet worden ist. Zu diesem Zweck unterhalten Gerätehersteller und/oder Betreiber mobiler Netze eine oder mehrere Datenbanken, die die soeben genannten Schutzmaßnahmen der IMEI zur Verfügung stellen. Gegebenenfalls sind diese Datenbanken auch unter einander vernetzt. Ein Netzbetreiber kann z.B. anhand seines EIR bzw. des firmenübergreifenden CEIR (Central EIR der GSMA), dort anhand der „white list" feststellen, ob die IMEI eines mobilen Kommunikationsgerätes korrekt ist.
Dieses Ausführungsbeispiel wendet keine weiteren, besonderen Schutzmaßnahmen auf die Daten und Programme an, die für ein IMEI-basiertes DRM System relevant sind. Insbesondere werden die nachfolgenden Daten und Programme nicht von einer VRE des Gerätes geschützt:

• IMEI des Gerätes.
• Privater Schlüssel des Gerätes.
• Öffentlicher Schlüssel des Gerätes, der zu dem privaten Schlüssel des Gerätes korrespondiert.
• Ein Zertifikat, das die Bindung der IMEI des Gerätes an seinen öffentlichen Schlüssel überprüfbar verbürgt. Dieses Zertifikat verwendet die IMEI als Identifizierer für das zugehörende Gerät.
• Rechteobjekte für jeden verschlüsselten Dateninhalt. Es ist auch möglich, dass sich ein Rechteobjekt auf mehrere Dateninhalte bezieht. Zu jedem Rechteobjekt gehört auch ein Dateninhaltsverschlüsselungsschlüssel (CEK), der mit Hilfe eines Rechteverschlüsselungsschlüssel (REK) verschlüsselt ist, der selbst wiederum über den öffentlichen Geräteschlüssel verschlüsselt ist.
• Gegebenenfalls einzelne Rechteverschlüsselungsschlüssel, die bereits unter Zuhilfenahme des privaten Geräteschlüssels dekodiert wurden.
• Dateninhalte, die mit ihrem jeweiligen Dateninhaltsverschlüsselungsschlüssel (CEK) verschlüsselt sind.
• Eines oder mehrere Dekodierungsprogramme.
• Eines oder mehrere Anwendungsprogramme.

Dieses Ausführungsbeispiel liefert einen nur bedingten Schutz der Nutzungsrechte, die einem mobilen Gerät im Bezug auf einen Dateninhalt gewährt werden: Der private Schlüssel des Gerätes, dessen Kenntnis letztendlich die Entschlüsselung des Dateninhaltes ermöglicht, ist nicht explizit gegen Auslesen, Kopieren und Abspeichern auf anderen Geräten geschützt.
Ausführungsbeispiel 3 (5)
In diesem Ausführungsbeispiel besitzt das mobile Kommunikationsgerät eine VRE, die die IMEI des Gerätes enthält. Die VRE gewährleistet, dass die IMEI nicht verändert werden kann, gestattet aber Lesezugriffe auf die IMEI. Nicht von einer VRE des Gerätes geschützte Daten und Programme sind die folgenden:

• Privater Schlüssel des Gerätes.
• Öffentlicher Schlüssel des Gerätes, der zu dem privaten Schlüssel des Gerätes korrespondiert.
• Ein Zertifikat, das die Bindung der IMEI des Gerätes an seinen öffentlichen Schlüssel überprüfbar verbürgt. Dieses Zertifikat verwendet die IMEI als Identifizierer für das zugehörende Gerät.
• Rechteobjekte für jeden verschlüsselten Dateninhalt. Es ist auch möglich, dass sich ein Rechteobjekt auf mehrere Dateninhalte bezieht. Zu jedem Rechteobjekt gehört auch ein Dateninhaltsverschlüsselungsschlüssel (CEK), der mit Hilfe eines Rechteverschlüsselungsschlüssel (REK) verschlüsselt ist, der selbst wiederum über den öffentlichen Geräteschlüssel verschlüsselt ist.
• Gegebenenfalls einzelne Rechteverschlüsselungsschlüssel, die bereits unter Zuhilfenahme des privaten Geräteschlüssels dekodiert wurden.
• Dateninhalte, die mit ihrem jeweiligen Dateninhaltsverschlüsselungsschlüssel (CEK) verschlüsselt sind.
• Eines oder mehrere Dekodierungsprogramme.
• Eines oder mehrere Anwendungsprogramme.

Auch dieses Ausführungsbeispiel liefert einen nur eingeschränkten Schutz der Nutzungsrechte von Dateninhalten: Es wendet nur eine einzige geräteseitige Maßnahmen zum Schutz der relevanten Daten und Programme an (nämlich den Schutz der IMEI durch eine VRE) und verzichtet auf infrastrukturgestützte Maßnahmen von Seiten der Gerätehersteller und/oder von Seiten der Betreiber mobiler Netze.
Ausführungsbeispiel 4 (6)
Eine Variante des letzten Ausführungsbeispiels besteht darin, neben einer VRE zum Schutz der IMEI auch noch infrastrukturgestützte Maßnahmen zu deren Schutz zu ergreifen. Dadurch wird die Vertrauenswürdigkeit eines IMEI-basierten DRM Systems, das dem letzten Ausführungsbeispiel entspricht, weiter erhöht.
Sogenannte Equipment Identity Registers (EIR) sind bislang hauptsächlich zum Erkennen von gestohlenen Geräten vorgesehen. Eine infrastrukturgestützte Schutzmaßnahme besteht aus folgenden Komponenten und Prozessen:

– einem Programm auf dem Gerät, das die Geräte-IMEI lesen darf und kann, und diese an einen Server überträgt, der Datenbankabfragen an EIRs durchführen kann;
– aus einem oder mehreren solchen Servern, die von Geräteherstellern und/oder Betreibern mobiler Netze betrieben werden;
– aus einem oder mehreren EIRs oder CEIRs, die von Geräteherstellern und/oder Betreibern mobiler Netze betrieben werden;
– aus den Datenbankabfragen der Server an die (C)EIRs, die Eigenschaften der übertragenen IMEIs überprüfen, die für die Vertrauenswürdigkeit des IMEI-basierten DRM Systems relevant sind. Beispiele: "Ist diese IMEI eindeutig?", "Lässt sich diese IMEI einem Gerätehersteller zuordnen?", "Hat dieser Hersteller diese IMEI in der Vergangenheit einem Gerät zugeordnet?".

Ausführungsbeispiel 5 (7)
Um die Vertrauenswürdigkeit eines IMEI-basierten DRM Systems weiter zu steigern, kann eine VRE des Gerätes nicht nur die IMEI des Gerätes schützen, sondern auch den privaten Schlüssel des Gerätes. Nicht unter dem Schutz einer Geräte-VRE stehen dann:

• Den öffentlichen Schlüssel des Gerätes, der zu dem privaten Schlüssel des Gerätes korrespondiert.
• Ein Zertifikat, das die Bindung der IMEI des Gerätes an seinen öffentlichen Schlüssel überprüfbar verbürgt. Dieses Zertifikat verwendet die IMEI als Identifizierer für das zugehörende Gerät.
• Rechteobjekte für jeden verschlüsselten Dateninhalt. Es ist auch möglich, dass sich ein Rechteobjekt auf mehrere Dateninhalte bezieht. Zu jedem Rechteobjekt gehört auch ein Dateninhaltsverschlüsselungsschlüssel (CEK), der mit Hilfe eines Rechteverschlüsselungsschlüssel (REK) verschlüsselt ist, der selbst wiederum über den öffentlichen Geräteschlüssel verschlüsselt ist.
• Gegebenenfalls einzelne Rechteverschlüsselungsschlüssel, die bereits unter Zuhilfenahme des privaten Geräteschlüssels dekodiert wurden.
• Dateninhalte, die mit ihrem jeweiligen Dateninhaltsverschlüsselungsschlüssel (CEK) verschlüsselt sind.
• Eines oder mehrere Dekodierungsprogramme.
• Eines oder mehrere Anwendungsprogramme.

Die VRE trägt Sorge dafür, dass die IMEI nicht verändert werden kann, gestattet aber Lesezugriffe auf die IMEI. Sie schützt den privaten Schlüssel des Gerätes vor nicht autorisierter Veränderung und gestattet nur autorisierte Lesezugriffe auf den privaten Schlüssel.
In diesem Ausführungsbeispiel muss der private Geräteschlüssel die VRE verlassen, da er an mindestens eines der Dekodierungsprogramme, das außerhalb der VRE liegt, übergeben werden muss. Dies stellt ein gewisses Sicherheitsrisiko dar. Dieses Risiko kann allerdings minimiert werden, indem Verfahren angewendet werden, die die Vertrauenswürdigkeit der Dekodierungsprogramme überprüfen, und indem der private Geräteschlüssel nicht länger als unbedingt nötig außerhalb der VRE sichtbar ist.
Ausführungsbeispiel 6 (8)
Ausführungsbeispiel 5 kann mit infrastrukturgestützten Schutzmaßnahmen der IMEI auf Seiten der Gerätehersteller und/oder Betreiber mobiler Netze kombiniert werden, um die Vertrauenswürdigkeit des zugehörenden IMEI-basierten DRM Systems zu steigern.
Ausführungsbeispiel 7 (9)
Eine weitere Verbesserung des zugehörenden IMEI-basierten DRM Systems ergibt sich, wenn zusätzlich zur IMEI und dem privaten Schlüssel des Gerätes auch noch die vorhandenen Dekodierungsprogramme und dekodierte Rechteverschlüsselungsschlüssel unter den Schutz einer Geräte-VRE gestellt werden. Ohne besonderen Schutz verwaltet das mobile Kommunikationsgerät dann nur noch:

• Öffentlicher Schlüssel des Gerätes, der zu dem privaten Schlüssel des Gerätes korrespondiert.
• Ein Zertifikat, das die Bindung der IMEI des Gerätes an seinen öffentlichen Schlüssel überprüfbar verbürgt. Dieses Zertifikat verwendet die IMEI als Identifizierer für das zugehörende Gerät.
• Rechteobjekte für jeden verschlüsselten Dateninhalt. Es ist auch möglich, dass sich ein Rechteobjekt auf mehrere Dateninhalte bezieht. Zu jedem Rechteobjekt gehört auch ein Dateninhaltsverschlüsselungsschlüssel (CEK), der mit Hilfe eines Rechteverschlüsselungsschlüssel (REK) verschlüsselt ist.
• Dateninhalte, die mit ihrem jeweiligen Dateninhaltsverschlüsselungsschlüssel (CEK) verschlüsselt sind.
• Eines oder mehrere Anwendungsprogramme.

Programme, die verschlüsselte Dateninhalte dekodieren, könnten bösartig so verändert werden, dass sie den entschlüsselten Dateninhalt auf ein Speichermedium des Gerätes schreiben, auf das der Benutzer freien Zugriff hat. Er könnte den entschlüsselten Dateninhalt dann beliebig selbst nutzen, weitergeben oder weiterverkaufen. Deshalb sollten Dekodierungsprogramme (aber auch andere Programme, die Zugriff auf sensible Daten haben) vor Veränderung geschützt werden. Das kann man erreichen, indem man solche Programme in einer VRE speichert, und das VRE-Kontrollprogramm so programmiert, dass es nichtautorisierte Schreibzugriffe auf diese Programme verhindert.
Bereits dekodierte Rechteverschlüsselungsschlüssel (REK=Priv_Key(Publ_Key(REK))) dürfen nur vom DRM Agent gelesen werden und das Gerät nicht verlassen, da sich mit dem REK ein CEK entschlüsseln lässt (CEK=REK(REK(CEK))), welcher wiederum die Dekodierung eines Dateninhaltes Cont zuläßt (Cont=CEK(CEK(Cont))). Eine Geräte-VRE kann verhindern, dass bereits dekodierte Rechteverschlüsselungsschlüssel in falsche Hände geraten, indem der DRM Agent solche Schlüssel in einen Speicherbereich der VRE schreibt, auf den das VRE-Kontrollprogramm nur dem DRM Agent Zugriff gestattet.
Ausführungsbeispiel 8 (10)
Auch zum letzten Ausführungsbeispiel können infrastrukturgestützte Schutzmaßnahmen der IMEI hinzugefügt werden.
Ausführungsbeispiel 9 (11)
In diesem Ausführungsbeispiel schützt eine VRE des Gerätes nicht nur die IMEI, den privaten Geräteschlüssel, die Dekodierungsprogramme und entschlüsselte Rechteverschlüsselungsschlüssel, sondern auch noch einen zusätzlichen Verifi kationsmodul. Dieser ist dafür verantwortlich, die Integrität der Anwendungsprogramme vor deren Aufruf zu überprüfen. Nicht unter dem Schutz einer VRE stehen dann, wie in den Beispielen 7 und 8, die folgenden Daten und Programme, die für das zugehörende IMEI-basierte DRM System relevant sind:

Das Verifikationsmodul kann neben der Integritätsprüfung der Anwendungsprogramme auch dazu dienen, den Anwendungsprogrammen die entschlüsselten Dateninhalte zu übergeben: Zu diesem Zweck liest das Verifikationsmodul ein Rechteobjekt und den darin enthaltenen, verschlüsselten Dateninhaltsverschlüsselungsschlüssel, dekodiert diesen mit Hilfe: des zugehörenden Rechteverschlüsselungsschlüssel, und ist damit in der Lage, den verschlüsselten Dateninhalt zu entschlüsseln und in dieser Form an ein geeignetes Anwendungsprogramm weiterzuleiten.
Um überprüfen zu können, dass ein Anwendungsprogramm A unverändert ist im Vergleich zur ersten Verwendung von A, enthält ein Verifikationsmodul VM ein Teil-Programm H, das nach Eingabe des Programmcodes C von A einen Prüfwert W' berechnet: W'=H(C). Zum Implementieren von H eignen sich Hash-Funktionen. Verifiziert VM das Programm A zum ersten Mal (was bei der Geräteherstellung geschehen sollte, aber auch noch bei einem späteren, ersten Aufruf die Vertrauenswürdigkeit des Systems erhöht), dann schreibt es den ersten Prüfwert W=H(C) in einen VRE-Speicherbereich, der vom VRE-Kontrollprogramm gegen nicht-autorisierte Veränderung geschützt wird. Bei allen weiteren Aufrufen von A überprüft VM, ob der jetzt neu berechnete Wert W'=H(C) mit dem ersten Wert W übereinstimmt. A wird nur dann ausgeführt, wenn dies der Fall ist.
Ein Verifikationsmodul besitzt also teilweise die Funktionalität und die Vorgehensweise von Darstellungsprogrammen. Die Ähnlichkeit vergrößert sich, wenn ein Verifikationsmodul auch noch die genannten, zusätzlichen Prozesse ausführt. Der Unterschied zwischen einem Verifikationsmodul und einem Darstellungsprogramm besteht aber immer darin, dass nur letzteres den entschlüsselten Dateninhalt dem Benutzer auch wirklich darstellt.
Ausführungsbeispiel 10 (12)
Auch das letzte Ausführungsbeispiel kann vorteilhaft mit infrastrukturgestützten Maßnahmen zum Schutz der IMEI weiterentwickelt werden. Die zusätzliche Verwendung von infrastrukturgestützten Maßnahmen zum Schutz der IMEI erhöht die Vertrauenswürdigkeit des DRM Systems, das dem letzten Ausführungsbeispiel entspricht.
Ausführungsbeispiel 11 (13)
Auch Anwendungsprogramme können die Vertrauenswürdigkeit von IMEI-basierten DRM Systemen verringern, wenn sie sich nicht wie erwartet verhalten. Bösartige Anwendungsprogramme könnten zum Beispiel entschlüsselte Dateninhalte in einen frei zugänglichen Gerätespeicher schreiben; von dort aus könnten die Dateninhalte dann in einer Art und Weise benutzt werden, die nicht den Rechten entspricht, die dem Gerät vom Rechteinhaber gewährt wurden. In Abwesenheit oder zusätzlich zu anderen Maßnahmen kann es daher auch sinnvoll sein, Anwendungsprogramme mit Hilfe einer VRE vor einem Verhalten zu schützen, das die Rechte von Rechteinhabern verletzt. Nicht unter dem Schutz einer Geräte-VRE stehen in diesem Ausführungsbeispiel:

• Öffentlicher Schlüssel des Gerätes, der zu dem privaten Schlüssel des Gerätes korrespondiert.
• Ein Zertifikat, das die Bindung der IMEI des Gerätes an seinen öffentlichen Schlüssel überprüfbar verbürgt. Dieses Zertifikat verwendet die IMEI als Identifizierer für das zugehörende Gerät.
• Rechteobjekte für jeden verschlüsselten Dateninhalt. Es ist auch möglich, dass sich ein Rechteobjekt auf mehrere Dateninhalte bezieht. Zu jedem Rechteobjekt gehört auch ein Dateninhaltsverschlüsselungsschlüssel (CEK), der mit Hilfe eines Rechteverschlüsselungsschlüssel (REK) verschlüsselt ist.
• Dateninhalte, die mit ihrem jeweiligen Dateninhaltsverschlüsselungsschlüssel (CEK) verschlüsselt sind.

Ausführungsbeispiel 12 (14):
Kombiniert mit infrastrukturgestützten Schutzmaßnahmen für die Geräte-IMEI, die von Geräteherstellern und/oder Betrei bern mobiler Netze durchgeführt werden, liefert das so modifizierte Ausführungsbeispiel 11 unter allen bisher genannten Ausführungsbeispielen den höchsten Grad an Vertrauenswürdigkeit in das zugehörende IMEI-basierte DRM System.
Ausführungsbeispiel 13 (15)
Dieses Ausführungsbeispiel illustriert den Fall eines IMEI-basierten DRM Systems, das den Speicherplatzbedarf einer VRE möglichst gering hält. Es verwendet ein sogenanntes Darstellungsprogramm D, das schließlich – falls alle erforderlichen Bedingungen erfüllt sind – den Dateninhalt für den Benutzer sinnvoll darstellt. Die Ausführung von D wird von einem Prüfwert W abhängig gemacht, in dessen Berechnung u.a. die Geräte-IMEI und der Programmcode von D eingeht. Ein solches System kann folgendermaßen arbeiten:

• Das Darstellungsprogramm D erhält als Eingabe die folgenden Daten:
1. Publ_Key(REK): das ist der mit dem öffentlichen Geräteschlüssel Publ_Key verschlüsselte Rechteverschlüsselungsschlüssel REK;
2. REK(CEK): das ist der mit REK verschlüsselte Dateninhaltsverschlüsselungsschlüssel CEK;
3. CEK(Cont): das ist der mit CEK verschlüsselte Dateninhalt Cont;
4. die Rechte, die dem Gerät im Bezug auf den Cont gewährt wurden;
5. seinen eigenen Programmcode C;
6. Priv_Key: das ist der zu Publ_Key korrespondierende, geheime Geräteschlüssel;
7. die IMEI des Gerätes.
• Wird D zum ersten Mal aufgerufen, so berechnet D zunächst einen Prüfwert W (etwa eine schlüsselabhängige Signatur oder einen Hashwert) über seinen eigenen Programmcode und die IMEI, die ihm als Parameter zur Verfügung gestellt wurde. Diesen Prüfwert W schreibt D in einen bestimmten Speicherbereich des Gerätes, um ihn bei nachfolgenden Programmdurchläufen wiederverwenden zu können. Anschließend überprüft D anhand der Rechte, ob die Nutzung des Dateninhaltes zulässig ist. Sollte dies nicht der Fall sein, so stellt D den Dateninhalt nicht für den Benutzer dar. Andernfalls entschlüsselt D mit Hilfe von Priv_Key nacheinander REK, CEK und Cont, und stellt den Dateninhalt den Nutzungsrechten entsprechend dem Benutzer des Gerätes dar.
• Bei jedem weiteren Aufruf verfährt das Darstellungsprogramm D wie im letzten Punkt beschrieben – mit einem Unterschied: D überprüft jetzt nicht nur die Nutzungsrechte, sondern berechnet den genannten Prüfwert aufs neue und vergleicht diesen neuen Wert W' mit dem Prüfwert W, der während des ersten Aufrufs im Speicher hinterlegt wurde. Sollte W' von W verschieden sein, oder sollten die Nutzungsrechte eine Darstellung nicht zulassen, so bricht D an dieser Stelle ab. Andernfalls entschlüsselt D den Dateninhalt wie im letzten Punkt beschrieben und stellt den Dateninhalt den Nutzungsrechten entsprechend dem Benutzer dar.

Was die Vertrauenswürdigkeit des Systems angeht, erledigt das Darstellungsprogramm D mit Programmcode C das folgende:

1) Beim ersten Aufruf wird die Funktion W=F(IMEI, C) berechnet. Dabei ist F(x,y) eine Funktion, die dadurch charakterisiert ist, dass es in der Realität praktisch unmöglich ist (d.h.: mathematisch gesehen existiert vielleicht eine Möglichkeit, aber deren Durchführung dauert in der Realität zu lange), zu x und y zwei weitere Parameter x' und y' zu finden, von denen sich zumindest x' von x oder y' von y unterscheidet, so dass F(x,y)=F(x',y') gilt. Beispiele solcher Funktionen sind sog. Hash-Funktionen. Beim ersten Aufruf von D sollte D den Prüfwert W in einem Speicherbereich des Gerätes abgelegen, den nur D lesen und einmalig beschreiben kann.
2) Bei allen weiteren Aufrufen: Berechne W'=F(IMEI, C)
3) Ist W'=W und erlauben die Nutzungsrechte dies, dann wird der Dateninhalt dem Benutzer dargestellt. Andernfalls wird der Dateninhalt dem Benutzer nicht dargestellt.

Der erste Aufruf von D sollte vorzugsweise bereits bei der Geräteherstellung durchgeführt werden. Allerdings würde die Vertrauenswürdigkeit des Systems auch schon erhöht, wenn die Berechnung und Abspeicherung des ersten Wertes W erst später erfolgen würden. In beiden Fällen schützt das System vor Angriffen, bei denen eine IMEI verwendet wird, die nicht mit der im ersten Programmaufruf verwendeten übereinstimmt, oder bei denen ein im Vergleich zum ersten Programmaufruf veränderter Code zum Einsatz kommt.
Es kann durch dieses Verfahren also der Schutz gegen Benutzer verbessert werden, die nach dem ersten Aufruf von D versuchen, über manipulierte IMEIs an Nutzungsrechte zu kommen, die ihnen nicht zustehen, oder die versuchen, über einen veränderten Programmcode z.B. an die entschlüsselten Dateninhalte zu kommen.
Die Absicht hinter diesem Verfahren ist es, den Speicherplatz, den eine Geräte-VRE haben muss, möglichst gering zu halten: Es sollten lediglich der Prüfwert W, die IMEI und der private Geräteschlüssel von einer VRE geschützt werden. Es müssen insbesondere keine (langen) Programme in einen VRE-Speichermodul aufgenommen werden.
Die Verlässlichkeit eines IMEI-basierten DRM Systems, das diesem Ausführungsbeispiel entspricht, hängt entscheidend davon ab, in wie weit eine VRE den Prüfwert W, der beim ersten Aufruf des Darstellungsprogramms D gespeichert wird, gegen Veränderung schützt.
Mit Hilfe von IMEI-basierten DRM Systemen können Nutzungsrechte, die Rechteanbieter mobilen Kommunikationsgeräten im Bezug auf Dateninhalte gewähren, an diese Geräte gebunden werden. Die wesentliche vorteilhafte Wirkung der ersten Grundidee liegt darin, eine Methode zur Verfügung zu stellen, die es technisch überhaupt erst ermöglicht, Nutzungsrechte von Dateninhalten auch tatsächlich an mobile Kommunikationsgeräte zu binden. Die Erfindung solcher IMEI-basierter DRM Systeme schließt damit eine entscheidende Lücke in den DRM Spezifikationen der Open Mobile Alliance (OMA).
Ein weiterer Vorteil lässt sich mit Blick auf die zweite Grundidee und die Ausführungsbeispiele erkennen: Mit Hilfe von Vertrauenswürdigen Recheneinheiten und/oder infrastrukturgestützten Maßnahmen lassen sich IMEI-basierte DRM Systeme mit sehr unterschiedlichen Verlässlichkeits-Niveaus implementieren. Damit können IMEI-basierte DRM Syeteme sehr flexibel an die Bedürfnisse und Anforderungen der Inhaber von Dateninhaltsrechten, der Anbieter und Nutzer von Dateninhalten, der Hersteller mobiler Kommunikationsgeräte und der Betreiber mobiler Netze angepasst werden.
Neben hard- und softwaregestützten Mechanismen können auch infrastrukturgestütze Maßnahmen zum Schutz, der IMEI zum Ein satz kommen (siehe Erläuterungen am Anfang von Punkt 3). Gerätehersteller und Betreiber mobiler Kommunikationsnetze, die solche infrastrukturgestützten Schutzmaßnahmen durchführen wollen, können dabei auf der vorhandenen Funktionalität von Geräteidentitätsregistern aufbauen und diese erweitern – was ebenfalls als Vorteil von IMEI-basierten DRM Systemen zu sehen ist.
In den nachfolgenden, zeichnerischen Darstellungen der Ausführungsbeispiele werden die folgenden Abkürzungen verwendet:

• IMEI: International Mobile Equipment Identity (Internationale Mobilgeräteidentität)
• Priv_Key: Private Key (der geheime, private Schlüssel des Gerätes)
• Publ_Key: Public Key (der öffentliche, zu Priv_Key korrespondierende Schlüssel des Gerätes)
• Cert: Certificate (Ein Zertifikat, das die Bindung zwischen der IMEI des Gerätes und Publ_Key überprüfbar verbürgt)
• RO: Rechteobjekt (enthält u.a. einen verschlüsselten Dateninhaltsverschlüsselungsschlüssel)
• REK: Rights Encryption Key (Rechteverschlüsselungsschlüssel)
• CEK: Content Encryption Key (Dateninhaltsverschlüsselungsschlüssel)
• DP: Dekodierungsprogramm (entschlüsselt Dateninhalte mit Hilfe von Dateninhaltsverschlüssselungsschlüssel)
• AP: Anwendungsprogramm (macht Dateninhalte für den Benutzer sinnvoll zugänglich)
• VM: Verifikationsmodul (überprüft u.a. die Integrität der Anwendungsprogramme; siehe auch die Erläuterungen zum Ausführungsbeispiel 9)
• VRE: Vertrauenswürdige Recheneinheit (kann z.B. die Integrität der von ihr kontrollierten Daten und Programme gewährleisten und Zugriffe auf solche Daten und Programme kontrollieren)
• D: Darstellungsprogramm (siehe Erläuterung zu Ausführungsbeispiel 13)
• W: IMEI-abhängiger Prüfwert, von dem ein Darstellungsprogramm die Entschlüsselung und Darstellung eines Dateninhaltes für den Benutzer abhängig macht (siehe Erläuterungen zu Ausführungsbeispiel 13)

In den zeichnerischen Darstellungen treten Felder mit der Beschriftung "IMEI" in zwei Varianten auf: Besitzt ein solches Feld einen schraffierten Hintergrund, so wird die IMEI durch infrastrukturgestützte Maßnahmen geschützt. Diese Maßnahmen können von Seiten der Gerätehersteller und/oder der Netzbetreiber bereitgestellt werden. Sie können beispielsweise mit Hilfe von (C)EIRs die Eindeutigkeit der IMEI gewährleisten. Sie können auch sicherstellen, dass sich die IMEI eindeutig einem Hersteller zuordnen läßt und in der Vergangenheit tatsächlich von diesem Hersteller einem mobilen Kommunikationsgerät zugeordnet worden ist. Ein Feld mit der Beschriftung "IMEI", das keinen schraffierten Hintergrund besitzt, zeigt an, dass keine solchen infrastrukturgestützten Schutzmechanismen auf die IMEI angewendet werden.

Claims

Verfahren zur Verwaltung digitaler Rechte auf der Grundlage eines eindeutigen Geräteidentifikators (IMEI) eines Gerätes zur Nutzung solcher digitalen Rechte, bei dem dieser Geräteidentifikator mit Hilfe einer vertrauenswürdigen Recheneinheit gegen unerlaubte Zugriffe oder unerlaubte Veränderungen geschützt wird.
Verfahren nach Anspruch 1, bei dem ein privater Geräteschlüssel eines Gerätes mit Hilfe einer vertrauenswürdigen Recheneinheit gegen unerlaubte Zugriffe oder unerlaubte Veränderungen geschützt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem ein Rechtever-/entschlüsselungsschlüssel oder ein Dateninhaltsver-/entschlüsselungsschlüssel eines Gerätes mit Hilfe einer vertrauenswürdigen Recheneinheit gegen unerlaubte Zugriffe oder unerlaubte Veränderungen geschützt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem Dekodierungsprogramme, Anwendungsprogramme, Verifikationsmodule, Darstellungsprogramme oder von solchen Programmen verwendete Prüfwerte mit Hilfe einer vertrauenswürdigen Recheneinheit gegen unerlaubte Zugriffe oder unerlaubte Veränderungen geschützt werden.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Gerät zur Nutzung eines solchen Rechts ein mobiles Kommunikationsendgerät ist, das als Bestandteil eines Mobilfunknetzes mit einer Kommunikationsinfrastruktur in Verbindung steht, wobei zusätzlich zur Verwendung vertrauenswürdiger Recheneinheiten auch infrastrukturelle Maßnahmen zum Schutz von schutzwürdigen Daten eingesetzt werden.
Verfahren nach Anspruch 5, bei dem durch Abfrage eines Geräteidentifikatorenregisters (EIR) geprüft wird, ob ein gegebener Geräteidentifikator eindeutig ist oder von einem Gerätehersteller in der Vergangenheit einem Gerät zugeordnet worden ist.
Gerät mit einer vertrauenswürdigen Recheneinheit zur Sicherstellung der Einhaltung von Vorschriften zur Prüfung von Nutzungsrechten an Daten, bei dem ein eindeutiger Geräteidentifikator (IMEI) dieses Gerätes mit Hilfe einer vertrauenswürdigen Recheneinheit gegen unerlaubte Zugriffe oder unerlaubte Veränderungen geschützt wird.
Gerät nach Anspruch 7, bei dem ein privater Geräteschlüssel eines Gerätes mit Hilfe einer vertrauenswürdigen Recheneinheit gegen unerlaubte Zugriffe oder unerlaubte Veränderungen geschützt wird.
Gerät nach einem der vorhergehenden Ansprüche, bei dem ein Rechtever-/entschlüsselungsschlüssel oder ein Da teninhaltsver-/entschlüsselungsschlüssel eines Gerätes mit Hilfe einer vertrauenswürdigen Recheneinheit gegen unerlaubte Zugriffe oder unerlaubte Veränderungen geschützt wird.
Gerät nach einem der vorhergehenden Ansprüche, bei dem Dekodierungsprogramme, Anwendungsprogramme, Verifikationsmodule, Darstellungsprogramme oder von solchen Programmen verwendete Prüfwerte mit Hilfe einer vertrauenswürdigen Recheneinheit gegen unerlaubte Zugriffe oder unerlaubte Veränderungen geschützt wird.
Gerät nach einem der vorhergehenden Ansprüche, bei dem das Gerät zur Nutzung eines solchen Rechts ein mobiles Kommunikationsendgerät ist, das als Bestandteil eines Mobilfunknetzes mit einer Kommunikationsinfrastruktur in Verbindung steht, wobei zusätzlich zur Verwendung vertrauenswürdiger Recheneinheiten auch infrastrukturelle Maßnahmen zum Schutz von schutzwürdigen Daten eingesetzt werden.
Gerät nach Anspruch 11, bei dem durch Abfrage eines Geräteidentifikatorenregisters (EIR) geprüft wird, ob ein gegebener Geräteidentifikator eindeutig ist oder von einem Gerätehersteller in der Vergangenheit einem Gerät zugeordnet worden ist.