Inhaltsverpackung und -lieferung

Die grundlegende Funktion von PlayReady besteht darin, Inhalte vor unbefugter Verwendung zu schützen. Dazu müssen Ihre Inhalte zuerst verschlüsselt werden, und ein zugeordneter PlayReady-Header wird in den Inhalt eingefügt. Das System, das diesen Vorgang ausführt, ist der Packager, auch als Verschlüsselung bezeichnet, der manchmal in den Encoder integriert ist.

In diesem Thema werden verschiedene Möglichkeiten zum Verschlüsseln und Bereitstellen von Inhalten mithilfe von PlayReady beschrieben.

Packen von PlayReady-Inhalten – Verschlüsseln und Einfügen des DRM-Headers

Der Prozess der Verschlüsselung von klaren Inhalten besteht darin, einen oder mehrere Verschlüsselungsschlüssel zu definieren, indem sie diese Schlüssel verwenden, um die Bytes zu verschlüsseln, die den Inhalt selbst darstellen, und das Einfügen eines DRM-Headers in den Inhalt (in den Dateien des Inhalts oder im Manifest, wenn der Inhalt über einen verfügt).

Alle verschlüsselten Inhalte, die durch PlayReady geschützt sind, müssen einen PlayReady-Header in die verschlüsselte Datei eingefügt haben. Dieser PlayReady-Header wird von einem PlayReady-Client verwendet, um eine Lizenz für diesen bestimmten Inhalt zu suchen oder zu erwerben. Ein PlayReady-Header besteht aus XML, das in UTF-16 codiert ist. Es enthält die Schlüsselbezeichner (KEY Identifiers, KIDs), die zum Verschlüsseln des Inhalts verwendet werden, eine Standard-URL, die der Client zum Abrufen einer Lizenz verwendet, wenn keine andere bereitgestellt wird, und benutzerdefinierte Attribute.  

Jeder Packager, der klare Inhalte packt, muss einen PlayReady-Header-Generator implementieren, um den Header zu erstellen und in den verschlüsselten Inhalt einzubetten. Der PlayReady-Header muss gemäß der PlayReady-Headerspezifikation implementiert werden. Es gibt mehrere Möglichkeiten zum Erstellen eines PlayReady-Header-Generators in Ihrem Packager:

• Entwickeln Sie es selbst basierend auf der PlayReady-Headerspezifikation. 
• Verwenden Sie die PlayReady Server SDK-API, die einen PlayReady-Header generiert. 
• Verwenden Sie die Windows 10-API, die einen PlayReady-Header generiert. 

Ihre verschlüsselten Inhalte können mehrere DRM-Header enthalten, einschließlich PlayReady-Headern zusammen mit DRM-Headern von Drittanbietern. Weitere Informationen zur Funktionsweise finden Sie unter Verwenden von Verschlüsselungstools.

Inhaltstyp

PlayReady kann verwendet werden, um Audio- und Videoinhalte zu schützen. Die gängigsten Arten von Codierungen, die mit PlayReady verwendet werden, sind MPEG-4 AVC (H.264), High Efficiency Video Coding (HEVC) H.265-Standards und der AV1-Standard. PlayReady ist nicht auf diese Standards beschränkt und kann mit jedem Audio- und Videoformat verwendet werden, das auf dem Clientgerät unterstützt wird.

Mit PlayReady Version 1 und 2 können Sie ein geschütztes Paket erstellen, das Inhalte enthält, die nicht auf Audio- oder Videonutzlasten beschränkt sind. Diese Pakete, die als Umschläge bezeichnet werden, können Dateien wie eine Sammlung von Datendateien und ausführbaren Dateien enthalten (z. B. eine Anwendung, die von einem Anwendungsspeicher verteilt wird), Bilder (z. B. Bildschirmhintergrund) oder E-Books. Dieser Inhalt wird verpackt, indem die Dateien in eine Umschlagdatei gekapselt werden, die auf ähnliche Weise wie Audio-/Videoinhalte entschlüsselt werden kann.

Diese Nicht-Audio-/Videoinhaltstypen werden in PlayReady 3.0 und höher nicht mehr unterstützt. 

Verschlüsselungstools

Microsoft liefert keinen Packager als Teil des PlayReady-Lieferumfangs. PlayReady stellt stattdessen Spezifikationen basierend auf allgemeinen Verschlüsselungsstandards für die Verwendung durch Encoder bereit. Daher ist das Verschlüsselungsformat nicht playReady spezifisch, sondern eine Funktion des Dateiformats. Das am häufigsten verwendete Verschlüsselungsformat ist heute das Common Encryption ISO Standard Format, ISO/IEC 23001-7.

Im Grunde könnten Sie entweder einen eigenen Packager erstellen oder mit einem beliebigen Open Source-Verschlüsselungstyp (z. B. ffmpeg) arbeiten. Darüber hinaus können Sie mit einem professionellen Encoderunternehmen arbeiten, wenn Sie Inhalte mit PlayReady verschlüsseln möchten (z. B. Harmonic, Elemental, Ericsson, Wowza, Allegro).

Verwenden von Verschlüsselungstools

PlayReady unterstützt den allgemeinen ISO IEC-Verschlüsselungsstandard. Dieser Prozess ist identisch mit dem im Standardverschlüsselungs- und Lizenzierungsprozess beschriebenen Prozess, mit Ausnahme von Headern, die für andere DRMs enthalten sind – jeweils als Nutzlast des Felds "Systemspezifischer Schutzheader" ('pssh'), der von der SystemID dieses DRM identifiziert wird. Alle diese Header verfügen über eine eigene Syntax, die die KIDs oder die informationen angibt, die erforderlich sind, um letztendlich auf die Inhaltsschlüssel zuzugreifen. Und die Inhaltsschlüssel für diese Ressource werden für alle DRMs identisch sein.

Verwenden von Verschlüsselungsschlüsseln

Es gibt viele verschiedene Möglichkeiten zum Verschlüsseln Ihrer Ressourcen. Von den einfachsten bis zu den anspruchsvollsten hängt es davon ab, wie viel Komplexität Sie im System entwerfen möchten und welche Anforderungen der Dienst hat.

Nehmen wir beispielsweise eine adaptive Streamingressource, wie in der abbildung unten dargestellt. Es verfügt über vier verschiedene Videoqualitäten, einen Audiotitel und einen Untertiteltitel. Es wird in segmentierten MP4-Dateien codiert, wobei segmentierte Segmente von jeweils 2,0 Sekunden enthalten sind. Es handelt sich um eine Ressource, die in mehreren Formaten bereitgestellt wird, je nachdem, was der Client lieber wiedergeben möchte. Smooth Streaming, HLS und DASH sind die am häufigsten verwendeten Varianten. Während der Wiedergabe wird der Client (der Videoplayer) die Segmente der Ressource über das Netzwerk nacheinander herunterladen, für jede Wiedergabe des Videosegments aus der entsprechenden Videospur auswählen, um die Wiedergabequalität so hoch wie möglich zu halten, angesichts der Einschränkungen der Netzwerkbandbreite, der Wiedergabegeschwindigkeit und anderer eingeschränkter Ressourcen wie der Player-Funktionen. Diese Logik wird als adaptive Streamingwiedergabe bezeichnet, die von einigen heuristischen Regeln gesteuert wird, die im Player implementiert sind. 

Verschlüsseln der Ressource mit nur einem Schlüssel

Die einfachste Möglichkeit zum Verschlüsseln dieser Ressourcen wäre die Verwendung eines einzelnen Inhaltsschlüssels zum Verschlüsseln aller Elemente (in der Regel sind Untertitel nicht verschlüsselt – es ist nicht gegen eine Regel, aber sie werden in der Regel klar gehalten). Die Verwendung eines Inhaltsschlüssels erleichtert den Lizenzserver, da der Lizenzserver einen Schlüssel {KID, CK} bereitstellen muss. Dieser Schlüssel würde in der Regel vom Client abgerufen, bevor die Wiedergabe erfolgt ist.

Verschlüsseln des Vermögenswertes mit zwei Schlüsseln, wobei einer der höchsten Qualität gewidmet ist.

In den letzten Jahren wurden einige Verbesserungen vorgenommen, um mehrere Schlüssel pro Asset zu verwenden, wobei das Hauptrationale darin besteht, nur hochrobusten Clients den Zugriff auf hochwertigen Inhalt zu ermöglichen. Mit der Ankunft von Ultra HD (4K)-Inhalten und mit dem Hinzufügen von HIGH Dynamic Range (HDR) für höhere Farbinhalte gab es eine Notwendigkeit von Studios und Diensten, die höchste Qualität nur auf bestimmten Clients zu ermöglichen, die in der Regel Hardware-DRM integriert haben. In diesem Szenario wird die Ressource mit einem Inhaltsschlüssel {kid1, ck1} für alle Titel verschlüsselt, mit Ausnahme des 4K-Titels, der mit einem anderen Inhaltsschlüssel {kid2, ck2} verschlüsselt ist. Dies bedeutet:

• Einem Client, der nur die Möglichkeit hat, bis zu Full HD wiederzugeben (nicht die 4K-Spur), wird eine PlayReady-Lizenz geliefert, die nur {kid1, ck1} enthält. 
• Einem Client, der die Möglichkeit hat, bis zu 4K wiederzugeben, wird eine PlayReady-Lizenz geliefert, die {kid1, ck1} und {kid2, ck2} enthält.

Mit dieser zusätzlichen Komplexität kann der Dienst sicherstellen, dass einige Clients die 4K-Spur nicht entschlüsseln können, und dass die 4K-Spur nur den Clients vorbehalten bleibt, denen der Dienst am meisten vertraut. 

Verschlüsseln der Ressource mit einem Schlüssel pro Track

Der Dienst verfügt möglicherweise über eine komplexere Zuordnung von Rechten zum Erzwingen. Einige Clients können je nach Bildschirmgröße, Robustität, Ausgabe und Position möglicherweise nur auf einige Videospuren, einige Videoqualitäten und einige Audiospuren zugreifen. Um sicherzustellen, dass der Dienst in Zukunft beliebige Einschränkungen erzwingen kann, kann er ein Asset mit einem für jede Spur spezifischen Inhaltsschlüssel verschlüsseln. Zum Beispiel:

• Ein Client, dem nur die Wiedergabe von 720p erlaubt ist, erhält eine PlayReady-Lizenz, die {kid1, ck1}, {kid2, ck2} und {kidA, ckA} umfasst. 
• Ein Client, der 4K-Inhalte wiedergeben darf, wird eine PlayReady-Lizenz erhalten, einschließlich {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4} und {kidA, ckA}. 
• Ein Client, der die zuvor heruntergeladene 4K-Version der Ressource offline abspielt, wird eine PlayReady-Lizenz erhalten, die {kid4, ck4} und {kidA, ckA} umfasst. 

Regelmäßiges Ändern der Verschlüsselungsschlüssel (Ressource mit mehreren Perioden) – Lizenzrotation

In einigen Szenarien möchte der Dienst die Verschlüsselungsschlüssel gelegentlich ändern, in der Regel an Programmgrenzen. Beispielsweise verfügt ein linearer Livestream über mehrere Perioden mit frei empfangbaren Inhalten, auf die jeder Zugriff haben kann, anschließend gefolgt von einigen Inhalten, die auf Abonnenten beschränkt sind. Durch das Ändern der Verschlüsselungsschlüssel an Programmgrenzen kann der Dienst die kostenlosen Air Keys {KIDi1, CKi1} für alle Benutzer ohne Einschränkungen bereitstellen und die Inhaltsschlüssel {kidi2, cki2} nur an die Abonnenten übermitteln, die sich erfolgreich beim Dienst angemeldet haben.

Beachten Sie, dass diese Lizenzrotation nicht sehr skalierbar ist: Jedes Mal, wenn sich die Verschlüsselungsschlüssel ändern, fordern alle Clients die neuen Verschlüsselungsschlüssel mithilfe ihrer eigenen Lizenzanforderung an. Dies kann zu einem hohen Höchstwert von Lizenzanforderungen in Systemen mit einer großen Anzahl von Clients führen. 

Häufiges Ändern der Verschlüsselungsschlüssel – skalierbare Schlüsseldrehung

Es gibt einen erweiterten Mechanismus in PlayReady, der als skalierbare Schlüsseldrehung (im Gegensatz zur Lizenzrotation) bezeichnet wird. Diese Methode speichert einen eingebetteten Lizenzspeicher (ELS) im Datenstrom des tatsächlichen Inhalts. In diesem Mechanismus wird der Schlüssel, der zum Verschlüsseln des A2-Segments selbst verwendet wird, als Blattschlüssel {kidA2, ckA2} bezeichnet und in der ELS des Segments A2 bereitgestellt, wobei er selbst mit einem separaten Schlüssel verschlüsselt wird, der für alle Segmente von Track A identisch ist, der als Stammschlüssel {kidRA, ckRA} bezeichnet wird. Wenn Sie mit MPEG-2 TS und der Control Word-Verschlüsselung vertraut sind, ist dies ein ähnlicher Mechanismus, außer dass die Verschlüsselung viel stärker ist und auch flexibler ist.

Angenommen, diese Ressource ist live lineare TV. Wenn der Client die Wiedergabe versucht, findet er kidRA im PlayReady-Header des Streammanifests und fordert eine Lizenz für kidRA an. Der Lizenzserver gibt eine Stammlizenz für den Stammschlüssel {kidRA, ckRA} zurück. Anschließend analysiert der Client segment A1 und ermittelt den ELS in der Kopfzeile des Segments. Beim Parsen dieser ELS findet er die Leaf-Lizenz {kidA1, ckA1} in dieser ELS. Mit dem Stammschlüssel {kidRA, ckRA} und der Blattlizenz {kidA1, ckA1} kann der Wert von ckA1 abgerufen und das Segment A1 entschlüsselt und gerendert werden. 

Das skalierbare PlayReady-Schlüsseldrehungsfeature ist äußerst flexibel, da Clients nicht jedes Mal, wenn die Verschlüsselungsschlüssel geändert werden, den Lizenzserver kontaktieren müssen. Das Volumen der Lizenzanforderungen bleibt so gering wie möglich, da ein Client nur eine Stammlizenz vom Lizenzserver pro Stream oder Track benötigt. Es ermöglicht Verschlüsselungsschlüsseln, so häufig wie jedes Segment zu drehen, in der Regel alle zwei Sekunden, falls erforderlich. 

Siehe auch

Schlüssel und Schlüssel-IDs (KIDs)