Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In der typischen Verwendung schützt Microsoft PlayReady Inhalte, indem Lizenzen für Mediendateien bereitgestellt werden. Es ist nicht erforderlich, Dateien auszublenden, sie unzugänglich zu machen oder einen speziellen Schutz zu setzen, wenn Dateien von System zu System übertragen werden. Mit anderen Worten, es sind keine Betriebssystemanforderungen oder Hochsicherheitsmechanismen für den Dateitransport erforderlich. Das Kopieren einer Datei und das Senden an einen Freund ermöglicht es diesem Freund jedoch nicht, die Datei zu verwenden, wenn sie durch PlayReady geschützt ist. Um eine Mediendatei zu verwenden, benötigen Benutzer eine Lizenz. Diese Lizenz ist die primäre Möglichkeit, die Kontrolle über Inhalte (die Mediendatei) auszuüben. Einem einzelnen Client (z. B. einem Media Player) oder einer Domäne wird eine Lizenz gewährt. Die Lizenz funktioniert nicht für andere Clients oder andere Domänen.
Jede Lizenz enthält Rechte und Einschränkungen, die genau definieren, wie der Inhalt verwendet werden kann und unter welchen Bedingungen. Eine Musikdateilizenz kann z. B. ein "Recht auf Wiedergabe" aktivieren, aber die Sicherheitsstufe der Anwendung einschränken, auf der der Inhalt wiedergegeben werden kann. Die Lizenz kann für den Zeitraum zwischen dem 1. Oktober 2017 und dem 1. November 2017 gültig sein. Möglicherweise gibt es mehrere Lizenzen für eine einzelne Datei. Ein Benutzer kann auf seine Inhalte zugreifen und sie verwenden, solange einer der Lizenzen die entsprechenden Rechte gewährt und die Einschränkungen den Zugriff nicht verhindern.
Übersicht über einen End-to-End-Videodienst
Die folgende Abbildung enthält einen allgemeinen Blick auf einen End-to-End-Videodienst, einschließlich des Backend-Diensts auf der linken Seite und Clients auf der rechten Seite.
Auf der linken Seite der Abbildung sehen Sie, dass der Dienst einige Server hat, um das Video zu streamen (Content Distribution Network). Es gibt auch einige Server, auf denen benutzer den Inhalt durchsuchen und den Inhalt auswählen können, den sie wiedergeben möchten (Benutzeroberfläche). Darüber hinaus gibt es einige Server, die es den Benutzern ermöglichen, sich anzumelden und authentifiziert zu werden, sowie inhalte zu bezahlen (authentifizieren, bezahlen). Und es gibt auch einen PlayReady License Server.
Auf der rechten Seite der Abbildung sind die Clients. Bei den Clients kann es sich um Windows-Anwendungen, Smartphone-Anwendungen oder bestimmte Geräte wie set top boxen, Netzwerkempfänger usw. handeln. Einige dieser Clients verfügen möglicherweise über einen integrierten PlayReady-Client in ihren Spielern, z. B. kann der OEM PlayReady in das Betriebssystem oder in die Hardware integriert haben. Andere könnten einen Client enthalten, der in die Anwendung integriert ist, die im App Store veröffentlicht wird. Es gibt viele verschiedene Optionen für Spieler, playReady auf der Clientseite zu integrieren.
Dieses Thema befasst sich mit der Funktionsweise von PlayReady für einen Dienst, wie in der folgenden Abbildung dargestellt.
Was PlayReady bietet, ist eine Möglichkeit für einen Client, Lizenzen von einem Server anzufordern, wodurch dann die Schlüssel bereitgestellt werden, die den Inhalt in einer geschützten Form über ein offenes Netzwerk schützen. Das zweite, was PlayReady tut, ist, dem Client Rechte und Rechtseinschränkungen zu liefern. Mit PlayReady bietet der Dienst die Möglichkeit, einen Schlüssel für die Inhaltswiedergabe bereitzustellen, aber beispielsweise nur zulassen, dass der Client diesen Schlüssel für zwei Tage in einem Mietszenario verwenden kann. Daher bietet PlayReady eine Möglichkeit, Rechte und Rechteeinschränkungen mit dem Schlüssel zu deklarieren.
PlayReady bietet außerdem eine Möglichkeit, den Inhaltsschlüssel auf der Clientseite sicherer zu speichern, sodass der Client diesen Schlüssel zur Entschlüsselung von Inhalten für die Wiedergabe verwenden kann, jedoch nicht erlaubt, Inhalte unverschlüsselt zu speichern und mit anderen Benutzern zu teilen.
Um sicherzustellen, dass sich PlayReady-Clients korrekt verhalten, erfordert PlayReady Hardware- und Softwareimplementierungen, um die Compliance- und Robustness-Regeln einzuhalten. Diese Regeln regeln, wie sich ein Client verhalten muss, wenn er PlayReady-Inhalte entschlüsselt oder verarbeitet. Sie erfordern außerdem, dass Clients die in einer Lizenz gefundenen Einschränkungen ordnungsgemäß verarbeiten. Wenn ein Client also Anweisungen erhält, den Inhaltsschlüssel nicht mehr als 48 Stunden zu verwenden, muss der Client diese Anweisungen befolgen. Diese Regeln werden von Microsoft in den Compliance- und Robustness-Regeln bereitgestellt, und es liegt an den Cliententwicklern, diese Regeln in ihren Clients zu erzwingen.
Grundlegende Verschlüsselung und Lizenzierung
Die folgenden Schritte veranschaulichen den End-to-End-Verschlüsselungs- und Lizenzierungsprozess für Inhalte und die Einbindung von PlayReady in den Prozess.
Die folgende Abbildung enthält eine Ressource – eine Audio-/Videodatei – die nicht verschlüsselt wurde. Die Methode, die zum Verschlüsseln des Inhalts verwendet wird, liegt vollständig bei dem Inhaltsanbieter und wird nicht als Teil von PlayReady bereitgestellt.
Um diese Datei zu verschlüsseln, muss der Dienst einen Schlüsselgenerator in seiner Inhaltsverschlüsselung verwenden, der einen neuen Inhaltsschlüssel generiert, der zum Verschlüsseln des Inhalts verwendet wird. Dieser Inhaltsschlüssel wird später vom PlayReady-Lizenzserver an den Client übermittelt, um die Entschlüsselung des Inhalts und das Rendering für den Benutzer zu ermöglichen. Zusammen mit dem Inhaltsschlüssel, bei dem es sich um einen privaten Wert handelt, ordnen Verschlüsselungsdienste dem Inhaltsschlüssel auch einen Schlüsselbezeichner (KeyID) zu, bei dem es sich um eine GUID handelt. Die KeyID ist ein öffentlicher Wert.
Der Schlüssel und die KeyID sind zur Verschlüsselungszeit konzipiert und werden in einem Schlüsselverwaltungssystem gespeichert, das in der Regel eine Art Datenbank ist. PlayReady stellt nicht das Schlüsselverwaltungssystem bereit. Daher liegt es an dem Dienst oder Partner, der den Dienst mit dem Sender erstellt, um das Schlüsselverwaltungssystem bereitzustellen.
Zusätzlich zum Speichern des Schlüssels und der KeyID im Schlüsselverwaltungssystem müssen Sie auch die KeyID an einen Packager anpassen, der dann einen Header generiert. Diese Kopfzeile wird vom Dienst oder Partner gemäß der PlayReady-Headerspezifikation formatiert und dann im Klarformat in den Inhaltsdateiheader integriert.
An diesem Punkt wird das Audio- und Videosignal mit der KeyID verschlüsselt, und Sie haben eine verschlüsselte Inhaltsdatei, die an einen Client übermittelt werden kann.
Jetzt kann der Client damit beginnen, den Inhalt zu verwenden. Das erste, was der Client wahrscheinlich tun wird, besteht darin, den Benutzer beim Dienst zu authentifizieren, in der Regel durch Bereitstellen eines Anmeldenamens und Kennworts, aber jeder andere Mechanismus für die Authentifizierung des Benutzers und geräts ist in Ordnung. Normalerweise wird ein Sitzungstoken nach der Überprüfung des Benutzers an den Client zurückgegeben. Beachten Sie, dass der Mechanismus zur Benutzerauthentifizierung vollständig vom Dienst bestimmt wird, also wie der Benutzer authentifiziert wird; PlayReady stellt diese Technologie nicht bereit.
Als Nächstes wird der Inhalt an den Client übermittelt (z. B. hat der Client mit dem Herunterladen eines Teils des Datenstroms begonnen, aus dem der Inhalt besteht). Der Client beginnt dann, diesen Inhalt zu analysieren und erkennt, dass er verschlüsselt ist und einen unbekannten Schlüssel verwendet, enthält jedoch eine KeyID.
An diesem Punkt sendet der Client eine Lizenzerwerbsanforderung an den Lizenzserver.
Der Lizenzserver verbindet sich dann mit dem Authentifizierungsdienst, um den Benutzer zu überprüfen. Normalerweise überprüft der Lizenzserver zunächst, ob der Client/Benutzer über das Recht für diese bestimmte Lizenz verfügt. Und auch hier stellt PlayReady dieses Layout (Authentifizierung) nicht bereit, wir stellen nur den Lizenzserver bereit. Der Authentifizierungsdienst antwortet dann in der Regel mit "Ja" oder "Nein" oder "ja" mit Einschränkungen (z. B. hat dieser Benutzer das Recht für diesen bestimmten Film, aber nur bei einer niedrigeren Videoqualität, da der Benutzer nicht über die höchste Abonnementqualität verfügt – basierend auf dem Betrag, den der Benutzer pro Monat zahlt).
Anschließend fordert der Lizenzserver den Wert des Schlüssels basierend auf der KeyID vom Schlüsselverwaltungssystem an, das die Schlüssel speichert, und das Schlüsselverwaltungssystem antwortet auf diese Anforderung. Um es noch einmal zu betonen: PlayReady liefert nicht die Komponenten des Schlüsselverwaltungssystems, daher wird eine Anforderung vom PlayReady-Lizenzserver an die vom Dienst erstellte Komponente gesendet, um die Schlüssel zu speichern.
Der Schlüssel wird vom Lizenzserver empfangen, und der Lizenzserver kann die Lizenz bereitstellen. Die geschützte PlayReady-Lizenzantwort enthält den Wert des Schlüssels und eine Liste der Rechte und Rechteeinschränkungen, die der Client erzwingen kann.
Obwohl diese Demonstration zeigt, dass der PlayReady-Lizenzserver nur einen Schlüssel liefert, ist es möglich, dass der Lizenzserver einen Stapel von Lizenzen in einer Lizenzantwort liefert. Mehrere Lizenzen können in einer Transaktion enthalten sein, wobei jede Lizenz einen Schlüssel bereitstellt, wenn der Inhalt mit mehreren Schlüsseln geschützt ist oder wenn der Dienst mehrere Schlüssel im Voraus bereitstellen möchte, da der Dienst beispielsweise weiß, dass der Benutzer acht Titel in einer Zeile abhört.
Die andere Technologie, die PlayReady bereitstellt, ist eine Möglichkeit, den Schlüssel und die Rechte im Client zu speichern, die als Lizenzspeicher bezeichnet wird.
The License Store is typically called the HDS because the structure of the License Store is a *hashed data store*. There can be multiple types of License Stores on a device — one application could contain its own HDS just to ensure that one company's HDS is not in the same file as another company's HDS. It is entirely up to the client developer to make this design choice. For example, using PlayReady on Windows, Microsoft chose to have one HDS for Internet Explorer and another for Microsoft Edge per site, as well as one for each Windows Universal App.
The HDS can be stored in a persistent way, such as on the hard drive or persistent memory of the device, or it can be stored in a non-persistent way, such as in non-persistent memory. Therefore, when the License Server issues a license, it could set a property of the license indicating that the license should not be stored on the hard drive of the client, or in the case of a set top box or phone, that it should not be stored in persistent memory because, as a service, you don't want to have your licenses stored in persistent memory. In that case, just store the HDS in memory in the context of the player application, so as soon as the user closes the player application, the license and its rights will vanish.