-
TECHNISCHES
GEBIET
-
Die
vorliegende Erfindung bezieht sich auf ein Verfahren und ein Netzwerk
zum Zuführen
von Streaming-Daten von einem Streaming-Server zu einem Client und
auf Vorrichtungen und Server, welche zum Zuführen von Streaming-Daten verwendet
werden.
-
HINTERGRUND
-
Eine
digitale Kommunikationstechnologie bietet einfache Wege zum Verbreiten
und Kopieren von Daten an, es existieren jedoch wenige Mittel zum Schützen von
Copyright kontrollierten Medien gegen einen unautorisierten Zugriff
oder eine Weiterverbreitung.
-
Einige
Copyright-Besitzer haben ein großes ökonomisches Interesse zum Schutz
ihrer Rechte, und dies führte
zu einer ansteigenden Nachfrage nach einer digitalen Rechteverwaltung
(Digital Rights Management DRM). Im Allgemeinen erfordert der Schutz
von Copyright beschränkten
Daten, welche über
einen unsicheren Kanal übertragen
werden, kryptografische Mechanismen, wie beispielsweise eine Autorisierung
von legalen Benutzern, und eine Verschlüsselung der Daten. Die Verwaltung
der Rechte enthält
einen Aufbau von Vertrauensbeziehungen, eine Verwaltung von kryptographischen Schlüsseln und
einer Verbuchung, als auch eine Spezifikation der erlaubten Benutzung
der Medien, siehe hierzu beispielsweise die Internetseite http://www.cselt.it/mpeg/.
-
Eine
besondere Schwierigkeit tritt bei Drahtlosnetzwerken oder weiteren
Kommunikationssystemen auf, welche Störungen unterworfen sind. Aufgrund
der Ausstrahlungsnatur, ist ein Abhören potenziell sehr einfach,
welches nach einer Verschlüsselung
ruft. Jedoch können
in diesem Fall eine empfindliche Authentifizierungsinformation und/oder verschlüsselte Daten
während
der Übertragung
durch Fehler beschädigt
werden, welches die Kommunikation abbrechen oder stören kann.
Besonders empfindliche Daten enthalten Echtzeit- oder weitere Streaming-Medien, bei
denen es wenig oder gar keine Zeit gibt, beschädigte Daten zu reparieren oder
wiederzusenden. Darüber
hinaus, hat eine Verschlüsselung
einen Einfluss auf eine Bandbreiten-Ökonomie, und kann einen Thin-Client, wie beispielsweise
ein zellulares Telefon, rechnerisch überlasten.
-
Im
Falle einer streng beschränkten
Speicherkapazität
der Empfangsvorrichtung, beispielsweise ein zellulares Telefon oder
ein sogenannter "personal digital
assistant" (PDA),
ist es nicht möglich,
DRM Lösungen
einzubeziehen, welche eine große
Speicherkapazität
erfordern. Aus dem gleichen Grund ist es nicht geeignet oder sogar
unmöglich,
mehrere unterschiedliche DRM Lösungen
in einer Vorrichtung zu haben. Daher sollte eine DRM Lösung, soweit
wie möglich,
von einer bestimmten vorbestehenden Sicherheitsarchitektur gebrauch
machen. Andererseits, hat die beschränkte Umgebung in einer solchen
Vorrichtung ebenfalls Vorteile, welche in einer DRM Lösung ausgenutzt
werden sollten. Zunächst
neigen die begrenzten Speicherbeschränkungen dazu, eine Speicherung
der gesamten Streaming-Daten für
eine spätere
Extraktion zu verhindern. Zweitens ist es nicht besonders einfach,
die digitalen Inhalte von der Vorrichtung in jeglicher anderer Form
zu extrahieren, d.h., dass wir die Vorrichtung mit kleinen Mitteln
betrachten oder betrachten können,
welche in ein sogenanntes „fälschungssicheres
Modul" (engl. Tamper resistant
module) verwandelt werden können
oder dieses enthalten.
-
Die
meisten vorliegenden DRM Lösungen basieren
teilweise auf einer "Sicherheit
durch Obskurität", d.h., dass die
verwendeten Verfahren vor den Benutzern geheim gehalten werden.
Dies gestaltet es, vom Standpunkt des Benutzers aus, schwierig, ein
Vertrauen in die Lösung
aufzubauen. Zweitens, obwohl diese gestattete Obskurität Angriffe
schwieriger gestaltet, ist dies lediglich solange Wahrheitsgetreu,
wie die Obskurität
beibehalten wird. In der Vergangenheit hat es sich wiederholt gezeigt,
dass, wenn es jemand eventuell schafft, die Lösung zurück zu entwickeln, oder wenn
es eine "undichte
Stelle" gibt, die
Sicherheit des Systems unmittelbar gefährdet wird. Somit hat eine
Lösung,
welche soweit wie möglich
auf öffentlich
bekannte Algorithmen und Protokollen basiert, große Vorteile.
-
STAND DER
TECHNIK
-
Es
bestehen verschiedene Verfahren zum Inhaltsschutz und zur Rechteverwaltung,
jedoch ist es bei keinem möglich,
Streaming-Daten über ein
unsicheres Medium zu übertragen,
welches Störungen unterworfen
ist. Lösungen,
welche zu diesem Gegenstand eine gewisse Relevanz haben, werden
im folgenden aufgelistet und kurz kommentiert.
-
Im
folgenden werden allgemein verwendete Ausdrücke und Abkürzungen angegeben:
- – DRM
(Digital Rights Management): ein allgemeines Gerüst, welches eine oder mehrere
der folgenden Techniken umfasst.
- – Kryptografie,
siehe A. Menezes, P. van Oorschot, und S. Vanstone: "Handbook of Applied Cryptography", CRC Press, 1997
und die Internetseite http://www.cacr.math.uwaterloo.ca/hac/.
- – Wasserzeichenmarkierung:
ein Prozess, durch welchen ein Datenersteller digitale Markierungen auf
die aktuellen Daten aufbringt, so dass die zusammengefassten Daten
an den Datenersteller angebunden werden können, und so, dass die Markierung
gegenüber
einer Verfälschung
resistent ist. D.h., dass es schwierig sein sollte, die Markierungen
komplett zu entfernen, während eine
bestimmte "Qualität" der Daten beibehalten wird.
Eine Wasserzeichenmarkierung ist normalerweise eine Software-Technik.
- – Kopierschutz:
ein Prozess, bei welchem Daten derart gespeichert und verbreitet
werden, dass ein Kopieren mit einer beibehalten Qualität schwierig
gestaltet wird und/oder so, dass eine Kopie zurück zum Kopierer zurückverfolgt
werden kann. Ein vollständiger
Schutz erfordert für
gewöhnlich
eine Spezialzweck-Hardware.
Die folgenden Protokolle zum Transport
von Echtzeit-Medien werden in der Beschreibung im folgenden angegeben:
- – RTP
(Real Time Transport Protocol): IETF Proposed Standard for transport
of real-time and streaming data, siehe Schulzrinne, H., Casner,
S., Frederick, R., Jacobson, V., "RTP: A Transport Protocol for Real-Time
Applications", IETF
Request For Comments RFC 1889, und die Internetseite http://www.ietf.org/rfc/rfc1889.txt.
- – SRTP
(Secure RTP oder das Secure Real-Time Transport Protocol): IETF
Draft; ein Sicherheitsprotokoll für RTP, welches eine Verschlüsselung unter
Verwendung einer Fehlerrobustheit umfasst, eine relativ leichte
Stream-Chiffrierung,
welche für
die Verschlüsselung
keinen zusätzlichen Header
hinzufügt,
welches eine Übertragung
unter Verwendung von SRTP unter Verwendung eines geringeren Bandbreitenverbrauchs
und weniger anfällig
auf Störungen
gestaltet, und zwar verglichen beispielsweise mit IPsec, siehe die
Internetseite http://search.ietf.org/internet-drafts/draft-ietf-avt-srtp-00.txt.
- – RTSP
(Real Time Streaming Protocol): ein von IETF vorgeschlagener Standard
zum Steuern von digitalen Strömen,
und zwar größtenteils
auf die gleiche Weise wie eine "Fernsteuerung" für eine Audio/Video-Vorrichtung,
siehe die Internetseite http://www.ietf.org/rfc/rfc2326.txt.
- – ROHC
(RObust Header Compression): ein von IETF vorgeschlagener Standard
zur Komprimierung beispielsweise der UDP- und RTP-Header (wie März 5, 2001),
siehe die Internetseiten http://www.ietf.org/rfc/rfc3095.txt, http://www.ietf.org/rfc/rfc3096.txt
und http://search.ietf.org/internet-drafts/draft-ietf-rohc-rtp-09.txt. Die Komprimierung
nimmt mit der Größe des Pakets
ab, welches die Wahrscheinlichkeit von Bitfehlern reduziert, und
es zum Transport über
Rauschkanäle geeigneter
gestaltet. Da SRTP lediglich die RTP Nutzlast verschlüsselt, sind
ROHC und SRTP vollständig
kompatibel.
-
Standardisierte
Lösungen
-
Es
gibt mehrere Standardisierungs-Institutionen, welche DRM und Streaming-Medien
diskutieren, wobei die ausgereifteste Standard-Arbeit das Intellectual
Property Management and Protection (IPMP) in Moving Picture Experts
Group (MPEG) ist, siehe hierzu die Internetseite http://www.cselt.it/mpeg/standards/ipmp.
MPEG IPMP bietet ein Gerüst
für DRM
an, enthält
jedoch nicht die DRM selber, es lässt dies absichtlich für proprietäre Lösungen offen.
-
Die
Open Platform Initiative for Multimedia Access (OPIMA), siehe die
Internetseite http://drogo.cselt.it/leonardo/opima/, arbeitet an
der Standardisierung eines Gerüstes
zur Zugriffssteuerung, Inhaltsverwaltung und für Schutzwerkzeuge. Sie arbeitet
an einer herunterladbaren und/oder ersetzbaren Sicherheit bei Internet
und Pay-TV Anwendungen, spricht jedoch nicht die Drahtlosumgebung
an.
-
Die
IETF (oder genauer ihre Forschungsgruppe IRTF) baut derzeit eine
Studiengruppe für DRM
auf, siehe hierzu die Internetseite http://www.idrm.org.
-
Proprietäre Lösungen
-
Die
Microsoft Corporation hat ihren Windows Media Rights Manager 7,
siehe die Internetseite http://www.microsoft.com/windows/windowsmedia/en/wm7/drm.asp.
Diese Lösung
gibt dem Benutzer eine Möglichkeit,
an einer sogenannten Abrechnungsstelle eine Lizenz zu kaufen, welche
dann zum Abspielen eines speziellen Mediums verwendet werden kann,
welches auf einer CD, in einem Email- oder einem Streaming-Server
enthalten sein kann. Die Lizenzen werden an den Computer, nicht
an den Benutzer angebunden. Die Lösung ist auf den PC Markt ausgerichtet,
in welchem sowohl Speicher- als auch Verarbeitungsressourcen nicht
beschränkt
sind, so dass eine Spezialzweck-Software für das Playback heruntergeladen
und ausgeführt
werden kann.
-
Verance,
siehe die Internetseite http://www.verance.com/verance/technology.html beansprucht
eine spezielle drahtlose DRM zu haben, jedoch scheint es, dass das
System lediglich auf Wasserzeichenmarkierung basiert. Ihre Lösung scheint
keine Verschlüsselung
der Streaming-Medien einzubeziehen.
-
E-vue,
siehe die Internetseite http://www.e-vue.com, stellt MPEG-4 komplementäre Enkodierungs-
und Autorisierungs-Werkzeuge
her. Auf der Seite werden keine Details angegeben, jedoch sind ihre
Netzwerklösungen
unabhängig
vom Transportprotokoll, welches eine Einbeziehung von einer separaten
Verschlüsselung
auf einem höheren Pegel
erfordern würde.
-
Bei
der veröffentlichten
europäischen
Patentanmeldung EP-1041823
von Toshiba, ist ein System für
eine sichere MPEG-4 Verbreitung offenbart. Sie bietet keine reale
DRM Lösung
an, sie spezifiziert hauptsächlich,
wie MPEG-4 verschlüsselt
wird, und wie es in einem RTP Rahmen einzubeziehen ist. Nach der
Verschlüsselung
von MPEG-4 wird ein zusätzlicher
Verschlüsselungs-Header
der Nutzlast hinzugefügt.
Die Verschlüsselung
wird nicht auf einer Transportschicht vorgenommen, und erfordert
eine Spezialzweck-Software und/oder -Hardware.
-
In
der veröffentlichten
europäischen
Patentanmeldung EP-1062812
von Intertrust, ist eine allgemeine DRM Lösung offenbart, welche einen
sogenannten Sicherheitscontainer verwendet, welcher Streaming-Medien,
eine Steuerinformation und eine Vorrichtung zum Öffnen des Containers und Extrahieren
von kryptographischen Schlüsseln
enthalten kann. Es ist explizit keine Lösung zur Verwendung in einer
Umgebung angeboten, welche Störungen
unterworfen ist. Ebenfalls, da die Schlüssel im Container sind, müssen sie
extrahiert und verifiziert werden, bevor das Streaming fortgesetzt
werden kann, welches einen großen
Einfluss auf die Echtzeit-Anforderungen
haben würde.
-
In
der veröffentlichen
internationalen Patentanmeldung WO 2000/52583 von Audible Inc. ist
ein Gerüst
zur Autorisierung von einer Playback-Vorrichtung zum Abspielen von
Streaming-Daten
offenbart, jedoch ist keine Referenz zur Verschlüsselung oder Chiffrierung gegeben,
trotz der Tatsache, dass ein Transport über ein sicheres Medium nicht
angenommen wird.
-
Probleme
-
Es
existiert keine DRM Lösung,
die Echtzeit-Anforderungen in einer Umgebung erfüllt, welche Störungen ausgesetzt
ist. Die existierenden Lösungen
erfordern ebenfalls eine umfangreiche Speicherung in der Client-
und/oder Spezialzweck-Software und/oder -Hardware. Existierende
DRM Lösungen
sind im allgemeinen Proprietär
und verwenden keine Standardprotokolle, welches Implementierungen
von mehreren DRM Lösungen
in einem Client erfordert. Dies kann unmöglich sein, wenn die Speicherkapazität knapp
ist. Zusätzlich
gestaltet es die Nichtoffenbarung der verwendeten Algorithmen dies den
meisten Benutzern weniger glaubwürdig.
-
Ein
weiteres Problem in Zusammenhang mit existierenden Lösungen ist,
dass die digitalen Rechte für
eine spezielle Hardware oder einen kleinen Satz von Hardware-Vorrichtungen,
beispielsweise ein PC, ausgegeben werden, und die Möglichkeit,
die Medien einmal auf eine CD zu kopieren, was im Gegensatz zu einem
spezifischen Benutzer steht.
-
ÜBERSICHT
-
Es
ist eine Aufgabe der Erfindung, ein Verfahren und eine Vorrichtung
für ein
robustes und sicheres Herunterladen von Streaming-Daten, insbesondere
von Streaming-Daten, welche durch Copyright geschützt sind,
bereitzustellen.
-
Bei
dem hier offenbarten Verfahren werden existierende sichere Transportprotokolle
verwendet, wobei dies den Vorteil von einer einfachen Erweiterung
auf DRM gibt. Da ein kryptografischer Schutz des Dateninhaltes bereits
etabliert ist, ist es prinzipiell nicht notwendig, das Protokoll
durch geeignete AAA-förmige
(Authentication, Authorization and Accounting) Mechanismen zu erweitern.
-
Bei
dem Verfahren und Netzwerk können
die folgenden Bauteile verwendet werden:
- – Ein robustes,
leichtes und sicherheitsstandardisiertes Echtzeit-Transportprotokoll.
- – Ein
Schlüsselverbreitungs-Mechanismus.
- – Ein
Verrechnungsdienst.
- – Ein
fälschungssicheres
Modul.
-
Im
allgemeinen können
bei dem Verfahren und Netzwerk zum Zugreifen auf Streaming-Daten, beispielsweise
Daten, welche durch Copyright geschützt sind, die folgenden Ereignisse
stattfinden, jedoch nicht notwendigerweise in der im folgenden angegebenen
Reihenfolge:
- – Eine Anforderung oder Anordnung
von einem Client oder einer Client-Vorrichtung nach Streaming-Daten.
- – Eine
Authentifizierung des Client.
- – Eine
Verrechnung.
- – Eine Übertragung
der Streaming-Daten.
-
Die
Teile, welche beim Zugriff auf Streaming-Medien miteinander in Wechselwirkung
sind, enthalten im allgemeinen einen Client oder eine Client-Vorrichtung,
einen Order-Server (OS) und einen Streaming-Server (SS), wobei der
Client die Medien vom Order-Server anordnet, der Order-Server die Medien-Anordnung handhabt
und der Streaming-Server die Streaming-Medien an den Client zuführt.
-
Das
Verfahren und Netzwerk bieten eine einfache Weise zum Verteilen
von Material an, welches durch Copyright geschützt ist, welche auf Streaming-Zwecke,
Echtzeit angepasst ist, wobei eine mögliche interaktive Datenübertragung
ein spezieller Fall sein kann. Durch die Verwendung eines robusten Protokolls
bei dem Verfahren und Netzwerk, sind sie für Drahtlos-Clients und heterogene
Umgebungen besser geeignet als existierende Lösungen. Der Vorteil bei der
Verwendung eines standardisierten Protokolls, wie SRTP, WTLS, usw.,
ist, dass es in vielen Vorrichtungen, nicht nur zum Zwecke einer
digitalen Rechteverwaltung, implementiert werden kann, und daher
wiederverwendet werden kann, um eine Speicherkapazität wesentlich
einzusparen. Dies ist bei Client-Vorrichtungen ausschlaggebend,
welche geringe Kapazitäten
haben, wie beispielsweise zellulare Telefone und PDAs.
-
Das
vorgeschlagene Verfahren und Netzwerk, und die Bauteile davon, sogar
das fälschungssichere
Modul, welches in der Client-Vorrichtung enthalten sein kann, basieren
auf den offenen Standards und bekannten Algorithmen oder können darauf
basieren. Es ist oftmals schwierig, weitere DRM Lösungen zu
beurteilen, weil sie teilweise auf "Sicherheit durch Obskurität" basieren, d.h.,
dass sie von geheimen Prozeduren oder Implementierungen abhängen können. Da
geheime Algorithmen, welche ein gewünschtes Objekt schützen, dazu
tendieren, eventuell veröffentlicht
zu werden, beispielsweise der GSM Verschlüsselungsalgorithmus, die DVD
Verschlüsselungsalgorithmen,
usw., werden solche Lösungen
im allgemeinen im Bereich der Kryptografie als schwach angesehen:
Sie sind vor einer Implementierung zur öffentlichen Überprüfung nicht
offen. In diesem Fall, wie bei der gesamten heutigen öffentlichen
Kryptografie, wird die Stärke
der einmal bewerteten Prozedur auf den Schlüsseln und auf die Schlüsselverwaltung
beruhen.
-
Ein
weiterer Vorteil von einer offenen, größtenteils standardisierten
Lösung,
ist, dass jeder sie zum Schutze und zur Verbreitung seiner/ihrer
Daten verwenden kann. Beispielsweise kann eine relativ unbekannte "Garagen-Rockgruppe" oder ein unabhängiger Filmemacher
oder -schreiber, auf eine einfache, günstige Weise seine Arbeiten
auf eine sichere Weise an ein größeres Publikum
verbreiten. Man kann sich ein Web-Portal vergegenwärtigen,
welches Erzeuger von solchen Arbeiten unterhält.
-
Eine
weiterer Vorteil, wenn das Verfahren und Netzwerk, wie hier beschrieben,
für einen
Spezialzweck Thin-Client verwendet wird, ist, dass es für einen "Hacker" viel unmöglicher
ist, auf die Streaming-Daten zuzugreifen oder diese zu speichern,
als in dem Fall, bei welchem der Empfänger eine viel offenere und
leistungsstärkere
Vorrichtung ist, wie beispielsweise ein Personal Computer. Obwohl
es immer noch möglich
sein kann, ein analoges Ausgangssignal aufzuzeichnen, sind die hoch
qualitativen digitalen Signale innerhalb der Vorrichtung gut geschützt. Mit
anderen Worten, kann der Thin-Client bei vielen praktischen Zwecken
in sich selber, als eine fälschungssichere
Vorrichtung betrachtet werden. Im Gegensatz zur Eigenbau-Umgebung bei Personal-Computern,
bei welcher es potenziell sehr einfach ist, einen Hardware-Kopierschutz
zu umgehen, ist es viel einfacher, eine Sicherheit bei den in ihrer Herstellung
stärker
kontrollierten zellularen Telefonen und weiteren tragbaren Vorrichtungen
zu erlangen. Tatsächlich
können
Hersteller eine Sicherheits-Zertifizierung ihrer Produkte erlangen.
-
Wenn
dies mit einem zusätzlichen
DRM Modul und einer Wasserzeichenmarkierung gekoppelt wird, ist
der Copyrightschutz genauso gut wie bei jeglicher existierender
Lösung.
-
Wenn
der Order-Server durch einen Operator verwaltet wird, und der Client
eine Subskription mit diesem Operator hat, kann diese Vertrauensbeziehung
zu Authentifizierungs- und Abbuchungszwecken angewendet werden.
Wenn ferner angenommen wird, dass der Streaming-Server ein Inhalts-Provider
ist, wenn ein Operator und ein Inhalts-Provider miteinander kooperieren,
beispielsweise in der Form eines Musik-Download-Portals, hat der
Benutzer, welcher dem Operator vertraut, einen Grund dazu, sich
sicherer gegen einen Betrug von einem Piraten oder eine Manipulation
von Inhalts-Providern zu fühlen.
-
Das
Verfahren und Netzwerk sind in der Hinsicht sehr flexibel, als dass
sie für
den Client unterschiedliche Anonymitätspegel bereitstellen können, und
zwar in Abhängigkeit
von der tatsächlichen
Implementierung. Beispielsweise kann eine gänzlich anonyme Lösung mit
Bezug auf den Streaming-Server, den Order-Server und ebenfalls mit
möglichen
finanziellen Institutionen, welche einbezogen sind, erlangt werden,
indem anonyme digitale Bezahlungen zum Zugriff und zur Inhalts-Bezahlung verwendet
werden. Am anderen extremen Ende des Spektrums, kann eine sehr feste
Verbindung zum Benutzer erlangt werden, indem ein Identitäts-Modul
und mögliche Wasserzeichenmarkierungs-Techniken
verwendet werden. Vom Standpunkt eines Operators oder eines Inhalts-Providers
aus, kann dies sehr zugkräftig
sein, da dies ein besseres Mittel zum Nachverfolgen von einer unerlaubten
Kopie zum Benutzer, welcher die Kopie bereitstellt, gibt.
-
Da
der Streaming-Server die Medien unterhält und ebenfalls die letztendliche
Validierung der Anforderung vor einer Übertragung der Daten vornehmen
kann, hat der Streaming-Server eine maximale Kontrolle über die
Medien.
-
Die
den Order-Server einleitende Anforderung gibt ebenfalls einen zusätzlichen
Vorteil bei einem Multicast-Szenarium, beispielsweise beim Internet
TV, bei der Video-/Radioausstrahlung.
-
Zusätzliche
Aufgaben und Vorteile der Erfindung werden in der folgenden Beschreibung
dargelegt, und werden teilweise anhand der Beschreibung offensichtlich,
oder können
durch ein Anwenden der Erfindung erlernt werden. Die Aufgaben und
Vorteile der Erfindung können
mittels der Verfahren, Prozesse, Instrumentalisierungen und Kombinationen,
welche teilweise in den anliegenden Ansprüchen hervorgehoben sind, realisiert
und erlangt werden.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Obwohl
die neuen Merkmale der Erfindung insbesondere in den anliegenden
Ansprüchen
dargelegt sind, kann ein vollständiges
Verständnis
der Erfindung, was sowohl die Organisation als auch den Inhalt betrifft,
und des obigen und der weiteren Merkmale davon anhand der folgenden
detaillierten Beschreibung von nicht beschränkenden Ausführungsformen,
welche im folgenden mit Bezug auf die begleitenden Zeichnungen dargelegt
sind, erlangt werden, wobei die Erfindung anhand der Betrachtung
derer besser verstanden werden wird, wobei in den begleitenden Zeichnungen:
-
1 ein
allgemeines Blockdiagramm ist, welches ein elementares Netzwerk
darstellt, welches Teile enthält,
welche in einer Prozedur zum Zuführen von
Streaming-Medien von einem Streaming-Server an einen Client, welcher
die Medien von einem Order-Server anfordert, einbezogen sind,
-
2 ein
Blockdiagramm ist, welches die Funktionen von einem DRM Modul von
einem Client darstellt,
-
3 ein
Blockdiagramm ist, welches eine optionale Vertrauensverwaltung im
Netzwerk von 1 darstellt,
-
4 ein
Signalisierungsdiagramm ist, welches Schritte darstellt, welche
beim Zuführen
von Streaming-Daten ausgeführt
werden,
-
5 ein
schematisches Diagramm ist, welches die grundlegenden Teile von
einem digitalen Ticket zeigt,
-
6 ein
schematisches Blockdiagram von einem Client ist, welches einige
grundlegende Bauteile davon zeigt, wobei einige davon optional sein können, und
einige Alternativen sein können,
-
7 ein
schematisches Blockdiagramm von einem Order-Server ist, welches
einige grundlegende Bauteile davon zeigt, wobei einige davon optional
sein können
und einige Alternativen sein können,
und
-
8 ein
schematisches Blockdiagramm von einem Streaming-Server ist, welches einige grundlegende
Bauteile davon zeigt, wobei einige davon optional sein können und
einige Alternativen sein können.
-
GENAUE BESCHREIBUNG
-
In
einem System zum Anordnen und Empfangen von Streaming-Medien, wird die
Wechselwirkung von drei Knoten, nämlich ein Client 1,
ein Order-Server (OS) 3 und ein Streaming-Server (SS) 5, welche
ein elementares Netzwerk ausbilden, nun in Bezug auf 1 beschrieben.
-
Der
Client 1 kann eine Vorrichtung sein, welche eine beschränkte Verarbeitungs-
und Speicherkapazität
hat, beispielsweise ein zellulares Telefon, ein PDA, usw., welche
ein herkömmliches
manuelles Eingabemittel und ein Mittel zum Wiedergeben von Streaming-Daten
auf einem Display und/oder durch einen Lautsprecher hat, siehe hierzu
ebenfalls das Blockdiagramm von 6. Der Client
kann optional eingebaute Spezialzweck-DRM fälschungssichere Soft- oder
Hardware-Module haben. Diese Module können mit einem Inhalts-Provider,
einer Finanzinstitution oder einem Netzwerk-Operator in Zusammenhang
stehen. Der Client kann optional ebenfalls ein Identitäts-Modul (IM) enthalten
oder damit verbunden sein, welches eine fälschungssichere Vorrichtung
ist, welche Daten des Benutzers oder eine Subskription enthält, beispielsweise
eine SIM Card, eine Smart Card, usw. Das IM kann durch einen Inhalts-Provider, einen Netzwerk-Operator
oder durch eine dritte Partei, wie beispielsweise eine Bank, ausgegeben
werden.
-
Der
Order-Server OS 3 behandelt die Anfragen vom Client und
verwaltet grundlegend die Verrechnung in Bezug auf die angeforderten
Medien, siehe hierzu ebenfalls das Blockdiagramm von 7.
Der Streaming-Server 5, siehe hierzu ebenfalls das Blockdiagramm
von 8, beinhaltet und verwaltet die Streaming-Daten
gemäss
den Bedingungen, welche durch den Order-Server und durch den Client
gesetzt sind.
-
In
einer praktischen Situation können
der Order-Server 3 und der Streaming-Server SS 5 miteinander
integriert sein, oder es können
die Aufgaben, welche hier beschrieben sind, welche in jeglichen
aus dem Order-Server und dem Streaming-Server durchgeführt werden,
an zwei oder mehrere Server zugewiesen werden.
-
Die
Prozedur zum Erlangen/Zuführen
von Streaming-Medien beginnt beim Client 1, welcher eine
Anfrage nach einem bestimmten Objekt von Steaming-Medien an den
Order-Server 3 darlegt. Diese Anfrage kann ebenfalls eine
zusätzliche
Information zu Verrechnungszwecken, wie beispielsweise eine Bezahlung,
eine Kreditkartennummer oder eine weitere monetäre Information, und eine gewünschte Verwendung
der Streaming-Daten,
wie beispielsweise Dauer, Format der Medien, usw., enthalten. Als Antwort
auf die Client-Anfrage, kann der Order-Server 3 Aufgaben durchführen, wie
beispielsweise eine Authentifizierung des Clients, eine Verrechnung
und eine Vorbereitung der Übertragung
des angeforderten Medienobjekts. Die Vorbereitung kann eine QoS (Quality
of Service) Zuweisung enthalten, welche wiederum mit dem Geldbetrag
in Zusammenhang steht, den der Benutzer bereit ist für den Dienst
zu zahlen. Die Verrechnung kann beispielsweise eine vorbestehende
Operator-Teilnehmer Beziehung zwischen dem Client 1 und
dem Order-Server 3, eine Kreditkartennummer, welche durch
den Client oder eine anonyme Partei bereitgestellt ist, beispielsweise ein
elektronisches Bezahlsystem, verwenden. Alternativ kann eine bestimmte
Art eines Vorbezahlungs-Mechanismus
verwendet werden. Wenn die Anfrage bewilligt wird, kann der Streaming-Server 5 das
Medienobjekt über
ein standardisiertes, robustes und sicheres Protokoll, wie beispielsweise
SRTP, WTLS, usw., oder über
weitere Protokolle, welche zu diesem Zwecke angepasst sind, an den
Client aussenden. Wenn die somit vorgenommene Medienbenutzungs-Übereinstimmung erlaubt ist,
kann die Ausstrahlung durch den Benutzer über ein Protokoll, wie beispielsweise
das RTSP, kontrolliert werden. Ein Beispiel hierzu, kann ein Benutzer
in einer Sportarena sein, welcher Slow-Motion-Wiederholungen von einem
Eishockeyspiel-Event von mehreren unterschiedlichen Winkeln aus
sehen möchte.
Eine solche Steuerungs-Signalisierung
bedarf eine derartige Authentifizierung, dass lediglich der beabsichtigte
Empfänger
der Ausstrahlung dies steuern kann.
-
Die
Verwendung eines standardisierten Protokolls erlaubt es, dass bereits
bestehende Implementierungen wieder verwendet werden, welches in einem
Client 1 notwendig ist, welcher leistungsarm (thin) ist,
d.h., beschränkte
Speicherressourcen hat.
-
Ein
robuster Transport erlaubt eine relativ hohe Bitfehlerrate, ohne
dass eine Leistung der Streaming-Daten ernsthaft beeinflusst wird.
-
Die
Streaming-Daten werden verschlüsselt, um
es zu ermöglichen,
dass der Inhalt der Daten gegen jegliche unautorisierte Einheit
geschützt
wird, welche darauf einen Zugriff unternimmt.
-
Ein
High-Level Protokoll für
eine digitale Rechteverwaltung wird nun detaillierter mit einem
Fokus auf eine Autorisierung, eine Schlüsselverwaltung und eine Verrechnung
beschrieben. Wie oben erwähnt,
kann die Implementierung eine Verwendung von einer Spezialzweck
Soft- oder Hardware, wenn diese vorliegt, machen. Somit wird nun
mit Bezug auf 4 ein High-Level Protokoll zur
digitalen Rechteverwaltung beschrieben. Die unterschiedlichen Schritte,
welche im Protokoll durchgeführt
werden, werden durch Pfeile, welche den Client 1 und den
Order-Server 3 miteinander verbinden, und durch Pfeile,
welche den Client und den Streaming-Server 5 miteinander
verbinden, gekennzeichnet.
-
Schritt Nr. 1, Pfeil 11:
Vororder
-
Bevor
der Client 1 tatsächlich
ein gewisses Medienobjekt anordert, können bestimmte Aktionen bei
der Kommunikation zwischen dem Client und dem Order-Server 3 vorgenommen
werden, wie beispielsweise das Herausfinden von einer Information über einen
Medientyp, eine Qualität,
einen Preis, eine Voransicht, usw. Ein Teil dieser Information kann möglicherweise
ebenfalls vom Streaming-Server 5 erlangt werden, wie beispielsweise
Listen von verfügbaren
Medienobjekten, eine Information darüber, ob sie durch den Order-Server 3 erlangt
werden können, Datentypen,
Voransicht-Dateien.
-
Schritt Nr. 2, Pfeil 12:
Order
-
Der
Client 1 ist bei einer Kommunikation mit dem Order-Server 3 einbezogen,
welches zu einer formalen Order oder Orderanfrage eines bestimmten spezifischen
Medienobjektes führt,
welches vom Client zum Order-Server, beispielsweise über WAP, HTTP
oder I-Mode, gesendet wird, wobei bestimmte Rechte mit der Order
in Zusammenhang stehen. Der Empfang der Order-Anfrage leitet eine
Sequenz von Aktionen ein, welche einen Austausch von einer Sicherheitsinformation,
beispielsweise eine Authentifizierung des Client, enthalten können, welche
beim Order-Prozess und/oder beim Verrechnungs-Prozess und/oder beim Ticketerzeugungs-Prozess
zu verwenden ist, wie später
beschrieben.
-
Schritt Nr. 3, Pfeil 13:
Freigabe/Verrechnung
-
Die
Anfrage von Schritt Nr. 2 leitet ebenfalls eine Freigabe- oder Verrechnungsaktion
ein, wobei im normalen Fall das Medienobjekt, und tatsächlich die
Inhalte davon, verrechnet wird. Der Client 1 spezifiziert,
wie die Order zu bezahlen ist, und zwar durch die Order-Meldung
oder durch ein bestimmtes, vorexistierendes Übereinkommen, und bewilligt
dem Order-Server 3 das Recht dazu, zu verrechnen. Der Order-Server
kann optional mit einem Freigabe-Haus/-Broker in Kontakt sein, um
die Verrechnungsanfrage zu handhaben, beispielsweise um zu überprüfen, ob
ein ausreichender Geldbetrag auf dem Benutzerkonto ist, usw.
-
Schritt Nr. 4, Pfeil 14:
Ticketzuführung
-
Der
Order-Server 3 erzeugt dann ein digital signiertes Ticket
oder digital signierte Tickets, welche er zurück zum Client 1 sendet.
Ein solches Ticket ist ein Beleg über die Order und enthält eine
Information über
das Übereinkommen,
welche für
den Client notwendig ist, um das angefragte Medienobjekt vom Streaming-Server 5 zu
erlangen und um die Inhalte daraus zu erlangen. Dies kann eine Information über den
Streaming-Server und über
angefragte Medien, eine kryptografische Information, wie beispielsweise ein
Schlüssel,
und weitere Parameter für
die Streaming-Daten und Benutzungsrechte oder Bedingungen, d.h.,
eine Autorisierungs-Information über
die angefragten Medien, beispielsweise die Anzahl von erlaubten
Zugriffen, eine Anfangs- und Ablaufzeit, sein. Beim Empfang des
Tickets kann der Client 1 überprüfen ob die Inhalte des Tickets
mit der zuvor gestellten Order übereinstimmen.
-
Schritt Nr. 5: Ticketweiterleitung
-
Um
die Zuführung
der Medien einzuleiten, wird das gesamte Ticket oder vorzugsweise
ein spezieller Teil des Tickets vom Client 1 zum Streaming-Server 5 gesendet.
Anstelle dessen, kann eine bestimmte wesentliche Information, welche
vom empfangenen Ticket hergeleitet wird, zum Streaming-Server gesendet
werden. Optional kann der Client eine Information über den
Aspekt des bewilligten Rechtes auf die Medien, welche angefragt
sind, dem Medien-Sitzung Aufbauschritt hinzufügen, wie später beschrieben. Zusätzliche
Daten können
ebenfalls hinzugefügt
werden, um diese Information dem Client kryptografisch anzubinden,
und zwar über
die kryptografische Information, welche in das Ticket durch den
Order-Server 3 gesetzt wird. Der Streaming-Server verifiziert
die Gültigkeit
des Tickets, beispielsweise ob es später immer noch gültig ist,
ob es durch einen legitimen Order-Server ausgegeben wurde, ob die
Rechte, welche durch den Client angefragt sind, mit den im Ticket
geschriebenen Rechten übereinstimmen,
usw.
-
Schritt Nr. 6: Sicherheits-Aufbau
-
Die
kryptografische Information, welche im Ticket übermittelt wird, kann entweder
direkt verwendet werden, oder um eine erweiterte Authentifizierung
zu erlangen und/oder um eine zusätzliche
kryptografische Information zu erlangen, wie beispielsweise Sitzungs-
(SRTP) Schlüssel,
separate Verschlüsselungs-
und Integritätsschutz-Schlüssel, usw. Solche
Schlüssel
können
beispielsweise unter Verwendung eines Schlüsselverwaltungs-Protokolls
erlangt werden.
-
Schritt Nr. 7: Medien-Sitzung
Aufbau.
-
Wenn
das Ticket gültig
ist, wird eine Vorbereitung der aktuellen Ausstrahlung von Medien
vorgenommen. Somit können, um
die Medien wiederzugeben, bestimmte Konfigurations- und Manipulations-Prozeduren
notwendig sein, wie beispielsweise ein Konfigurieren von Codecs,
eine Übertragung
von Ursprungs- und
Ziel-Netzwerkadressen und -Anschlüssen, eine schnelle Weiterleitung
an gewünschte
Orte, usw. Dies kann durch ein Steuerprotokoll, wie beispielsweise
das RTSP, gehandhabt werden.
-
Schritt Nr. 8: Streaming/Verrechnung
-
Nachdem
alle Vorbereitungen vorgenommen wurden, beginnt der Streaming-Server 5 mit
der Ausstrahlung der Medien an den Client 1, und zwar gemäss dessen
was geordert wurde. Der Client empfängt die Daten und entschlüsselt diese,
und zwar typischerweise "on
the fly" in Echtzeit,
unter Verwendung des zuvor erlangten Schlüssels. Optional, wenn das Übereinkommen
dies erlaubt, kann der Client 1 mit dem Streaming-Server
wechselwirken, und zwar beispielsweise unter Verwendung von RTSP,
um den Medienfluss gemäss
dessen, was gewünscht
ist, zu steuern. Eine zusätzliche
Verrechnung kann dazu verwendet werden, um beispielsweise eine Volumen- oder
zeitbasierte Preisbildung der Medien zu erlauben. Dieser Verrechnungstyp
bedarf keinerlei zusätzliche
Bezahlung vom Client 1, markiert jedoch einen Verbrauch
des Tickets, indem dessen Rechte aufgebraucht werden. Beispielsweise,
im Falle einer zeitbasierenden Verrechnung, kann das Ticket eine
bestimmte Zeitlänge
enthalten, welche über
einen bestimmten Mediensatz verbreitet wird. Der Streaming-Server 5 kann
die verwendete Zeit aufzeichnen und Belege an den Client senden. Ähnlich kann
der Streaming-Server bei einer volumenbasierten Bezahlung die Datengröße aufzeichnen,
welche ausgestrahlt wird, und zwar anstelle der Zeit.
-
Optional,
wenn das Ticket abgelaufen ist, kann der Client abermals den Order-Server 3 kontaktieren,
und zwar im Falle, bei welchem er ein Fortsetzen der Ausstrahlung
wünscht.
Diese Neuverhandlung kann eine zuvor ausgetauschte Information verwendet,
und kann daher eine schnellere und einfachere Transaktion sein,
um eine Unterbrechung des Datenflusses zu reduzieren. Das Protokoll
fährt dann von
Schritt Nr. 5 aus fort.
-
Beispiele
eines Ticketinhaltes
-
Die
digitalen Tickets können
eine verschiedenartige Information, welche von den Beziehungen zwischen
dem Order-Server 3,
dem Streaming-Server 5 und dem Client 1 abhängen kann,
die Existenz einer Öffentlicher-Schlüssel Infrastruktur
(PKI) und eine Hardware-Identität
des Medien-Spielers, d.h. des Clients, enthalten. Die Tickets können eine
Information über
die angefragten Medien, die erlaubten Benutzungsbedingungen enthalten,
und sie können ebenfalls
als Belege oder Quittungen für
die in Zusammenhang stehende ökonomische
Transaktion wirken.
- 1. Wenn der Order-Server 3 und
der Client 1 eine Operator-/Teilnehmer-Beziehung haben, kann ein Ticket
den Sitzungs-Schlüssel, beispielsweise den
SRTP Schlüssel,
enthalten, welcher mit bestimmten geheimen Daten verschlüsselt ist,
welche die Beziehung manifestieren, wie beispielsweise ein kryptografischer
Schlüssel,
welcher dem Order-Server bekannt ist, und welcher in einem Identitäts-Modul
im Client enthalten sein kann. Ein weiteres Ticket kann den Sitzungs-Schlüssel enthalten,
welcher mit einem öffentlichen
Schlüssel
verschlüsselt
ist, welcher zum Streaming-Server 5 gehört. Das vorherige Ticket kann
als ein Beleg für
den Client wirken, wobei das letztere Ticket als ein Token wirken
kann, welcher bei der letzen Anfrage nach den Medien den Streaming-Server
zu zeigen oder an diesen zu passieren ist.
- 2. Wenn der Client 1 einen bekannten öffentlichen Schlüssel hat,
kann der Order-Server 3 die Erzeugung des Sitzungs-Schlüssels dem
Streaming-Server 5 überlassen,
und die Tickets brauchen diese Information nicht zu tragen.
-
In
beiden Fällen,
können
Tickets optional die Identität
der abspielenden Vorrichtung, d.h., des Clients, enthalten, wie
beispielsweise eine IP Adresse, eine Hardware-Einheit, usw. Tickets
können
einen Zeitstempel, einen Zählwert
oder etwas anderes, beispielsweise um die Neuheit eines Tickets
anzuzeigen oder um eine nicht autorisierte Neuspielung zu verhindern,
enthalten. Ein vom Order-Server 3 gesendetes Ticket, welches
auf den Streaming-Server 5 gerichtet ist, kann eine Client-Kennung
enthalten, mit welcher der Streaming-Server den Medien beispielsweise ein
Wasserzeichen versetzen kann. Sie kann dem Client eine Anonymität bereitstellen,
mit Ausnahme des Falles einer Copyright-Verletzung, wobei der Order-Server
in diesem Fall die mit dieser Kennung verbundene Identität enthüllen kann.
-
Ebenfalls
können
die Tickets optional digital durch den Order-Server signiert werden, beispielsweise
mit einem öffentlichen
Schlüssel,
welcher zum Order-Server gehört,
und zwar zum Integritäts-Schutz,
beispielsweise um gegen eine Manipulation zu schützen.
-
Ein
Ticket kann beispielsweise die folgenden Felder, wie in 5 gezeigt,
enthalten:
- – Ein Feld 21 für allgemeine
Parameter. Diese Parameter können
eine Information enthalten, welche sowohl der Client 1 als
auch der Streaming-Server 5 zu empfangen haben, beispielsweise
Kennungen, eine Information über
Rechte, eine Authentifizierung und Verschlüsselungs-Algorithmen.
- – Ein
Feld 22 für
spezifische Parameter des Streaming-Servers. Auf die Inhalte des
Feldes kann durch den Client nicht zugegriffen werden, und sie können eine
Information enthalten, welche für
den Streaming-Server 5 notwendig ist, um eine kryptografische
Beziehung mit dem Client 1 aufzubauen. Ein Beauftragter-Teil
(engl. mandatory part) ist ein kryptografischer Schlüssel, welcher
durch den Order-Server 3 verschlüsselt ist, welcher durch den
Streaming-Server entschlüsselt
werden kann. Dies kann unter Verwendung des öffentlichen Schlüssels des
Streaming-Servers oder eines Schlüssels, welcher zuvor zwischen
dem Streaming-Server und dem Order-Server ausgetauscht ist, vorgenommen
werden. Der gleiche Beauftragten-Schlüssel ist ebenfalls in den Client-Parametern enthalten,
wie im folgenden zu erkennen. Eine spezielle Ausführungsform
des Beauftragten-Schlüssels
ist der SRTP Schlüssel oder
ein Schlüssel,
welcher dazu verwendet werden kann, um den SRTP Schlüssel zu
erlangen.
- – Ein
Feld 23 für
spezifische Parameter des Client. Dieses Feld kann eine Information
enthalten, welche für
den Client 1 notwendig ist, um eine kryptografische Beziehung
mit dem Streaming-Server 5 aufzubauen. Wie oben, ist ein
Beauftragter-Teil
ein kryptografischer Schlüssel,
welcher durch den Order-Server 3 verschlüsselt ist und
welcher durch den Client entschlüsselt
werden kann. Dies kann unter Verwendung des öffentlichen Schlüssels des
Client oder eines Schlüssels,
welcher zuvor zwischen dem Client und dem Order-Server ausgetauscht
ist, vorgenommen werden.
- – Ein
Feld 24 zur Authentifizierungs-Information. Dieses Feld
enthält
eine Information für
den Streaming-Server 5 und für den Client 1 um
die Gültigkeit
des Tickets zu verifizieren. Entweder enthält das Feld eine Signatur,
welche mit dem öffentlichen
Schlüssel
des Order-Servers erstellt ist, welche sowohl der Streaming-Server 5 als
auch der Client verifizieren können,
oder es enthält
zwei Teile, wobei ein Teil davon durch den Streaming-Server verifiziert
werden kann und ein weiterer Teil davon durch den Client verifiziert
werden kann.
-
Letztgenanntes
kann unter Verwendung eines Meldungs-Authentifizierungs-Kodes unter Verwendung
von Schlüsseln
erreicht werden, welche jeweils zuvor durch den Order-Server und
den Streaming-Server und durch den Order-Server und den Client ausgetauscht
worden sind.
-
Es
kann beobachtet werden, dass es unter Verwendung der oben beschriebenen
Prozeduren sehr einfach ist, Zugriffsrechte für die Medien an den Benutzer,
d.h. eine Einheit, anzubinden, anstelle an die Hardware, bei welcher
das Herunterladen vorgenommen wird. Dies kann beispielsweise unter
Verwendung eines Identitäts-Moduls,
wie beispielsweise eine SIM Karte in einem mobilen Endgerät, welches bei
den Transaktionen eingebunden ist, erreicht werden. Alternativ kann
eine Kreditkartennummer zu diesem Zwecke dienen. Indem anonyme,
elektronische Bezahlungen vorgenommen werden, wird der Zugriff an
den Benutzer angebunden, ohne dass dessen Identität enthüllt wird.
-
Um
ferner eine Sicherheit gegen ein unerlaubtes Kopieren oder ein Wiederspielen
zu verbessern, kann die kontrollierte Umgebung in einem mobilen
Endgerät
einfach durch ein optionales Hardware Sicherheits-Modul erweitert
werden. Ein solches Modul kann eine Übertragung der Daten an eine externe
digitale Vorrichtung verhindern oder steuern, und/oder ein Wasserzeichen
zum Signal basierend auf der Benutzeridentität setzen, so dass der Benutzer
verfolgt werden kann. Ein Beispiel eines solchen Moduls wird nun
beschrieben.
-
Das DRM Modul
-
Ein
DRM Modul, wie beispielsweise eine Spezialzweck fälschungssichere
integrierte Schaltung oder eine physikalisch geschützte Vorrichtung, kann
optional im Client 1 enthalten sein, um es noch schwieriger
zu gestalten, einen unrechtmäßigen Zugriff
auf die Medien vorzunehmen. Im Blockdiagramm von 2 sind
die Funktionen eines solchen Moduls 41 für eine SRTP
basierte Lösung
dargestellt.
-
Das
Modul muss zumindest (1) bestimmte Geheimdaten K1 enthalten, welche
in einem sicheren Speicher 43 gespeichert sind, wie beispielsweise ein
kryptografischer Schlüssel,
welcher eine Ressource sein kann, welche für das IM allgemein gültig ist
oder darin gespeichert ist. Diese Daten können dazu verwendet werden,
die Nutzrechte an eine Teilnehmer-Identität oder an eine Vorrichtung
anzubinden. Es kann ebenfalls (2) eine Vorrichtung F1, 45 enthalten,
um einen Entschlüsselungs-Algorithmus oder
eine kryptografische Einwege-Funktion durchzuführen, welche stattfindet, sobald
die geheimen Daten K1 eingegeben werden, welche vom sicheren Speicher 43 auf
einer Leitung 44 zugeführt
werden, welche eine Schnittstelle A, 46 und den verschlüsselten
SRTP Schlüssel
enthält,
sobald er auf einer Eingangsleitung 47 des Moduls 41 bereitgestellt
ist, und als Ausgabe den entschlüsselten
SRTP Schlüssel auf
einer Leitung 49 erzeugt. Als eine dritte Version (3),
kann das Modul 41 ebenfalls die gesamte SRTP Entschlüsselungs-Funktionalität enthalten,
wie durch den Block 51 dargestellt, welchem der entschlüsselte SRTP
Schlüssel
auf einer Leitung 49 bereitgestellt wird. Der SRTP Entschlüsselungs-Block 51 empfängt die
Daten des verschlüsselten
Medien-Stroms auf einer Leitung 52, welche dem Modul eingegeben
wird, und führt
einen entschlüsselten
Strom an Daten auf einer Leitung 52, welche vom Modul 41 ausgegeben wird.
Auf diese Weise wird der SRTP Schlüssel, welcher in Klartext über eine
Schnittstelle B bei 53 auf der Leitung 49 passiert,
vollständig
innerhalb des Moduls 41 geschützt. In diesem Fall, kann es
vorteilhaft sein, eine Schnittstelle C, 55 an einer Eingangsleitung 57 zum
Modul zuzulassen, um einen Schlüssel in
die Schnittstelle B 53 einzusetzen, so dass diese SRTP
Implementierung für
weitere Zwecke neu verwendet werden kann. Die Funktion F1 im Block 45 wird
in einem solchen Fall eine nicht autorisierte Verwendung verhindern,
wenn es jemand versucht, die DRM Funktionalität zu übersteuern.
-
Beispielsweise
kann die Verwendung des DRM Moduls 41 wie folgt sein. Zunächst wird
das digitale Ticket durch den Client 1 empfangen und die Streaming-Sitzung
wird aufgebaut, Schritte Nr. 5-7.
- – Der verschlüsselte SRTP
Schlüssel
wird dem DRM Modul 41 auf der Eingangsleitung 47 bereitgestellt.
Der Schlüssel
wird durch den Funktionsblock F1 45 empfangen, welcher
ihn und die geheime Information K1, welche im sicheren Speicher 43 gespeichert
ist, verwendet, um den Reiner-Text SRTP Schlüssel zu erzeugen, welcher der
Leitung 49 bereitgestellt wird und auf der B Schnittstelle 53 erscheint
und durch den SRTP Entschlüsselungsblock 51 zugegriffen
wird.
- – Der
eingehende verschlüsselte
SRTP Strom kann nun dem DRM Modul 41 auf der Eingangsleitung 52 bereitgestellt
werden, wird durch den Block 51 entschlüsselt, und die Reiner-Text
RTP Pakete werden von dem Entschlüsselungsblock auf die Ausgangsleitung 52' zugeführt.
- – Es
ist nun möglich,
die Schlüssel
zu extrahieren, welche auf der B Schnittstelle 53 außerhalb
des DRM Moduls 41 zur Verfügung stehen. Jedoch ist es
möglich,
Reiner-Text SRTP Schlüssel
auf der C Schnittstelle 55 in die Eingangsleitung 57 einzugeben,
und daher das DRM Modul ebenfalls zur Entschlüsselung von SRTP Strömen zu verwenden,
wenn der Reiner-Text SRTP Schlüssel
bekannt ist. Es kann beobachtet werden, dass eine Entschlüsselung
und Verschlüsselung
gemäss dem
SRTP auf die gleiche Weise durchgeführt werden können, und
dass das DRM Modul 41 somit zur Verschlüsselung als auch zur Entschlüsselung
in dem Fall verwendet werden kann, bei welchem der Reiner-Text SRTP
Schlüssel
bekannt ist.
-
Obwohl
wenig wahrscheinlich, kann im extremsten Fall, welcher nicht gezeigt
ist, der Client eine Drahtlos-Vorrichtung mit einer Antenneneingabe und
beispielsweise einer analogen Audio-Ausgabe sein, wobei alles, welches dazwischen
verbunden ist, auf eine fälschungssichere
Weise implementiert ist.
-
Vertrauens-Verwaltung
-
Um
eine Vertrauens-Verwaltung in dem Fall, bei welchem es keine vorbestehende
Beziehung und/oder Authentifizierung zwischen den Kommunikationsparteien
gibt, bereitzustellen, kann der folgende optionale "Zertifikat" Aufbau verwendet
werden, wie durch das Blockdiagramm von 3 dargestellt. Mit
Zertifikat sind gewisse Daten gemeint, welche die Identität und/oder
Rechte einer bestimmten Partei oder einer Umgebung bestätigen.
-
Der
Order-Server 3 kann eine Sicherstellung wünschen,
dass der Streaming-Server 5 die Rechte auf die Streaming-Medien
hat, für
welche der Order-Server verrechnet, und dies kann demonstriert werden,
indem ein Zertifikat 61 verwendet wird, welches durch einen
Rechtebesitzer ausgegeben wird. Der Besitz dieses Zertifikats kann
dem Order-Server zu einer geeigneten Zeit, beziehungsweise Zeiten, demonstriert
werden. Dieses Zertifikat kann ebenfalls dynamisch während des
Order-Prozesses
erlangt werden.
-
Der
Streaming-Server 5 kann es andererseits wünschen,
zu wissen, ob der Client 1 ein rechtmäßiges Equipment hat, um die
Medien ohne eine Verletzung der gegebenen Rechte zu handhaben, und
ebenfalls, dass das Equipment keine Fehlfunktion hat und/oder gestohlen
ist oder andererseits illegal erlangt ist. Zu diesem Zwecke, kann
das Equipment des Clients optional ein Zertifikat 63 oder
ein Token enthalten, welches durch den Hersteller des Equipments
ausgegeben wird, um beispielsweise zu prüfen, dass es ein originales
Equipment ist, dass es das relevante DRM Modul 41 enthält, usw.
Wenn der Order-Server 3 durch einen Operator verwaltet
wird, kann der Order-Server überprüfen, ob
das Equipment in einer Datenbank registriert ist, welche ein gestohlenes,
nicht autorisiertes oder defektes Equipment verfolgt, wie beispielsweise
das GSM Netzwerk Equipment Identitäts-Register (EIR) 65,
siehe hierzu "GSM
System Survey",
Ericsson Student Text, EN/LZT 123 3321 R3A.
-
Der
Streaming-Server 5 kann es ebenfalls wünschen, sich gegen eine "falscher Order-Server" Attacke zu schützen, bei
welcher ein Client 1 beansprucht, für ein bestimmtes Medienobjekt
bezahlt zu haben, ohne dies getan zu haben. Dies kann durch die
oben beschriebenen Mechanismen gelöst werden, wenn ein aufgebautes Übereinkommen
zwischen dem Order-Server 3 und dem Streaming-Server vorliegt,
siehe Pfeil 67 von 3. Ein solches Übereinkommen
kann beispielsweise durch die Verwendung eines Freigabe-Haus Zertifikats
erzeugt werden, siehe Element 69, welches durch eine Partei ausgegeben
wird, welcher der Streaming-Server vertraut, und welches anzeigt,
dass der Order-Server eine vertrauenswürdige Partei sein sollte. Dieses Zertifikat
kann ebenfalls dynamisch während
des Order-Prozesses
erlangt werden.
-
Es
wird nun ein Beispiel beschrieben, bei welchem ein bevorzugtes Verfahren
ausgeführt
wird.
-
Der
Client 1 findet durch ein Surfen durch das World Wide Web
von einem Drahtlos-Endgerät, ein
Angebot, einen Rock Videoclip zur beschränkten Verwendung, beispielsweise
eine Zeitperiode von 30 Minuten, zu kaufen/sehen. Der Client entscheidet ebenfalls,
für Hifi-Qualität Audio
ein wenig extra zu zahlen. Der Client spezifiziert die gewünschten
Medien und die Verwendung und stimmt mit dem Preis überein.
Der Order-Server 3 empfängt
diese Information und verrechnet basierend auf einem zuvor vertraglich
abgeschlossenen Übereinkommen
mit dem Client, wie beispielsweise eine Telefon- oder Internet-Subskription. Der
Order-Server überprüft ebenfalls
den Status mit dem Streaming-Server 5, um zu sehen, ob
die angefragten Medien gemäss
den spezifizierten Bedingungen zugeführt werden können, oder
ob der Streaming-Server hierfür
eine Kapazität reserviert.
Der Order-Server erzeugt ein Ticket und sendet es, und zwar verschlüsselt und
signiert/authentifiziert, an den Client mit den folgenden Inhalten: Eine
Referenz zu den angefragten Daten, beispielsweise ein Dateiname,
ein Sitzungs-Verschlüsselungs-Schlüssel für den SRTP
Strom, ein Neuheits-Token
um gegen ein wiederholtes Abspielen zu schützen, eine Information über die
Gültigkeitsperiode,
d.h. 30 Minuten, QoS Daten und die Identität und Adresse des Client und
des Streaming-Servers. Aus dem Ticket extrahiert der Client 1 die
Daten, am wichtigsten den Sitzungs-Schlüssel, und leitet sie in verschlüsselter
Form an den Streaming-Server 5 entlang der Autorisierung
des Order-Servers, d.h. das Signatur/Authentifizierungs-Kennzeichen
des Order-Servers. Der Streaming-Server extrahiert den Ticketinhalt, überprüft eine Neuigkeit
und Autorisierung des durch den Order-Server 3 gemachten
Clients. Schließlich
beginnt der Streaming-Server damit, den verschlüsselten Strom an den Client
zu senden. Das DRM Modul 41 im Client erzeugt einen entschlüsselten
Strom, wie mit Bezug auf 1, 2 und 4 beschrieben,
welcher auf der Vorrichtung abgespielt wird. Auf halbem Wege durch
das Video, wird der Client durch ein lokales Rauschen gestört. Über RTSP "spult" der Client den Strom
ein wenig zurück
und startet den vom Streaming-Server 5 gesendeten Medienstrom
von diesem Punkt aus neu. Der Client kann es benötigen, die Steuerungs-Anfrage
mit dem Ticket, oder eine daraus hergeleitete Information, zu begleiten,
so dass der Streaming-Server
die Gültigkeit überprüfen kann.
Die RTSP Meldungen können ebenfalls
durch den Client authentifiziert werden, so dass niemand sonst eine
Steuerung über
die Ausstrahlung übernehmen
kann oder eine Verneinung des Dienstes vornehmen kann.
-
Zusätzlich kann
der Streaming-Server 5 die Transaktion der Medien mit dem
Order-Server 3 bestätigen,
so dass die Verrechnung nicht vorgenommen wird, bis die tatsächlichen
Medien zugeführt wurden.
Zusätzlich
können
Bestätigungen
der Zuführung
vom Streaming-Server zum Order-Server vor oder während der Transaktion gesendet
werden, um eine flexible Verrechnung zu erlauben, beispielsweise
proportional zur gespendeten Zeit oder zur tatsächlich zugeführten Datenmenge.
-
Obwohl
spezifische Ausführungsformen
der Erfindung hier dargestellt und beschrieben worden sind, ist
es verständlich,
dass zahlreiche zusätzliche Vorteile,
Modifikationen und Änderungen
dem Fachmann leicht einfallen werden. Daher ist die Erfindung in
ihren breitesten Aspekten nicht auf die spezifischen Details, darstellhaften
Vorrichtungen und angezeigten Beispiele, wie hier gezeigt und beschrieben,
beschränkt.