-
Querverweis auf verwandte
Anmeldungen
-
Diese
Anmeldung nimmt die Priorität
der vorläufigen
Anmeldung US 60/981928 in Anspruch, welche am 23. Oktober 2007 eingereicht
wurde, und deren Offenbarung durch Inbezugnahme hierin aufgenommen
ist.
-
Technisches Gebiet
-
Die
vorliegende Erfindung betrifft das Gebiet der digitalen Rechteverwaltung
(Digital Rights Management, DRM). Die vorliegende Erfindung ist
insbesondere, jedoch ohne darauf beschränkt zu sein, auf eine Vorrichtung
und ein Verfahren für
das Bereitstellen einer sicheren Verknüpfung mit einer Benutzeridentität gerichtet.
-
Hintergrund
-
Ein
Problem bekannter Verfahren für
das Konsumieren von Inhalten geht auf die Tatsache zurück, dass
heutzutage die meisten Inhalt-konsumierenden Geräte nicht mit einem Benutzeridentitätsmodul,
wie z. B. einem Teilnehmeridentitätsmodul (Subscriber Identity
Module, *SIM), versehen sind. Dies ist häufig bei herkömmlichen
Endgeräten
der Fall, wie beispielsweise bei einem PC, TV und beweglichen Medienplayer.
Eine einfache Lösung
würde darin
bestehen, zum Zeitpunkt des Inhaltserwerbs, wenn die Benutzeridentität für Bezahlzwecke
bereitgestellt wird, auch die Identität des/der konsumierenden Geräts/Geräte anzugeben.
Aber dies ist nicht immer durchführbar,
da der Benutzer nicht im Voraus wissen kann, auf welchem/welchen
Gerät/Geräte der erworbene
Inhalt wiedergegeben werden wird. Ebenso kann das Angeben der Geräteidentität hinsichtlich der
Benutzerfreundlichkeit nachteilig sein.
-
Ein
anderer Weg, ein Gerät
mit einem Benutzer zu verknüpfen,
besteht für
den Dienstleister darin, eine Datenbank zu unterhalten, welche die
Beziehung zwischen Benutzern und Geräten erfasst. Um aber eine solche
Datenbank auf den aktuellen. Stand zu halten, muss der Benutzer
den Dienstleister jedes Mal informieren, wenn ein neues Gerät gekauft
oder ein altes Gerät
entsorgt wird, was für
den Benutzer eine schwere Bürde
darstellt. Ferner kann eine statische Datenbank nicht die Anwendungsfälle unterstützen, bei
welchen der Benutzer zeitweise von einem Fremdgerät Gebrauch
macht (z. B. TV in einem Hotelzimmer), um Inhalte wiederzugeben.
-
Eine
weitere Lösung
besteht darin, dem Benutzer einen Token auszustellen, nachdem er
oder sie erfolgreich authentifiziert wurde. Solch ein Token beinhaltet
die authentifizierte Benutzeridentität und muss dem DRM-Server für den Lizenzerwerb
präsentiert
werden. Ein Nachteil dieser Token-basierten Lösung besteht darin, dass der
Token auf sichere Weise vergeben werden muss, da jeder, der sich
Zugriff zum Token verschafft (oder einer Kopie davon) unter dem
Benutzernamen Lizenzen erwerben kann. Natürlich muss auch der Token selbst
hinsichtlich Authentizität
und Unversehrtheit geschützt
werden, sodass keiner einen Token fälschen oder die darin enthaltene
Benutzeridentität ändern kann.
-
Daher
bedarf es eines Verfahrens und einer Anordnung, welche viele Nachteile
der bekannten Verfahren überwindet,
um Inhalte für
das Konsumieren an einem Endgerät
bereitzustellen und zu in Rechnung zu stellen.
-
Zusammenfassung
-
Die
vorliegende Erfindung offenbart ein DRM-Gerät und ein Verfahren für das Bereitstellen einer
sicheren Verknüpfung
mit einer Benutzeridentität.
In einer Ausführungsform
wird eine erste Anfrage von einem DRM-Gerät an ein Teilnehmeridentitätsmodul
(Subscriber Identity Module) gesendet. Die erste Anfrage umfasst
wenigstens eine Gerätekennung.
Das Teilnehmeridentitätsmodul
führt ein
Sicherheits-Initialisierungsverfahren (security bootstrapping procedure)
mit einem vertrauenswürdigen
Schlüsselverwaltungs-Server
(key management server) durch, und sie einigen sich auf einen gemeinsam
benutzten Hauptschlüssel
(shared master key). Das Teilnehmeridentitätsmodul oder das Gerät, welches
das Teilnehmeridentitätsmodul
beherbergt, leitet vom Hauptschlüssel
basierend auf wenigstens der Gerätekennung
und einer Zufallszahl einen Schlüssel
ab. Eine Nachricht wird an das DRM-Gerät über einen sicheren authentifizierten
Kanal zurückgesendet.
Die Nachricht umfasst wenigstens eine Kennung für den Hauptschlüssel, die
Zufallszahl und den abgeleiteten Schlüssel. Als Reaktion auf die Nachricht
wird eine zweite Anfrage an einen DRM-Server gesendet. Die zweite
Anfrage umfasst wenigstens die Hauptschlüsselkennung, die Gerätekennung
und die Zufallszahl.
-
Es
wird auch ein DRM-Server und ein Verfahren für das Bereitstellen einer sicheren
Verknüpfung
mit einer Benutzeridentität
offenbart. In einer Ausführungsform
wird eine erste Anfrage von einem DRM-Gerät empfangen. Die erste Anfrage
umfasst wenigstens eine Hauptschlüsselkennung, eine Gerätekennung
und eine Zufallszahl. Das DRM-Gerät wird auf eine DRM-spezifische
Weise authentifiziert. Eine zweite Anfrage wird an einen vertrauenswürdigen Schlüsselverwaltungs-Server
gesendet. Die zweite Anfrage umfasst wenigstens die Hauptschlüsselkennung.
Ein abgeleiteter Schlüssel
wird vom Hauptschlüssel
basierend wenigstens auf der Gerätekennung
und der Zufallszahl bestimmt. Ein Challenge/Response-Schema wird
verwendet, um zu bestimmen, ob der abgeleitete Schlüssel des
DRM-Servers mit einem abgeleiteten Schlüssel des DRM-Geräts übereinstimmt.
-
Kurze Beschreibung der Zeichnungen
-
Im
folgenden Abschnitt wird die Erfindung bezüglich beispielhafter Ausführungsformen
beschrieben werden, welche in den Figuren dargestellt sind, wobei:
-
1 einen
Schritt zum Inhaltserwerb sowie einen Schritt zum Lizenzerwerb gemäß einer
Ausführungsform
darstellt;
-
2 ein
DRM-System gemäß einer
Ausführungsform
darstellt;
-
3 ein
Host-Gerät
gemäß einer
Ausführungsform
darstellt;
-
4 ein
Diagramm eines Verfahrens gemäß einer
Ausführungsform
darstellt;
-
5 ein
Diagramm eines Verfahrens gemäß einer
weiteren Ausführungsform
darstellt; und
-
6 ein
Blockschaltbild eines Knotens in einem DRM-System gemäß einer
Ausführungsform darstellt.
-
Detaillierte Beschreibung
-
Im
Folgenden soll ein DRM-Gerät
ein Gerät bezeichnen,
welches fähig
ist, Inhalte zu empfangen und zu konsumieren, die durch ein Verfahren
für digitale
Rechteverwaltung (Digital Rights Management, DRM) geschützt sind,
und Anforderungen erfüllt,
welche mit diesem Verfahren verbunden sind. Ferner soll ein DRM-System
ein Sys tem bezeichnen, das geschützte
Inhalte für
das Konsumieren bei einem DRM-Gerät verwaltet.
-
Es
werden ein Verfahren und eine Anordnung für das Verknüpfen des DRM-Geräts mit einer Benutzeridentität auf eine
dynamische und kryptografisch sichere Weise offenbart. Ein benutzer-
und gerätespezifischer
Schlüssel
wird als Ergebnis einer erfolgreichen Benutzerauthentifizierung,
basierend auf einem Teilnehmeridentitätsmodul (Subscriber Identity
Module, *SIM), wobei *SIM unterschiedliche Arten von Teilnehmeridentitätsmodulen
repräsentiert, wie
z. B. SIM, USIM (Universal Subscriber Identity Module), ISIM (IP
Multimedia Services Identity Module) usw., und einer erfolgreichen
Geräteauthentifizierung
erzeugt. Ein Gerät,
welches den spezifischen Schlüssel
kennt, kann einem Dienstleister versichern, dass das Gerät ein DRM-Gerät ist und
gegenwärtig
mit einer bestimmten Benutzeridentität verknüpft ist.
-
1 stellt
den Schritt eines Inhaltserwerbs und den Schritt eines Lizenzerwerbs
dar, welche für diese
Offenbarung relevant sind. Beim Schritt des Inhaltserwerbs wird
der Benutzer authentifiziert bevor es ihm erlaubt ist, eine Bestellung
zu machen. Beim Schritt des Lizenzerwerbs authentifiziert, indem
ein DRM-spezifischer Mechanismus verwendet wird (z. B. Gerätezertifikat),
der DRM-Server 135 das DRM-fähige Verbrauchergerät (im Folgenden
als DRM-Gerät 115 bezeichnet)
und überprüft den aktuellen
Status des Geräts 115.
Wenn bekannt ist, dass das Gerät
beeinträchtigt
ist, weist der DRM-Server 135 die Anfrage auf einen Lizenzerwerb
zurück.
-
Ein
Dienst für
Online-Inhalte, umfassend beispielsweise einen Inhalts-Shop 125 und
den DRM-Server 135, vollzieht gewöhnlich mehrere Schritte, einschließlich des
Durchsuchens des Inhalts, welcher durch den Inhalts-Shop 125 angeboten
wird, des Erwerbs des Inhalts über
ein Gerät 105 für Inhaltserwerb
und die Zustellung des erworbenen Inhalts (gewöhnlicherweise geschützt, indem
ein Verfahren für
digitale Rechteverwaltung (DRM) verwendet wird), des Lizenzerwerbs
und letztendlich des Konsumierens des Inhalts an einem oder mehreren Geräten. Das
Gerät,
welches für
den Inhaltserwerb verwendet wird, kann oder kann auch nicht das
Gerät sein,
welches gegenwärtig
den Inhalt konsumiert. Das Verbrauchergerät braucht eine Lizenz, um den Inhalt
wiederzugeben. Es kann die Lizenz selbständig erwerben (z. B. eine gerätegebundene
Lizenz) oder es kann eine Lizenz von einem anderen Gerät erhalten
(z. B. eine domänengebundene
Lizenz).
-
Das
DRM-Gerät 115,
welches beim Schritt des Lizenzerwerbs authentifiziert wird, muss
sicher mit dem Benutzer verknüpft
werden, welcher beim Schritt des Inhalts erwerbs authentifiziert
wird. Andernfalls kann ein Gerät
eines Angreifers, welches ein legitimes DRM-Gerät sein kann, die Lizenz kostenlos
erhalten. Der normale Ansatz herkömmlicher Dienstleister besteht
darin, eine Username/Password-basierte Authentifizierung bei beiden
Schritten zu verlangen (oder im Fall, dass das Erwerbsgerät und das
DRM-Gerät,
die eine Lizenz anfordern, dieselben sind, erfolgen beide Schritte
gemeinsam und teilen denselben Sicherheitskontext, welcher basierend
auf Username/Password etabliert wird).
-
In
einer betreiberverwalteten Diensteinfrastruktur (z. B. IMS) haben
Benutzer einen Sicherheitsberechtigungsnachweis, welcher besser
als eine Username/Password-Kombination
ist, d. h. ein manipulationssicheres Teilnehmeridentitätsmodul (*SIM).
Die Dienste für
Online-Inhalte sollten natürlich
die erhöhte
Sicherheit durch Verwenden einer *SIM-basierten Benutzerauthentifizierung
(oder genauer Teilnehmerauthentifizierung) unterstützen. Da Inhaltskosten
mit der selben *SIM-Teilnahme bzw. dem selben *SIM-Vertrag berechnet
werden können wie
andere Dienste, die der Benutzer empfängt, wie z. B. Anrufe, wird
auch das Abrechnen sowohl von Seiten des Betreibers als auch von
Seiten des Benutzers einfacher.
-
2 stellt
ein DRM-System 200 gemäß einer
Ausführungsform
dar. Ein DRM-Gerät 235 kann mit
dem Gerät,
welches das Benutzeridentitätsmodul beherbergt,
durch irgendwelche lokalen Mittel verbunden sein, welches im Folgenden
als *SIM 215 bezeichnet wird. Eine Vielzahl von Geräten kann
mit dem *SIM-beherbergenden Gerät,
wie z. B. Gerät 305 von 3,
gleichzeitig verbunden sein, wobei *SIM 215 jene Geräte gleichzeitig
bedient, wie beispielsweise in einem Heim-IMS Gateway-Szenario.
-
Es
gibt einen sicheren authentifizierten Kanal (Secure Authenticated
Channel, SAC) zwischen dem DRM-Gerät 235 und *SIM 215.
Dieser Kanal kann durch Verwenden unterschiedlicher Mechanismen
etabliert werden, wie z. B. Bluetooth SIM Zugang oder ETSI TS 102
484. Die Details für
die SAC-Etablierung sind im Stand der Technik wohl bekannt.
-
Im
Allgemeinen bauen die Ausführungsformen
der vorliegenden Erfindung auf einem sicheren *SIM-basierten Bootstrapping
Verfahren auf, welches nach einer erfolgreichen Benutzerauthentifierung
in einem Schlüssel
resultiert, der zwischen dem *SIM und einem vertrauenswürdigen Schlüsselverwaltungs-Server
geteilt wird. Es wird angenommen, dass der DRM-Server jenen Schlüssel (oder
einen davon abgeleiteten Schlüssel)
vom Schlüsselverwaltungs-Server
abrufen kann.
-
Eine
Ausführungsform
der Erfindung wird nun beschrieben werden, welche, um die Beschreibung
klar und leicht verständlich
zu machen, auf die 3GPP-generische Bootstrapping-Architektur (Generic
Bootstrapping Architecture, GBA) als das Bootstrapping-Protokoll
basiert. Für
einen Fachmann ist offensichtlich, dass jedes andere Protokoll,
welches *SIM verwendet, um den Benutzer zu authentifizieren und
nach erfolgreicher Authentifizierung einen gemeinsam benutzten Schlüssel zwischen
dem *SIM und dem Schlüsselverwaltungs-Server
zu etablieren, für
die Erfindung verwendet werden kann.
-
Im
Zusammenhang mit GBA ist die Bootstrapping-Funktion 205 (Bootstrapping
function, BSF) der vertrauenswürdige
Schlüsselverwaltungs-Server,
und der Schlüssel,
welcher zwischen *SIM 215 und BSF 205 geteilt
wird, ist der Hauptschlüssel
Ks, welcher durch die Bootstrapping-Transaktions-ID (B-TID) identifiziert
wird. Der DRM-Server 225,
welcher in der GBA-Terminologie als Netzwerkanwendungsfunktion (Network
Application Funktion, NAF) agiert, ruft einen von Ks abgeleiteten
Schlüssel, wie
beispielsweise einen anwendungsspezifischen Schlüssel (KS_NAF), von BSF 205 ab.
-
Die
Schritte, welche in 2 dargestellt sind, erfolgen
zur Zeit des Lizenzerwerbs. Als eine Vorstufe wurde der Benutzer
durch Ausführen
von GBA authentifiziert. BSF 205 und *SIM 215 des
Benutzers teilen infolgedessen den Hauptschlüssel Ks und B-TID.
-
Das
Verfahren ist wie folgt:
- 1. Das DRM-Gerät 235 muss
eine Lizenz vom DRM-Server 225 erwerben. Bevor die Lizenz
erworben wird, sendet das DRM-Gerät 235 eine Anfrage
an *SIM 215, welche die Kennung des DRM-Servers (NAF_id)
und die Geräte-ID (Dev_id)
umfasst. Die Geräte-ID
ist eine Kennung des Geräts,
welche durch das DRM-System zugeteilt wird.
- 2. Basierend auf der NAF_id leitet *SIM 215 einen anwendungsspezifischen
Schlüssel
(Ks_NAF) vom Hauptschlüssel
Ks ab. Anschließend
leitet *SIM 215 basierend auf der Dev_id und einer Zufallszahl
(Random Number, RN) zusätzlich
einen abgeleiteten Schlüssel
(Ks_NAF_Dev) vom anwendungsspezifischen Schlüssel (Ks_NAF) ab. Die Zufallszahl
RN kann in einer Ausführungsform durch
*SIM 215 erzeugt werden und in einer anderen Ausführungsform
durch das *SIM- beherbergende
Gerät 315 bei
jeder Ableitung von Ks_NAF_Dev neu bereitgestellt werden.
Es
ist zu beachten, dass GBA zwei Varianten umfasst: eine universelle
Identifikationsschaltungskarte für
die generische Bootstrapping-Architektur (Generic Bootstrapping
Architecture Universal Identification Circuit Card, GBA_UICC oder GBA_U)
und ein GBA-Mobilgerät
(GBA Mobile Equipment, GBA_ME). In der GBA_U Variante wird der Hauptschlüssel durch
*SIM 215 erzeugt. *SIM 215 leitet später einen
anwendungsspezifischen Schlüssel
auf Anfrage ab. Gewöhnlich
leitet *SIM 215 einen internen anwendungsspezifischen Schlüssel (Ks_int_NAF)
und einen externen anwendungsspezifischen Schlüssel (Ks_ext_NAF) vom Hauptschlüssel Ks
ab. In dieser Ausführungsform
bezieht sich Ks_NAF auf den Ks_int_NAF und wird von *SIM 215 benutzt, um
den Ks_NAF_Dev abzuleiten. In einer anderen Ausführungsform kann sich Ks_NAF
auf Ks_ext_NAF beziehen und kann durch das Gerät 235 verwendet werden,
um Ks_NAF_Dev abzuleiten.
In der GBA_ME Variante erzeugt *SIM 215 den Hauptschlüssel Ks.
Das Mobilgerät
(ME oder Host-Gerät),
d. h. Gerät 305,
leitet weitere Schlüssel
(sowohl Ks_NAF als auch Ks_NAF_Dev) vom Hauptschlüssel ab.
- 3. *SIM 215 gibt dem DRM-Gerät innerhalb des sicheren authentifizierten
Kanals (SAC) B-TID, RN und Ks_NAF_Dev zurück.
- 4. Das DRM-Gerät 235 sendet
eine Anfrage an den DRM-Server 225, welcher unter anderem
die B-TID, Dev_id und RN umfasst. Das Protokoll für den Lizenzerwerb
wird durch das verwendete DRM-System bestimmt. Typischerweise bringt das
Protokoll eine Reihe von Nachrichtenaustauschen mit sich. B-TID,
Dev_ID und RN werden in der Kommunikation gesendet, in welcher der DRM-Server 225 zuerst
das DRM-Gerät 235 authentifiziert.
Die Kommunikation schließt
Informationen ein, welche für
die Geräteauthentifizierung erforderlich
sind, wie z. B. ein Gerätezertifikat
und eine Signatur.
- 5. Der DRM-Server 225 authentifiziert das DRM-Gerät 235,
indem ein spezieller Mechanismus verwendet wird, z. B. indem das
Gerätezertifikat
und die Signatur verifiziert werden. Wenn die Authentifizierung
gelingt, fährt
der DRM-Server 225 mit Schritt 6 fort. Andernfalls
weist der DRM-Server 225 die Anfrage vom DRM-Gerät 235 zurück.
- 6. Der DRM-Server 225 (welcher als Netzwerkanwendungsfunktion
(Network Application Funktion, NAF) agiert) kontaktiert BSF 205,
um Ks_NAF abzurufen, indem er B-TID und NAF_id eingibt.
- 7. BSF 205 ruft Ks basierend auf B-TID ab und leitet
von Ks Ks_NAF ab.
- 8. BSF 205 gibt an den -DRM Server 225 Ks_NAF, IMPI
(IMS Private Identity) sowie USS (User Security Setting) zurück.
- 9. Basierend auf Dev_id und RN leitet der DRM-Server 225 Ks_NAF_Dev
von Ks_NAF ab.
- 10. Der DRM-Server 225 überprüft, ob das DRM-Gerät 235 die
korrekte Ks_NAF_Dev weiß. In
einer Ausführungsform
verwendet der DRM-Server 225 ein Challenge/Response-Schema
bevor die Lizenz erteilt wird.
-
Innerhalb
eines angemessenen Zeitraums kann das DRM-Gerät 235 Ks_NAF_Dev wieder
benutzen, um eine neue Lizenz zu erwerben, ohne dabei das gesamte
Verfahren zu wiederholen. Der Zeitraum darf die Lebensdauer des
Ks nicht überschreiten.
In einer Ausführungsform
wird der Zeitraum durch den DRM-Server 225 bestimmt.
-
In
einer Ausführungsform
basiert die Schlüsselableitungsfunktion
(Key Derivation Funktion, KDF), die verwendet wird, um Ks_NAF von
Ks abzuleiten, auf HMAC-SHA-256,
wie durch GBA spezifiziert. Für
die Ableitung von Ks_NAF_Dev von Ks_NAF kann dieselbe KDF verwendet
werden. Aber auch andere moderne sichere schlüsselbasierte Hash-Algorithmen
können
verwendet werden. Die Eingabeparameter für die Schlüsselableitungsfunktion müssen Ks_NAF
(als den Schlüssel
zur schlüsselbasierten
Hash-Funktion), Dev_id und RN umfassen. Andere Parameter können entsprechend
hinzugefügt werden.
-
3 stellt
ein Gerät
dar, welches ein *SIM-Modul 215 und ein Schlüsselableitungs- und Kommunikationsmodul 315 umfasst,
welches über den
SAC mit externen Einheiten kommuniziert. In 3 kommuniziert
das DRM-Gerät 225 mit
*SIM 215 direkt. In einigen Szenarien, bei denen dem Gerät 305,
welches *SIM 215 beherbergt, vertraut wird (z. B. ein Internet
Protocol Multimedia Subsystem (IMS) Gateway), kommuniziert das DRM-Gerät 225 mit
dem *SIM-beherbergenden Gerät 305 (und
das *SIM-beherbergende
Gerät 305 kommuniziert
seinerseits mit *SIM 215). In dieser Ausfüh rungsform
leitet das *SIM-beherbergende Gerät 305 die Ks_NAF_Dev
von Ks_NAF ab und ein SAC zwischen dem *SIM-beherbergenden Gerät 305 und
dem DRM-Gerät 235 wird
etabliert. Der Vorteil dieses Ansatzes besteht darin, dass eine „normale” *SIM verwendet
werden kann, d. h. es besteht kein Bedarf, die *SIM mit zusätzlichen
Fähigkeiten
auszustatten, um die vorgeschlagene Lösung zu unterstützen.
-
Zusätzlich zum
Lizenzerwerb kann Ks_NAF_Dev verwendet werden, um andere Transaktionen
zu ermöglichen,
welche einen Nachweis der Verknüpfung
zwischen Gerät
und Benutzer und/oder den Status des Geräts verlangen. Da Ks_NAF_Dev, wie
z. B. der abgeleitete Schlüssel,
gerätespezifisch ist,
d. h. dass unterschiedliche Geräte,
welche Gebrauch von derselben *SIM machen, unterschiedliche Schlüssel erhalten,
kann dieser abgeleitete Schlüssel
verwendet werden, um zu authentifizieren und/oder jegliche DRM-Systemprotokollnachricht
zu verschlüsseln,
welche zwischen dem Gerät 235, 305 und
dem DRM Server 325 ausgetauscht wird.
-
Es
ist zu bemerken, dass die vorgeschlagene Lösung auch verwendet werden
kann, wenn das DRM-Gerät 235 ein
*SIM beherbergt, entweder denselben *SIM, welcher für die Benutzerauthentifizierung
verwendet wird, oder einen anderen *SIM (welcher z. B. zu einem
anderen Benutzer gehört).
-
4 zeigt
ein Verfahren zum Bereitstellen einer sicheren Verknüpfung mit
einer Benutzeridentität
an einem DRM-Gerät,
wie z. B. einem DRM-Gerät 235.
Das DRM-Gerät 235 muss
eine Lizenz vom DRM Server 225 erwerben. Bei Schritt 405 wird
eine erste Anfrage vom DRM-Gerät 235 an
ein Benutzeridentitätsmodul,
d. h. *SIM 215, gesendet. Die erste Anfrage umfasst eine
NAF-Kennung des DRM-Servers 225 und eine Gerätekennung
des DRM-Gerätes 335.
Die Geräte-ID
ist eine Kennung des Gerätes, welche
durch das DRM-System zugewiesen wird.
-
Bei
Schritt 415 wird eine Nachricht vom Benutzeridentitätsmodul 215 über einen
sicheren authentifizierten Kanal empfangen. Diese Nachricht umfasst
wenigstens eine Hauptschlüsselkennung, eine
Zufallszahl und einen abgeleiteten Schlüssel. In einer Ausführungsform
umfasst die Nachricht eine GBA Bootstrapping-Transaktionskennung, welche auch den
Hauptschlüssel
Ks, eine Zufallszahl RN und einen abgeleiteten Schlüssel identifiziert.
In dieser Ausführungsform
empfängt
das DRM-Gerät 235 B-TID,
RN und Ks_NAF_Dev von *SIM 215 innerhalb des sicheren authentifizierten
Kanals (SAC).
-
Bei
Schritt 425 wird als Antwort auf die Nachricht eine zweite
Nachricht an den DRM Server 225 gesendet. Die zweite Anfrage
umfasst wenigstens eine Hauptschlüsselkennung, eine Gerätekennung und
eine Zufallszahl. In einer Ausführungsform
umfasst die zweite Anfrage die GBA Bootstrapping-Transaktionskennung,
die Gerätekennung
und die Zufallszahl RN.
-
Das
DRM-Gerät 235 sendet
eine Anfrage an den DRM-Server 225, welcher unter anderem
die B-TID, Dev_ID und RN umfasst.
-
Das
Protokoll für
den Lizenzerwerb wird durch das verwendete DRM-System bestimmt.
Typischerweise bringt das Protokoll eine Reihe von Nachrichtenaustauschen
mit sich. B-TID, Dev_id und RN werden in der Kommunikation gesendet,
bei welcher der DRM-Server 225 zuerst das DRM-Gerät 235 authentifiziert.
Die Kommunikation umfasst die Information, welche für die Geräteauthentifizierung
erforderlich ist, wie beispielsweise ein Gerätezertifikat und eine Signatur.
-
5 zeigt
ein Verfahren für
das Bereitstellen einer sicheren Verknüpfung mit einer Benutzeridentität an einem
DRM-Server, wie z. B. einen NAF/DRM-Server 225. Bei Schritt 505 wird
eine erste Anfrage vom DRM-Gerät 235 empfangen.
Die erste Anfrage umfasst wenigstens eine Hauptschlüsselkennung,
eine Gerätekennung
und eine Zufallszahl. In einer Ausführungsform enthält die erste
Anfrage eine GBA-Bootstrapping-Transaktionskennung, eine Gerätekennung
und eine Zufallszahl RN.
-
Der
DRM-Server 225 empfängt
vom DRM-Gerät 235 eine
Anfrage für
eine Lizenz, welche in einer Ausführungsform unter anderem die
B-TID, Dev_id und RN umfasst. Das Protokoll für den Lizenzerwerb wird durch
das verwendete DRM-System bestimmt. Typischerweise bringt das Protokoll
eine Reihe von Nachrichtenaustauschen mit sich. In dieser Ausführungsform
werden B-TID, Dev_id und RN in der Kommunikation gesendet, bei welcher
der DRM-Server 225 zuerst das DRM-Gerät 235 authentifiziert.
Die Kommunikation schließt
Informationen ein, welche für
die Geräteauthentifizierung
notwendig sind, wie z. B. ein Gerätezertifikat und eine Signatur.
-
Bei
Schritt 515 wird das DRM-Gerät 235 durch den DRM-Server 225 authentifiziert.
Der DRM-Server 225 authentifiziert das DRM-Gerät 235, indem
ein DRM-spezifischer Mechanismus verwendet wird, wie z. B. das Verifizieren
des Gerätezertifikats
und der Signatur. Ist die Authentifizierung erfolgreich, so fährt der
DRM-Server 225 mit Schritt 525 fort. Andernfalls
weist der DRM-Server 225 die Anfrage vom DRM-Gerät 235 zurück.
-
Bei
Schritt 525 wird eine zweite Anfrage an einen vertrauenswürdigen Schlüsselverwaltungs-Server,
wie z. B. die Bootstrapping-Serverfunktion (BSF) 205, gesendet.
Die zweite Anfrage umfasst wenigstens eine Hauptschlüsselkennung.
In einer Ausführungsform,
in welcher der vertrauenswürdige
Schlüsselverwaltungs-Server
eine BSF umfasst, umfasst die zweite Anfrage die Bootstrapping-Transaktionskennung
und eine Kennung für
die Netzwerkanwendungsfunktion. Bei Schritt 525 und in
der Ausführungsform,
in welcher der vertrauenswürdige Schlüsselverwaltungs-Server
eine BSF ist, kontaktiert der DRM-Server 225 (welcher als
eine Netzwerkanwendungsfunktion (NAF) fungiert) BSF 205,
um Ks_NAF abzufragen, indem B-TID und NAF_id als Eingabe präsentiert
werden.
-
Bei
Schritt 535 wird wenigstens ein Schlüssel vom vertrauenswürdigen Schlüsselverwaltungs-Server,
wie z. B. BSF 205, erhalten. In einer Ausführungsform
wird von BSF 205 der anwendungsspezifische Schlüssel, eine
private Kennung des Internetprotokoll-Multimediasubsystem (IP Multimedia
Private Identity, IMPI) und eine Benutzersicherheitseinstellung
(User Security Setting, USS) empfangen.
-
Bei
Schritt 545 wird basierend auf wenigstens der Gerätekennung
und der Zufallszahl RN ein abgeleiteter Schlüssel vom Schlüssel bestimmt,
welcher vom vertrauenswürdigen
Schlüsselverwaltungs-Server
empfangen wird. In einer Ausführungsform
wird der abgeleitete Schlüssel
vom anwendungsspezifischen Schlüssel
bestimmt, welcher auf der Gerätekennung
und der Zufallszahl RN basiert.
-
Bei
Schritt 555 wird ein Challenge/Response-Schema verwendet,
um zu bestimmen, ob der abgeleitete Schlüssel des DRM-Servers 225 mit dem
abgeleiteten Schlüssel
des DRM-Geräts übereinstimmt.
Der DRM-Server 225 prüft,
ob das DRM-Gerät 235 die
korrekte Ks_NAF_Dev weiß.
In einer Ausführungsform
verwendet der DRM-Server 225 ein
Challenge/Response-Schema bevor die Lizenz gewährt wird.
-
6 zeigt
ein Blockdiagramm 600 eines Knotens 205, 215, 225, 235, 305 innerhalb
eines DRM-Systems der vorliegenden Erfindung. Insbesondere kann
das System zur Bereitstellung einer sicheren Verknüpfung eines
DRM-Geräts,
wie z. B. das DRM-Gerät 235,
mit einer Benutzeridentität
eingesetzt werden. In einer Ausführungsform
wird der Knoten 205, 215, 225, 235 und 305 implementiert,
indem ein Allzweckcomputer oder jedes andere äquivalente Hardware-Gerät verwendet
wird.
-
Folglich
umfasst der Knoten 205, 215, 225, 235 und 305 einen
Prozessor (CPU) 610, einen Speicher 620, wie z.
B. einen Arbeitsspeicher (Random Access Memory, RAM) und/oder einen
Lesespeicher (Read Only Memory, ROM), ein sicheres Verbindungsmodul 640 und
unterschiedliche Input/Output-Geräte 630 (z. B. Speichergeräte welche
folgende Geräte
einschließen
können
ohne auf diese Geräte
beschränkt
zu sein: ein Bandlaufwerk, eine Diskette, ein Festplattenlaufwerk
oder ein CD-Laufwerk, einen Empfänger,
einen Sender, einen Lautsprecher, einen A/D- und D/A-Wandler).
-
Es
versteht sich, dass das sichere Verbindungsmodul 640 als
ein oder als mehrere physikalische Geräte implementiert werden kann,
welche durch einen Kommunikationskanal an die CPU 610 gekoppelt
sind. Alternativ kann das sichere Verbindungsmodul 640 durch
eine oder mehrere Softwareanwendungen repräsentiert werden (oder gar eine Kombination
aus Software und Hardware, wie z. B. durch Verwenden von anwendungsspezifischen
integrierten Schaltkreisen (Application Specific Integrated Circuit,
ASIC)), wobei die Software von einem Speichermedium geladen wird
(z. B. ein magnetisches oder optisches Laufwerk oder eine Diskette) und
im Speicher 620 des Computers durch die CPU ausgeführt wird.
Als solches kann das Datenpaket-Detektionsmodul 640 (umfassend
assoziierte Datenstrukturen) der vorliegenden Erfindung auf einem Computer-lesbaren
Medium, wie beispielsweise einem RAM-Speicher, einem magnetischen oder optischen
Laufwerk, einer Diskette oder ähnlichen
Vorrichtungen gespeichert werden.
-
Die
folgenden Vorteile der vorliegenden Erfindung sind offensichtlich:
- • Bereitstellen
einer dynamischen Bindung zwischen einem Benutzer und einem Gerät auf eine sichere
Weise.
- • Bereitstellen
einer einfachen Verwaltung des Geräteschlüssels Ks_NAF_Dev, wobei kein
zusätzlicher
Vertrauensschutz erforderlich ist.
- • Ermöglichen
eines einmaligen Anmeldens.
- • Vorsehen
des Schutzes von DRM-Protokollnachrichten durch den Schlüssel Ks_NAF_Dev.
-
Wie
von Leuten leicht erkannt werden kann, können die innovativen Konzepte,
welche in der vorliegenden Anmeldung beschrieben werden, über einen
weiten Bereich von Anwendungen modifiziert und variiert werden.
Dementsprechend sollte der Umfang des patentierten Gegenstandes
nicht auf eine der oben diskutierten spezifischen Ausführungsformen
beschränkt
werden, sondern ist stattdessen durch die folgenden Ansprüche definiert.
-
Es
wird ein DRM-Gerät
und ein Verfahren für das
Bereitstellen einer sicheren Verknüpfung mit einer Benutzeridentität offenbart.
Eine erste Anfrage wird an ein Teilnehmeridentitätsmodul gesendet. Eine Nachricht
vom Teilnehmeridentitätsmodul
wird über
einen sicheren authentifizierten Kanal empfangen. Die Nachricht
umfasst wenigstens eine Hauptschlüsselkennung, eine Zufallszahl
und einen abgeleiteten Schlüssel.
Als Antwort auf die Nachricht wird eine zweite Anfrage an einen
DRM-Server gesendet. Die
zweite Anfrage umfasst wenigstens eine Hauptschlüsselkennung, die Gerätekennung
und eine Zufallszahl. Offenbart wird auch ein DRM-Server und ein
Verfahren für
das Bereitstellen einer sicheren Verknüpfung mit einer Benut zeridentität. Eine
erste Anfrage wird von einem DRM-Gerät empfangen. Die erste Anfrage
umfasst wenigstens eine Hauptschlüsselkennung, eine Gerätekennung
und eine Zufallszahl. Das DRM Gerät wird authentifiziert. Eine
zweite Anfrage für
einen anwendungsspezifischen Schlüssel wird an einen vertrauenswürdigen Schlüsselverwaltungs-Server
gesendet. Die zweite Anfrage umfasst wenigstens eine Hauptschlüsselkennung.
Wenigstens ein Schlüssel
wird vom vertrauenswürdigen Schlüsselverwaltungs-Server
empfangen. Ein abgeleiteter Schlüssel
wird vom Schlüssel
bestimmt, welcher vom vertrauenswürdigen Schlüsselverwaltungs-Server empfangen
wurde, basierend auf wenigstens der Gerätekennung und der Zufallszahl.
Ein Challenge/Response-Schema wird verwendet, um zu bestimmen, ob
der abgeleitete Schlüssel
des DRM-Servers mit einem abgeleiteten Schlüssel des DRM-Geräts übereinstimmt.