Inhaltsverpackung und Lieferung
Die grundlegende Funktion von PlayReady besteht darin, Inhalte vor nicht autorisierter Verwendung zu schützen. Dazu müssen Ihre Inhalte zuerst verschlüsselt sein, und ein zugeordneter PlayReady-Header wird in den Inhalt eingefügt. Das System, das diesen Vorgang ausführt, ist der Packager, der auch als Verschlüsselung bezeichnet wird, 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.
Verpacken von PlayReady-Inhalten – Verschlüsseln und Einfügen des DRM-Headers
Der Prozess der Verschlüsselung eindeutiger Inhalte besteht darin, einen oder mehrere Verschlüsselungsschlüssel zu definieren, indem diese Schlüssel verwendet werden, 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 von 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, die in UTF-16 codiert ist. Es enthält die Schlüsselbezeichner (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 Paketgeber, der inhalte löscht, 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 dazu, wie dies funktioniert, finden Sie unter Verwenden von Verschlüsselungstools.
Inhaltstyp
PlayReady kann verwendet werden, um Audio- und Videoinhalte zu schützen. Die am häufigsten verwendeten Codierungstypen mit PlayReady 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 eine Weise entschlüsselt werden kann, die dem Audio-/Videoinhalt ähnelt.
Diese Nicht-Audio-/Videoinhaltstypen werden in PlayReady 3.0 und höher nicht mehr unterstützt.
Verschlüsselungstools
Microsoft enthält keinen Packager als Teil der PlayReady-Lieferumfang. PlayReady bietet stattdessen Spezifikationen basierend auf allgemeinen Verschlüsselungsstandards für die Verwendung durch Encoder. Daher ist das Verschlüsselungsformat nicht playReady spezifisch, sondern eine Funktion des Dateiformats. Das am häufigsten verwendete Verschlüsselungsformat ist heute das Standardformat "Common Encryption ISO Standard", ISO/IEC 23001-7.
Im Grunde können Sie entweder einen eigenen Packager erstellen oder mit jedem Typ von Open Source Verschlüsseln (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). Azure Media Services bietet auch eine Verpackungsfunktionalität für klare Inhalte.
Verwenden von Verschlüsselungstools
PlayReady unterstützt den allgemeinen ISO IEC-Verschlüsselungsstandard. Dieser Prozess ist identisch wie im Standardverschlüsselungs- und Lizenzierungsprozess beschrieben, mit Ausnahme von Headern für andere DRMs – jeweils als Nutzlast des Felds "Schutzsystemspezifischer Header "pssh", das von der SystemID des DRM identifiziert wird. Alle diese Header verfügen über eine eigene Syntax, die die KIDs oder die informationen bestimmt, die für den letztendlichen Zugriff auf die Inhaltsschlüssel erforderlich sind. Und die Inhaltsschlüssel für dieses Objekt werden für alle DRMs identisch sein.
Verwenden von Verschlüsselungsschlüsseln
Es gibt viele verschiedene Möglichkeiten zum Verschlüsseln Ihrer Ressourcen. Der einfachste der anspruchsvollsten ist, hängt davon ab, wie viel Komplexität Sie im System entwerfen möchten und welche Anforderungen der Dienst erfüllt sind.
Nehmen wir uns beispielsweise ein adaptives Streaming-Objekt an, 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 Segmente jeweils 2,0 Sekunden betragen. 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 des Asset über das Netzwerk aufeinanderfolgende herunterladen, die Auswahl für jede Wiedergabezeit des Videosegments aus der entsprechenden Videospur, 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 den Playerfunktionen. Diese Logik wird als adaptive Streamingwiedergabe bezeichnet, die von einigen heuristischen Regeln gesteuert wird, die im Player implementiert wurden.
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 jede Regel, aber sie werden normalerweise im Klaren gehalten). Die Verwendung eines Inhaltsschlüssels erleichtert das Leben für 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 aufgetreten ist.
Hinweis
PlayReady-Clients können Lizenzen proaktiv oder reaktiv erwerben. Eine Beschreibung dieser beiden Modi finden Sie auf der Seite " Lizenzakquisition ".
Verschlüsseln der Ressource mit zwei Schlüsseln, Dedidieren eines der höchsten Qualität
In den vergangenen Jahren gab es einige Verbesserungen, um mehrere Schlüssel pro Asset zu verwenden, hauptsächlich durch die Anforderung, nur bestimmte höchste Zuverlässigkeitsclients zu ermöglichen, die höchste Qualität zu nutzen. 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 normalerweise Hardware-DRM integriert haben. In diesem Szenario wird das Objekt mit einem Inhaltsschlüssel {kid1, ck1} für alle Titel verschlüsselt, mit Ausnahme der 4K-Spur, die mit einem anderen Inhaltsschlüssel {kid2, ck2} verschlüsselt ist. Dies bedeutet:
- Ein Client, der nur bis full HD wiedergeben darf (nicht der 4K-Titel), wird eine PlayReady-Lizenz einschließlich nur {kid1, ck1} übermittelt.
- Ein Client, der bis zu 4K spielen darf, wird eine PlayReady-Lizenz einschließlich {kid1, ck1} und {kid2, ck2} übermittelt.
Mithilfe 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 für die Clients reserviert werden kann, denen der Dienst am meisten vertraut.
Verschlüsseln der Ressource mit einem Schlüssel pro Titel
Der Dienst verfügt möglicherweise über eine komplexere Zuordnung von Rechten, die erzwungen werden sollen. Einige Clients können je nach Bildschirmgröße, ihrer Robustität, ihren Ausgaben und ihrer Position möglicherweise nur auf einige Videotitel, einige Videoqualitäten und einige Audiospuren zugreifen. Um sicherzustellen, dass der Dienst volle Flexibilität beim Erzwingen einer beliebigen Gruppe von Einschränkungen in der Zukunft hat, kann es ein Objekt mit einem Inhaltsschlüssel verschlüsseln, der für jeden Titel spezifisch ist. Zum Beispiel:
- Ein Client, der nur 720p spielen darf, wird eine PlayReady-Lizenz einschließlich {kid1, ck1}, {kid2, ck2} und {kidA, ckA} übermittelt.
- Ein Client, der bis zu 4K spielen darf, wird eine PlayReady-Lizenz einschließlich {kid1, ck1}, {kid2, ck2}, {kid3, ck3}, {kid4, ck4} und {kidA, ckA} übermittelt.
- Ein Client, der offline die 4K-Version des Objekts (zuvor heruntergeladen) spielt, wird eine PlayReady-Lizenz einschließlich {kid4, ck4} und {kidA, ckA} übermittelt.
Regelmäßiges Ändern der Verschlüsselungsschlüssel (Multi-Period Asset) – Lizenzdrehung
In einigen Szenarien möchte der Dienst die Verschlüsselungsschlüssel gelegentlich ändern, in der Regel an Programmgrenzen. Ein linearer Livestream verfügt z. B. über mehrere Zeiträume mit kostenlosen Luftinhalten, auf die jeder Zugriff haben soll, 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 Lizenzdrehung 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 Spitzenwert 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 namens skalierbarer Schlüsseldrehung (im Gegensatz zur Lizenzdrehung). Diese Methode speichert eine eingebettete Lizenz Store (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 den ELS des Segmentes 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 Steuerelement-Word-Verschlüsselung vertraut sind, ist dies ein ähnlicher Mechanismus mit Ausnahme der Verschlüsselung viel stärker und ist auch flexibler.
Sagen wir, 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 die ELS im Header des Segments. Diese ELS analysiert, findet sie die Blattlizenz {kidA1, ckA1} in dieser ELS. Mit dem Stammschlüssel {kidRA, ckRA} und der Blattlizenz {kidA1, ckA1}, kann er den Wert von ckA1 abrufen und das Segment A1 entschlüsseln und rendern.
Das skalierbare PlayReady-Schlüsseldrehungsfeature ist extrem skalierbar, da clients nicht jedes Mal, wenn die Verschlüsselungsschlüssel geändert werden, nicht an den Lizenzserver wenden müssen. Es hält das Volumen der Lizenzanforderungen am niedrigsten, da ein Client nur eine Stammlizenz vom Lizenzserver pro Stream benötigt oder nachverfolgt. Es ermöglicht Verschlüsselungsschlüsseln, so häufig wie jedes Segment zu drehen, in der Regel alle zwei Sekunden, falls erforderlich.
